From kamilion at gmail.com Sat Sep 1 00:09:46 2007 From: kamilion at gmail.com (Kamilion) Date: Sat Sep 1 00:09:50 2007 Subject: [sldev] Re: [svc] Back end features (was: New viewer released) In-Reply-To: <200708312142.23728.dale@daleglass.net> References: <200708310423.22452.dale@daleglass.net> <200708312014.44606.dale@daleglass.net> <46D86861.4070400@lindenlab.com> <200708312142.23728.dale@daleglass.net> Message-ID: On 8/31/07, Dale Glass wrote: > Viewer uses handles a lot, for example object updates are sent with a handle > and not a region key. Not sure why, compactness maybe? Though why use a 64 > bit number to keep 16 bits of data? While I expect SL will grow beyond 64K > sims some day, more than 2^32 is something I don't think will happen any time > soon. > Consider that the server/grid source will eventually make it out into the community. What, then, is stopping someone from running 128 simulators in xen containers next year? What's stopping people from having and using massive private regions? What's stopping devices from containing a management region in them? Picture a 2010 router with an internal simulator with all of a modern-day's router pages each on a GeckoRenderPrim... With 2GB of SD flash memory going for $20 today [1], it won't be odd to see larger flash devices built into devices in the future, and total CPU power is slowly increasing even in portable devices. More and more portable devices will soon be multicore themselves, and power management becomes much easier when you can control the speed or state of individual cores, instead of scaling a single core. The PSP already demonstrates this with it's main 333Mhz R4000 CPU and a secondary 333Mhz R4000 CPU with a different subdevice layout in the Media Engine. The bus speed and core speed can be modified on the fly. A lot of PSP software currently available, both homebrew and commercial, doesn't make use of both cores. The homebrew developers are currently working on innovative and creative uses of the second core, StrmnNrmn's Daedalus [2] Nintendo64 emulator is a good example. It uses the second core for dynamic recompilation of the n64's R4300, and the RCP R4000-based coprocessor opcodes. Now picture a network of networks full of these devices and many more like them. Picture a smart harddrive that could expose 'folders' as simulators full of objects. What's to stop a simulator from becoming the next Window Manager for X? There's many things you can do once you have access to the backend. It's like the difference between using Geocities Pagebuilder [3] in 1995 exclusively for all your website needs, and developing a current Ruby on Rails or PHP web application today. This is, of course, assuming the grid doesn't fragment, or use a link/portal-system to 'exit' to private simulators like Snow Crash alluded to. (The metaverse club, The Black Sun is a example of such a system, placing the exterior of the building on the 'public' grid with the doorway as a portal to a private grid.) The other thing is, Eventually, the grid is going to require simulator X, Y, AND Z coordinates. Currently, as far as I know, only X and Y are used. Lindens, when you have a chance and feel like puttering around, add a Z value to the region coordinates, and populate all the current regions with a sane default value (DON'T FORGET SUBTERRANEAN REGIONS! If you decide to use unsigned values, make sure it's a non-zero default value!) [1] http://www.circuitcity.com/ccd/productDetail.do?oid=134292&WT.mc_n=67&WT.mc_t=U&cm_ven=COMPARISON%20SHOPPING&cm_cat=PRICEGRABBER&cm_pla=DATAFEED-%3EPRODUCTS&cm_ite=1%20PRODUCT&cm_keycode=67 [2] http://strmnnrmn.blogspot.com/ [3] The old geocities page creator from this era was widely known as one of the absolute worst pieces of crap ever written, garnering geocities the nick name 'geoshitties'. One of the poorest examples of WYSIWYG, and was limited to generating horrible looking pages. Then again, browsers weren't very advanced then, eh? Let's try not to be known like that in 2020 ;) From kamilion at gmail.com Sat Sep 1 01:09:54 2007 From: kamilion at gmail.com (Kamilion) Date: Sat Sep 1 01:09:58 2007 Subject: [sldev] Re: OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <46D5A7A3.2010604@lindenlab.com> References: <20070829105027.3308941B233@stupor.lindenlab.com> <51EF5462-5ED2-4423-974B-5BDC03EB045A@gmail.com> <20070829113449.GD29798@bruno.sbruno> <69E7BB34-7D27-4208-80C5-5483CE88457A@gmail.com> <20070829153559.GF29798@bruno.sbruno> <46D59CF6.9070700@lindenlab.com> <20070829165220.GH29798@bruno.sbruno> <46D5A7A3.2010604@lindenlab.com> Message-ID: On 8/29/07, Kelly Linden wrote: > * Forced chat join. When anyone sends an IM to a group in SL it forces > every member to join the chat. I would rather specifically choose which > chats to join and when, and only receive the messages for those chats I > already have open. > > Well, that seems to be like something that's quite fixed in the viewer > > This is actually a complex system on the server end. Changing this to be > more IRC like would actually reduce complexity of the group IM system a fair > amount .... until someone says 'make it an option'. As far as I know we are > the only chat system (in any game, irc or other chat system) that behaves > this way. > One simple little fix that I'd like to see would be a simple checkbox to NOT print group IMs to the fade-out variable-size chatbox (When communicate is closed) -- This is my current #1 peeve with the Group IM system. I don't mind it filling up the log inside the chat WINDOW and highlighting that tab's name, but it's just downright annoying when I'm working on something but I still want to read the conversation happening in Scripters Of Second Life group so I can't leave the conversation, but I still get spammed through the fadebox. Currently, it seems like no matter what, it's printed to the screen when it arrives, message by message, without even an indication of what group the message is from, other than opening up the IM window and checking which tab highlighted. From seg at haxxed.com Sat Sep 1 01:43:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 1 01:43:28 2007 Subject: [sldev] Re: [svc] Back end features (was: New viewer released) In-Reply-To: References: <200708310423.22452.dale@daleglass.net> <200708312014.44606.dale@daleglass.net> <46D86861.4070400@lindenlab.com> <200708312142.23728.dale@daleglass.net> Message-ID: <1188636216.28015.14.camel@localhost> On Sat, 2007-09-01 at 00:09 -0700, Kamilion wrote: > The other thing is, Eventually, the grid is going to require simulator > X, Y, AND Z coordinates. Currently, as far as I know, only X and Y are > used. The whole "grid" thing is a rather un-necessary forcing of real world limitations onto a virtual world. Simulators should be able to "shape" themselves any way they like, and link to each other through a web of portals, negotiated between the simulators themselves with no centralized control required or desired. We could call it... the world wide web! Parcels designed as a starting point to finding places of interest could be called "portal sites"! People could order pet supplies online and have then delivered to their home! This is going to be big! oh god am I sleep deprived zzzzzzzzzzzzzzz... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070901/37bc01c8/attachment.pgp From kamilion at gmail.com Sat Sep 1 04:57:47 2007 From: kamilion at gmail.com (Kamilion) Date: Sat Sep 1 04:57:51 2007 Subject: [sldev] Re: [svc] Back end features (was: New viewer released) In-Reply-To: <1188636216.28015.14.camel@localhost> References: <200708310423.22452.dale@daleglass.net> <200708312014.44606.dale@daleglass.net> <46D86861.4070400@lindenlab.com> <200708312142.23728.dale@daleglass.net> <1188636216.28015.14.camel@localhost> Message-ID: On 9/1/07, Callum Lerwick wrote: > On Sat, 2007-09-01 at 00:09 -0700, Kamilion wrote: > > The other thing is, Eventually, the grid is going to require simulator > > X, Y, AND Z coordinates. Currently, as far as I know, only X and Y are > > used. > > The whole "grid" thing is a rather un-necessary forcing of real world > limitations onto a virtual world. Simulators should be able to "shape" > themselves any way they like, and link to each other through a web of > portals, negotiated between the simulators themselves with no > centralized control required or desired. We could call it... the world > wide web! Parcels designed as a starting point to finding places of > interest could be called "portal sites"! People could order pet supplies > online and have then delivered to their home! This is going to be big! > > oh god am I sleep deprived zzzzzzzzzzzzzzz... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > *falls out of his chair laughing* .... Yeeeaaaaah. I'm thinking I'm in sleepdep too. Better turn in. Sleep well, World Wide Web. From seg at haxxed.com Sat Sep 1 10:08:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 1 10:08:45 2007 Subject: [sldev] Re: OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: References: <20070829105027.3308941B233@stupor.lindenlab.com> <51EF5462-5ED2-4423-974B-5BDC03EB045A@gmail.com> <20070829113449.GD29798@bruno.sbruno> <69E7BB34-7D27-4208-80C5-5483CE88457A@gmail.com> <20070829153559.GF29798@bruno.sbruno> <46D59CF6.9070700@lindenlab.com> <20070829165220.GH29798@bruno.sbruno> <46D5A7A3.2010604@lindenlab.com> Message-ID: <1188666536.28705.2.camel@localhost> On Sat, 2007-09-01 at 01:09 -0700, Kamilion wrote: > One simple little fix that I'd like to see would be a simple checkbox > to NOT print group IMs to the fade-out variable-size chatbox (When > communicate is closed) -- This is my current #1 peeve with the Group > IM system. Yes this is the most irritating and useless things ever, and the first thing I was going to patch when the source was released. I'm just now realizing... I haven't done it yet. Hmmm. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070901/e0dba8e1/attachment.pgp From tao.takashi at googlemail.com Sat Sep 1 10:29:29 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sat Sep 1 10:29:32 2007 Subject: [sldev] Re: [svc] Back end features In-Reply-To: <46D87B6F.6050303@lindenlab.com> References: <200708310423.22452.dale@daleglass.net> <200708312014.44606.dale@daleglass.net> <46D86861.4070400@lindenlab.com> <200708312142.23728.dale@daleglass.net> <46D87B6F.6050303@lindenlab.com> Message-ID: <23bbb49e0709011029t3a4afa71r1ba2b082f63c90c@mail.gmail.com> 2007/8/31, Ryan Williams : > > Dale Glass wrote: > >> So, anyway, the immediate use case suggests a larger use case, and it's > >> important to implement the former in terms of the latter. > >> > > If thinking long term, something to consider would be doing a general > sim > > information request instead. If people are going to have bots running > through > > the whole grid to collect data, might as well let them have it directly > and > > reduce the grid load a bit. > > > Totally. I believe that one challenge with such a request is that the > set of information you can see varies based on you role relative to the > region. So, maybe there could be a public-info request that has only > the totally public data, which would presumably include the varying > names. Actually, it'd be interesting to compile a list of what > information is already public about a region, that would remove an > additional step in the implementation of a 'public-region-info' API. A web service for this would be a great help for many things IMHO. Like requesting parcel data from a region might be very useful. Of course this needs to take into account whether a sim is public or not and what permissions you have there actually. As for object information I guess this would be more complicated but still it would be handy so have some API for requestion info about objects on a sim or maybe queried on a different set of variables. This would make external search engines more easily possible. Issues here are of course how to opt-out etc. But even this could be more easily solved by Linden Lab than by any 3rd party which scans the grid via bots. -- Tao PS: And I still would like a web service for uploading new assets to my account like textures or sounds :-) -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070901/efc7833a/attachment-0001.htm From seg at haxxed.com Sat Sep 1 10:32:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 1 10:32:30 2007 Subject: [sldev] Improving the avatar in SL: hair... In-Reply-To: References: Message-ID: <1188667959.28705.15.camel@localhost> On Mon, 2007-08-27 at 07:55 +0000, Matthew Dowd wrote: > > In theory you could just allow people to write shaders in GLSL. I'm not > > up on the spec but seems to me that should be safe, the worst people > > could do is maybe lock up the video card, and I would hope that would > > only be because of bugs in the GL driver's compiler. > > You are basically writing machine code to run on the GPU - there's limited checking even a perfect/bug free driver could do. Well, you're not. You're programming in GLSL, a fairly limited language, for a fairly limited architecture. You don't get things such as pointers to cause trouble with, for example. The worst you could do is maybe infinite loops, which could be dealt with. Though I'm sure someone will figure out something. An unprivileged user space program with the ability to lock up the hardware is a major security failure any way you slice it. It should not be possible. If it is, oh boy, the vulnerable video cards are going to find themselves blacklisted by systems administrators worldwide until they fix it. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070901/6817f0e2/attachment.pgp From lenglish5 at cox.net Sat Sep 1 10:37:24 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 1 10:37:26 2007 Subject: [sldev] GUI class programming Message-ID: <46D9A354.6070504@cox.net> Hi all, I'm trying to add a "simple" bit of functionality to the LSL edit window. At least, on paper it is simple, but after spending several days delving into the depths of the LL classes, I'm feeling less than confidant that I can do this project nearly as fast as I expected (a diagram of the function of my floater is found at the bottom of this too-long article). My plan: create a simple folder/outline hierarchy of categories of LSL keywords using a nested-folder paradigm, but instead of displaying items in the same list as the folders, use them as buttons to display progressively more focused (and therefore smaller) lists. The sub-categories and sub-sub-categories, etc., are based on the categories used by the LSL wiki and the whole thing will be found in a floater window that resizes itself from barely large enough to hold the top three categories, to large enough to hold the expanded categories and a scrolling list (and an optional prototype). It is meant as a replacement for the drop-down combo box labeled "Insert..." found at the bottom of each LS editor window, and (in the simplest form) will simply paste either the keyword or the keyword + prototype into the current selection of the LSL editor in the same manner the Insert... combo box does. My plan was to use the existing classes that handle folders ala the inventory and other hierarchical lists in the SL viewer, and override the appropriate methods to display the list to the side rather than underneath. Then I discovered llInventoryPanel... It feels like someone was feeling up to a challenge to merge at least two levels of classes into one. In my mind there is at least one class missing between LLPanel and LLInventoryPanel. Or, to put it differently, the durned thing is so complicated that I think it will be easier to fake a static hierarchical list using simple scrolling lists and icons modified on the fly, then to use the LLInventoryPanel for something far simpler than it was designed for. I'd rather not reinvent the wheel, but given a choice between fitting a racing car wheel on a haywagon, or building my own, I may have no choice. Has anyone used LLInventoryPanel for providing a simple "outline view" in the client? Any pointers to code or other suggestions? I've looked at all the classes that use it, but they are so tied in with the LL data types that its hard to see how to simplify things. Should I just fake my own using other classes given that this is a static hierarchy or is there a simple example of how to do what I want using the existing classes that I have missed, or is there some "key" to understanding the class that will make it all fall into place? Thanks in advance, Lawson English [Floater Keywords] >Functions No list >Events >Constants \/Functions Huge list >Sub_cat1 >Sub_cat2 >Sub_cat3 >Events >Constants \/Functions Smaller list \/Sub_cat1 >Sub_Sub_cat1 >Sub_Sub_cat2 >Sub_Sub_cat3 >Sub_cat2 >Sub_cat3 >Events >Constants From dzonatas at dzonux.net Sat Sep 1 10:43:28 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 1 10:43:14 2007 Subject: [sldev] Re: OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <1188666536.28705.2.camel@localhost> References: <20070829105027.3308941B233@stupor.lindenlab.com> <51EF5462-5ED2-4423-974B-5BDC03EB045A@gmail.com> <20070829113449.GD29798@bruno.sbruno> <69E7BB34-7D27-4208-80C5-5483CE88457A@gmail.com> <20070829153559.GF29798@bruno.sbruno> <46D59CF6.9070700@lindenlab.com> <20070829165220.GH29798@bruno.sbruno> <46D5A7A3.2010604@lindenlab.com> <1188666536.28705.2.camel@localhost> Message-ID: <46D9A4C0.4080007@dzonux.net> Callum Lerwick wrote: > On Sat, 2007-09-01 at 01:09 -0700, Kamilion wrote: > >> One simple little fix that I'd like to see would be a simple checkbox >> to NOT print group IMs to the fade-out variable-size chatbox (When >> communicate is closed) -- This is my current #1 peeve with the Group >> IM system. >> > > Yes this is the most irritating and useless things ever, and the first > thing I was going to patch when the source was released. I'm just now > realizing... I haven't done it yet. Hmmm. :) > This was easily done by minimizing the tear-off group IM window. That minimize box is one feature that keeps appearing and disappearing through releases, so yeah maybe a secondary checkbox will help. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070901/03bdf80e/attachment.htm From secret.argent at gmail.com Sat Sep 1 11:02:31 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 1 11:02:19 2007 Subject: [sldev] Re: [svc] Back end features (was: New viewer released) (Callum Lerwick) In-Reply-To: <20070901172932.B887D41B00E@stupor.lindenlab.com> References: <20070901172932.B887D41B00E@stupor.lindenlab.com> Message-ID: <77DC36D8-66AC-4078-9F6A-C05759EA2B6C@gmail.com> > The whole "grid" thing is a rather un-necessary forcing of real world > limitations onto a virtual world. Simulators should be able to "shape" > themselves any way they like, and link to each other through a web of > portals, negotiated between the simulators themselves with no > centralized control required or desired. First, the decision to make the grid geographical was a deliberate and cultural choice. It's unusual... most virtual worlds have been linked the way you describe... but it's unlikely to be changed. Creating non-euclidean connectivity within the grid is hard, and tools to make it easier (like llTeleportAgent) have been repeatedly deferred. Second, there's a lot of other ways SL forces real-world limitations onto a virtual world. Making avatars significantly larger or smaller than the normal human range is difficult, and non-humanoid avatars require all kinds of tricks. These all seem to have come out of the influence of the book _Snow Crash_ on the principle designers of SL. From lenglish5 at cox.net Sat Sep 1 11:05:34 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 1 11:05:36 2007 Subject: [sldev] Re: [svc] Back end features In-Reply-To: <77DC36D8-66AC-4078-9F6A-C05759EA2B6C@gmail.com> References: <20070901172932.B887D41B00E@stupor.lindenlab.com> <77DC36D8-66AC-4078-9F6A-C05759EA2B6C@gmail.com> Message-ID: <46D9A9EE.3060800@cox.net> Argent Stonecutter wrote: >> The whole "grid" thing is a rather un-necessary forcing of real world >> limitations onto a virtual world. Simulators should be able to "shape" >> themselves any way they like, and link to each other through a web of >> portals, negotiated between the simulators themselves with no >> centralized control required or desired. > > First, the decision to make the grid geographical was a deliberate and > cultural choice. It's unusual... most virtual worlds have been linked > the way you describe... but it's unlikely to be changed. Creating > non-euclidean connectivity within the grid is hard, and tools to make > it easier (like llTeleportAgent) have been repeatedly deferred. > > Second, there's a lot of other ways SL forces real-world limitations > onto a virtual world. Making avatars significantly larger or smaller > than the normal human range is difficult, and non-humanoid avatars > require all kinds of tricks. > > These all seem to have come out of the influence of the book _Snow > Crash_ on the principle designers of SL. Not to mention constraints having to do with the interaction of Havok physics and the underlying data-structures of SL, which may or may not go back to your point about design philosophy. From damianpoirier at hotmail.com Sat Sep 1 11:12:08 2007 From: damianpoirier at hotmail.com (Damian Poirier) Date: Sat Sep 1 11:12:13 2007 Subject: [sldev] how do I reply to list instead of individual Message-ID: how do I reply to the list group instead of individual? I use hotmail. Any suggestions? _________________________________________________________________ Kick back and relax with hot games and cool activities at the Messenger Café. http://www.cafemessenger.com?ocid=TXT_TAGHM_SeptHMtagline1 From seg at haxxed.com Sat Sep 1 11:18:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 1 11:18:02 2007 Subject: [sldev] Re: [svc] Back end features (was: New viewer released) (Callum Lerwick) In-Reply-To: <77DC36D8-66AC-4078-9F6A-C05759EA2B6C@gmail.com> References: <20070901172932.B887D41B00E@stupor.lindenlab.com> <77DC36D8-66AC-4078-9F6A-C05759EA2B6C@gmail.com> Message-ID: <1188670693.28705.29.camel@localhost> On Sat, 2007-09-01 at 13:02 -0500, Argent Stonecutter wrote: > > The whole "grid" thing is a rather un-necessary forcing of real world > > limitations onto a virtual world. Simulators should be able to "shape" > > themselves any way they like, and link to each other through a web of > > portals, negotiated between the simulators themselves with no > > centralized control required or desired. > > First, the decision to make the grid geographical was a deliberate > and cultural choice. It's unusual... most virtual worlds have been > linked the way you describe... but it's unlikely to be changed. > Creating non-euclidean connectivity within the grid is hard, and > tools to make it easier (like llTeleportAgent) have been repeatedly > deferred. For the record this is how I expect the future non-LL non-grid to function, I have no expectation or desire of LL implementing things this way, ever. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070901/0beea016/attachment.pgp From aspen.grey at greydawning.net Sat Sep 1 10:26:23 2007 From: aspen.grey at greydawning.net (Aspen d'Grey) Date: Sat Sep 1 11:26:28 2007 Subject: [sldev] how do I reply to list instead of individual In-Reply-To: References: Message-ID: Hit Reply All. On Sat, 01 Sep 2007 12:12:08 -0600, Damian Poirier wrote: > how do I reply to the list group instead of individual? > > I use hotmail. Any suggestions? > > _________________________________________________________________ > Kick back and relax with hot games and cool activities at the Messenger > Caf?. http://www.cafemessenger.com?ocid=TXT_TAGHM_SeptHMtagline1 > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Aspen d'Grey Lead Architect Line Through the World Architecture, Second Life From secret.argent at gmail.com Sat Sep 1 12:16:57 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 1 12:16:46 2007 Subject: [sldev] [VIEWER] Re: OS-SL Development Issues In-Reply-To: <20070901190009.8E2DE41B089@stupor.lindenlab.com> References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> Message-ID: Dzonatas writes: > This was easily done by minimizing the tear-off group IM window. That > minimize box is one feature that keeps appearing and disappearing > through releases, so yeah maybe a secondary checkbox will help. Unfortunately minimized windows block the most recent line of chat. :) Hmm... how about a patch to make the minimized windows minimize to a different corner of the screen, or even title/menu bar icons? The current location is pretty much the worst possible place. From dale at daleglass.net Sat Sep 1 17:11:22 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 1 17:11:36 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> Message-ID: <200709020211.28175.dale@daleglass.net> On Friday 31 August 2007 23:09:18 Harold Brown wrote: > They are there now. [snip] > There is also the reverse: > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s >lRegionName&grid_x=997&grid_y=1002 > > It returns: > > var slRegionName='Ahern'; Ok, I've googled around a bit and found this: https://secure-web5.secondlife.com/developers/third_party_reg/ I guess that works as the documentation I wanted. I tried the form there and it only returns get_error_codes. Now, it says there: "Avoid hardcoding in your capabilities urls." and "Keep your capability urls secret!". So how do I obtain the capability URL as needed if it's not listed there? Will this functionality be available to everybody? It's not much good for me unless everybody can use it (excepting the sim position to key feature request below) Also, while the sim name from region xy request works for me, I would prefer a direct key to sim name function, as well as xy to key. First one would avoid the intermediate key to region id lookup, second one would allow me to build my database much more easily (which then would ship with the viewer, avoiding most lookups) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070902/3cac9b7a/attachment.pgp From labrat.hb at gmail.com Sat Sep 1 17:31:20 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sat Sep 1 17:31:23 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <200709020211.28175.dale@daleglass.net> References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> Message-ID: The cap URLS I posted do not require authentication, and as such appear to be static at the moment On 9/1/07, Dale Glass wrote: > > On Friday 31 August 2007 23:09:18 Harold Brown wrote: > > They are there now. > [snip] > > There is also the reverse: > > > > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s > >lRegionName&grid_x=997&grid_y=1002 > > > > It returns: > > > > var slRegionName='Ahern'; > > Ok, I've googled around a bit and found this: > > https://secure-web5.secondlife.com/developers/third_party_reg/ > > I guess that works as the documentation I wanted. > > I tried the form there and it only returns get_error_codes. > > Now, it says there: "Avoid hardcoding in your capabilities urls." and > "Keep > your capability urls secret!". > > So how do I obtain the capability URL as needed if it's not listed there? > > Will this functionality be available to everybody? It's not much good for > me > unless everybody can use it (excepting the sim position to key feature > request below) > > Also, while the sim name from region xy request works for me, I would > prefer a > direct key to sim name function, as well as xy to key. First one would > avoid > the intermediate key to region id lookup, second one would allow me to > build > my database much more easily (which then would ship with the viewer, > avoiding > most lookups) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070901/92c89a03/attachment.htm From dale at daleglass.net Sat Sep 1 17:51:01 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 1 17:51:17 2007 Subject: [sldev] Re: [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: References: <200708310423.22452.dale@daleglass.net> <200709020211.28175.dale@daleglass.net> Message-ID: <200709020251.06251.dale@daleglass.net> On Sunday 02 September 2007 02:31:20 Harold Brown wrote: > The cap URLS I posted do not require authentication, and as such appear > to be static at the moment Ok, that's good to know, thanks :-) Then the list only shows the ones that require authentication and you have permission to use? If so, where is the list of services that anybody can use? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070902/1c4205df/attachment.pgp From mrfrans at gmail.com Sat Sep 1 20:54:17 2007 From: mrfrans at gmail.com (Jeroen Frans) Date: Sat Sep 1 20:54:20 2007 Subject: [sldev] Invite from Jeroen Frans (mrfrans@gmail.com) Message-ID: <20070902035417.4B8282B263B@www1.quechup.com> JeroenFrans (mrfrans@gmail.com) has invited you as a friend on Quechup... ...the social networking platform sweeping the globe Go to: http://quechup.com/join.php/aT0wMDAwMDAwMDA5MTk4MDc4JmM9OTcxNzI%3D to accept Jeroen's invite You can use Quechup to meet new people, catch up with old friends, maintain a blog, share videos & photos, chat with other members, play games, and more. It's no wonder Quechup is fast becoming 'The Social Networking site to be on' Join Jeroen and his friends today: http://quechup.com/join.php/aT0wMDAwMDAwMDA5MTk4MDc4JmM9OTcxNzI%3D ------------------------------------------------------------------ You received this because Jeroen Frans (mrfrans@gmail.com) knows and agreed to invite you. You will only receive one invitation from mrfrans@gmail.com. Quechup will not spam or sell your email address, see our privacy policy - http://quechup.com/privacy.php Go to http://quechup.com/emailunsubscribe.php/ZW09c2xkZXZAbGlzdHMuc2Vjb25kbGlmZS5jb20%3D if you do not wish to receive any more emails from Quechup. ------------------------------------------------------------------ Copyright Quechup.com 2007. ------------------------------------ Go to http://quechup.com/emailunsubscribe.php/ZW09c2xkZXZAbGlzdHMuc2Vjb25kbGlmZS5jb20%3D if you do not wish to receive any more emails from Quechup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070902/b2722950/attachment.htm From mrfrans at gmail.com Sat Sep 1 21:23:37 2007 From: mrfrans at gmail.com (Frans) Date: Sat Sep 1 21:23:40 2007 Subject: [sldev] Invite from Jeroen Frans (mrfrans@gmail.com) In-Reply-To: <20070902035417.4B8282B263B@www1.quechup.com> References: <20070902035417.4B8282B263B@www1.quechup.com> Message-ID: <7765f2c60709012123g6719af0bm48d7fff5db672adc@mail.gmail.com> Hi, I apologise for sending the Q invite email, this was a automaticallygenerated email that was send without my consent. Please don't signup to it, the site is a scam. Frans -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070902/aeed4593/attachment.htm From corax at ravenscall.net Sat Sep 1 23:07:42 2007 From: corax at ravenscall.net (Corax) Date: Sat Sep 1 22:55:26 2007 Subject: [sldev] [VIEWER] Re: OS-SL Development Issues In-Reply-To: References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> Message-ID: <46DA532E.60003@ravenscall.net> Argent Stonecutter wrote: > Dzonatas writes: >> This was easily done by minimizing the tear-off group IM window. That >> minimize box is one feature that keeps appearing and disappearing >> through releases, so yeah maybe a secondary checkbox will help. > > Unfortunately minimized windows block the most recent line of chat. :) > > Hmm... how about a patch to make the minimized windows minimize to a > different corner of the screen, or even title/menu bar icons? The > current location is pretty much the worst possible place. In the latest version of the viewer I've actually been able to move the minimized icons around on the screen, to avoid them blocking my chat text - the restore button still works, while clicking the small title bar moves rather than restores. Just the way it should be! Corax Homewood From lenglish5 at cox.net Sat Sep 1 23:15:10 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 1 23:15:12 2007 Subject: [sldev] what and/or where is TEST_HARNESS? Message-ID: <46DA54EE.501@cox.net> Hey all, I found a bit of code at the end of llcontrol.cpp I was wondering if any Linden has the missing definitions that enable this code and could 1) tell me what it does and 2) furnish me with a copy. SEEMS like it would be helpful in designing a viable windows class so that we can prototype GUI and related stuff without having to deal with the client or the login panel. Even the login panel establishes contact with the webserver and downloads the splash image and latest blog URLs which takes up waay too much time. As well, by being able to deal with the GUI framework on a hello world level, we can make a serious stab at upgrading the GUI framework and eventually port the client-specific code back to the improved version of the framework. Division of labor and all that. #ifdef TEST_HARNESS void main() { F32_CONTROL foo, getfoo; S32_CONTROL bar, getbar; BOOL_CONTROL baz; U32 count = gGlobals.loadFromFile("controls.ini"); llinfos << "Loaded " << count << " controls" << llendl; // test insertion foo = new LLControl("gFoo", 5.f, 1.f, 20.f); gGlobals.addEntry("gFoo", foo); bar = new LLControl("gBar", 10, 2, 22); gGlobals.addEntry("gBar", bar); baz = new LLControl("gBaz", FALSE); gGlobals.addEntry("gBaz", baz); // test retrieval getfoo = (LLControl*) gGlobals.resolveName("gFoo"); getfoo->dump(); getbar = (S32_CONTROL) gGlobals.resolveName("gBar"); getbar->dump(); // change data getfoo->set(10.f); getfoo->dump(); // Failure modes // ...min > max // badfoo = new LLControl("gFoo2", 100.f, 20.f, 5.f); // ...initial > max // badbar = new LLControl("gBar2", 10, 20, 100000); // ...misspelled name // getfoo = (F32_CONTROL) gGlobals.resolveName("fooMisspelled"); // getfoo->dump(); // ...invalid data type getfoo = (F32_CONTROL) gGlobals.resolveName("gFoo"); getfoo->set(TRUE); getfoo->dump(); // ...out of range data // getfoo->set(100000000.f); // getfoo->dump(); // Clean Up delete foo; delete bar; delete baz; } #endif BOOL control_insert_before( LLControlBase* first, LLControlBase* second ) { return ( first->getName().compare(second->getName()) < 0 ); } From nicholaz at blueflash.cc Sun Sep 2 03:52:38 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Sep 2 03:52:44 2007 Subject: [sldev] [VIEWER] Minimized Windows In-Reply-To: References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> Message-ID: <46DA95F6.5000200@blueflash.cc> I think in the voice viewer I've seen code that looked like it would allow minimized windows to be moved (and even remembered)? I'm not sure, but with the voice release there was a lot of new code in the llui project. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Argent Stonecutter wrote: > Dzonatas writes: >> This was easily done by minimizing the tear-off group IM window. That >> minimize box is one feature that keeps appearing and disappearing >> through releases, so yeah maybe a secondary checkbox will help. > > Unfortunately minimized windows block the most recent line of chat. :) > > Hmm... how about a patch to make the minimized windows minimize to a > different corner of the screen, or even title/menu bar icons? The > current location is pretty much the worst possible place. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Sun Sep 2 04:03:47 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 2 04:03:33 2007 Subject: [sldev] [VIEWER] Minimized Windows In-Reply-To: <46DA95F6.5000200@blueflash.cc> References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> <46DA95F6.5000200@blueflash.cc> Message-ID: <2F9D759E-414E-4F7C-B392-FE6146202572@gmail.com> On 02-Sep-2007, at 05:52, Nicholaz Beresford wrote: > I think in the voice viewer I've seen code that looked > like it would allow minimized windows to be moved (and > even remembered)? I'm not sure, but with the voice release > there was a lot of new code in the llui project. Nod, that seems to work. It's still annoying that it picks the absolutely worst possible corner to start placing the minimized windows in. From alissa_sabre at yahoo.co.jp Sun Sep 2 03:06:50 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun Sep 2 05:20:13 2007 Subject: [sldev] SIM SOURCE CODE In-Reply-To: <46D7170A.7040400@lindenlab.com> References: <46D7170A.7040400@lindenlab.com> Message-ID: > > Also, how will this going to work? I mean like, hooking up to the grid > > and asset/login systems etc.. > > And will it require changes in scripting too? > > To add to Bryan's response: we don't know the answers to these > questions, and we need to figure then out before we can open-source it. If this is the major reason why LL does not make the server source code available immediaely, you are going toward a wrong direction. I understand the said issues are tough. If you disclosed the current server source code now, many more people would work for it, and a set of solutions would be found earlier. How many people are actually working on the big issues above? We now LL has thrity some devs, but many of them are focusing on the stability issues these days. I believe you can easily get five or ten more people to work on these future issues when you disclose the server source. In this context, the source need not be usable; it is not needed to be compiled successfully. So the set of source files as-is, minus some third-party licensed codes are enough for the moment. Lessons from BSD Netwrok Releases will work here. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From lenglish5 at cox.net Sun Sep 2 08:01:14 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 2 08:01:16 2007 Subject: [sldev] what and/or where is TEST_HARNESS? In-Reply-To: <46DA54EE.501@cox.net> References: <46DA54EE.501@cox.net> Message-ID: <46DAD03A.5010605@cox.net> Lawson English wrote: > [...] > > As well, by being able to deal with the GUI framework on a hello world > level, we can make a serious stab at upgrading the GUI framework and > eventually port the client-specific code back to the improved version > of the framework. > > Division of labor and all that. What would this "division of labor" gain us? Well, in addition to a more rational GUI framework, it would make Benjamin's proposal to redo the GUI of the viewer much easier. As well, any scripting of the viewer's GUI could be targeted to the revised framework, rather than the current, messy one. Finally, the long-proposed plug-in API could be built around the revised framework. In fact, the revised client itself could be seen as a "plug-in" for this framework, which would make porting the client to other GUIs such as a web-page-based interface, that much easier. From sllists at boroon.dasgupta.ch Sun Sep 2 08:17:37 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun Sep 2 08:17:45 2007 Subject: [sldev] [IDEA] GUI framework (was: what and/or where is TEST_HARNESS?) In-Reply-To: <46DAD03A.5010605@cox.net> References: <46DA54EE.501@cox.net> <46DAD03A.5010605@cox.net> Message-ID: <43187.83.180.254.242.1188746257.squirrel@datendelphin.net> > Lawson English wrote: > [...] > Finally, the long-proposed plug-in API could be built around the revised > framework. In fact, the revised client itself could be seen as a > "plug-in" for this framework, which would make porting the client to > other GUIs such as a web-page-based interface, that much easier. Now this sounds like a similar (if not the same) concept as http://jira.secondlife.com/browse/MISC-621 I'd appreciate the viewer to get more modularized (if that's the correct expression) :-) Boroondas From rdw at lindenlab.com Sun Sep 2 22:47:01 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Sun Sep 2 22:47:03 2007 Subject: [sldev] SIM SOURCE CODE In-Reply-To: References: <46D7170A.7040400@lindenlab.com> Message-ID: <46DB9FD5.8010407@lindenlab.com> Alissa Sabre wrote: > If this is the major reason why LL does not make the server source > code available immediaely, you are going toward a wrong direction. I > understand the said issues are tough. If you disclosed the current server > source code now, many more people would work for it, and a set of > solutions would be found earlier. > I don't know what the major reasons are -- that's Cory's job to worry about. :-) -RYaN From jhurliman at wsu.edu Mon Sep 3 01:32:03 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Sep 3 01:32:20 2007 Subject: [sldev] Adding technical documentation to the SL wiki? Message-ID: <46DBC683.40403@wsu.edu> I want to start documenting Second Life protocol details on the SL wiki, but so far I've not been marking new pages with anything to note that they are technical docs and sometimes just making paragraphs on existing pages. The main benefit of the libsecondlife.org wiki for me right now is a better signal to noise ratio of technical docs. If there is a way to isolate things like how the network protocol and viewer code actually work in to separate namespaces or the wiki-equivalent it would solve this issue, so I'm looking for the proper protocol on how to do this. John Hurliman From adam at gwala.net Mon Sep 3 01:36:35 2007 From: adam at gwala.net (Adam Frisby) Date: Mon Sep 3 01:38:19 2007 Subject: [sldev] Adding technical documentation to the SL wiki? In-Reply-To: <46DBC683.40403@wsu.edu> References: <46DBC683.40403@wsu.edu> Message-ID: <46DBC793.5040307@gwala.net> I'm thinking a couple of 'huge' pages might be the way to go - most of these entries are not going to justify a single page, even with all the implementation details. Let me know if you set something up like that, I know the protocol pretty well thanks to OpenSim, so I'd be glad to chip in. Adam John Hurliman wrote: > I want to start documenting Second Life protocol details on the SL wiki, > but so far I've not been marking new pages with anything to note that > they are technical docs and sometimes just making paragraphs on existing > pages. The main benefit of the libsecondlife.org wiki for me right now > is a better signal to noise ratio of technical docs. If there is a way > to isolate things like how the network protocol and viewer code actually > work in to separate namespaces or the wiki-equivalent it would solve > this issue, so I'm looking for the proper protocol on how to do this. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Mon Sep 3 01:42:13 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Sep 3 01:43:56 2007 Subject: [sldev] Adding technical documentation to the SL wiki? In-Reply-To: <46DBC793.5040307@gwala.net> References: <46DBC683.40403@wsu.edu> <46DBC793.5040307@gwala.net> Message-ID: <46DBC8E5.9040802@wsu.edu> Yes I agree, but even with one page for each distinct "manager" system in libsl (plus the separate backend systems) you'll still have enough pages to want an easy way to search them exclusively. John Adam Frisby wrote: > I'm thinking a couple of 'huge' pages might be the way to go - most of > these entries are not going to justify a single page, even with all > the implementation details. > > Let me know if you set something up like that, I know the protocol > pretty well thanks to OpenSim, so I'd be glad to chip in. > > Adam > > John Hurliman wrote: > >> I want to start documenting Second Life protocol details on the SL >> wiki, but so far I've not been marking new pages with anything to >> note that they are technical docs and sometimes just making >> paragraphs on existing pages. The main benefit of the >> libsecondlife.org wiki for me right now is a better signal to noise >> ratio of technical docs. If there is a way to isolate things like how >> the network protocol and viewer code actually work in to separate >> namespaces or the wiki-equivalent it would solve this issue, so I'm >> looking for the proper protocol on how to do this. >> >> John Hurliman >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From tao.takashi at googlemail.com Mon Sep 3 01:57:19 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 3 01:57:22 2007 Subject: [sldev] SIM SOURCE CODE In-Reply-To: <46DB9FD5.8010407@lindenlab.com> References: <46D7170A.7040400@lindenlab.com> <46DB9FD5.8010407@lindenlab.com> Message-ID: <23bbb49e0709030157r7bb8ea14s1e50e0ccd561fb4d@mail.gmail.com> > I don't know what the major reasons are -- that's Cory's job to worry > about. :-) I'd guess it has something to do with a business plan ;-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070903/5f0add42/attachment.htm From alissa_sabre at yahoo.co.jp Mon Sep 3 06:33:51 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Sep 3 06:34:04 2007 Subject: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <46D6F0B2.6070400@lindenlab.com> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> Message-ID: <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> > I was just fixing some Japanese IME input bugs yesterday > (which should fix Chinese and Korean as well). Great. What is the JIRA issue number of that bug? > Perhaps we should get > in touch off-line to see if I can help bring some of your work into the > main code. It would be nice to get the SL viewer working better with > these languages. Exactly. Have you seen my patch? It's available on JIRA issue VWR-250. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From robla at lindenlab.com Mon Sep 3 10:05:43 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Sep 3 10:05:54 2007 Subject: [sldev] Adding technical documentation to the SL wiki? In-Reply-To: <46DBC683.40403@wsu.edu> References: <46DBC683.40403@wsu.edu> Message-ID: <46DC3EE7.2030306@lindenlab.com> On 9/3/07 1:32 AM, John Hurliman wrote: > I want to start documenting Second Life protocol details on the SL > wiki, but so far I've not been marking new pages with anything to note > that they are technical docs and sometimes just making paragraphs on > existing pages. The main benefit of the libsecondlife.org wiki for me > right now is a better signal to noise ratio of technical docs. If > there is a way to isolate things like how the network protocol and > viewer code actually work in to separate namespaces or the > wiki-equivalent it would solve this issue, so I'm looking for the > proper protocol on how to do this. Hmm....I don't want to break this information out into a separate namespace. All of the English Wikipedia fits in one namespace, and the lines between "signal" and "noise" vary from person to person. Using namespaces for taxonomy definition essentially hardcodes it. The right place to place this seems to be here: https://wiki.secondlife.com/wiki/Protocol As far as searching that goes, Google searches may be the best way to narrow down the search to the technical part of the wiki. For example, this search: site:wiki.secondlife.com "open source portal" texture ...gives results only from pages that are associated with the open source portal. Category tagging can help make it more specific. If there are other things Wikipedia or other MediaWiki-based wikis are doing, I'd rather go down that road. A couple places to take this conversation if we want to go offlist: Discussion about how to document the protocol: https://wiki.secondlife.com/wiki/Talk:Protocol General wiki organization: https://wiki.secondlife.com/wiki/Project:Editing_Discussion Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070903/f8654e06/signature.pgp From seg at haxxed.com Mon Sep 3 11:18:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 3 11:19:05 2007 Subject: [sldev] Clients newer than 1.18.0.6 unusable on x86_64 Message-ID: <1188843538.2798.41.camel@localhost> Okay, wasted all day yesterday trying to figure this out. 1.18.1.2 and 1.18.3.2 are both completely unusable on my wife's x86_64 laptop (512mb RAM, Fedora 7, Mobile Radeon 9600, open source r300 DRI). Within minutes it rapidly eats up all RAM causing severe swap, making SL, and the entire system for that matter, unusable. Am I the only one seeing this? I do not see this on i386, neither my laptop (512mb, F7, Intel 830M) or a similar i386 box (768mb, F7, Radeon 9800SE, open source r300). It handles what has been my primary test (Walk from Furnation Vista to Gamma sandboxes, through Alpha) just fine, while only ever using half its RAM, never touching swap! The x86_64 machine running 1.18.0.6 handles it just fine as well. Unfortunately, running with massif in an attempt to find where all this RAM is being used, seems to kill texture decode dead and also seems to make the r300 driver crash so I don't think I'm getting a valid test run out of it. My Fedora package will stay at 1.18.0.6 until this is fixed. Not that its in the repo yet. ;P Which brings up a related question, what's the cleanest way to disable the optional update nagbox? I tried to patch it out, but the startup code is a nightmare and I quickly gave up as it was taking more work than I wanted to put in to it at the time. A while back there was some mention of "update channels". I just want the update checking disabled entirely, we have our own update system. (RPM, yum-updatesd) Though "this client is not compatible with this grid" alerts would have to remain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070903/63e33aa4/attachment.pgp From nicholaz at blueflash.cc Mon Sep 3 11:42:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 3 11:42:15 2007 Subject: [sldev] Clients newer than 1.18.0.6 unusable on x86_64 In-Reply-To: <1188843538.2798.41.camel@localhost> References: <1188843538.2798.41.camel@localhost> Message-ID: <46DC557D.3040705@blueflash.cc> Hi! I'm currently in the process of debugging memory use as well (on 32bit Windows). One area seems to involve animations. I don't have any solid results yet, but you can try to apply (reverse) the attached patch, which seems to be one of the offenders. Regarding skipping optional updates, there's a parameter for that in the authenticate() function (llstartup, look for gSkipOptionalUpdate). Btw, now that you mention it, I have a user under Vista with extreme memory growth ... I think he's using 64bit Vista ... there may be something related. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Callum Lerwick wrote: > Okay, wasted all day yesterday trying to figure this out. 1.18.1.2 and > 1.18.3.2 are both completely unusable on my wife's x86_64 laptop (512mb > RAM, Fedora 7, Mobile Radeon 9600, open source r300 DRI). Within minutes > it rapidly eats up all RAM causing severe swap, making SL, and the > entire system for that matter, unusable. Am I the only one seeing this? > > I do not see this on i386, neither my laptop (512mb, F7, Intel 830M) or > a similar i386 box (768mb, F7, Radeon 9800SE, open source r300). It > handles what has been my primary test (Walk from Furnation Vista to > Gamma sandboxes, through Alpha) just fine, while only ever using half > its RAM, never touching swap! The x86_64 machine running 1.18.0.6 > handles it just fine as well. > > Unfortunately, running with massif in an attempt to find where all this > RAM is being used, seems to kill texture decode dead and also seems to > make the r300 driver crash so I don't think I'm getting a valid test run > out of it. > > My Fedora package will stay at 1.18.0.6 until this is fixed. Not that > its in the repo yet. ;P Which brings up a related question, what's the > cleanest way to disable the optional update nagbox? I tried to patch it > out, but the startup code is a nightmare and I quickly gave up as it was > taking more work than I wanted to put in to it at the time. A while back > there was some mention of "update channels". I just want the update > checking disabled entirely, we have our own update system. (RPM, > yum-updatesd) Though "this client is not compatible with this grid" > alerts would have to remain. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotion.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llmotion.cpp --- linden/indra/llcharacter/llmotion.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotion.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -126,6 +126,11 @@ mDeactivateCallbackUserData = userdata; } +BOOL LLMotion::isBlending() +{ + return mPose.getWeight() < 1.f; +} + //----------------------------------------------------------------------------- // activate() //----------------------------------------------------------------------------- @@ -142,10 +147,16 @@ void LLMotion::deactivate() { mActive = FALSE; + mPose.setWeight(0.f); if (mDeactivateCallback) (*mDeactivateCallback)(mDeactivateCallbackUserData); onDeactivate(); } +BOOL LLMotion::canDeprecate() +{ + return TRUE; +} + // End diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotion.h sl1_18_2_0\linden-orig\indra/llcharacter/llmotion.h --- linden/indra/llcharacter/llmotion.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotion.h 2007-08-10 10:39:40.000000000 +0200 @@ -99,13 +99,14 @@ void setStopped(BOOL stopped) { mStopped = stopped; } + BOOL isBlending(); + void activate(); void deactivate(); BOOL isActive() { return mActive; } - public: //------------------------------------------------------------------------- // animation callbacks to be implemented by subclasses @@ -145,6 +146,11 @@ // called when a motion is deactivated virtual void onDeactivate() = 0; + // can we crossfade this motion with a new instance when restarted? + // should ultimately always be TRUE, but lack of emote blending, etc + // requires this + virtual BOOL canDeprecate(); + // optional callback routine called when animation deactivated. void setDeactivateCallback( void (*cb)(void *), void* userdata ); diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotioncontroller.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llmotioncontroller.cpp --- linden/indra/llcharacter/llmotioncontroller.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -194,34 +194,44 @@ //----------------------------------------------------------------------------- void LLMotionController::addLoadedMotion(LLMotion* motionp) { + std::set motions_to_kill; + + // gather all inactive, loaded motions if (mLoadedMotions.size() > MAX_MOTION_INSTANCES) { // too many motions active this frame, kill all blenders mPoseBlender.clearBlenders(); - for (U32 i = 0; i < mLoadedMotions.size(); i++) + for (motion_list_t::iterator loaded_motion_it = mLoadedMotions.begin(); + loaded_motion_it != mLoadedMotions.end(); + ++loaded_motion_it) { - LLMotion* cur_motionp = mLoadedMotions.front(); - mLoadedMotions.pop_front(); + LLMotion* cur_motionp = *loaded_motion_it; // motion isn't playing, delete it if (!isMotionActive(cur_motionp)) { - mCharacter->requestStopMotion(cur_motionp); - mAllMotions.erase(cur_motionp->getID()); - delete cur_motionp; - if (mLoadedMotions.size() <= MAX_MOTION_INSTANCES) - { - break; - } - } - else - { - // put active motion on back - mLoadedMotions.push_back(cur_motionp); + motions_to_kill.insert(cur_motionp->getID()); } } } + + // clean up all inactive, loaded motions + for (std::set::iterator motion_it = motions_to_kill.begin(); + motion_it != motions_to_kill.end(); + ++motion_it) + { + // look up the motion again by ID to get canonical instance + // and kill it only if that one is inactive + LLUUID motion_id = *motion_it; + LLMotion* motionp = findMotion(motion_id); + if (motionp && !isMotionActive(motionp)) + { + removeMotion(motion_id); + } + } + + // add new motion to loaded list mLoadedMotions.push_back(motionp); } @@ -280,14 +290,24 @@ void LLMotionController::removeMotion( const LLUUID& id) { LLMotion* motionp = findMotion(id); + + removeMotionInstance(motionp); + + mAllMotions.erase(id); +} + +// removes instance of a motion from all runtime structures, but does +// not erase entry by ID, as this could be a duplicate instance +// use removeMotion(id) to remove all references to a given motion by id. +void LLMotionController::removeMotionInstance(LLMotion* motionp) +{ if (motionp) { - stopMotionLocally(id, TRUE); + stopMotionInstance(motionp, TRUE); mLoadingMotions.erase(motionp); mLoadedMotions.remove(motionp); mActiveMotions.remove(motionp); - mAllMotions.erase(id); delete motionp; } } @@ -348,28 +368,39 @@ //----------------------------------------------------------------------------- BOOL LLMotionController::startMotion(const LLUUID &id, F32 start_offset) { - // look for motion in our list of created motions - LLMotion *motion = createMotion(id); + // do we have an instance of this motion for this character? + LLMotion *motion = findMotion(id); + + // motion that is stopping will be allowed to stop but + // replaced by a new instance of that motion + if (motion + && motion->canDeprecate() + && motion->getFadeWeight() > 0.01f // not LOD-ed out + && (motion->isBlending() || motion->getStopTime() != 0.f)) + { + deprecateMotionInstance(motion); + // force creation of new instance + motion = NULL; + } + + // create new motion instance + if (!motion) + { + motion = createMotion(id); + } if (!motion) { return FALSE; } - //if the motion is already active, then we're done - else if (isMotionActive(motion)) // motion is playing and... + //if the motion is already active and allows deprecation, then let it keep playing + else if (motion->canDeprecate() && isMotionActive(motion)) { - if (motion->isStopped()) // motion has been stopped - { - deactivateMotion(motion, false); - } - else if (mTime < motion->mSendStopTimestamp) // motion is still active - { - return TRUE; - } + return TRUE; } // llinfos << "Starting motion " << name << llendl; - return activateMotion(motion, mTime - start_offset); + return activateMotionInstance(motion, mTime - start_offset); } @@ -380,6 +411,12 @@ { // if already inactive, return false LLMotion *motion = findMotion(id); + + return stopMotionInstance(motion, stop_immediate); +} + +BOOL LLMotionController::stopMotionInstance(LLMotion* motion, BOOL stop_immediate) +{ if (!motion) { return FALSE; @@ -396,7 +433,7 @@ if (stop_immediate) { - deactivateMotion(motion, false); + deactivateMotionInstance(motion); } return TRUE; } @@ -492,7 +529,7 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - deactivateMotion(motionp, false); + deactivateMotionInstance(motionp); } else if (motionp->isStopped() && mTime > motionp->getStopTime()) { @@ -510,7 +547,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } else if (mTime >= motionp->mActivationTimestamp) @@ -538,7 +575,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -546,7 +583,8 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - deactivateMotion(motionp, true); + posep->setWeight(0.f); + deactivateMotionInstance(motionp); } continue; } @@ -572,7 +610,8 @@ } else { - deactivateMotion(motionp, true); + posep->setWeight(0.f); + deactivateMotionInstance(motionp); continue; } } @@ -617,7 +656,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -661,7 +700,7 @@ // propagate this to the network // as not all viewers are guaranteed to have access to the same logic mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -733,7 +772,7 @@ // this motion should be playing if (!motionp->isStopped()) { - activateMotion(motionp, mTime); + activateMotionInstance(motionp, mTime); } } else if (status == LLMotion::STATUS_FAILURE) @@ -741,6 +780,7 @@ llinfos << "Motion " << motionp->getID() << " init failed." << llendl; sRegistry.markBad(motionp->getID()); mLoadingMotions.erase(curiter); + mAllMotions.erase(motionp->getID()); delete motionp; } @@ -773,9 +813,9 @@ //----------------------------------------------------------------------------- -// activateMotion() +// activateMotionInstance() //----------------------------------------------------------------------------- -BOOL LLMotionController::activateMotion(LLMotion *motion, F32 time) +BOOL LLMotionController::activateMotionInstance(LLMotion *motion, F32 time) { if (mLoadingMotions.find(motion) != mLoadingMotions.end()) { @@ -818,23 +858,38 @@ } //----------------------------------------------------------------------------- -// deactivateMotion() +// deactivateMotionInstance() //----------------------------------------------------------------------------- -BOOL LLMotionController::deactivateMotion(LLMotion *motion, bool remove_weight) +BOOL LLMotionController::deactivateMotionInstance(LLMotion *motion) { - if( remove_weight ) + motion->deactivate(); + + motion_set_t::iterator found_it = mDeprecatedMotions.find(motion); + if (found_it != mDeprecatedMotions.end()) { - // immediately remove pose weighting instead of letting it time out - LLPose *posep = motion->getPose(); - posep->setWeight(0.f); + // deprecated motions need to be completely excised + removeMotionInstance(motion); + mDeprecatedMotions.erase(found_it); + } + else + { + // for motions that we are keeping, simply remove from active queue + mActiveMotions.remove(motion); } - - motion->deactivate(); - mActiveMotions.remove(motion); return TRUE; } +void LLMotionController::deprecateMotionInstance(LLMotion* motion) +{ + mDeprecatedMotions.insert(motion); + + //fade out deprecated motion + stopMotionInstance(motion, FALSE); + //no longer canonical + mAllMotions.erase(motion->getID()); +} + //----------------------------------------------------------------------------- // isMotionActive() //----------------------------------------------------------------------------- @@ -857,7 +912,7 @@ //----------------------------------------------------------------------------- LLMotion *LLMotionController::findMotion(const LLUUID& id) { - return mAllMotions[id]; + return get_if_there(mAllMotions, id, NULL); } //----------------------------------------------------------------------------- diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotioncontroller.h sl1_18_2_0\linden-orig\indra/llcharacter/llmotioncontroller.h --- linden/indra/llcharacter/llmotioncontroller.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.h 2007-08-10 10:39:40.000000000 +0200 @@ -179,16 +179,21 @@ LLMotion *findMotion( const LLUUID& id ); protected: + // internal operations act on motion instances directly + // as there can be duplicate motions per id during blending overlap void deleteAllMotions(); void addLoadedMotion(LLMotion *motion); - BOOL activateMotion(LLMotion *motion, F32 time); - BOOL deactivateMotion(LLMotion *motion, bool remove_weight); + BOOL activateMotionInstance(LLMotion *motion, F32 time); + BOOL deactivateMotionInstance(LLMotion *motion); + void deprecateMotionInstance(LLMotion* motion); + BOOL stopMotionInstance(LLMotion *motion, BOOL stop_imemdiate); + void removeMotionInstance(LLMotion* motion); void updateRegularMotions(); void updateAdditiveMotions(); void resetJointSignatures(); void updateMotionsByType(LLMotion::LLMotionBlendType motion_type); -protected: +protected: F32 mTimeFactor; static LLMotionRegistry sRegistry; LLPoseBlender mPoseBlender; @@ -203,11 +208,13 @@ // Once an animations is loaded, it will be initialized and put on the mLoadedMotions deque. // Any animation that is currently playing also sits in the mActiveMotions list. - std::map mAllMotions; + typedef std::map motion_map_t; + motion_map_t mAllMotions; motion_set_t mLoadingMotions; motion_list_t mLoadedMotions; motion_list_t mActiveMotions; + motion_set_t mDeprecatedMotions; LLFrameTimer mTimer; F32 mTime; diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llpose.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llpose.cpp --- linden/indra/llcharacter/llpose.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llpose.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -275,9 +275,9 @@ joint_state_index < JSB_NUM_JOINT_STATES && mJointStates[joint_state_index] != NULL; joint_state_index++) { - U32 current_usage = mJointStates[joint_state_index]->getUsage(); - F32 current_weight = mJointStates[joint_state_index]->getWeight(); LLJointState* jsp = mJointStates[joint_state_index]; + U32 current_usage = jsp->getUsage(); + F32 current_weight = jsp->getWeight(); if (current_weight == 0.f) { @@ -292,17 +292,14 @@ // add in pos for this jointstate modulated by weight added_pos += jsp->getPosition() * (new_weight_sum - sum_weights[POS_WEIGHT]); - //sum_weights[POS_WEIGHT] = new_weight_sum; } - // now do scale if(current_usage & LLJointState::SCALE) { F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // add in scale for this jointstate modulated by weight added_scale += jsp->getScale() * (new_weight_sum - sum_weights[SCALE_WEIGHT]); - //sum_weights[SCALE_WEIGHT] = new_weight_sum; } if (current_usage & LLJointState::ROT) @@ -311,7 +308,6 @@ // add in rotation for this jointstate modulated by weight added_rot = nlerp((new_weight_sum - sum_weights[ROT_WEIGHT]), added_rot, jsp->getRotation()) * added_rot; - //sum_weights[ROT_WEIGHT] = new_weight_sum; } } else @@ -326,13 +322,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[POS_WEIGHT]); // blend positions from both - blended_pos = lerp(mJointStates[joint_state_index]->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); + blended_pos = lerp(jsp->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); sum_weights[POS_WEIGHT] = new_weight_sum; } else { // copy position from current - blended_pos = mJointStates[joint_state_index]->getPosition(); + blended_pos = jsp->getPosition(); sum_weights[POS_WEIGHT] = current_weight; } } @@ -345,13 +341,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // blend scales from both - blended_scale = lerp(mJointStates[joint_state_index]->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); + blended_scale = lerp(jsp->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); sum_weights[SCALE_WEIGHT] = new_weight_sum; } else { // copy scale from current - blended_scale = mJointStates[joint_state_index]->getScale(); + blended_scale = jsp->getScale(); sum_weights[SCALE_WEIGHT] = current_weight; } } @@ -364,13 +360,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[ROT_WEIGHT]); // blend rotations from both - blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, mJointStates[joint_state_index]->getRotation(), blended_rot); + blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, jsp->getRotation(), blended_rot); sum_weights[ROT_WEIGHT] = new_weight_sum; } else { // copy rotation from current - blended_rot = mJointStates[joint_state_index]->getRotation(); + blended_rot = jsp->getRotation(); sum_weights[ROT_WEIGHT] = current_weight; } } diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llpose.h sl1_18_2_0\linden-orig\indra/llcharacter/llpose.h --- linden/indra/llcharacter/llpose.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llpose.h 2007-08-10 10:39:40.000000000 +0200 @@ -81,7 +81,7 @@ S32 getNumJointStates() const; }; -const S32 JSB_NUM_JOINT_STATES = 4; +const S32 JSB_NUM_JOINT_STATES = 6; class LLJointStateBlender { From gigstaggart at gmail.com Mon Sep 3 11:59:15 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 3 11:59:25 2007 Subject: [sldev] My recent patches (retry) Message-ID: <46DC5983.1030709@gmail.com> (This apparently didn't go through the first time) Here's some of my recent patches suitable for incorporation for testing and code review: https://jira.secondlife.com/browse/VWR-6 https://jira.secondlife.com/browse/VWR-2065 Note that with VWR-6, that patch is correct, but the new code in llui has completely broken app_early_exit so that it returns immediately and is not fatal, this causes the program to try to continue to execute after a fatal error, a dangerous situation (which will probably just cause segfaults, but could corrupt data). I need to speak with some Linden about the new UI stuff to know how to go about addressing that. I can think of a few ways but I'm not sure which one is the "right" one. A fix for app_early_exit if I make one will be posted in a new bug, not in VWR-6. -Jason From gigstaggart at gmail.com Mon Sep 3 10:40:51 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 3 12:29:36 2007 Subject: [sldev] [PATCH] My recent patches Message-ID: <46DC4723.5060209@gmail.com> Here's some of my recent patches suitable for incorporation for testing and code review: https://jira.secondlife.com/browse/VWR-6 https://jira.secondlife.com/browse/VWR-2065 Note that with VWR-6, that patch is correct, but the new code in llui has completely broken app_early_exit so that it returns immediately and is not fatal, this causes the program to try to continue to execute after a fatal error, a dangerous situation (which will probably just cause segfaults, but could corrupt data). I need to speak with some Linden about the new UI stuff to know how to go about addressing that. I can think of a few ways but I'm not sure which one is the "right" one. A fix for app_early_exit if I make one will be posted in a new bug, not in VWR-6. -Jason From lenglish5 at cox.net Mon Sep 3 12:54:26 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 3 12:54:27 2007 Subject: [sldev] Adding technical documentation to the SL wiki? In-Reply-To: <46DC3EE7.2030306@lindenlab.com> References: <46DBC683.40403@wsu.edu> <46DC3EE7.2030306@lindenlab.com> Message-ID: <46DC6672.10009@cox.net> Rob Lanphier wrote: > On 9/3/07 1:32 AM, John Hurliman wrote: > >> I want to start documenting Second Life protocol details on the SL >> wiki, but so far I've not been marking new pages with anything to note >> that they are technical docs and sometimes just making paragraphs on >> existing pages. The main benefit of the libsecondlife.org wiki for me >> right now is a better signal to noise ratio of technical docs. If >> there is a way to isolate things like how the network protocol and >> viewer code actually work in to separate namespaces or the >> wiki-equivalent it would solve this issue, so I'm looking for the >> proper protocol on how to do this. >> > > Hmm....I don't want to break this information out into a separate > namespace. All of the English Wikipedia fits in one namespace, and the > lines between "signal" and "noise" vary from person to person. Using > namespaces for taxonomy definition essentially hardcodes it. > > The right place to place this seems to be here: > https://wiki.secondlife.com/wiki/Protocol > > As far as searching that goes, Google searches may be the best way to > narrow down the search to the technical part of the wiki. For example, > this search: > site:wiki.secondlife.com "open source portal" texture > > ...gives results only from pages that are associated with the open > source portal. Category tagging can help make it more specific. > > If there are other things Wikipedia or other MediaWiki-based wikis are > doing, I'd rather go down that road. > > A couple places to take this conversation if we want to go offlist: > > Discussion about how to document the protocol: > https://wiki.secondlife.com/wiki/Talk:Protocol > > General wiki organization: > https://wiki.secondlife.com/wiki/Project:Editing_Discussion > > On a related note, I'm learning much about the existing classes as I try to figure out how to do what I want. What is the proper format for documenting the classes and how they are used? From boz3d at inbox.com Mon Sep 3 14:15:41 2007 From: boz3d at inbox.com (Ernie Kabowski) Date: Mon Sep 3 14:16:02 2007 Subject: [sldev] NSV Support Message-ID: Hello all. I accidentally posted a proposal to the SL Business list after reading it's description and seeing "developers" in it. I'll make it again here. I'm working with the 1.18.2.0 source. I managed to write some rough code that works seamlessly with the parcel media URI system already implemented. If there's any interest I may continue with it and submit it. I just wanted to know if there was any interest in NSV or not. Someone mentioned another SDK or something that had a more broad range of codec support, but I think they where ignorant to it's licensing and platform support. NSV is even supported on OpenBSD without any third party packages or custom drivers. It's also got a really large user base already. AOL uses it for there video services, and there are also literally hundreds of non-commercial streams. The system I have now adds some conditional code around the parcel media URI submission system. It identifies the resource by headers and parses it's bit stream accordingly. The main reason to consider it is it's more bandwidth friendly. It'll buffer and play any bit length faster that Apple Video, WMV, Real, or any other codec protocol combination I have found so far. There may be a faster alternative, but it doesn't have near the selection of media as NSV, there are also a lot of hosting company's now providing NSV front ends for rational prices. It uses MP3 for audio and VP3 for video, and has a XML based bit stream wrapper for it's protocol. From seg at haxxed.com Mon Sep 3 15:48:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 3 15:48:34 2007 Subject: [sldev] NSV Support In-Reply-To: References: Message-ID: <1188859711.2798.62.camel@localhost> On Mon, 2007-09-03 at 13:15 -0800, Ernie Kabowski wrote: > I just wanted to know if there was any interest in NSV or not. Someone > mentioned another SDK or something that had a more broad range of > codec support, but I think they where ignorant to it's licensing and > platform support. On Linux/unix, gstreamer support recently landed in the client. Just install an NSV plugin and bam, you've got NSV. In fact, I just tried it, I'm playing NSV in totem right now. Looks like its the "gstreamer-ffmpeg" plugin that handles it: http://gstreamer.freedesktop.org/modules/gst-ffmpeg.html On Windows/OSX, Quicktime is used. Theoretically you should be able to install an NSV plugin for QT and be done with it, but none seem to exist that I can find. There doesn't even seem to be a DirectShow filter. Your efforts would be better put into rectifying this situation, rather than promulgating yet another damn library. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070903/1581d26b/attachment.pgp From labrat.hb at gmail.com Mon Sep 3 17:10:52 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Sep 3 17:10:56 2007 Subject: [sldev] NSV Support In-Reply-To: <1188859711.2798.62.camel@localhost> References: <1188859711.2798.62.camel@localhost> Message-ID: gstreamer is available on windows as well.... I'd think getting rid of the quicktime reliance would be a good direction to go. On 9/3/07, Callum Lerwick wrote: > > On Mon, 2007-09-03 at 13:15 -0800, Ernie Kabowski wrote: > > I just wanted to know if there was any interest in NSV or not. Someone > > mentioned another SDK or something that had a more broad range of > > codec support, but I think they where ignorant to it's licensing and > > platform support. > > On Linux/unix, gstreamer support recently landed in the client. Just > install an NSV plugin and bam, you've got NSV. In fact, I just tried it, > I'm playing NSV in totem right now. Looks like its the > "gstreamer-ffmpeg" plugin that handles it: > > http://gstreamer.freedesktop.org/modules/gst-ffmpeg.html > > On Windows/OSX, Quicktime is used. Theoretically you should be able to > install an NSV plugin for QT and be done with it, but none seem to exist > that I can find. There doesn't even seem to be a DirectShow filter. > > Your efforts would be better put into rectifying this situation, rather > than promulgating yet another damn library. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070903/8f137b70/attachment.htm From nicholaz at blueflash.cc Mon Sep 3 17:28:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 3 17:28:30 2007 Subject: [sldev] [VIEWER] Uploads crashing on RC 1.18.3 Message-ID: <46DCA6A3.7090308@blueflash.cc> Did anyone else see texture uploads crashing on the current RC? Had it a few times now, but couldn't nail it yet. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From seg at haxxed.com Mon Sep 3 20:26:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 3 20:26:26 2007 Subject: [sldev] NSV Support In-Reply-To: References: <1188859711.2798.62.camel@localhost> Message-ID: <1188876384.2798.72.camel@localhost> On Mon, 2007-09-03 at 17:10 -0700, Harold Brown wrote: > gstreamer is available on windows as well.... I'd think getting rid of > the quicktime reliance would be a good direction to go. If gstreamer can seamlessly wrap itself around DirectShow/Windows Media on Win32, and Quicktime on OSX, this just might be wonderful. The problem is, media codecs are a patent licensing minefield. By using Quicktime and/or DirectShow, you push the responsibility and liability for proper licensing onto Microsoft and Apple, who have already taken care of it, and conveniently placed codecs for MP3 and MPEG4 and whatnot on everyone's systems for you. Or demand everyone use Theora/OGG, which would be fine by me. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070903/d6025e4b/attachment.pgp From boz3d at inbox.com Tue Sep 4 04:46:31 2007 From: boz3d at inbox.com (Ernie Kabowski) Date: Tue Sep 4 04:46:47 2007 Subject: [sldev] NSV Support Message-ID: > gstreamer is available on windows as well.... I'd think getting rid of > the quicktime reliance would be a good direction to go. >> If gstreamer can seamlessly wrap itself around DirectShow/Windows Media >> on Win32, and Quicktime on OSX, this just might be wonderful. >> The problem is, media codecs are a patent licensing minefield. By using >> Quicktime and/or DirectShow, you push the responsibility and liability >> for proper licensing onto Microsoft and Apple, who have already taken >> care of it, and conveniently placed codecs for MP3 and MPEG4 and whatnot >> on everyone's systems for you. The Apple media playback API has little to no streaming capabilitys in it's own format. Plugins are cool if you want to constantly remind people to install them, and provide support and documentation for all. Most players are NT users or Desktop Linux system users. If I'm not mistaken all the viewers use FMOD for sound, so that covers a lot of audio codecs, and the module is very dynamic with codecs. I worked with it years back, and implement OGG, Shoutcast, and Icecast for a 3D game using it's sensor functions and buffering. I was impressed with it. I can't think of anything else to do with the source outside of fixing there physics and rendering algorithms. I barely got threw threw 10 hours of Calc II though so I'll not touch those. NSV just seemed cool cause you didn't have the 2+ minute waiting period for a 11MB video to load on a 1.5Mbps downstream. I also researched it's license. It's a GNU friendly license. The content Infringement Policy's are the responsibility of the owner of the streamserver. PS: What's with the Pokemon style retort with a hint of profanity? ____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth From nicholaz at blueflash.cc Tue Sep 4 05:32:00 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 4 05:32:09 2007 Subject: [sldev] [VIEWER] Memory Usage / Animations Message-ID: <46DD5040.2090600@blueflash.cc> I applied little wizardry to my leak dump routines for visual studio yesterday, allowing me to get a heap snapshot while the program runs, spitting out a list of places in the source which have the memory allocated on the heap and sorting them by size. I was going to a busy sim (Bad Girls) and found that (besides textures) the biggest memory spenders were llpointerskipmap, llpolymesh and keyframemotion (not entirely surprising in a place with 30-50 avatars dancing). There's a construct called llkeyframemotioncache which I discovered previously, which caches keyframemotions, but never clears them. I have a patch (see VWR-1769) which clears this cache on teleports, but unfortunately it's broken (or collides) by something that appeared in 1.18.1, leading to crashes after teleport (I think it was planned to go into a recent release but was backed out because of the collision). The Linden change also seems to produce new leaks (my own viewer runs normally practically with no mmory left over when it exits), even when not colliding with my VWR-1769, so somethig seems fishy there. I also have a patch from Soft, refcounting LLMotion, which counter the effects, but I'm not sure if it fixes the collision and leaks entirely (doing test runs is a bit awkward, as they depend on what other avatars do). * Well, long story short: The llkeyframemotion cache needs some attention as it eats a lot of memory in busy sims. 30 minutes at Bad Girls or a similar sim can cost up to 50MB-100MB which never get freed until you log off with (literally) a million of small heap blocks. If you have your own builds you may be interested in this: Builds based on 1.16.0.8 can apply the 1769 from the JIRA (it's tried and trusted, runs on my viewer build for a long time now) to get the cache flushed on teleports. If you have a build based on voice (1.18.1 or later) you need to apply (reverse) the attached llmotion patch if you want to run with VWR-1769. And I'm attaching a newer version of VWR-1769 which expires entries from the cache while staying on a sim. That one is pretty new and more beta'ish, so it could use some eyeballs or comments. On the other hand, one of my users who is a manager at Bad Girls and stays there for hours, was running it with my voice viewer and very good results yesterday. Nick -------------- next part -------------- diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotion.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llmotion.cpp --- linden/indra/llcharacter/llmotion.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotion.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -126,6 +126,11 @@ mDeactivateCallbackUserData = userdata; } +BOOL LLMotion::isBlending() +{ + return mPose.getWeight() < 1.f; +} + //----------------------------------------------------------------------------- // activate() //----------------------------------------------------------------------------- @@ -142,10 +147,16 @@ void LLMotion::deactivate() { mActive = FALSE; + mPose.setWeight(0.f); if (mDeactivateCallback) (*mDeactivateCallback)(mDeactivateCallbackUserData); onDeactivate(); } +BOOL LLMotion::canDeprecate() +{ + return TRUE; +} + // End diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotion.h sl1_18_2_0\linden-orig\indra/llcharacter/llmotion.h --- linden/indra/llcharacter/llmotion.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotion.h 2007-08-10 10:39:40.000000000 +0200 @@ -99,13 +99,14 @@ void setStopped(BOOL stopped) { mStopped = stopped; } + BOOL isBlending(); + void activate(); void deactivate(); BOOL isActive() { return mActive; } - public: //------------------------------------------------------------------------- // animation callbacks to be implemented by subclasses @@ -145,6 +146,11 @@ // called when a motion is deactivated virtual void onDeactivate() = 0; + // can we crossfade this motion with a new instance when restarted? + // should ultimately always be TRUE, but lack of emote blending, etc + // requires this + virtual BOOL canDeprecate(); + // optional callback routine called when animation deactivated. void setDeactivateCallback( void (*cb)(void *), void* userdata ); diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotioncontroller.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llmotioncontroller.cpp --- linden/indra/llcharacter/llmotioncontroller.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -194,34 +194,44 @@ //----------------------------------------------------------------------------- void LLMotionController::addLoadedMotion(LLMotion* motionp) { + std::set motions_to_kill; + + // gather all inactive, loaded motions if (mLoadedMotions.size() > MAX_MOTION_INSTANCES) { // too many motions active this frame, kill all blenders mPoseBlender.clearBlenders(); - for (U32 i = 0; i < mLoadedMotions.size(); i++) + for (motion_list_t::iterator loaded_motion_it = mLoadedMotions.begin(); + loaded_motion_it != mLoadedMotions.end(); + ++loaded_motion_it) { - LLMotion* cur_motionp = mLoadedMotions.front(); - mLoadedMotions.pop_front(); + LLMotion* cur_motionp = *loaded_motion_it; // motion isn't playing, delete it if (!isMotionActive(cur_motionp)) { - mCharacter->requestStopMotion(cur_motionp); - mAllMotions.erase(cur_motionp->getID()); - delete cur_motionp; - if (mLoadedMotions.size() <= MAX_MOTION_INSTANCES) - { - break; - } - } - else - { - // put active motion on back - mLoadedMotions.push_back(cur_motionp); + motions_to_kill.insert(cur_motionp->getID()); } } } + + // clean up all inactive, loaded motions + for (std::set::iterator motion_it = motions_to_kill.begin(); + motion_it != motions_to_kill.end(); + ++motion_it) + { + // look up the motion again by ID to get canonical instance + // and kill it only if that one is inactive + LLUUID motion_id = *motion_it; + LLMotion* motionp = findMotion(motion_id); + if (motionp && !isMotionActive(motionp)) + { + removeMotion(motion_id); + } + } + + // add new motion to loaded list mLoadedMotions.push_back(motionp); } @@ -280,14 +290,24 @@ void LLMotionController::removeMotion( const LLUUID& id) { LLMotion* motionp = findMotion(id); + + removeMotionInstance(motionp); + + mAllMotions.erase(id); +} + +// removes instance of a motion from all runtime structures, but does +// not erase entry by ID, as this could be a duplicate instance +// use removeMotion(id) to remove all references to a given motion by id. +void LLMotionController::removeMotionInstance(LLMotion* motionp) +{ if (motionp) { - stopMotionLocally(id, TRUE); + stopMotionInstance(motionp, TRUE); mLoadingMotions.erase(motionp); mLoadedMotions.remove(motionp); mActiveMotions.remove(motionp); - mAllMotions.erase(id); delete motionp; } } @@ -348,28 +368,39 @@ //----------------------------------------------------------------------------- BOOL LLMotionController::startMotion(const LLUUID &id, F32 start_offset) { - // look for motion in our list of created motions - LLMotion *motion = createMotion(id); + // do we have an instance of this motion for this character? + LLMotion *motion = findMotion(id); + + // motion that is stopping will be allowed to stop but + // replaced by a new instance of that motion + if (motion + && motion->canDeprecate() + && motion->getFadeWeight() > 0.01f // not LOD-ed out + && (motion->isBlending() || motion->getStopTime() != 0.f)) + { + deprecateMotionInstance(motion); + // force creation of new instance + motion = NULL; + } + + // create new motion instance + if (!motion) + { + motion = createMotion(id); + } if (!motion) { return FALSE; } - //if the motion is already active, then we're done - else if (isMotionActive(motion)) // motion is playing and... + //if the motion is already active and allows deprecation, then let it keep playing + else if (motion->canDeprecate() && isMotionActive(motion)) { - if (motion->isStopped()) // motion has been stopped - { - deactivateMotion(motion, false); - } - else if (mTime < motion->mSendStopTimestamp) // motion is still active - { - return TRUE; - } + return TRUE; } // llinfos << "Starting motion " << name << llendl; - return activateMotion(motion, mTime - start_offset); + return activateMotionInstance(motion, mTime - start_offset); } @@ -380,6 +411,12 @@ { // if already inactive, return false LLMotion *motion = findMotion(id); + + return stopMotionInstance(motion, stop_immediate); +} + +BOOL LLMotionController::stopMotionInstance(LLMotion* motion, BOOL stop_immediate) +{ if (!motion) { return FALSE; @@ -396,7 +433,7 @@ if (stop_immediate) { - deactivateMotion(motion, false); + deactivateMotionInstance(motion); } return TRUE; } @@ -492,7 +529,7 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - deactivateMotion(motionp, false); + deactivateMotionInstance(motionp); } else if (motionp->isStopped() && mTime > motionp->getStopTime()) { @@ -510,7 +547,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } else if (mTime >= motionp->mActivationTimestamp) @@ -538,7 +575,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -546,7 +583,8 @@ { if (motionp->isStopped() && mTime > motionp->getStopTime() + motionp->getEaseOutDuration()) { - deactivateMotion(motionp, true); + posep->setWeight(0.f); + deactivateMotionInstance(motionp); } continue; } @@ -572,7 +610,8 @@ } else { - deactivateMotion(motionp, true); + posep->setWeight(0.f); + deactivateMotionInstance(motionp); continue; } } @@ -617,7 +656,7 @@ if (mLastTime <= motionp->mSendStopTimestamp) { mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -661,7 +700,7 @@ // propagate this to the network // as not all viewers are guaranteed to have access to the same logic mCharacter->requestStopMotion( motionp ); - stopMotionLocally(motionp->getID(), FALSE); + stopMotionInstance(motionp, FALSE); } } @@ -733,7 +772,7 @@ // this motion should be playing if (!motionp->isStopped()) { - activateMotion(motionp, mTime); + activateMotionInstance(motionp, mTime); } } else if (status == LLMotion::STATUS_FAILURE) @@ -741,6 +780,7 @@ llinfos << "Motion " << motionp->getID() << " init failed." << llendl; sRegistry.markBad(motionp->getID()); mLoadingMotions.erase(curiter); + mAllMotions.erase(motionp->getID()); delete motionp; } @@ -773,9 +813,9 @@ //----------------------------------------------------------------------------- -// activateMotion() +// activateMotionInstance() //----------------------------------------------------------------------------- -BOOL LLMotionController::activateMotion(LLMotion *motion, F32 time) +BOOL LLMotionController::activateMotionInstance(LLMotion *motion, F32 time) { if (mLoadingMotions.find(motion) != mLoadingMotions.end()) { @@ -818,23 +858,38 @@ } //----------------------------------------------------------------------------- -// deactivateMotion() +// deactivateMotionInstance() //----------------------------------------------------------------------------- -BOOL LLMotionController::deactivateMotion(LLMotion *motion, bool remove_weight) +BOOL LLMotionController::deactivateMotionInstance(LLMotion *motion) { - if( remove_weight ) + motion->deactivate(); + + motion_set_t::iterator found_it = mDeprecatedMotions.find(motion); + if (found_it != mDeprecatedMotions.end()) { - // immediately remove pose weighting instead of letting it time out - LLPose *posep = motion->getPose(); - posep->setWeight(0.f); + // deprecated motions need to be completely excised + removeMotionInstance(motion); + mDeprecatedMotions.erase(found_it); + } + else + { + // for motions that we are keeping, simply remove from active queue + mActiveMotions.remove(motion); } - - motion->deactivate(); - mActiveMotions.remove(motion); return TRUE; } +void LLMotionController::deprecateMotionInstance(LLMotion* motion) +{ + mDeprecatedMotions.insert(motion); + + //fade out deprecated motion + stopMotionInstance(motion, FALSE); + //no longer canonical + mAllMotions.erase(motion->getID()); +} + //----------------------------------------------------------------------------- // isMotionActive() //----------------------------------------------------------------------------- @@ -857,7 +912,7 @@ //----------------------------------------------------------------------------- LLMotion *LLMotionController::findMotion(const LLUUID& id) { - return mAllMotions[id]; + return get_if_there(mAllMotions, id, NULL); } //----------------------------------------------------------------------------- diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llmotioncontroller.h sl1_18_2_0\linden-orig\indra/llcharacter/llmotioncontroller.h --- linden/indra/llcharacter/llmotioncontroller.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llmotioncontroller.h 2007-08-10 10:39:40.000000000 +0200 @@ -179,16 +179,21 @@ LLMotion *findMotion( const LLUUID& id ); protected: + // internal operations act on motion instances directly + // as there can be duplicate motions per id during blending overlap void deleteAllMotions(); void addLoadedMotion(LLMotion *motion); - BOOL activateMotion(LLMotion *motion, F32 time); - BOOL deactivateMotion(LLMotion *motion, bool remove_weight); + BOOL activateMotionInstance(LLMotion *motion, F32 time); + BOOL deactivateMotionInstance(LLMotion *motion); + void deprecateMotionInstance(LLMotion* motion); + BOOL stopMotionInstance(LLMotion *motion, BOOL stop_imemdiate); + void removeMotionInstance(LLMotion* motion); void updateRegularMotions(); void updateAdditiveMotions(); void resetJointSignatures(); void updateMotionsByType(LLMotion::LLMotionBlendType motion_type); -protected: +protected: F32 mTimeFactor; static LLMotionRegistry sRegistry; LLPoseBlender mPoseBlender; @@ -203,11 +208,13 @@ // Once an animations is loaded, it will be initialized and put on the mLoadedMotions deque. // Any animation that is currently playing also sits in the mActiveMotions list. - std::map mAllMotions; + typedef std::map motion_map_t; + motion_map_t mAllMotions; motion_set_t mLoadingMotions; motion_list_t mLoadedMotions; motion_list_t mActiveMotions; + motion_set_t mDeprecatedMotions; LLFrameTimer mTimer; F32 mTime; diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llpose.cpp sl1_18_2_0\linden-orig\indra/llcharacter/llpose.cpp --- linden/indra/llcharacter/llpose.cpp 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llpose.cpp 2007-08-10 10:39:40.000000000 +0200 @@ -275,9 +275,9 @@ joint_state_index < JSB_NUM_JOINT_STATES && mJointStates[joint_state_index] != NULL; joint_state_index++) { - U32 current_usage = mJointStates[joint_state_index]->getUsage(); - F32 current_weight = mJointStates[joint_state_index]->getWeight(); LLJointState* jsp = mJointStates[joint_state_index]; + U32 current_usage = jsp->getUsage(); + F32 current_weight = jsp->getWeight(); if (current_weight == 0.f) { @@ -292,17 +292,14 @@ // add in pos for this jointstate modulated by weight added_pos += jsp->getPosition() * (new_weight_sum - sum_weights[POS_WEIGHT]); - //sum_weights[POS_WEIGHT] = new_weight_sum; } - // now do scale if(current_usage & LLJointState::SCALE) { F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // add in scale for this jointstate modulated by weight added_scale += jsp->getScale() * (new_weight_sum - sum_weights[SCALE_WEIGHT]); - //sum_weights[SCALE_WEIGHT] = new_weight_sum; } if (current_usage & LLJointState::ROT) @@ -311,7 +308,6 @@ // add in rotation for this jointstate modulated by weight added_rot = nlerp((new_weight_sum - sum_weights[ROT_WEIGHT]), added_rot, jsp->getRotation()) * added_rot; - //sum_weights[ROT_WEIGHT] = new_weight_sum; } } else @@ -326,13 +322,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[POS_WEIGHT]); // blend positions from both - blended_pos = lerp(mJointStates[joint_state_index]->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); + blended_pos = lerp(jsp->getPosition(), blended_pos, sum_weights[POS_WEIGHT] / new_weight_sum); sum_weights[POS_WEIGHT] = new_weight_sum; } else { // copy position from current - blended_pos = mJointStates[joint_state_index]->getPosition(); + blended_pos = jsp->getPosition(); sum_weights[POS_WEIGHT] = current_weight; } } @@ -345,13 +341,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[SCALE_WEIGHT]); // blend scales from both - blended_scale = lerp(mJointStates[joint_state_index]->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); + blended_scale = lerp(jsp->getScale(), blended_scale, sum_weights[SCALE_WEIGHT] / new_weight_sum); sum_weights[SCALE_WEIGHT] = new_weight_sum; } else { // copy scale from current - blended_scale = mJointStates[joint_state_index]->getScale(); + blended_scale = jsp->getScale(); sum_weights[SCALE_WEIGHT] = current_weight; } } @@ -364,13 +360,13 @@ F32 new_weight_sum = llmin(1.f, current_weight + sum_weights[ROT_WEIGHT]); // blend rotations from both - blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, mJointStates[joint_state_index]->getRotation(), blended_rot); + blended_rot = nlerp(sum_weights[ROT_WEIGHT] / new_weight_sum, jsp->getRotation(), blended_rot); sum_weights[ROT_WEIGHT] = new_weight_sum; } else { // copy rotation from current - blended_rot = mJointStates[joint_state_index]->getRotation(); + blended_rot = jsp->getRotation(); sum_weights[ROT_WEIGHT] = current_weight; } } diff -urN -X srcdiff.ind --strip-trailing-cr linden/indra/llcharacter/llpose.h sl1_18_2_0\linden-orig\indra/llcharacter/llpose.h --- linden/indra/llcharacter/llpose.h 2007-07-11 15:19:44.000000000 +0200 +++ linden/indra/llcharacter/llpose.h 2007-08-10 10:39:40.000000000 +0200 @@ -81,7 +81,7 @@ S32 getNumJointStates() const; }; -const S32 JSB_NUM_JOINT_STATES = 4; +const S32 JSB_NUM_JOINT_STATES = 6; class LLJointStateBlender { -------------- next part -------------- --- linden-orig/indra/llcharacter/llkeyframemotion.h 2007-08-29 14:13:04.000000000 +0200 +++ linden/indra/llcharacter/llkeyframemotion.h 2007-09-04 00:58:44.656250000 +0200 @@ -40,6 +40,7 @@ #include "llhandmotion.h" #include "lljointstate.h" #include "llmotion.h" +#include "llmemory.h" #include "llptrskipmap.h" #include "llquaternion.h" #include "v3dmath.h" @@ -151,7 +152,7 @@ BOOL serialize(LLDataPacker& dp) const; BOOL deserialize(LLDataPacker& dp); void writeCAL3D(apr_file_t* fp); - BOOL isLoaded() { return mJointMotionList != NULL; } + BOOL isLoaded() { return mJointMotionList.notNull(); } // setters for modifying a keyframe animation @@ -391,10 +392,14 @@ //------------------------------------------------------------------------- // JointMotionList //------------------------------------------------------------------------- - class JointMotionList + class JointMotionList : public LLRefCount { + protected: + ~JointMotionList(); + public: U32 mNumJointMotions; + U64 mTimeLastCacheHit; JointMotion* mJointMotionArray; F32 mDuration; BOOL mLoop; @@ -410,7 +415,6 @@ LLBBoxLocal mPelvisBBox; public: JointMotionList(); - ~JointMotionList(); U32 dumpDiagInfo(); }; @@ -421,7 +425,7 @@ //------------------------------------------------------------------------- // Member Data //------------------------------------------------------------------------- - JointMotionList* mJointMotionList; + LLPointer mJointMotionList; LLJointState* mJointStates; LLJoint* mPelvisp; LLCharacter* mCharacter; @@ -441,13 +445,16 @@ LLKeyframeDataCache(){}; ~LLKeyframeDataCache(); - typedef std::map keyframe_data_map_t; + typedef std::map > keyframe_data_map_t; static keyframe_data_map_t sKeyframeDataMap; + static U64 sLastCacheCleanup; + static void addKeyframeData(const LLUUID& id, LLKeyframeMotion::JointMotionList*); static LLKeyframeMotion::JointMotionList* getKeyframeData(const LLUUID& id); static void removeKeyframeData(const LLUUID& id); + static void cleanupCache(int maxage = 0); //print out diagnostic info static void dumpDiagInfo(); --- linden-orig/indra/llcharacter/llkeyframemotion.cpp 2007-08-29 14:13:04.000000000 +0200 +++ linden/indra/llcharacter/llkeyframemotion.cpp 2007-09-04 01:43:02.343750000 +0200 @@ -42,6 +42,7 @@ #include "llkeyframemotion.h" #include "llquantize.h" #include "llvfile.h" +#include "lltimer.h" #include "m3math.h" #include "message.h" @@ -50,6 +51,8 @@ //----------------------------------------------------------------------------- LLVFS* LLKeyframeMotion::sVFS = NULL; LLKeyframeDataCache::keyframe_data_map_t LLKeyframeDataCache::sKeyframeDataMap; +U64 LLKeyframeDataCache::sLastCacheCleanup; + //----------------------------------------------------------------------------- // Globals @@ -69,6 +72,7 @@ //----------------------------------------------------------------------------- LLKeyframeMotion::JointMotionList::JointMotionList() : mNumJointMotions(0), + mTimeLastCacheHit(0), mJointMotionArray(NULL) { } @@ -1858,8 +1862,7 @@ //----------------------------------------------------------------------------- void LLKeyframeMotion::flushKeyframeCache() { - // TODO: Make this safe to do -// LLKeyframeDataCache::clear(); + LLKeyframeDataCache::clear(); } //----------------------------------------------------------------------------- @@ -2102,6 +2105,7 @@ //-------------------------------------------------------------------- void LLKeyframeDataCache::addKeyframeData(const LLUUID& id, LLKeyframeMotion::JointMotionList* joint_motion_listp) { + joint_motion_listp->mTimeLastCacheHit = (U64)LLTimer::getTotalSeconds(); sKeyframeDataMap[id] = joint_motion_listp; } @@ -2113,7 +2117,6 @@ keyframe_data_map_t::iterator found_data = sKeyframeDataMap.find(id); if (found_data != sKeyframeDataMap.end()) { - delete found_data->second; sKeyframeDataMap.erase(found_data); } } @@ -2128,6 +2131,11 @@ { return NULL; } + + found_data->second->mTimeLastCacheHit = (U64)LLTimer::getTotalSeconds(); + + cleanupCache(); + return found_data->second; } @@ -2139,12 +2147,72 @@ clear(); } + +//----------------------------------------------------------------------------- +// flush older entries +//----------------------------------------------------------------------------- +void LLKeyframeDataCache::cleanupCache(S32 maxage) +{ + U64 now = (U64)LLTimer::getTotalSeconds(); + + if (0 == sLastCacheCleanup) + { + sLastCacheCleanup = now; + return; + } + + if (now-sLastCacheCleanup > 60 || maxage != 0) + { + S32 count = sKeyframeDataMap.size(); + S32 deleted = 0; + + if (0 == maxage) { + // lifetime of 30 min - 5 min depending on #of entries (0 - 250+) + maxage = 60 * (S32)(30.f - llclamp((F32)count/10, 0.f, 25.f)); + } + + llinfos << "before: " << count << " entries, flushing with maxage " << maxage << llendl; + + for (keyframe_data_map_t::iterator map_it = sKeyframeDataMap.begin(); + map_it != sKeyframeDataMap.end(); + ) + { + LLPointer motion_list_p = map_it->second; + + U64 age = now - motion_list_p->mTimeLastCacheHit; + if (age > maxage) + { + llinfos << " erasing JointMotionList " + << map_it->first + << " from sKeyframeDataMap" + << llendl; + keyframe_data_map_t::iterator tmp_it = map_it; + ++map_it; + sKeyframeDataMap.erase(tmp_it); + deleted++; + } + else + { + ++map_it; + } + } + + if (deleted>0) + { + llinfos << "after: " << sKeyframeDataMap.size() << " (-" << deleted << ") entries " << llendl; + } + + sLastCacheCleanup = now; + } + +} + //----------------------------------------------------------------------------- // clear() //----------------------------------------------------------------------------- void LLKeyframeDataCache::clear() { - for_each(sKeyframeDataMap.begin(), sKeyframeDataMap.end(), DeletePairedPointer()); + // dumpDiagInfo(); sKeyframeDataMap.clear(); } --- linden-orig/indra/newview/llviewermessage.cpp 2007-08-29 14:13:08.000000000 +0200 +++ linden/indra/newview/llviewermessage.cpp 2007-09-04 02:05:20.234375000 +0200 @@ -93,6 +93,7 @@ #include "llimpanel.h" #include "llinventorymodel.h" #include "llinventoryview.h" +#include "llkeyframemotion.h" #include "llmenugl.h" #include "llmutelist.h" #include "llnetmap.h" @@ -1189,9 +1190,17 @@ return; } + // NICHOLAZ: KLUDGE to unclutter the server side message + LLString::format_map_t repl; + LLString msg = info->mDesc; + repl[" ( http://slurl.com/secondlife/"] = "("; + repl[" )"] = ")"; + LLString::format(msg, repl); + LLString::format_map_t args; - args["[OBJECTNAME]"] = info->mDesc; + args["[OBJECTNAME]"] = msg; args["[OBJECTTYPE]"] = LLAssetType::lookupHumanReadable(info->mType); + // ~NICHOLAZ // Name cache callbacks don't store userdata, so can't save // off the LLOfferInfo. Argh. JC @@ -2714,6 +2723,8 @@ llinfos << "Changing home region to " << x << ":" << y << llendl; + LLKeyframeDataCache::cleanupCache(60); + // set our upstream host the new simulator and shuffle things as // appropriate. LLVector3 shift_vector = regionp->getPosRegionFromGlobal( From blakar at gmail.com Tue Sep 4 06:04:50 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Sep 4 06:04:53 2007 Subject: [sldev] [VIEWER] Dead code removal Message-ID: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> I've been working on particles and have run into quite a lot of dead code. What are we supposed to do with it? I consider it dead if: a) It's a class, method ... that is never referenced (or only referenced by elements that are in turn dead) b) A conditional statement that has only one possible result is keeping the code from being executed c) The code is executed but the result is unused d) It's a placeholder returning a default value. Personally I'd like to remove all of it. More extensive reasoning for each case: a) The logic in unreferenced code hasn't been tested ever since it became dead. As such newer changes may have invalidated the code or may conflict with it. Yet people will feel inclined to bring it back from the dead or may reference it without knowing it's no longer up to date. b) Same as in case a applies and additionally there are other concerns. The condition will most likely still eat CPU cycles and you're likely wasting memory on the code and it's data elements as the compiler can't always see the condition will never be met. c) This is a tricky one. In come cases there's code that seems just fine but somewhere else the results are thrown away and replaced. As such the code results into nothing and there's no knowing whether the result would have had value. This can also eat a lot of CPU cycles if the dead part is CPU intensive (there is in fact pointless code in loops). d) Several functions just return simple values while they are supposed to do true calculations. This gives a bit of useless overhead and it makes the code ugly and hard to understand. While it does point out sometimes that something is missing it does at the same time hide that things are missing as not everybody will check whether a method really returns somethings useful or not. Is it ok to submit a patch for this? I've split my particles stuff in pieces and the first part of it now is an extensive dead code removal patch (only for particle related dead code off course). It helps speed up code as it removes CPU and memory taxing pieces and it also makes the code easier to understand and read. Dirk aka Blakar Ogre From adam at gwala.net Tue Sep 4 06:09:13 2007 From: adam at gwala.net (Adam Frisby) Date: Tue Sep 4 06:11:01 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> Message-ID: <46DD58F9.2030702@gwala.net> Remember -- "a" and "b" can come from the server code which shares a lot of code with the viewer. Be careful when submitting patches that removes classes like that, since it may still be required for the sim. Adam Dirk Moerenhout wrote: > I've been working on particles and have run into quite a lot of dead > code. What are we supposed to do with it? > > I consider it dead if: > a) It's a class, method ... that is never referenced (or only > referenced by elements that are in turn dead) > b) A conditional statement that has only one possible result is > keeping the code from being executed > c) The code is executed but the result is unused > d) It's a placeholder returning a default value. > > > Personally I'd like to remove all of it. More extensive reasoning for each case: > a) The logic in unreferenced code hasn't been tested ever since it > became dead. As such newer changes may have invalidated the code or > may conflict with it. Yet people will feel inclined to bring it back > from the dead or may reference it without knowing it's no longer up to > date. > > b) Same as in case a applies and additionally there are other > concerns. The condition will most likely still eat CPU cycles and > you're likely wasting memory on the code and it's data elements as the > compiler can't always see the condition will never be met. > > c) This is a tricky one. In come cases there's code that seems just > fine but somewhere else the results are thrown away and replaced. As > such the code results into nothing and there's no knowing whether the > result would have had value. This can also eat a lot of CPU cycles if > the dead part is CPU intensive (there is in fact pointless code in > loops). > > d) Several functions just return simple values while they are supposed > to do true calculations. This gives a bit of useless overhead and it > makes the code ugly and hard to understand. While it does point out > sometimes that something is missing it does at the same time hide that > things are missing as not everybody will check whether a method really > returns somethings useful or not. > > Is it ok to submit a patch for this? I've split my particles stuff in > pieces and the first part of it now is an extensive dead code removal > patch (only for particle related dead code off course). It helps speed > up code as it removes CPU and memory taxing pieces and it also makes > the code easier to understand and read. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Tue Sep 4 06:22:58 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Sep 4 06:23:02 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <46DD58F9.2030702@gwala.net> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> Message-ID: <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> True but I'm mostly referring to parts of newview and I hope it is at least so that this is never used by the server code. It might even be a good question: What do we really share with the server code? I guess we probably share llcommon but what other parts are dangerous too? Dirk aka Blakar Ogre On 9/4/07, Adam Frisby wrote: > Remember -- "a" and "b" can come from the server code which shares a lot > of code with the viewer. Be careful when submitting patches that removes > classes like that, since it may still be required for the sim. > > Adam > > Dirk Moerenhout wrote: > > > I've been working on particles and have run into quite a lot of dead > > code. What are we supposed to do with it? > > > > I consider it dead if: > > a) It's a class, method ... that is never referenced (or only > > referenced by elements that are in turn dead) > > b) A conditional statement that has only one possible result is > > keeping the code from being executed > > c) The code is executed but the result is unused > > d) It's a placeholder returning a default value. > > > > > > Personally I'd like to remove all of it. More extensive reasoning for each case: > > a) The logic in unreferenced code hasn't been tested ever since it > > became dead. As such newer changes may have invalidated the code or > > may conflict with it. Yet people will feel inclined to bring it back > > from the dead or may reference it without knowing it's no longer up to > > date. > > > > b) Same as in case a applies and additionally there are other > > concerns. The condition will most likely still eat CPU cycles and > > you're likely wasting memory on the code and it's data elements as the > > compiler can't always see the condition will never be met. > > > > c) This is a tricky one. In come cases there's code that seems just > > fine but somewhere else the results are thrown away and replaced. As > > such the code results into nothing and there's no knowing whether the > > result would have had value. This can also eat a lot of CPU cycles if > > the dead part is CPU intensive (there is in fact pointless code in > > loops). > > > > d) Several functions just return simple values while they are supposed > > to do true calculations. This gives a bit of useless overhead and it > > makes the code ugly and hard to understand. While it does point out > > sometimes that something is missing it does at the same time hide that > > things are missing as not everybody will check whether a method really > > returns somethings useful or not. > > > > Is it ok to submit a patch for this? I've split my particles stuff in > > pieces and the first part of it now is an extensive dead code removal > > patch (only for particle related dead code off course). It helps speed > > up code as it removes CPU and memory taxing pieces and it also makes > > the code easier to understand and read. > > > > Dirk aka Blakar Ogre > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > From nicholaz at blueflash.cc Tue Sep 4 06:26:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 4 06:26:59 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> Message-ID: <46DD5D1B.3070400@blueflash.cc> Dirk Moerenhout wrote: > Is it ok to submit a patch for this? I've split my particles stuff in > pieces and the first part of it now is an extensive dead code removal > patch (only for particle related dead code off course). It helps speed > up code as it removes CPU and memory taxing pieces and it also makes > the code easier to understand and read. If you have the patch already anyway, why not submit it? I've done this with source cleanups in the past, some have been accepted, others not. But if you don't submit, they can't decide. It may be different if you had to decide upfront if you invest effort, but now you seem to have it ... Besides, submitting has the benefit that others could use it. I for example would be interested in applying dead code removal to my builds (as well as your other improvements of course :-)). Or just post the stuff here ... > Remember -- "a" and "b" can come from the server code which shares a > lot of code with the viewer. Be careful when submitting patches that > removes classes like that, since it may still be required for the sim. I don't think the risk is too high that particle related stuff will affect the server side, but anyway, the Lindens will find out when they apply it :-) Nick From soft at lindenlab.com Tue Sep 4 07:08:59 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 4 07:09:02 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> Message-ID: <9e6e5c9e0709040708g52e8651ey190c83fd999ff7c3@mail.gmail.com> On 9/4/07, Dirk Moerenhout wrote: > I've been working on particles and have run into quite a lot of dead > code. What are we supposed to do with it? > > I consider it dead if: > a) It's a class, method ... that is never referenced (or only > referenced by elements that are in turn dead) > b) A conditional statement that has only one possible result is > keeping the code from being executed > c) The code is executed but the result is unused > d) It's a placeholder returning a default value. > > > Personally I'd like to remove all of it. I'd ask case by case on the list if you want to ensure you're not burning up a lot of time on excising something that's actually there by design. But in a system that's been reworked a number of times, such as particles, it's almost certain that there's cruft left over. The same goes for stripping out dead code that goes with other kinds of cleanup: If you're near it, do it. Just be careful that you don't overreach and create a ten file patch for a one file feature. Past some point, cleanup gets riskier than crufty but tested, code. From nicholaz at blueflash.cc Tue Sep 4 08:01:04 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 4 08:01:13 2007 Subject: [sldev] [VIEWER][PATCH][BUG][JIRA] Problems displaying parcel voice status when voice turned off Message-ID: <46DD7330.4040601@blueflash.cc> Can someone please have a look at my last comment on https://jira.secondlife.com/browse/VWR-2142 It's a one liner (in the comment) but I'm not sure if I'm missing something. Nick From lenglish5 at cox.net Tue Sep 4 08:24:56 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 4 08:24:57 2007 Subject: [sldev] NSV Support In-Reply-To: References: Message-ID: <46DD78C8.4070200@cox.net> Ernie Kabowski wrote: >> gstreamer is available on windows as well.... I'd think getting rid of >> the quicktime reliance would be a good direction to go. >> > > >>> If gstreamer can seamlessly wrap itself around DirectShow/Windows Media >>> on Win32, and Quicktime on OSX, this just might be wonderful. >>> > > >>> The problem is, media codecs are a patent licensing minefield. By using >>> Quicktime and/or DirectShow, you push the responsibility and liability >>> for proper licensing onto Microsoft and Apple, who have already taken >>> care of it, and conveniently placed codecs for MP3 and MPEG4 and whatnot >>> on everyone's systems for you. >>> > > The Apple media playback API has little to no streaming capabilitys in it's > own format. Plugins are cool if you want to constantly remind people to > install them, and provide support and documentation for all. Most players are > NT users or Desktop Linux system users. > ??? QT on the Web predates most other formats for web streaming of audio and video and the current server versions seem quite feature-laden, though I'm not familiar with Real Player's or Microsoft's or the NSV equivalents, so I can't make comparisons: http://images.apple.com/server/docs/QuickTime_Streaming_TB_v10.4.pdf Perhaps you're thinking that the client QT player is all that is available as far as providing server functions for QuickTime? > If I'm not mistaken all the viewers use FMOD for sound, so that covers a lot > of audio codecs, and the module is very dynamic with codecs. I worked with it > years back, and implement OGG, Shoutcast, and Icecast for a 3D game using it's > sensor functions and buffering. I was impressed with it. > > I can't think of anything else to do with the source outside of fixing there > physics and rendering algorithms. I barely got threw threw 10 hours of Calc > II though so I'll not touch those. NSV just seemed cool cause you didn't have > the 2+ minute waiting period for a 11MB video to load on a 1.5Mbps downstream. > > I also researched it's license. It's a GNU friendly license. The content > Infringement Policy's are the responsibility of the owner of the streamserver. > > PS: What's with the Pokemon style retort with a hint of profanity? > > ____________________________________________________________ > FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! > Check it out at http://www.inbox.com/earth > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From lenglish5 at cox.net Tue Sep 4 09:11:35 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 4 09:11:37 2007 Subject: [sldev] framework documentation pattern Message-ID: <46DD83B7.4010808@cox.net> Lawson English wrote: > > On a related note, I'm learning much about the existing classes as I > try to figure out how to do what I want. What is the proper format for > documenting the classes and how they are used? > I'm putting this issue in its own thread. I couldn't find anything on the wiki about how the framework should be documented, so I'm proposing something along the lines of Apple's Cocoa framework documentation, though probably nothing quite as elaborate: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSOutlineView_Class/index.html#//apple_ref/doc/uid/TP40004079 As an aside, there are huge amounts of work that can/should be done to make these frameworks more usable, up to and including an entire rewrite. Several classes stand out as being kitchen sink classes and should definitely be rewritten such as llInventoryPanel and the viewer class itself. A REAL rewrite will need to await rewriting of the lower level classes, though at least some work can be done using the existing classes (I hope). The LLSD class seems to be designed to allow better communication between framework objects, among other uses, so any redesigned classes should probably use LLSD when talking to each other. This last is only the vaguest of intuitions on my part, so feel free to gently correct me if I'm wrong about its intended use or the utility of using it when rewriting the framework. From nicholaz at blueflash.cc Tue Sep 4 09:42:38 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 4 09:42:58 2007 Subject: [sldev] [SOURCE] llkdu.dll in 1.18.3.2 windows library pack broken? Message-ID: <46DD8AFE.6090108@blueflash.cc> I just had a few crashes rebaking and uploading and found that it seems that the llkdu.dll that comes with the release libs for Windows seems to be different from the one coming with the viewer. Replacing one with the other did fix the problems. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From soft at lindenlab.com Tue Sep 4 09:48:56 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 4 09:49:00 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> Message-ID: <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> Actually, authentication is provided by that cap URL, ie you've told people how to look up map data via your own Second Life account. In some ways, this is like sharing a php session key. Be very careful about which of those you share. In this case, I don't know that there's a way to use that cap to elevate privileges in any way, but others may have non-obvious side-effects. On 9/1/07, Harold Brown wrote: > The cap URLS I posted do not require authentication, and as such appear to > be static at the moment > > On 9/1/07, Dale Glass wrote: > > On Friday 31 August 2007 23:09:18 Harold Brown wrote: > > > They are there now. > > [snip] > > > There is also the reverse: > > > > > > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s > > >lRegionName&grid_x=997&grid_y=1002 > > > > > > It returns: > > > > > > var slRegionName='Ahern'; > > > > Ok, I've googled around a bit and found this: > > > > > https://secure-web5.secondlife.com/developers/third_party_reg/ > > > > I guess that works as the documentation I wanted. > > > > I tried the form there and it only returns get_error_codes. > > > > Now, it says there: "Avoid hardcoding in your capabilities urls." and > "Keep > > your capability urls secret!". > > > > So how do I obtain the capability URL as needed if it's not listed there? > > > > Will this functionality be available to everybody? It's not much good for > me > > unless everybody can use it (excepting the sim position to key feature > > request below) > > > > Also, while the sim name from region xy request works for me, I would > prefer a > > direct key to sim name function, as well as xy to key. First one would > avoid > > the intermediate key to region id lookup, second one would allow me to > build > > my database much more easily (which then would ship with the viewer, > avoiding > > most lookups) From soft at lindenlab.com Tue Sep 4 09:53:58 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 4 09:54:00 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> Message-ID: <9e6e5c9e0709040953i5a286b8pe55a8408512181e6@mail.gmail.com> Strike that - this conversation is still going on at LL... Apparently someone hard-coded their own caps in the map javascript. The same point stands about being careful with sharing caps URLs, but in this case it's not Harold's login that's the one being used willy nilly. :) On 9/4/07, Soft Linden wrote: > Actually, authentication is provided by that cap URL, ie you've told > people how to look up map data via your own Second Life account. In > some ways, this is like sharing a php session key. > > Be very careful about which of those you share. In this case, I don't > know that there's a way to use that cap to elevate privileges in any > way, but others may have non-obvious side-effects. > > On 9/1/07, Harold Brown wrote: > > The cap URLS I posted do not require authentication, and as such appear to > > be static at the moment > > > > On 9/1/07, Dale Glass wrote: > > > On Friday 31 August 2007 23:09:18 Harold Brown wrote: > > > > They are there now. > > > [snip] > > > > There is also the reverse: > > > > > > > > > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s > > > >lRegionName&grid_x=997&grid_y=1002 > > > > > > > > It returns: > > > > > > > > var slRegionName='Ahern'; > > > > > > Ok, I've googled around a bit and found this: > > > > > > > > https://secure-web5.secondlife.com/developers/third_party_reg/ > > > > > > I guess that works as the documentation I wanted. > > > > > > I tried the form there and it only returns get_error_codes. > > > > > > Now, it says there: "Avoid hardcoding in your capabilities urls." and > > "Keep > > > your capability urls secret!". > > > > > > So how do I obtain the capability URL as needed if it's not listed there? > > > > > > Will this functionality be available to everybody? It's not much good for > > me > > > unless everybody can use it (excepting the sim position to key feature > > > request below) > > > > > > Also, while the sim name from region xy request works for me, I would > > prefer a > > > direct key to sim name function, as well as xy to key. First one would > > avoid > > > the intermediate key to region id lookup, second one would allow me to > > build > > > my database much more easily (which then would ship with the viewer, > > avoiding > > > most lookups) > From bos at lindenlab.com Tue Sep 4 10:01:03 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Sep 4 10:01:05 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> Message-ID: <46DD8F4F.6010005@lindenlab.com> Dirk Moerenhout wrote: > True but I'm mostly referring to parts of newview and I hope it is at > least so that this is never used by the server code. It's best to keep the dead code removal in a patch of its own. That makes it easier for us to review patches. > It might even be > a good question: What do we really share with the server code? I guess > we probably share llcommon but what other parts are dangerous too? You can see the exact lists of libraries that the viewer and server depend on in the SConstruct file that ships with the source. A lot of the libraries are shared. The easiest rule of thumb is to assume that any ll* directory that isn't related to drawing windows or other bits of UI is likely to be shared with the server code. References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> <46DD8F4F.6010005@lindenlab.com> Message-ID: <46DD976D.8070501@cox.net> Bryan O'Sullivan wrote: > Dirk Moerenhout wrote: >> True but I'm mostly referring to parts of newview and I hope it is at >> least so that this is never used by the server code. > > It's best to keep the dead code removal in a patch of its own. That > makes it easier for us to review patches. > >> It might even be >> a good question: What do we really share with the server code? I guess >> we probably share llcommon but what other parts are dangerous too? > > You can see the exact lists of libraries that the viewer and server > depend on in the SConstruct file that ships with the source. > > A lot of the libraries are shared. The easiest rule of thumb is to > assume that any ll* directory that isn't related to drawing windows or > other bits of UI is likely to be shared with the server code. I'm confused... The client build ships with server-only libraries included? From kelly at lindenlab.com Tue Sep 4 10:38:11 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Sep 4 10:38:13 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <46DD976D.8070501@cox.net> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> <46DD8F4F.6010005@lindenlab.com> <46DD976D.8070501@cox.net> Message-ID: <46DD9803.8090701@lindenlab.com> Lawson English wrote: > Bryan O'Sullivan wrote: >> Dirk Moerenhout wrote: >>> True but I'm mostly referring to parts of newview and I hope it is at >>> least so that this is never used by the server code. >> >> It's best to keep the dead code removal in a patch of its own. That >> makes it easier for us to review patches. >> >>> It might even be >>> a good question: What do we really share with the server code? I guess >>> we probably share llcommon but what other parts are dangerous too? >> >> You can see the exact lists of libraries that the viewer and server >> depend on in the SConstruct file that ships with the source. >> >> A lot of the libraries are shared. The easiest rule of thumb is to >> assume that any ll* directory that isn't related to drawing windows >> or other bits of UI is likely to be shared with the server code. > > I'm confused... The client build ships with server-only libraries > included? > > No, but some of the libraries used by the client are also used by the servers. This means that some code in the libraries that appears to be 'dead' from the viewer perspective may not be, if any of the server code relies on it. - Kelly From lenglish5 at cox.net Tue Sep 4 10:57:50 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 4 10:57:51 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <46DD9803.8090701@lindenlab.com> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> <46DD8F4F.6010005@lindenlab.com> <46DD976D.8070501@cox.net> <46DD9803.8090701@lindenlab.com> Message-ID: <46DD9C9E.8090309@cox.net> Kelly Linden wrote: > Lawson English wrote: > >> Bryan O'Sullivan wrote: >> >>> Dirk Moerenhout wrote: >>> >>>> True but I'm mostly referring to parts of newview and I hope it is at >>>> least so that this is never used by the server code. >>>> >>> It's best to keep the dead code removal in a patch of its own. That >>> makes it easier for us to review patches. >>> >>> >>>> It might even be >>>> a good question: What do we really share with the server code? I guess >>>> we probably share llcommon but what other parts are dangerous too? >>>> >>> You can see the exact lists of libraries that the viewer and server >>> depend on in the SConstruct file that ships with the source. >>> >>> A lot of the libraries are shared. The easiest rule of thumb is to >>> assume that any ll* directory that isn't related to drawing windows >>> or other bits of UI is likely to be shared with the server code. >>> >> I'm confused... The client build ships with server-only libraries >> included? >> >> >> > No, but some of the libraries used by the client are also used by the > servers. This means that some code in the libraries that appears to be > 'dead' from the viewer perspective may not be, if any of the server code > relies on it. > > - Kelly > > Pardon me if this sounds like a bad library design to me, unless that code is definitely designeed to be "dual use" between client and server like common definitions and communications modules, and in that case, it should be factored into its own files and placed in the "common" if I understand what that is for. (I'm on a refactoring warpath with the GUI, sorry if I sound a bit extreme today). From nicholaz at blueflash.cc Tue Sep 4 11:03:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 4 11:03:35 2007 Subject: [sldev] [VIEWER] Uploads crashing on RC 1.18.3 In-Reply-To: <46DCA6A3.7090308@blueflash.cc> References: <46DCA6A3.7090308@blueflash.cc> Message-ID: <46DD9DEE.5050009@blueflash.cc> Seems to have been the LLKDU.DLL shipped with the library pack from the 1.18.3RC. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford wrote: > > Did anyone else see texture uploads crashing on > the current RC? Had it a few times now, but > couldn't nail it yet. > > > Nick From kelly at lindenlab.com Tue Sep 4 11:16:37 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Sep 4 11:16:40 2007 Subject: [sldev] [VIEWER] Dead code removal In-Reply-To: <46DD9C9E.8090309@cox.net> References: <7992d0d60709040604q590e2c14v94cac0e97a64f8fe@mail.gmail.com> <46DD58F9.2030702@gwala.net> <7992d0d60709040622g3b99d748tf48780a1651212c4@mail.gmail.com> <46DD8F4F.6010005@lindenlab.com> <46DD976D.8070501@cox.net> <46DD9803.8090701@lindenlab.com> <46DD9C9E.8090309@cox.net> Message-ID: <46DDA105.9090506@lindenlab.com> Lawson English wrote: > Kelly Linden wrote: >> Lawson English wrote: >> >>> Bryan O'Sullivan wrote: >>> >>>> Dirk Moerenhout wrote: >>>> >>>>> True but I'm mostly referring to parts of newview and I hope it is at >>>>> least so that this is never used by the server code. >>>>> >>>> It's best to keep the dead code removal in a patch of its own. That >>>> makes it easier for us to review patches. >>>> >>>> >>>>> It might even be >>>>> a good question: What do we really share with the server code? I >>>>> guess >>>>> we probably share llcommon but what other parts are dangerous too? >>>>> >>>> You can see the exact lists of libraries that the viewer and server >>>> depend on in the SConstruct file that ships with the source. >>>> >>>> A lot of the libraries are shared. The easiest rule of thumb is to >>>> assume that any ll* directory that isn't related to drawing windows >>>> or other bits of UI is likely to be shared with the server code. >>>> >>> I'm confused... The client build ships with server-only libraries >>> included? >>> >>> >>> >> No, but some of the libraries used by the client are also used by the >> servers. This means that some code in the libraries that appears to be >> 'dead' from the viewer perspective may not be, if any of the server code >> relies on it. >> >> - Kelly >> >> > Pardon me if this sounds like a bad library design to me, unless that > code is definitely designeed to be "dual use" between client and > server like common definitions and communications modules, and in that > case, it should be factored into its own files and placed in the > "common" if I understand what that is for. > > (I'm on a refactoring warpath with the GUI, sorry if I sound a bit > extreme today). > The cases where this happens the code is indeed definitely designed to be "dual use" and are generally common definitions - although not always of communications modules. The server and client often need to share a lot of data - to have a common representation of what an inventory item is or a parcel is for example. That isn't to say it couldn't be better designed, there are LOTS of places where the code could be better designed, as I'm sure you are aware if you are on a refactoring warpath. Most of the cases of shared code though aren't that bad, and the alternatives could be worse. Could you imagine the pain of a permissions system implemented separately in the viewer and the server? It is bad enough as it is. :) For the over all project layout, it should probably be clearer where this happens. Perhaps llcommon should really be a directory with many projects in it, rather than the single project is it now, although I think there may be reasons we have preferred a flatter hierarchy. - Kelly From rdw at lindenlab.com Tue Sep 4 11:18:05 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Sep 4 11:18:07 2007 Subject: [sldev] framework documentation pattern In-Reply-To: <46DD83B7.4010808@cox.net> References: <46DD83B7.4010808@cox.net> Message-ID: <46DDA15D.5090209@lindenlab.com> Lawson English wrote: > > The LLSD class seems to be designed to allow better communication > between framework objects, among other uses, so any redesigned classes > should probably use LLSD when talking to each other. This last is only > the vaguest of intuitions on my part, so feel free to gently correct > me if I'm wrong about its intended use or the utility of using it when > rewriting the framework. Sounds right to me. :-) Though of course LLSD is not the hammer for every nail. -RYaN From odysseus654 at gmail.com Tue Sep 4 13:30:15 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Tue Sep 4 13:30:17 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <9e6e5c9e0709040953i5a286b8pe55a8408512181e6@mail.gmail.com> References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> <9e6e5c9e0709040953i5a286b8pe55a8408512181e6@mail.gmail.com> Message-ID: <1674f6c70709041330v504285f7xfd2e0f8e513776a0@mail.gmail.com> Sounds like what we need is a "nobody Linden" that can be used to provide public and published CAPS services without worrying about compromising someone's account... On 9/4/07, Soft Linden wrote: > > Strike that - this conversation is still going on at LL... > > Apparently someone hard-coded their own caps in the map javascript. > The same point stands about being careful with sharing caps URLs, but > in this case it's not Harold's login that's the one being used willy > nilly. :) > > On 9/4/07, Soft Linden wrote: > > Actually, authentication is provided by that cap URL, ie you've told > > people how to look up map data via your own Second Life account. In > > some ways, this is like sharing a php session key. > > > > Be very careful about which of those you share. In this case, I don't > > know that there's a way to use that cap to elevate privileges in any > > way, but others may have non-obvious side-effects. > > > > On 9/1/07, Harold Brown wrote: > > > The cap URLS I posted do not require authentication, and as such > appear to > > > be static at the moment > > > > > > On 9/1/07, Dale Glass wrote: > > > > On Friday 31 August 2007 23:09:18 Harold Brown wrote: > > > > > They are there now. > > > > [snip] > > > > > There is also the reverse: > > > > > > > > > > > > > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s > > > > >lRegionName&grid_x=997&grid_y=1002 > > > > > > > > > > It returns: > > > > > > > > > > var slRegionName='Ahern'; > > > > > > > > Ok, I've googled around a bit and found this: > > > > > > > > > > > https://secure-web5.secondlife.com/developers/third_party_reg/ > > > > > > > > I guess that works as the documentation I wanted. > > > > > > > > I tried the form there and it only returns get_error_codes. > > > > > > > > Now, it says there: "Avoid hardcoding in your capabilities urls." > and > > > "Keep > > > > your capability urls secret!". > > > > > > > > So how do I obtain the capability URL as needed if it's not listed > there? > > > > > > > > Will this functionality be available to everybody? It's not much > good for > > > me > > > > unless everybody can use it (excepting the sim position to key > feature > > > > request below) > > > > > > > > Also, while the sim name from region xy request works for me, I > would > > > prefer a > > > > direct key to sim name function, as well as xy to key. First one > would > > > avoid > > > > the intermediate key to region id lookup, second one would allow me > to > > > build > > > > my database much more easily (which then would ship with the viewer, > > > avoiding > > > > most lookups) > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070904/7aa63fc0/attachment.htm From xotmid at gmail.com Tue Sep 4 13:41:25 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Tue Sep 4 13:41:29 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <1674f6c70709041330v504285f7xfd2e0f8e513776a0@mail.gmail.com> References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> <9e6e5c9e0709040953i5a286b8pe55a8408512181e6@mail.gmail.com> <1674f6c70709041330v504285f7xfd2e0f8e513776a0@mail.gmail.com> Message-ID: Why would you want logging the slurl thing already sucks... Now people can know where your updators are and grief em... Whats next attachments reporting? I am curious why you would want to have it show the im.. kinda sucks. and its spamtastic. On 9/4/07, Erik Anderson wrote: > Sounds like what we need is a "nobody Linden" that can be used to provide > public and published CAPS services without worrying about compromising > someone's account... > > > On 9/4/07, Soft Linden wrote: > > Strike that - this conversation is still going on at LL... > > > > Apparently someone hard-coded their own caps in the map javascript. > > The same point stands about being careful with sharing caps URLs, but > > in this case it's not Harold's login that's the one being used willy > > nilly. :) > > > > On 9/4/07, Soft Linden wrote: > > > Actually, authentication is provided by that cap URL, ie you've told > > > people how to look up map data via your own Second Life account. In > > > some ways, this is like sharing a php session key. > > > > > > Be very careful about which of those you share. In this case, I don't > > > know that there's a way to use that cap to elevate privileges in any > > > way, but others may have non-obvious side-effects. > > > > > > On 9/1/07, Harold Brown wrote: > > > > The cap URLS I posted do not require authentication, and as such > appear to > > > > be static at the moment > > > > > > > > On 9/1/07, Dale Glass wrote: > > > > > On Friday 31 August 2007 23:09:18 Harold Brown wrote: > > > > > > They are there now. > > > > > [snip] > > > > > > There is also the reverse: > > > > > > > > > > > > > > > > > https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=s > > > > > >lRegionName&grid_x=997&grid_y=1002 > > > > > > > > > > > > It returns: > > > > > > > > > > > > var slRegionName='Ahern'; > > > > > > > > > > Ok, I've googled around a bit and found this: > > > > > > > > > > > > > > > https://secure-web5.secondlife.com/developers/third_party_reg/ > > > > > > > > > > I guess that works as the documentation I wanted. > > > > > > > > > > I tried the form there and it only returns get_error_codes. > > > > > > > > > > Now, it says there: "Avoid hardcoding in your capabilities urls." > and > > > > "Keep > > > > > your capability urls secret!". > > > > > > > > > > So how do I obtain the capability URL as needed if it's not listed > there? > > > > > > > > > > Will this functionality be available to everybody? It's not much > good for > > > > me > > > > > unless everybody can use it (excepting the sim position to key > feature > > > > > request below) > > > > > > > > > > Also, while the sim name from region xy request works for me, I > would > > > > prefer a > > > > > direct key to sim name function, as well as xy to key. First one > would > > > > avoid > > > > > the intermediate key to region id lookup, second one would allow me > to > > > > build > > > > > my database much more easily (which then would ship with the viewer, > > > > avoiding > > > > > most lookups) > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From kamilion at gmail.com Tue Sep 4 13:55:58 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Sep 4 13:56:02 2007 Subject: [sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location In-Reply-To: References: <200708310423.22452.dale@daleglass.net> <46D87DD8.6010606@wsu.edu> <200709020211.28175.dale@daleglass.net> <9e6e5c9e0709040948n72067fe4k695bc48a17a4f3c0@mail.gmail.com> <9e6e5c9e0709040953i5a286b8pe55a8408512181e6@mail.gmail.com> <1674f6c70709041330v504285f7xfd2e0f8e513776a0@mail.gmail.com> Message-ID: On 9/4/07, Brandon Husbands wrote: > Why would you want logging, the slurl thing already sucks... Now people > will know where your updaters are and grief them... What's next, > attachments reporting? > > I am curious why you would want to have it show the IM data. > That kind of sucks, and its spamtastic. (Quote edited for clarity) Perhaps you should have read Dale's blog. http://daleglass.wordpress.com/2007/08/09/silencing-the-voice-of-god/ >From the Blog: Silencing the Voice of God Yesterday I had a lot of fun tracking down a spammer. Sesh Kamachi IMed the Linux group asking how to find a location of an object that keep spamming messages. I gave him a tool I made for the purpose, which shows the last speaker's name, owner (if it's an object) and location. Sesh reported that this didn't work, so I came there to check it out myself. My theory was that perhaps this was some object he owned that used llOwnerSay. Just in case, I decided to hang around for a while. Finally I got the message: [2007/08/08 17:51] VoG: Very early in the morning, the chief priests, with the elders, the teachers of the law and the whole Sanhedrin, reached a decision. They bound Jesus, led him away and handed him over to Pilate."Are you the king of the Jews?" asked Pilate."Yes, it is as you say," Jesus replied. The chief priests accused him of many things. So again Pilate asked him, "Aren't you going to answer? See how many things they are accusing you of." But Jesus still made no reply, and Pilate was amazed. Now it was the custom at the Feast to release a prisoner whom the people requested. A man called Barabbas was in prison with the insurrectionists who had committed murder in the uprising. The crowd came up and asked Pilate to do for them what he usually did. "Do you want me to release to you the king of the Jews?" asked Pilate,knowing it was out of envy that the chief priests had handed Jesus over to him. But the chief priests stirred up the crowd to have Pilate release Barabbas instead. "What shall I do, then, with the one you call the Turns out, this thing sends IMs to a list of avatars (I'm so lucky that they added me to it!), so objects listening for chat can't hear it. There's no good way of tracking this down with the standard tools or any scripts residents have available (though Lindens can). Fortunately, Linden Labs released the source to the viewer, and that makes it possible to do some really useful changes to the viewer. ------- Now I don't know about you, but as a non-religious person, it would drive me up the wall to be spammed with drivel like that. Now we can track it down. From jhurliman at wsu.edu Tue Sep 4 14:21:45 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 4 14:22:10 2007 Subject: [sldev] framework documentation pattern In-Reply-To: <46DDA15D.5090209@lindenlab.com> References: <46DD83B7.4010808@cox.net> <46DDA15D.5090209@lindenlab.com> Message-ID: <46DDCC69.9090908@wsu.edu> Ryan Williams (Which) wrote: > Lawson English wrote: > >> The LLSD class seems to be designed to allow better communication >> between framework objects, among other uses, so any redesigned classes >> should probably use LLSD when talking to each other. This last is only >> the vaguest of intuitions on my part, so feel free to gently correct >> me if I'm wrong about its intended use or the utility of using it when >> rewriting the framework. >> > Sounds right to me. :-) Though of course LLSD is not the hammer for > every nail. > I'm not sure that sounds right at all. Serializing and deserializing data to blobs of LLSD/XML/whatever when making calls from class to class is not going to make things more interoperable then just passing arguments, you are just spending a lot of CPU cycles (an incredible amount considering it would be done on ever cross-class call) to mangle and unmangle data. And compatibility will still break and need to be documented when something changes, LLSD doesn't address that problem at all. LLSD allows widely different programs and languages (for example a C++ client and a python web server) to have a common language to interact with. A C++ class calling a C++ class already has that common language. John Hurliman From lenglish5 at cox.net Tue Sep 4 14:58:01 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 4 14:58:03 2007 Subject: [sldev] framework documentation pattern In-Reply-To: <46DDCC69.9090908@wsu.edu> References: <46DD83B7.4010808@cox.net> <46DDA15D.5090209@lindenlab.com> <46DDCC69.9090908@wsu.edu> Message-ID: <46DDD4E9.6080109@cox.net> John Hurliman wrote: > Ryan Williams (Which) wrote: >> Lawson English wrote: >> >>> The LLSD class seems to be designed to allow better communication >>> between framework objects, among other uses, so any redesigned classes >>> should probably use LLSD when talking to each other. This last is only >>> the vaguest of intuitions on my part, so feel free to gently correct >>> me if I'm wrong about its intended use or the utility of using it when >>> rewriting the framework. >>> >> Sounds right to me. :-) Though of course LLSD is not the hammer for >> every nail. >> > > I'm not sure that sounds right at all. Serializing and deserializing > data to blobs of LLSD/XML/whatever when making calls from class to > class is not going to make things more interoperable then just passing > arguments, you are just spending a lot of CPU cycles (an incredible > amount considering it would be done on ever cross-class call) to > mangle and unmangle data. And compatibility will still break and need > to be documented when something changes, LLSD doesn't address that > problem at all. > > LLSD allows widely different programs and languages (for example a C++ > client and a python web server) to have a common language to interact > with. A C++ class calling a C++ class already has that common language. > Fair enough. Like I said, 'twas a dim intuition. Add "wit" where appropriate. From rdw at lindenlab.com Tue Sep 4 16:03:03 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Sep 4 16:02:54 2007 Subject: [sldev] framework documentation pattern In-Reply-To: <46DDCC69.9090908@wsu.edu> References: <46DD83B7.4010808@cox.net> <46DDA15D.5090209@lindenlab.com> <46DDCC69.9090908@wsu.edu> Message-ID: <46DDE427.8010406@lindenlab.com> John Hurliman wrote: > I'm not sure that sounds right at all. Serializing and deserializing > data to blobs of LLSD/XML/whatever when making calls from class to class > is not going to make things more interoperable then just passing > arguments, you are just spending a lot of CPU cycles (an incredible > amount considering it would be done on ever cross-class call) to mangle > and unmangle data. And compatibility will still break and need to be > documented when something changes, LLSD doesn't address that problem at > all. The LLSD class is not necessarily serialized. In memory it is just a convenient dynamically-typed container. Passing an LLSD object as an argument wouldn't incur any overhead above passing a std::list or whatever. It is confusing that we have LLSD, the serialization format, and LLSD, the C++ classes, which are closely related (i.e. only LLSD instances can be serialized), but not the same. -RYaN From monkowsk at watson.ibm.com Tue Sep 4 16:50:00 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 4 16:50:05 2007 Subject: [sldev] [META] Projects in progress, both Linden and Resident Message-ID: <46DDEF28.5010303@watson.ibm.com> (I originally posted this as part of a comment to WEB-306 on the JIRA, but I guess it's foolish to expect responses on the JIRA.) I think it interesting that we would like to know what projects Linden has in the works that they are committed to delivering, but I can't really keep track of what projects are being worked on by the SLDev community. I know I mentioned it a while back, but who remembers that I'm interested in lip-sync? It's not that I'm being secretive. I just don't have anything to say about it at the moment. The JIRA has entries for requested new features scattered all over the place. I guess if I were a JIRA expert, I could create a Search page that listed just the new feature entries, but I always have trouble searching JIRA. Maybe we should add feature requests for things we are working on so we and others can track their progress. Can New Feature entries have status "In Progress"? Can outside developers put them in this state? Would Linden identify projects they're working on by doing so? On the JIRA we see, not their internal one? Does anyone at Linden other than Rob look at the New Feature requests on the external JIRA? Mike From secret.argent at gmail.com Tue Sep 4 16:57:26 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 4 16:57:33 2007 Subject: [sldev] Re: [VIEWER] Dead code removal (Lawson English) In-Reply-To: <20070904181641.54E1441B1A2@stupor.lindenlab.com> References: <20070904181641.54E1441B1A2@stupor.lindenlab.com> Message-ID: <6A9060AA-C2C1-4AEC-9991-A8642A910C99@gmail.com> From: Lawson English > Pardon me if this sounds like a bad library design to me, unless that > code is definitely designeed to be "dual use" between client and > server > like common definitions and communications modules, and in that > case, it > should be factored into its own files and placed in the "common" if I > understand what that is for. There's a lot of code in the client that is clearly designed to be used by multiple programs. There are whole modules that look just like common libraries that the client happens to be using. And personally I'd rather work on programs that contain common libraries that are useful on their own than one where every part has been trimmed down and customized for that application. Factoring code so as to allow and encourage reuse is good design. From secret.argent at gmail.com Tue Sep 4 17:19:45 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 4 17:19:51 2007 Subject: [sldev] Re: [VIEWER] New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <20070904230255.B9B1041B1B2@stupor.lindenlab.com> References: <20070904230255.B9B1041B1B2@stupor.lindenlab.com> Message-ID: <57A0F15B-D129-40F1-9E64-F727A5DD89A8@gmail.com> Other things that I have had to track down in the past that would have been much easier with this tool: * Lucky Chairs on irregular cycles. * Copybot protection devices. * Vendors that spam-IM you. * Various shouters and other devices used in clubs. * Copybot protection devices. * Over-aggressive security spheres. * Chatty devices with generic names (like 'Object') * Copybot protection devices. From ettore_pasquini at 3dconnexion.com Tue Sep 4 18:04:51 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Tue Sep 4 18:05:01 2007 Subject: [sldev] Re: [VIEWER] Dead code removal (Lawson English) In-Reply-To: <6A9060AA-C2C1-4AEC-9991-A8642A910C99@gmail.com> Message-ID: On 9/4/07 4:57 PM, "Argent Stonecutter" wrote: > From: Lawson English >> Pardon me if this sounds like a bad library design to me, unless that >> code is definitely designeed to be "dual use" between client and >> server >> like common definitions and communications modules, and in that >> case, it >> should be factored into its own files and placed in the "common" if I >> understand what that is for. > > There's a lot of code in the client that is clearly designed to be > used by multiple programs. There are whole modules that look just > like common libraries that the client happens to be using. The "clearly" part is highly subjective, depending on how much confidence a reader has with the code. In this case, even if you have relatively good knowledge, we may still not know the "second reason to exist" of a particular piece of code because we don't know its whole story. (For reasons often discussed...) So... As part of having better code documentation, how about just adding a "used by" tag above the GPL header like: Used by: Viewer, Sim, (or whatever) That would eliminate some doubts, at least with a per-file granularity. -Ettore From iridium at lindenlab.com Tue Sep 4 18:40:27 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Tue Sep 4 18:41:06 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DDEF28.5010303@watson.ibm.com> References: <46DDEF28.5010303@watson.ibm.com> Message-ID: <46DE090B.8060905@lindenlab.com> Mike, first let me thank you for your email and bringing this to our attention. Rob and I both thought that this was a really good idea, and it hearkens back to conversations that we've had with other Open Source Lindens about giving SL Devs more permissions in Public JIRA. In honor of PJIRA Awareness Month (September at LL), we have decided to create a PJIRA group with permissions to assign tasks. Here are the details: 1) If you signed the Open Source Contributor Agreement , then you have likely been added to the Contrib-Agreement group in Public JIRA. 2) If you have signed the agreement and have not been added, please contact me . 3) If you require a copy of the agreement, follow the instructions on the wiki . Add your name to the contributor wiki , contact me , and I will add you to the group. 4) The Contrib-Agreement group in PJIRA entitles you to certain permissions. The main permission you are granted is the power to assign a JIRA task. Please note the following about your permissions: a) These permissions were introduced so that Open Source Contributors could assign JIRA tasks to *themselves* in order to show that work is in progress. b) These permissions also allow you to assign tasks to Lindens. c) *If you assign a JIRA task to a Linden without the explicit consent of that Linden, you will immediately be ejected from the group and your permissions thusly lost. *Questions? Email me. Iridium Mike Monkowski wrote: > (I originally posted this as part of a comment to WEB-306 on the JIRA, > but I guess it's foolish to expect responses on the JIRA.) > > I think it interesting that we would like to know what projects Linden > has in the works that they are committed to delivering, but I can't > really keep track of what projects are being worked on by the SLDev > community. I know I mentioned it a while back, but who remembers that > I'm interested in lip-sync? It's not that I'm being secretive. I just > don't have anything to say about it at the moment. > > The JIRA has entries for requested new features scattered all over the > place. I guess if I were a JIRA expert, I could create a Search page > that listed just the new feature entries, but I always have trouble > searching JIRA. > > Maybe we should add feature requests for things we are working on so > we and others can track their progress. Can New Feature entries have > status "In Progress"? Can outside developers put them in this state? > Would Linden identify projects they're working on by doing so? On the > JIRA we see, not their internal one? Does anyone at Linden other than > Rob look at the New Feature requests on the external JIRA? > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070904/360c50f8/attachment.htm From me at hamncheeseomlet.com Tue Sep 4 20:07:06 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Tue Sep 4 20:07:36 2007 Subject: [sldev] SVC-150 Message-ID: <3F6FD56250914C3F96442CE682DF262A@DreamStream> I'm looking for discussion from the list on possible implementation on SVC-150 http://jira.secondlife.com/browse/SVC-150 (Login picture changes to user-specific before password check is done) The last screenshot is queued up in init_start_screen and the viewer window is displayed long before the successful login response comes back. So based on the above and the comments in jira, I'm treating this as a feature request and want give the user explicit control over the display of the final snapshot as a splash screen. I'm doing this by storing a persisted bool setting in gSavedSettings and then hooking that up to a checkbox in Preferences. Default is true/checked. If the user unchecks the box, then no snapshot is shown when logging in and on the flip side, no final snapshot is taken when logging off. However after playing around with this, I realized that screen real-estate on Preferences was fairly precious for what amounts to fairly obscure feature. I had other thoughts such as adding it to the startup screen or making it a debug menu item. I like the debug menu item idea but you can't set it until you've actually logged in. Displaying on startup screen would be confusing for new users and in the way for most users. Any thoughts, ideas, ymbc, etc? Cheers, Ham From lenglish5 at cox.net Tue Sep 4 21:46:31 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 4 21:46:32 2007 Subject: [sldev] GUI prototype speedup tricks Message-ID: <46DE34A7.6020105@cox.net> OK, A trick Benjamin turned me onto is to type cmd/cntrl-t at the login screen. This evokes a floater window that is defined by floater_test.xml, which allows you to prototype GIU-related stuff without logging into the server. One problem though: The login process still takes you out to the internet and tries to grab a web-page, which makes the turnaround for GUI testing rather slow, even still. I browsed around and found that if you change a 1 to a zero in this line: #define LL_LIBXUL_ENABLED 0 in llpreprocessor.h, line 56, will bypass compiling the browser code on the Mac client and eventually set mHtmlAvailable = FALSE; in the login floater. This is a good thing, if you're trying to shorten the cycle for compiling and testing GUI and related code, and don't need access to the browser or the client, at least in the beginning stages because it brings the login window much closer to my greatly desired hello world GUI prototyping window. The drawback is that the constant is defined in the precompiled header, so changing it requires a recompile of all sources which is itself rather slow. The best bet seems to be to define two builds, I guess. One with the constant defined as 0 for GUI testing, and one with the constant defined as 1 for full-blown client testing, including the browser. The client will run without the browser code defined, but I didn't test for stability if you try to use the browser in-world. Just a heads up. From labrat.hb at gmail.com Tue Sep 4 22:34:42 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Sep 4 22:34:46 2007 Subject: [sldev] GUI prototype speedup tricks In-Reply-To: <46DE34A7.6020105@cox.net> References: <46DE34A7.6020105@cox.net> Message-ID: Or you could edit the skins/xui/en-us/panel_login.xml and remove the URL to http://secondlife.com/app/login/ This will allow the browser control to still load, but will prevent it from accessing the Internet to pull down a webpage on startup. You could also replace it with a local html page, or a light-weight page on the internet. On 9/4/07, Lawson English wrote: > > OK, A trick Benjamin turned me onto is to type cmd/cntrl-t at the login > screen. This evokes a floater window that is defined by > floater_test.xml, which allows you to prototype GIU-related stuff > without logging into the server. > > One problem though: The login process still takes you out to the > internet and tries to grab a web-page, which makes the turnaround for > GUI testing rather slow, even still. > > I browsed around and found that if you change a 1 to a zero in this line: > > #define LL_LIBXUL_ENABLED 0 > > in llpreprocessor.h, line 56, will bypass compiling the browser code on > the Mac client and eventually set mHtmlAvailable = FALSE; in the login > floater. > > This is a good thing, if you're trying to shorten the cycle for > compiling and testing GUI and related code, and don't need access to the > browser or the client, at least in the beginning stages because it > brings the login window much closer to my greatly desired hello world > GUI prototyping window. The drawback is that the constant is defined in > the precompiled header, so changing it requires a recompile of all > sources which is itself rather slow. The best bet seems to be to define > two builds, I guess. One with the constant defined as 0 for GUI testing, > and one with the constant defined as 1 for full-blown client testing, > including the browser. The client will run without the browser code > defined, but I didn't test for stability if you try to use the browser > in-world. > > > > Just a heads up. > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070904/60a48c8b/attachment-0001.htm From labrat.hb at gmail.com Tue Sep 4 22:40:48 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Sep 4 22:40:50 2007 Subject: [sldev] GUI prototype speedup tricks In-Reply-To: <46DE34A7.6020105@cox.net> References: <46DE34A7.6020105@cox.net> Message-ID: Just tested.. I'm not sure what "turnaround for GUI testing rather slow" means in your context. It appears to me that each time ctrl-t is pressed it re-reads the floater_test.xml file. So prototyping a GUI screen should go fairly quick. So the lag time of the initial load would seem to be the only delay you should be seeing. If it's for loading up faster to test new GUI controls / refactored controls. Well you probably just a few minutes compiling.... so the load time shouldn't be any more of an impediment to testing. On 9/4/07, Lawson English wrote: > > OK, A trick Benjamin turned me onto is to type cmd/cntrl-t at the login > screen. This evokes a floater window that is defined by > floater_test.xml, which allows you to prototype GIU-related stuff > without logging into the server. > > One problem though: The login process still takes you out to the > internet and tries to grab a web-page, which makes the turnaround for > GUI testing rather slow, even still. > > I browsed around and found that if you change a 1 to a zero in this line: > > #define LL_LIBXUL_ENABLED 0 > > in llpreprocessor.h, line 56, will bypass compiling the browser code on > the Mac client and eventually set mHtmlAvailable = FALSE; in the login > floater. > > This is a good thing, if you're trying to shorten the cycle for > compiling and testing GUI and related code, and don't need access to the > browser or the client, at least in the beginning stages because it > brings the login window much closer to my greatly desired hello world > GUI prototyping window. The drawback is that the constant is defined in > the precompiled header, so changing it requires a recompile of all > sources which is itself rather slow. The best bet seems to be to define > two builds, I guess. One with the constant defined as 0 for GUI testing, > and one with the constant defined as 1 for full-blown client testing, > including the browser. The client will run without the browser code > defined, but I didn't test for stability if you try to use the browser > in-world. > > > > Just a heads up. > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070904/4193281e/attachment.htm From robla at lindenlab.com Tue Sep 4 23:48:36 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Sep 4 23:48:42 2007 Subject: [sldev] [VIEWER] Uploads crashing on RC 1.18.3 In-Reply-To: <46DD9DEE.5050009@blueflash.cc> References: <46DCA6A3.7090308@blueflash.cc> <46DD9DEE.5050009@blueflash.cc> Message-ID: <46DE5144.9040705@lindenlab.com> Oh, righto, I know what's going on here. There's a manual update that needs to happen whenever the interface into llkdu changes. Only affects the source download process. I've filed the issue here: https://jira.secondlife.com/browse/VWR-2324 Sorry for the inconvenience. This bites us every so often; we really need to automate this. Rob On 9/4/07 11:03 AM, Nicholaz Beresford wrote: > > Seems to have been the LLKDU.DLL shipped > with the library pack from the 1.18.3RC. > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Nicholaz Beresford wrote: >> >> Did anyone else see texture uploads crashing on >> the current RC? Had it a few times now, but >> couldn't nail it yet. >> >> >> Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070904/b740a398/signature.pgp From lenglish5 at cox.net Wed Sep 5 00:47:36 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 5 00:47:36 2007 Subject: [sldev] GUI prototype speedup tricks In-Reply-To: References: <46DE34A7.6020105@cox.net> Message-ID: <46DE5F18.3050106@cox.net> Harold Brown wrote: > Or you could edit the skins/xui/en-us/panel_login.xml and remove the > URL to http://secondlife.com/app/login/ > On the Mac at least, or at least when *I* tried it, I got runtime errors and the viewer was terminated by the debugger. From lenglish5 at cox.net Wed Sep 5 00:49:21 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 5 00:49:20 2007 Subject: [sldev] GUI prototype speedup tricks In-Reply-To: References: <46DE34A7.6020105@cox.net> Message-ID: <46DE5F81.3060700@cox.net> Harold Brown wrote: > Just tested.. I'm not sure what "turnaround for GUI testing rather > slow" means in your context. It appears to me that each time ctrl-t > is pressed it re-reads the floater_test.xml file. So prototyping a > GUI screen should go fairly quick. So the lag time of the initial > load would seem to be the only delay you should be seeing. > > If it's for loading up faster to test new GUI controls / refactored > controls. Well you probably just a few minutes compiling.... so the > load time shouldn't be any more of an impediment to testing. I'm testing more than just an xml file though. I' trying to fudge the behavior of an outline list for non-asset data, which means I have at least a few lines of GUI code to test as well. From secret.argent at gmail.com Wed Sep 5 01:42:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 5 01:43:04 2007 Subject: [sldev] Re: [VIEWER] Dead code removal In-Reply-To: <20070905053448.8040641B1C7@stupor.lindenlab.com> References: <20070905053448.8040641B1C7@stupor.lindenlab.com> Message-ID: From: Ettore Pasquini > The "clearly" part is highly subjective, Certainly. It's my opinion only. Parts of the viewer that I have worked on have the feel of a general library that's designed to be used by more than one program. > depending on how much confidence a > reader has with the code. In this case, even if you have relatively > good > knowledge, we may still not know the "second reason to exist" of a > particular piece of code because we don't know its whole story. > (For reasons > often discussed...) Why do you need to know what that reason is? Knowing whether a *module* is a general library or a part of the viewer only and not depending on subjective assessment is useful, but knowing whether a file is used by the asset server or the sim or the presence server isn't really that useful. On the other hand, better (or any!) class/method/function documentation would be useful. While the code is usually pretty self- documenting, it would be nice to know what the intended inputs and outputs are and whether the observed ones are actually intentional or merely side-effects. THAT would not only help understanding the code, but would incidentally make dead code easier to locate. From secret.argent at gmail.com Wed Sep 5 01:45:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 5 01:45:55 2007 Subject: [sldev] Re: [VIEWER] GUI prototype speedup tricks In-Reply-To: <20070905053448.8040641B1C7@stupor.lindenlab.com> References: <20070905053448.8040641B1C7@stupor.lindenlab.com> Message-ID: From: "Harold Brown" > Or you could edit the skins/xui/en-us/panel_login.xml and remove > the URL to > http://secondlife.com/app/login/ > > This will allow the browser control to still load, but will prevent > it from > accessing the Internet to pull down a webpage on startup. You could > also > replace it with a local html page, or a light-weight page on the > internet. Nice, thanks. That would solve the problem I have that this page *never* loads for me because SL doesn't support HTTP proxies... and frankly I would rather it didn't even try. From boz3d at inbox.com Wed Sep 5 03:12:01 2007 From: boz3d at inbox.com (Ernie Kabowski) Date: Wed Sep 5 03:12:07 2007 Subject: [sldev] RE: NSV Support Message-ID: This will be my last entry on NSV support as its support status seems to be: play it if you got it. Using softwares age to excuse it's lacking in comparison is bad practice. I could say EasyWriter is better than Open Office by two decades. What's real is the QuickTime player that integrates on the majority of platforms doesn't have default NSV support. It takes a plugin. Also another thing that can be ignored in retorts, but not in usability is that fact it takes 2 plus minutes to buffer for playback on apple video on a 1.5Mbps(1.04Mbps) downstream from a commercial 8Mbps upstream dedicated server under little load. You can only ignore reality, but it's still there when denial isn't. I'm not going against Apple ether, so drones need not worry. ____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! From nicholaz at blueflash.cc Wed Sep 5 04:26:01 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 5 04:26:08 2007 Subject: [sldev] [META] [JIRA] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DE090B.8060905@lindenlab.com> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> Message-ID: <46DE9249.3040003@blueflash.cc> Keeewl! :-) Now if we could get the email addresses (btw, why don't you just put the email addresses from the SL accounts into the profiles)? Nick From dale at daleglass.net Wed Sep 5 04:34:45 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Sep 5 04:34:50 2007 Subject: [sldev] Re: [VIEWER] New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <57A0F15B-D129-40F1-9E64-F727A5DD89A8@gmail.com> References: <20070904230255.B9B1041B1B2@stupor.lindenlab.com> <57A0F15B-D129-40F1-9E64-F727A5DD89A8@gmail.com> Message-ID: <20070905113445.GA9878@bruno.sbruno> On Tue, Sep 04, 2007 at 07:19:45PM -0500, Argent Stonecutter wrote: > Other things that I have had to track down in the past that would > have been much easier with this tool: > [snip] Well, now they will be, since it's released already on http://sl.daleglass.net, both Linux and Windows versions. There are still things left to do and fix, but I'm rather busy until Friday. What is there should work meanwhile though. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070905/f4eee9f4/attachment-0001.pgp From hud at zurich.ibm.com Wed Sep 5 06:21:23 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Sep 5 06:21:15 2007 Subject: [sldev] [VIEWER] Uploads crashing on RC 1.18.3 In-Reply-To: <46DCA6A3.7090308@blueflash.cc> References: <46DCA6A3.7090308@blueflash.cc> Message-ID: <46DEAD53.2080400@zurich.ibm.com> Nicholaz Beresford wrote: > > Did anyone else see texture uploads crashing on > the current RC? Had it a few times now, but > couldn't nail it yet. > > > Nick nope. have uploaded a couple of textures, no crash so far. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070905/d3f40b1b/attachment.htm From secret.argent at gmail.com Wed Sep 5 07:48:12 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 5 07:48:21 2007 Subject: [sldev] Re: [VIEWER] New viewer released with logging of the owners of speaking objects and their location In-Reply-To: <20070905113445.GA9878@bruno.sbruno> References: <20070904230255.B9B1041B1B2@stupor.lindenlab.com> <57A0F15B-D129-40F1-9E64-F727A5DD89A8@gmail.com> <20070905113445.GA9878@bruno.sbruno> Message-ID: <9B09CF86-60CE-4C69-8E62-C306736354AD@gmail.com> On 05-Sep-2007, at 06:34, Dale Glass wrote: > Well, now they will be, since it's released already on > http://sl.daleglass.net, both Linux and Windows versions. No Mac, is that because you just don't have a Mac to build on? From secret.argent at gmail.com Wed Sep 5 07:59:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 5 08:00:06 2007 Subject: [sldev] Re: [META] [JIRA] *IMPORTANT* New PJIRA Perms (Nicholaz Beresford) In-Reply-To: <20070905113451.21E1B41B1D8@stupor.lindenlab.com> References: <20070905113451.21E1B41B1D8@stupor.lindenlab.com> Message-ID: <68AC19C7-25B4-4708-9227-D48C2834EA20@gmail.com> From: Nicholaz Beresford > Now if we could get the email addresses (btw, why don't you > just put the email addresses from the SL accounts into the > profiles)? I'm not sure what you're referring to here, but as public as I am I would prefer to limit the number of searchable databases my email addresses are automatically added to. Really, I'd like to have this option in preferences: [X] Accept mail to Argent.Stonecutter@residents.secondlife.com for forwarding to IM So I can be more easily contacted by customers who aren't in-world. I'm surprised that nobody's set up a SL-account email-to-IM proxy already, actually. I guess because only LL could do it properly since they could send replyable IMs that would go to email, whereas a third- party could only send scripted in-world IMs that just show up if you're online. From dzonatas at dzonux.net Wed Sep 5 11:39:41 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Sep 5 11:39:19 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DE090B.8060905@lindenlab.com> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> Message-ID: <46DEF7ED.5070602@dzonux.net> Iridium Linden wrote: > 1) If you signed the Open Source Contributor Agreement > , then you > have likely been added to the Contrib-Agreement group in Public JIRA. Given that my contract is not being upheld by Linden Lab, I can not fall back to the Open Source Contributor Agreement. I've tried to discuss this issue being that it is more about license issues. The agreement shown above is not secure enough for those that have written and published programs before SL ever existed. It seemed to be understood when I was offered the other contract. If the terms were more like that, I would sign it. This shows again another piece how this is not Open Source, as it creates a discrimination against me and my right to protect the security of Linden Lab and my work. It lacks 'freedom'. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070905/e8349d29/attachment.htm From bridie at lindenlab.com Wed Sep 5 12:03:28 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Wed Sep 5 12:03:27 2007 Subject: [sldev] Viewer Crashes Triage In-Reply-To: <46CB97EE.3080608@lindenlab.com> References: <46CB97EE.3080608@lindenlab.com> Message-ID: <46DEFD80.2050500@lindenlab.com> Howdy all - I've updated the Viewer Crashes agenda for this afternoon, but as we discussed last week -- we are fast running out of issues to review...only 6 items today. Now that our Release Candidate is out in the wild, I'm considering making my weekly triage an RC triage. Alternatively, it could turn into a more general purpose triage of 'hot' issues? I welcome your feedback. After triaging 1.18.3 issues w/Aric Linden and Josh Linden yesterday and considering a change in focus for my triage, I created a back up agenda for today that documented our 'pre-meeting activity': https://wiki.secondlife.com/wiki/Bug_triage/Wednesday_Agenda You're welcome to review and add any new issues. See you this afternoon! --Bridie Iridium Linden wrote: > Hiya devs, > Just a friendly reminder that tomorrow at 3 pm PDT, Bridie will be > hosting the Viewer Crashes Triage > at > her office in Linden Village. > See you there! > Iridium > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070905/49e70d23/attachment.htm From labrat.hb at gmail.com Wed Sep 5 12:34:57 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Sep 5 12:35:00 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DEF7ED.5070602@dzonux.net> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> <46DEF7ED.5070602@dzonux.net> Message-ID: You are the one who refuses to sign that contributer agreement. It has nothing to do with whatever work you have contracted with Linden Labs to write before, nor would it have anything to do with any work you may contract for or be hired to do in the future. I for one am tired of hearing you whine about your contract with LL's. If you have a problem with your situation with LL's talk to them OFF this mailing list. No life isn't fair. No not everyone gets to have their dream job. But right now the 500 people signed up for this list, who have no business being involved in your personal life or your issue with LL's, probably know more about your personal business then they do their own neighbors. And it has NOTHING to do with Second Life Development. We're trying to get more Lindens to participate on this list. But why would they want to? You've attacked almost every one of them about your stupid contract. You want to talk development... fine, I'm happy to hear whatever you say. You want to bitch about you contract, the contributer agreement or how evil Linden Labs is.... well I'll have to start filtering that noise out of my mailing list reading. And if the noise level keeps increasing... I'd expect others to start asking for that filter to be placed further upstream. On 9/5/07, Dzonatas wrote: > > Iridium Linden wrote: > > 1) If you signed the Open Source Contributor Agreement, > then you have likely been added to the Contrib-Agreement group in Public > JIRA. > > Given that my contract is not being upheld by Linden Lab, I can not fall > back to the Open Source Contributor Agreement. > > I've tried to discuss this issue being that it is more about license > issues. The agreement shown above is not secure enough for those that have > written and published programs before SL ever existed. It seemed to be > understood when I was offered the other contract. If the terms were more > like that, I would sign it. > > This shows again another piece how this is not Open Source, as it creates > a discrimination against me and my right to protect the security of Linden > Lab and my work. It lacks 'freedom'. > > > -- > Power to Change the Void > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070905/032f03c3/attachment.htm From aspen.grey at greydawning.net Wed Sep 5 12:42:22 2007 From: aspen.grey at greydawning.net (Aspen d'Grey) Date: Wed Sep 5 12:43:27 2007 Subject: [sldev] [META] [JIRA] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DE9249.3040003@blueflash.cc> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> <46DE9249.3040003@blueflash.cc> Message-ID: Eh, hmm, I for one would not want my email just sitting out there in plaintext for spambots to latch on too. If it had it in spamproofing (aspen dot grey at greydawning dot net) then I'd be fine. On Wed, 05 Sep 2007 05:26:01 -0600, Nicholaz Beresford wrote: > > Keeewl! :-) > > Now if we could get the email addresses (btw, why don't you > just put the email addresses from the SL accounts into the > profiles)? > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From bbyer at mm.st Wed Sep 5 14:36:04 2007 From: bbyer at mm.st (Ben Byer) Date: Wed Sep 5 14:36:04 2007 Subject: [sldev] How to debug X server crash? In-Reply-To: <20070829104056.GA29798@bruno.sbruno> References: <39960.83.180.254.242.1188383386.squirrel@datendelphin.net> <20070829104056.GA29798@bruno.sbruno> Message-ID: <49ABA1B9-649F-4D31-8FE7-B5273957D321@mm.st> On Aug 29, 2007, at 3:40 AM, Dale Glass wrote: > On Wed, Aug 29, 2007 at 12:29:46PM +0200, Boroondas Gupte wrote: >> >> However your description of the symptoms sounds to me, like the >> graphic >> card driver might come in, too. I guess it'll be difficult if not >> impossible to get debug symbols into that. > Yeah, darn closed source drivers. > > This didn't happen before though. Think there's two possibilities > here: > One is that the nvidia driver is buggy, and the other is that SL does > something incorrectly. Almost by definition, if something can cause the X server to crash, it's a bug in the X server. Unfortunately, you're going to get no love from the X.org folks while using a closed-source driver. -b From robla at lindenlab.com Wed Sep 5 15:38:31 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Sep 5 15:38:36 2007 Subject: [sldev] [POLICY] Mailing list policy Message-ID: <46DF2FE7.6020902@lindenlab.com> Hi everyone I've been careful to call my suggestions thus far "guidelines" rather than "policies", because I'm willing to concede that some of my suggestions might need to be ignored. However, it's become clear that it's time to explicitly institute a policy with some consequences for violation. Constructive criticism is welcome, but general complaints which only serve to discourage use of Second Life or discourage cooperation with Linden Lab should be taken elsewhere. 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, exectutive, human resources, etc). The guidelines for commenting on the blog also apply here. I've added a policy section to the wiki page for this list: https://wiki.secondlife.com/wiki/SLDev Since we can't delete comments that are in violation, we're going to instead preemptively set the "moderated" bit for repeat violators. Given how much spam we also get, that will probably have the effect of making the list read-only for those members.....we may hunt around and pull something out of the queue, but it's too large of a spam pile to sort through. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070905/4bbd4747/signature.pgp From jhurliman at wsu.edu Wed Sep 5 17:01:35 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Sep 5 17:01:53 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> <46DEF7ED.5070602@dzonux.net> Message-ID: <46DF435F.2090201@wsu.edu> A solution for this problem posted to the mailing list earlier is to setup our mail filters to properly deal with the signal to noise ratio. I went ahead and did by blacklisting "From" e-mail addresses but that only works for the first e-mail, not reply e-mails. Is there a way to block entire threads such as this one? No offense to anyone involved, I just can't justify spending my day reading watercooler chat. John Hurliman Harold Brown wrote: > You are the one who refuses to sign that contributer agreement. It > has nothing to do with whatever work you have contracted with Linden > Labs to write before, nor would it have anything to do with any work > you may contract for or be hired to do in the future. > > I for one am tired of hearing you whine about your contract with > LL's. If you have a problem with your situation with LL's talk to > them OFF this mailing list. > > No life isn't fair. No not everyone gets to have their dream job. > But right now the 500 people signed up for this list, who have no > business being involved in your personal life or your issue with LL's, > probably know more about your personal business then they do their own > neighbors. And it has NOTHING to do with Second Life Development. > > We're trying to get more Lindens to participate on this list. But why > would they want to? You've attacked almost every one of them about > your stupid contract. > > You want to talk development... fine, I'm happy to hear whatever you say. > > You want to bitch about you contract, the contributer agreement or how > evil Linden Labs is.... well I'll have to start filtering that noise > out of my mailing list reading. And if the noise level keeps > increasing... I'd expect others to start asking for that filter to be > placed further upstream. > > > On 9/5/07, *Dzonatas* > wrote: > > Iridium Linden wrote: >> 1) If you signed the Open Source Contributor Agreement >> , >> then you have likely been added to the Contrib-Agreement group in >> Public JIRA. > Given that my contract is not being upheld by Linden Lab, I can > not fall back to the Open Source Contributor Agreement. > > I've tried to discuss this issue being that it is more about > license issues. The agreement shown above is not secure enough for > those that have written and published programs before SL ever > existed. It seemed to be understood when I was offered the other > contract. If the terms were more like that, I would sign it. > > This shows again another piece how this is not Open Source, as it > creates a discrimination against me and my right to protect the > security of Linden Lab and my work. It lacks 'freedom'. > > > -- > Power to Change the Void > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From iridium at lindenlab.com Wed Sep 5 17:10:58 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Wed Sep 5 17:11:39 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DF435F.2090201@wsu.edu> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> <46DEF7ED.5070602@dzonux.net> <46DF435F.2090201@wsu.edu> Message-ID: <46DF4592.1080103@lindenlab.com> Linden Lab has addressed the issue presented in this thread. (See Rob's Mailing list policy email for more info) Don't foget to sign the agreement though if you would like more perms in JIRA. Iridium John Hurliman wrote: > A solution for this problem posted to the mailing list earlier is to > setup our mail filters to properly deal with the signal to noise > ratio. I went ahead and did by blacklisting "From" e-mail addresses > but that only works for the first e-mail, not reply e-mails. Is there > a way to block entire threads such as this one? No offense to anyone > involved, I just can't justify spending my day reading watercooler chat. > > John Hurliman > > > Harold Brown wrote: >> You are the one who refuses to sign that contributer agreement. It >> has nothing to do with whatever work you have contracted with Linden >> Labs to write before, nor would it have anything to do with any work >> you may contract for or be hired to do in the future. >> I for one am tired of hearing you whine about your contract with >> LL's. If you have a problem with your situation with LL's talk to >> them OFF this mailing list. >> >> No life isn't fair. No not everyone gets to have their dream job. >> But right now the 500 people signed up for this list, who have no >> business being involved in your personal life or your issue with >> LL's, probably know more about your personal business then they do >> their own neighbors. And it has NOTHING to do with Second Life >> Development. >> >> We're trying to get more Lindens to participate on this list. But >> why would they want to? You've attacked almost every one of them >> about your stupid contract. >> >> You want to talk development... fine, I'm happy to hear whatever you >> say. >> >> You want to bitch about you contract, the contributer agreement or >> how evil Linden Labs is.... well I'll have to start filtering that >> noise out of my mailing list reading. And if the noise level keeps >> increasing... I'd expect others to start asking for that filter to be >> placed further upstream. >> >> On 9/5/07, *Dzonatas* > > wrote: >> >> Iridium Linden wrote: >>> 1) If you signed the Open Source Contributor Agreement >>> , >>> then you have likely been added to the Contrib-Agreement group in >>> Public JIRA. >> Given that my contract is not being upheld by Linden Lab, I can >> not fall back to the Open Source Contributor Agreement. >> >> I've tried to discuss this issue being that it is more about >> license issues. The agreement shown above is not secure enough for >> those that have written and published programs before SL ever >> existed. It seemed to be understood when I was offered the other >> contract. If the terms were more like that, I would sign it. >> >> This shows again another piece how this is not Open Source, as it >> creates a discrimination against me and my right to protect the >> security of Linden Lab and my work. It lacks 'freedom'. >> >> >> -- Power to Change the Void >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at lindenlab.com Wed Sep 5 17:28:47 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Sep 5 17:28:49 2007 Subject: [sldev] Thursday Open Source Meeting Message-ID: <9e6e5c9e0709051728p66c4bd24jb227bb323e231f95@mail.gmail.com> Don't forget: the new location for the Thursday open source meeting is in Hippotropolis. Things have been a little out-of-sync with the Monday US holiday, but we're still on track for 2pm Thursday. See ya there, and don't be shy about raising topics for discussion: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From lenglish5 at cox.net Wed Sep 5 18:35:42 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 5 18:35:43 2007 Subject: [sldev] RE: NSV Support In-Reply-To: References: Message-ID: <46DF596E.60704@cox.net> Ernie Kabowski wrote: > This will be my last entry on NSV support as its support status > seems to be: play it if you got it. > > Using softwares age to excuse it's lacking in comparison is bad > practice. I could say EasyWriter is better than Open Office by > two decades. > > What's real is the QuickTime player that integrates on the majority > of platforms doesn't have default NSV support. It takes a plugin. > > Also another thing that can be ignored in retorts, but not in > usability is that fact it takes 2 plus minutes to buffer for > playback on apple video on a 1.5Mbps(1.04Mbps) downstream from > a commercial 8Mbps upstream dedicated server under little load. > > You can only ignore reality, but it's still there when denial > isn't. > > I'm not going against Apple ether, so drones need not worry. > > That's sounds like a server issue or even how the movie was prepped for streaming, though I can't speak to the specific interactions of the QT plugin in Second Life. This 720P (1280x720) 222.3 MB clip takes only a few seconds to buffer on my Mac using Safari, for instance. http://www.apple.com/quicktime/guide/hd/worldcafelive.html Here's some non-Apple-hosted QT movies. They all seem snappy in playback on my Mac: http://www.esm.psu.edu/Faculty/Gray/movies.html From soft at lindenlab.com Wed Sep 5 21:34:39 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Sep 5 21:34:41 2007 Subject: [sldev] Subject: SLDev-Traffic #25 Message-ID: <9e6e5c9e0709052134o4b9fec25wc764875bb4836917@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_25 SLDev-Traffic number 25 is up. (Did you miss it?) Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From alissa_sabre at yahoo.co.jp Thu Sep 6 04:04:44 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Sep 6 04:05:05 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DE090B.8060905@lindenlab.com> References: <46DE090B.8060905@lindenlab.com> Message-ID: <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> Just to making sure. > a) These permissions were introduced so that Open Source Contributors > could assign JIRA tasks to *themselves* in order to show that work is in > progress. > b) These permissions also allow you to assign tasks to Lindens. > c) *If you assign a JIRA task to a Linden without the explicit consent > of that Linden, you will immediately be ejected from the group and your > permissions thusly lost. That means: - An Open Souece Contributor may assign a taks to another Open Source Contributor. - A Linden may assign a task to another Linden. - A Linden may assign a taks to an Open Source Contributor. - An Open Source Contributor *must*not* assign a task to a Linden. Am I correct? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From nicholaz at blueflash.cc Thu Sep 6 04:25:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Sep 6 04:25:42 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> Message-ID: <46DFE3AA.8050401@blueflash.cc> Alissa Sabre wrote: > Just to making sure. > >> a) These permissions were introduced so that Open Source Contributors >> could assign JIRA tasks to *themselves* in order to show that work is in >> progress. >> b) These permissions also allow you to assign tasks to Lindens. >> c) *If you assign a JIRA task to a Linden without the explicit consent >> of that Linden, you will immediately be ejected from the group and your >> permissions thusly lost. > > That means: > > - An Open Souece Contributor may assign a taks to another Open Source > Contributor. > - A Linden may assign a task to another Linden. > - A Linden may assign a taks to an Open Source Contributor. > - An Open Source Contributor *must*not* assign a task to a Linden. The way I understand it, the perms technically mean everyone can assign to everyone, *practically* (by policy or agreement) the only change is that now OSCs can assign themselves to a task (same person). Like reporting a bug and by self-assignment making clear that it's being worked on (which makes sense). Nick From dale at daleglass.net Thu Sep 6 04:35:05 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 6 04:35:11 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> Message-ID: <20070906113505.GA15043@bruno.sbruno> On Thu, Sep 06, 2007 at 08:04:44PM +0900, Alissa Sabre wrote: > Just to making sure. > > > a) These permissions were introduced so that Open Source Contributors > > could assign JIRA tasks to *themselves* in order to show that work is in > > progress. > > b) These permissions also allow you to assign tasks to Lindens. > > c) *If you assign a JIRA task to a Linden without the explicit consent > > of that Linden, you will immediately be ejected from the group and your > > permissions thusly lost. > > That means: > > - An Open Souece Contributor may assign a taks to another Open Source > Contributor. > - A Linden may assign a task to another Linden. > - A Linden may assign a taks to an Open Source Contributor. > - An Open Source Contributor *must*not* assign a task to a Linden. > > Am I correct? My reading is: The rules are: * A contributor may assign bugs to themselves * A contributor MAY NOT assign bugs to a Linden without their consent Speculation: Rules for Lindens are unclear, but that's an internal matter between them an LL. My guess is that Lindens can assign bugs to each other and consent will be there pretty much all the time, although we won't see them discuss it on the list. Whether Lindens can assign bugs to residents is undefined as well. My guess is that it may be allowed, but they probably won't do it, unless at some point a contributor for example declares themselves and is accepted as the maintainer of a part of the code (eg, if my avatar scanner gets merged and I say I'm willing to do it, maybe they'll start assigning its bugs to me) It's not specified whether assigning a bug to another contributor is allowed. My guess is that it also requires consent and there may be consequences if you do it without permission and the one you assigned it to complains. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/2b630b2a/attachment.pgp From blakar at gmail.com Thu Sep 6 05:22:17 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Sep 6 05:22:21 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <20070906113505.GA15043@bruno.sbruno> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> Message-ID: <7992d0d60709060522o3ab77c92y1181126e62699ca1@mail.gmail.com> My reading is: Don't assign to a Linden without their consent. That's it. The reason should be obvious if you think about it: When LL uses PJIRA as an official tool they will run official reporting and whichever Linden doesn't work on this assignments gets a spanking. As such that Linden will be rather annoyed when he finds out that some overeager outsider has been assigning things to him. All the other examples are pretty pointless because they have no real use. The only useful reason to assign tasks to others is when they can't do so themselfs or if you're authorative when it comes to what they must do. Given Lindens don't have the authority to assign tasks to contributors just like contributors don't have when it comes to other contributors there's no need to debate it. For triages it could probably be useful to have a single person assign tasks in PJIRA during the meeting. Though in that case you'll have consent as that one person will just have to update whenever someone commits to providing something. That's nothing more than administrative efficiency. Dirk aka Blakar Ogre From roamingryozu at gmail.com Thu Sep 6 06:58:48 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Thu Sep 6 06:58:50 2007 Subject: [sldev] RE: NSV Support In-Reply-To: References: Message-ID: <5eff6d3b0709060658t56cd5c0fn708c54ec62fc89b2@mail.gmail.com> My two cents on the issue: Adding NSV support would probably be fine, as long as all you have to say to the end user is "Please install Winamp to play streaming video on these parcels." If you get any more technical than that, it won't fly. I'd love NSV support as it's a lot easier to deal with, and live streaming is free, as opposed to many quicktime streaming solutions. It's just also useless to the masses if it's not simply integrated into the client, or relies only on having installed a common program such as winamp. Asking to install codecs or plugins is not something I see the average SL resident following through on. As far as QuickTime .MOV files and buffering times go, that's almost entirely how the file is encoded. You have to remember .mov is a container format. In many cases, the file must be encoded with particular codecs, as well as have to the for streaming bit set in the container before it will play without needing long buffer times. On 9/5/07, Ernie Kabowski wrote: > > This will be my last entry on NSV support as its support status > seems to be: play it if you got it. > > Using softwares age to excuse it's lacking in comparison is bad > practice. I could say EasyWriter is better than Open Office by > two decades. > > What's real is the QuickTime player that integrates on the majority > of platforms doesn't have default NSV support. It takes a plugin. > > Also another thing that can be ignored in retorts, but not in > usability is that fact it takes 2 plus minutes to buffer for > playback on apple video on a 1.5Mbps(1.04Mbps) downstream from > a commercial 8Mbps upstream dedicated server under little load. > > You can only ignore reality, but it's still there when denial > isn't. > > I'm not going against Apple ether, so drones need not worry. > > ____________________________________________________________ > FREE ONLINE PHOTOSHARING - Share your photos online with your friends and > family! > Visit http://www.inbox.com/photosharing to find out more! > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/11a659ce/attachment.htm From roamingryozu at gmail.com Thu Sep 6 07:51:28 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Thu Sep 6 07:51:31 2007 Subject: [sldev] Re: [META] [JIRA] *IMPORTANT* New PJIRA Perms (Nicholaz Beresford) In-Reply-To: <68AC19C7-25B4-4708-9227-D48C2834EA20@gmail.com> References: <20070905113451.21E1B41B1D8@stupor.lindenlab.com> <68AC19C7-25B4-4708-9227-D48C2834EA20@gmail.com> Message-ID: <5eff6d3b0709060751o67130540w7ccaa39340787924@mail.gmail.com> I believe this is intended actually, to limit the possibility of getting in-world IM spam from out of world e-mail. Last thing we need is viagra spam in our in-world IMs ever few minutes. Heh. I believe what Argent was referring to, is the lack of e-mail support in pjira. On 9/5/07, Argent Stonecutter wrote: > > From: Nicholaz Beresford > > Now if we could get the email addresses (btw, why don't you > > just put the email addresses from the SL accounts into the > > profiles)? > > I'm not sure what you're referring to here, but as public as I am I > would prefer to limit the number of searchable databases my email > addresses are automatically added to. > > Really, I'd like to have this option in preferences: > > [X] Accept mail to Argent.Stonecutter@residents.secondlife.com for > forwarding to IM > > So I can be more easily contacted by customers who aren't in-world. > > I'm surprised that nobody's set up a SL-account email-to-IM proxy > already, actually. I guess because only LL could do it properly since > they could send replyable IMs that would go to email, whereas a third- > party could only send scripted in-world IMs that just show up if > you're online. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/8d9ef08c/attachment-0001.htm From nicholaz at blueflash.cc Thu Sep 6 07:59:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Sep 6 07:59:32 2007 Subject: [sldev] [VIEWER] Redmapping, silent disconnect Message-ID: <46E015D0.1060306@blueflash.cc> Hi! I had a few users asked about redmapping or timeout disconnects (e.g. when the viewer stalls for a bit (or even is held in the debugger for a minute)) and then communication is broken. Does anyone know of an area in the source where to detect that (to indicate that connection is lost) or sort of a ping message that could be used for that purpose? Nick From jhurliman at wsu.edu Thu Sep 6 08:05:30 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Sep 6 08:05:42 2007 Subject: [sldev] [VIEWER] Redmapping, silent disconnect In-Reply-To: <46E015D0.1060306@blueflash.cc> References: <46E015D0.1060306@blueflash.cc> Message-ID: <46E0173A.7040602@wsu.edu> Nicholaz Beresford wrote: > > Hi! > > I had a few users asked about redmapping or timeout disconnects > (e.g. when the viewer stalls for a bit (or even is held in the > debugger for a minute)) and then communication is broken. > > Does anyone know of an area in the source where to detect that > (to indicate that connection is lost) or sort of a ping message > that could be used for that purpose? > > > Nick It was my understanding that the bidirectional StartPingCheck CompletePingCheck packets were used by the client and server both to detect timeouts. I haven't taken a look at the source code there though so I don't know if that is true for sure. John From tlang303 at gmail.com Thu Sep 6 08:44:10 2007 From: tlang303 at gmail.com (Tobias Lang) Date: Thu Sep 6 08:44:16 2007 Subject: [sldev] Problems merging new LL code with SVK source version control Message-ID: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> Hello, I make quite a lot of changes to the SL viewer and always struggle applying my changes to a new LL release. After following the instructions for the SVK version control http://wiki.secondlife.com/wiki/Source_version_control I can update to a new LL code very easliy, but only if I use the same branch, like 1.18.1. If LL releases a new viewer in another branch like 1.18.3 the "smerge" SVK command doesn't work anymore, telling me that no common merge base exists between the LL branch and my SVN repository. Is this a common problem or am I doing s.th. wrong? How to you guys usually update to a new version? Merging always manually? Thank you, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/82d9c410/attachment.htm From monkowsk at watson.ibm.com Thu Sep 6 09:06:11 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Sep 6 09:06:24 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46DE090B.8060905@lindenlab.com> References: <46DDEF28.5010303@watson.ibm.com> <46DE090B.8060905@lindenlab.com> Message-ID: <46E02573.4080707@watson.ibm.com> Excellent! Thank you very much Iridium. I guess I'll have to run that contributors agreement by the company lawyers now. I took the liberty of putting this info out on the Wiki at http://wiki.secondlife.com/wiki/Category:Feature_Requests under topic "Tracking New Features that you are working on." Feel free to modify it if you don't like my editing. Mike Iridium Linden wrote: > Mike, first let me thank you for your email and bringing this to our > attention. Rob and I both thought that this was a really good idea, and > it hearkens back to conversations that we've had with other Open Source > Lindens about giving SL Devs more permissions in Public JIRA. In honor > of PJIRA Awareness Month (September at LL), we have decided to create a > PJIRA group with permissions to assign tasks. Here are the details: ... From jhurliman at wsu.edu Thu Sep 6 09:48:07 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Sep 6 09:49:45 2007 Subject: [sldev] Problems merging new LL code with SVK source version control In-Reply-To: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> Message-ID: <46E02F47.1070304@wsu.edu> Tobias Lang wrote: > Hello, > > I make quite a lot of changes to the SL viewer and always struggle > applying my changes to a new LL release. After following the > instructions for the SVK version control > http://wiki.secondlife.com/wiki/Source_version_control I can update > to a new LL code very easliy, but only if I use the same branch, like > 1.18.1. If LL releases a new viewer in another branch like 1.18.3 the > "smerge" SVK command doesn't work anymore, telling me that no common > merge base exists between the LL branch and my SVN repository. > > Is this a common problem or am I doing s.th . wrong? How > to you guys usually update to a new version? Merging always manually? > > Thank you, > Tobias I can't provide any useful advice on how to use SVK, but I use patch files excessively. Whenever I accomplish something that might be worth keeping I create a patch file out of it. Then if you do something else noteworthy in the same files the first patch touched you can reverse apply the first patch, create the second patch, then reapply the first. When a new viewer is released apply your patchset to the new branch and manually inspect any conflicts to see what needs updating. If you decide to create a JIRA for any of it you already have patch files on hand. John Hurliman From seg at haxxed.com Thu Sep 6 10:06:07 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 6 10:06:19 2007 Subject: [sldev] [VIEWER] Redmapping, silent disconnect In-Reply-To: <46E015D0.1060306@blueflash.cc> References: <46E015D0.1060306@blueflash.cc> Message-ID: <1189098367.2798.74.camel@localhost> On Thu, 2007-09-06 at 16:59 +0200, Nicholaz Beresford wrote: > Hi! > > I had a few users asked about redmapping or timeout disconnects > (e.g. when the viewer stalls for a bit (or even is held in the > debugger for a minute)) and then communication is broken. > > Does anyone know of an area in the source where to detect that > (to indicate that connection is lost) or sort of a ping message > that could be used for that purpose? Well, considering that when this happens, the client sits there spewing "Tried to send packet on non-existent circuit" messages nonstop, I'd look there. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/d3a9c114/attachment.pgp From seg at haxxed.com Thu Sep 6 10:12:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 6 10:12:16 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <7992d0d60709060522o3ab77c92y1181126e62699ca1@mail.gmail.com> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> <7992d0d60709060522o3ab77c92y1181126e62699ca1@mail.gmail.com> Message-ID: <1189098733.2798.78.camel@localhost> On Thu, 2007-09-06 at 14:22 +0200, Dirk Moerenhout wrote: > My reading is: > Don't assign to a Linden without their consent. > > That's it. The reason should be obvious if you think about it: > When LL uses PJIRA as an official tool they will run official > reporting and whichever Linden doesn't work on this assignments gets a > spanking. As such that Linden will be rather annoyed when he finds out > that some overeager outsider has been assigning things to him. I don't see why this is a big deal. If someone assigns something to you without your consent, just un-assign yourself. Or does Jira not allow that? If someone makes a habit of doing such, ask them to stop. If they don't, then bring out the banhammer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/a9edf6b0/attachment.pgp From dale at daleglass.net Thu Sep 6 10:34:40 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 6 10:34:50 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> Message-ID: <200709061934.44785.dale@daleglass.net> On Thursday 06 September 2007 17:44:10 Tobias Lang wrote: > Hello, > > I make quite a lot of changes to the SL viewer and always struggle > applying my changes to a new LL release. After following the > instructions for the SVK version control > http://wiki.secondlife.com/wiki/Source_version_control I can update to a > new LL code very easliy, but only if I use the same branch, like 1.18.1. > If LL releases a new viewer in another branch like 1.18.3 the "smerge" > SVK command doesn't work anymore, telling me that no common merge base > exists between the LL branch and my SVN repository. > > Is this a common problem or am I doing s.th. wrong? How to you guys > usually update to a new version? Merging always manually? > > Thank you, > Tobias Ok, the trick is that SVK needs a continous history from where you started to where you are now to figure out what to merge, and LL sometimes screws it up. There seems to be some confusion regarding what LL works on, /release or /branch/Branch*, etc. Recently they first committed the 1.18.2 changes into the 1.18.1 branch, THEN made 1.18.2 from that. So a smerge from 1.18.1 will work OK. LL seems to branch inconsistently, sometimes they do it from /release, sometimes from /branches/Branch*. So long the branch is from the previous one smerge should work. For SL it's pretty easy anyway: You need to find the first revision after you merged and merge from there with 'svk merge' instead of 'svk smerge'. Doing that will create a merge point, and after that you can use smerge again. The -C argument will test a merge without actually doing it, you can use that to safely play with the revision arguments until you get it right. You can find the revision by using svk log. Some hints: Use the -I (uppercase I as in the first character of "information" for those with evil fonts) argument to smerge. That results in a merge being done revision by revision instead of as one big chunk. If you're 5 revisions behind, without -I you're merging all 5 as one into the destination, while with -I you'll commit 5. That makes things a lot friendlier for external SVN users, and makes things much nicer for you if you need to merge the results of the merge somewhere else. The -l (lowercase L as in "land") argument will copy log entries. -Il will merge revision by revision, copying the original log entries so that you don't have to enter your own. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/cc6693da/attachment.pgp From simon at lindenlab.com Thu Sep 6 10:36:20 2007 From: simon at lindenlab.com (Dave Simmons (Simon)) Date: Thu Sep 6 10:36:23 2007 Subject: Japanese bugs, was Re: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> Message-ID: <46E03A94.3040309@lindenlab.com> Hi Alissa (and anyone else who's interested) - Thanks, I'll take a look at your patch. I did some of the same work on positioning the IME input where the text carat is located in text fields and editors. I haven't submitted the code yet as it's only partially working - it won't follow the field around correctly if you drag a floating window. Unfortunately I've had to look at some other more explosive problems and haven't had much time this week, but should be able to get back to it in a few days. I'll update VWR-250 when I make some progress. Thanks for the help on this, - Simon Alissa Sabre wrote: >> I was just fixing some Japanese IME input bugs yesterday >> (which should fix Chinese and Korean as well). >> > > Great. > > What is the JIRA issue number of that bug? > > >> Perhaps we should get >> in touch off-line to see if I can help bring some of your work into the >> main code. It would be nice to get the SL viewer working better with >> these languages. >> > > Exactly. > > Have you seen my patch? It's available on JIRA issue VWR-250. > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > From iridium at lindenlab.com Thu Sep 6 11:16:22 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Thu Sep 6 11:17:04 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <20070906113505.GA15043@bruno.sbruno> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> Message-ID: <46E043F6.50001@lindenlab.com> Lindens will NOT assign JIRA tasks to Open Source contributors without explicit consent. We expect the same courtesy. In that vein, I'm assuming that Open Source contributors will not assign tasks to other Open Source contributors without consent. The purpose of this move on our part is to allow Open Source contributors to make their work more transparent in JIRA. If you are working on a patch, it makes sense that you should be able to indicate progress. Assigning an issue to yourself will inform Lindens and your peers of that work in progress or your forthcoming contribution. So: 1) Lindens will not assign tasks to OS contributors without consent. 2) OS contributors should not assign tasks to other OS contributors without consent. 3) OS contributors must not assign tasks to Lindens without consent. These permissions are intended to give OS contributors the power to assign tasks to themselves as an effort to indicate work in progress or forthcoming commitment to a patch. Iridium Dale Glass wrote: > On Thu, Sep 06, 2007 at 08:04:44PM +0900, Alissa Sabre wrote: > >> Just to making sure. >> >> >>> a) These permissions were introduced so that Open Source Contributors >>> could assign JIRA tasks to *themselves* in order to show that work is in >>> progress. >>> b) These permissions also allow you to assign tasks to Lindens. >>> c) *If you assign a JIRA task to a Linden without the explicit consent >>> of that Linden, you will immediately be ejected from the group and your >>> permissions thusly lost. >>> >> That means: >> >> - An Open Souece Contributor may assign a taks to another Open Source >> Contributor. >> - A Linden may assign a task to another Linden. >> - A Linden may assign a taks to an Open Source Contributor. >> - An Open Source Contributor *must*not* assign a task to a Linden. >> >> Am I correct? >> > > My reading is: > > The rules are: > > * A contributor may assign bugs to themselves > * A contributor MAY NOT assign bugs to a Linden without their consent > > Speculation: > > Rules for Lindens are unclear, but that's an internal matter between > them an LL. My guess is that Lindens can assign bugs to each other and > consent will be there pretty much all the time, although we won't see > them discuss it on the list. > > Whether Lindens can assign bugs to residents is undefined as well. My > guess is that it may be allowed, but they probably won't do it, unless > at some point a contributor for example declares themselves and is > accepted as the maintainer of a part of the code (eg, if my avatar > scanner gets merged and I say I'm willing to do it, maybe they'll > start assigning its bugs to me) > > It's not specified whether assigning a bug to another contributor is > allowed. My guess is that it also requires consent and there may be > consequences if you do it without permission and the one you assigned > it to complains. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/52794948/attachment.htm From seg at haxxed.com Thu Sep 6 11:24:43 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 6 11:24:51 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46E043F6.50001@lindenlab.com> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> <46E043F6.50001@lindenlab.com> Message-ID: <1189103083.2798.84.camel@localhost> On Thu, 2007-09-06 at 11:16 -0700, Iridium Linden wrote: > So: > 1) Lindens will not assign tasks to OS contributors without consent. > 2) OS contributors should not assign tasks to other OS contributors > without consent. > 3) OS contributors must not assign tasks to Lindens without consent. > These permissions are intended to give OS contributors the power to > assign tasks to themselves as an effort to indicate work in progress > or forthcoming commitment to a patch. "Don't assign tasks to anyone without their consent" would be simpler and doesn't serve to gratuitously continue division between Linden and non-Linden. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/ffb64f7b/attachment.pgp From robla at lindenlab.com Thu Sep 6 11:54:25 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 6 11:54:29 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <1189103083.2798.84.camel@localhost> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> <46E043F6.50001@lindenlab.com> <1189103083.2798.84.camel@localhost> Message-ID: <46E04CE1.1070603@lindenlab.com> On 9/6/07 11:24 AM, Callum Lerwick wrote: > On Thu, 2007-09-06 at 11:16 -0700, Iridium Linden wrote: > >> So: >> 1) Lindens will not assign tasks to OS contributors without consent. >> 2) OS contributors should not assign tasks to other OS contributors >> without consent. >> 3) OS contributors must not assign tasks to Lindens without consent. >> These permissions are intended to give OS contributors the power to >> assign tasks to themselves as an effort to indicate work in progress >> or forthcoming commitment to a patch. >> > > "Don't assign tasks to anyone without their consent" would be simpler > and doesn't serve to gratuitously continue division between Linden and > non-Linden. :) > Ok Miss Manners. ;-) Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/c190cc57/signature.pgp From tlang303 at gmail.com Thu Sep 6 12:33:40 2007 From: tlang303 at gmail.com (Tobias Lang) Date: Thu Sep 6 12:33:45 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <200709061934.44785.dale@daleglass.net> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> <200709061934.44785.dale@daleglass.net> Message-ID: <66bc8ec50709061233q72492ce9jdfe88ed1831f604c@mail.gmail.com> Thank you for your explanation Dale, but I am still not successful. The smerge for 1.18.2 indeed worked well, but I don't get 1.18.3 working. After trying I ended up with: *svk merge -ll -r 184:185 //mirror/secondlife/branches/Branch_1-18-3-Viewer //mirror/secondlifeAEL* since the log command revealed that r184 is the first revision of the 1-18-3 branch. It merges s.th. but I get compiler errors afterwards so s.th. must be wrong. On 9/6/07, Dale Glass wrote: > > On Thursday 06 September 2007 17:44:10 Tobias Lang wrote: > > Hello, > > > > I make quite a lot of changes to the SL viewer and always struggle > > applying my changes to a new LL release. After following the > > instructions for the SVK version control > > http://wiki.secondlife.com/wiki/Source_version_control I can update to a > > new LL code very easliy, but only if I use the same branch, like 1.18.1. > > If LL releases a new viewer in another branch like 1.18.3 the "smerge" > > SVK command doesn't work anymore, telling me that no common merge base > > exists between the LL branch and my SVN repository. > > > > Is this a common problem or am I doing s.th. wrong? How to you guys > > usually update to a new version? Merging always manually? > > > > Thank you, > > Tobias > > Ok, the trick is that SVK needs a continous history from where you started > to where you are now to figure out what to merge, and LL sometimes screws > it up. There seems to be some confusion regarding what LL works > on, /release or /branch/Branch*, etc. Recently they first committed the > 1.18.2 changes into the 1.18.1 branch, THEN made 1.18.2 from that. So a > smerge from 1.18.1 will work OK. > > LL seems to branch inconsistently, sometimes they do it from /release, > sometimes from /branches/Branch*. So long the branch is from the previous > one smerge should work. > > For SL it's pretty easy anyway: You need to find the first revision after > you merged and merge from there with 'svk merge' instead of 'svk smerge'. > Doing that will create a merge point, and after that you can use smerge > again. > > The -C argument will test a merge without actually doing it, you can use > that to safely play with the revision arguments until you get it right. > > You can find the revision by using svk log. > > Some hints: > > Use the -I (uppercase I as in the first character of "information" for > those with evil fonts) argument to smerge. That results in a merge being > done revision by revision instead of as one big chunk. If you're 5 > revisions behind, without -I you're merging all 5 as one into the > destination, while with -I you'll commit 5. That makes things a lot > friendlier for external SVN users, and makes things much nicer for you if > you need to merge the results of the merge somewhere else. > > The -l (lowercase L as in "land") argument will copy log entries. -Il will > merge revision by revision, copying the original log entries so that you > don't have to enter your own. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/b4d64b6f/attachment.htm From dale at daleglass.net Thu Sep 6 13:35:47 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 6 13:35:58 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <66bc8ec50709061233q72492ce9jdfe88ed1831f604c@mail.gmail.com> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> <200709061934.44785.dale@daleglass.net> <66bc8ec50709061233q72492ce9jdfe88ed1831f604c@mail.gmail.com> Message-ID: <200709062235.52857.dale@daleglass.net> On Thursday 06 September 2007 21:33:40 Tobias Lang wrote: > Thank you for your explanation Dale, but I am still not successful. The > smerge for 1.18.2 indeed worked well, but I don't get 1.18.3 working. > After trying I ended up with: *svk merge -ll -r 184:185 > //mirror/secondlife/branches/Branch_1-18-3-Viewer > //mirror/secondlifeAEL* since the log command revealed that r184 is the Technically, you should avoid working on //mirror paths for this, as the whole point of SVK is to work without being dependent on an external server. Really all that's needed is to svk sync //mirror/secondlife, which should always succeed. Then you can do the whole merge offline, and upload changes to a server whenever convenient. This is the reason I work in //dg and not //mirror/daleglass. Mind, it should work fine anyway. > first revision of the 1-18-3 branch. It merges s.th. but I get compiler > errors afterwards so s.th. must be wrong. I don't have a file called s.th in my tree. Where is it and what errors do you get? Merging correctly doesn't guarantee that compilation will work, btw. Suppose we have a function that originally says: S32 foo = 0; I take that original code, and remove that variable from it. Then the next version comes from LL, where 50 lines down they add something like: llinfos << "Foo is " << foo << llendl; Then the merge will add this line to the code, even though I removed the declaration. This may very well merge perfectly, but compilation will fail. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/e5085051/attachment.pgp From robla at lindenlab.com Thu Sep 6 13:41:51 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 6 13:41:57 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <20070906113505.GA15043@bruno.sbruno> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> Message-ID: <46E0660F.9020509@lindenlab.com> Dale's got this roughly right. I doubt we're going to be as draconian as Iridium is letting on, but the point is: please don't abuse the new tool we're putting in your hands. And, if Iridium does deem it necessary to pull out the can of whip-ass, consider yourself warned. Could someone volunteer to capture this somewhere on the wiki? I'm happy to review for accuracy. Rob On 9/6/07 4:35 AM, Dale Glass wrote: > On Thu, Sep 06, 2007 at 08:04:44PM +0900, Alissa Sabre wrote: > >> Just to making sure. >> >> >>> a) These permissions were introduced so that Open Source Contributors >>> could assign JIRA tasks to *themselves* in order to show that work is in >>> progress. >>> b) These permissions also allow you to assign tasks to Lindens. >>> c) *If you assign a JIRA task to a Linden without the explicit consent >>> of that Linden, you will immediately be ejected from the group and your >>> permissions thusly lost. >>> >> That means: >> >> - An Open Souece Contributor may assign a taks to another Open Source >> Contributor. >> - A Linden may assign a task to another Linden. >> - A Linden may assign a taks to an Open Source Contributor. >> - An Open Source Contributor *must*not* assign a task to a Linden. >> >> Am I correct? >> > > My reading is: > > The rules are: > > * A contributor may assign bugs to themselves > * A contributor MAY NOT assign bugs to a Linden without their consent > > Speculation: > > Rules for Lindens are unclear, but that's an internal matter between > them an LL. My guess is that Lindens can assign bugs to each other and > consent will be there pretty much all the time, although we won't see > them discuss it on the list. > > Whether Lindens can assign bugs to residents is undefined as well. My > guess is that it may be allowed, but they probably won't do it, unless > at some point a contributor for example declares themselves and is > accepted as the maintainer of a part of the code (eg, if my avatar > scanner gets merged and I say I'm willing to do it, maybe they'll > start assigning its bugs to me) > > It's not specified whether assigning a bug to another contributor is > allowed. My guess is that it also requires consent and there may be > consequences if you do it without permission and the one you assigned > it to complains. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/f6f2a94b/signature.pgp From robla at lindenlab.com Thu Sep 6 13:44:12 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 6 13:44:18 2007 Subject: [sldev] Updates on RC Message-ID: <46E0669C.9090801@lindenlab.com> Hi folks, In the interest of keeping everyone abreast of what we're up to, I'm scanning some of our internal chatter and looking for tidbits I can publish: From Joshua Linden: > * 1.18.3 RC0 issues still being found by residents. Several fixed > internally, several still pending. > * See Bridie's page at: > https://wiki.secondlife.com/wiki/Bug_triage/Wednesday_Agenda > * Data: we branched on 8/22, 5 "fixes" (2 reversions) made; RC0 went > live on 8/29. 3 fixes since then, ~5 fixes needed > * Not looking like we'll have another RC this week. 9/12 is likely No promises I'll be very good at finding/publishing these bits, but per recent conversations, I'll try to be better, and encourage others here to do the same. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/42133417/signature.pgp From robla at lindenlab.com Thu Sep 6 13:53:25 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 6 13:53:29 2007 Subject: [sldev] Capabilities URLs In-Reply-To: <200709020251.06251.dale@daleglass.net> References: <200708310423.22452.dale@daleglass.net> <200709020211.28175.dale@daleglass.net> <200709020251.06251.dale@daleglass.net> Message-ID: <46E068C5.7090308@lindenlab.com> On 9/1/07 5:51 PM, Dale Glass wrote: > On Sunday 02 September 2007 02:31:20 Harold Brown wrote: > >> The cap URLS I posted do not require authentication, and as such appear >> to be static at the moment >> > Ok, that's good to know, thanks :-) > > Then the list only shows the ones that require authentication and you have > permission to use? > > If so, where is the list of services that anybody can use? > This thread spawned a long thread about what we should and shouldn't be encouraging on this front. To summarize: * We have two classes of cap.secondlife.com URLs: One used by the web team for the reg API and the APIs in Harold's message. The other used by the simulator for giving viewers access to various functions. * The former (web services APIs) are fine to publish, though they may not be stable APIs. Use at your own risk. * The latter (simulator access grants to the viewer) should be kept private. You really shouldn't be sharing those. * The two classes of caps URLs are visually indistinguishable. Yes, we know that's a problem. Much love to whoever finds a home for this information on the wiki (and actually posts it). Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/48bc1bb7/signature.pgp From dale at daleglass.net Thu Sep 6 14:42:21 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 6 14:42:33 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <66bc8ec50709061401u14fadbddq76edce6f866e5a97@mail.gmail.com> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> <200709062235.52857.dale@daleglass.net> <66bc8ec50709061401u14fadbddq76edce6f866e5a97@mail.gmail.com> Message-ID: <200709062342.26971.dale@daleglass.net> On Thursday 06 September 2007 23:01:35 Tobias Lang wrote: > On 9/6/07, Dale Glass wrote: > > Technically, you should avoid working on //mirror paths for this, as > > the whole point of SVK is to work without being dependent on an > > external server. Really all that's needed is to svk sync > > //mirror/secondlife, which should always succeed. Then you can do the > > whole merge offline, and upload changes to a server whenever > > convenient. > > I see, I guess I will make a local repository then as well, and start > from scratch... (CCing this to the list, assuming you sent it only to me by mistake) My general setup: //mirror/secondlife -- mirror of LL repository //mirror/daleglass -- mirror of svn.daleglass.net/sl //ll -- local copy of //mirror/secondlife //dg -- local copy of //mirror/daleglass Technically //ll is probably optional since it's effectively always in sync //mirror/secondlife. But I figure it's good for consistency, and in case LL ever gives me commit access. Then it'd be useful. My general work pattern: # Sync with LL tree. Needs a network connection, obviously. svk sync //mirror/secondlife # After this point, everything can be done offline ############################################# # Merge to local LL copy svk smerge -Il //mirror/secondlife //ll # Merge LL branch changes svk smerge -Il //ll/branches/Branch_1.18.2 //dg/branches/buildfixes_1.18.2 # Merge changes to feature branches svk smerge -Il //dg/branches/buildfixes //dg/branches/avatarscanner svk smerge -Il //dg/branches/buildfixes //dg/branches/viewercomm ... # Do whatever work on the branches is needed svk commit # (in a branch) # At this point there's a bunch of changes: New LL merges, new features of my own, bugfixes, etc. # Internet connection needed again ############################################# # Release to public SVN server svk smerge //dg //mirror/daleglass As you can see, an internet connection is only needed very shortly. Sync with LL will succeed unless something is badly broken (not normal). Sync with my SVN repository will succeed unless there was a commit to it and it conflicts with the changes I'm trying to merge (which won't happen) Even a few of minutes of connection that aren't timing sensitive at all are more than enough to do lots of useful work. > Sorry, with "s.th" I meant "something". I should be more clear when > talking about source code ;-) > It was an error in "llinventorybridge.cpp" with "item" defined several > times. I never touched this file, so I figured I mixed up some versions > incorrectly. Can happen if you merge something that can be merged twice and the change happens to be possible to apply twice, I think. If you didn't change the file you can fix it by brute force by svk copy from the original LL code to your. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/304461c2/attachment-0001.pgp From rdw at lindenlab.com Thu Sep 6 14:45:29 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Thu Sep 6 14:45:17 2007 Subject: [sldev] Capabilities URLs In-Reply-To: <46E068C5.7090308@lindenlab.com> References: <200708310423.22452.dale@daleglass.net> <200709020211.28175.dale@daleglass.net> <200709020251.06251.dale@daleglass.net> <46E068C5.7090308@lindenlab.com> Message-ID: <46E074F9.8010908@lindenlab.com> Rob Lanphier wrote: > On 9/1/07 5:51 PM, Dale Glass wrote: > >> On Sunday 02 September 2007 02:31:20 Harold Brown wrote: >> >> >>> The cap URLS I posted do not require authentication, and as such appear >>> to be static at the moment >>> >>> >> Ok, that's good to know, thanks :-) >> >> Then the list only shows the ones that require authentication and you have >> permission to use? >> >> If so, where is the list of services that anybody can use? >> >> > > This thread spawned a long thread about what we should and shouldn't be > encouraging on this front. To summarize: > > * We have two classes of cap.secondlife.com URLs: One used by the web > team for the reg API and the APIs in Harold's message. The other used > by the simulator for giving viewers access to various functions. > Sorry, Rob, I believe that this is incorrect. Our two cap classes are: - cap.secondlife.com - simFOO.agni.lindenlab.com:12043 Cap.secondlife.com caps appears to be used for two purposes: - sort of a temporary/hacky way to implement web apis. In this case the cap url is basically a way for the webdev team to muck with accessing internal data structures without going to the trouble of implementing a nice url structure. These should eventually be migrated to clean urls that are not https. - reg api participants. The reg api participant is given a set of capability urls that are intended for its use only, since each cap is authentication-included. Authentication-included means that anyone getting ahold of the cap url can act on behalf of the participant to whom the cap was granted! These caps should all be invoked over https to hide the url from sniffers. If you have one of these urls, you would know it. simFOO caps are for viewer<->sim communication, and are granted for the duration that a viewer has a connection to a simulator. They are also https. > * The two classes of caps URLs are visually indistinguishable. Yes, we > know that's a problem. > > The two cap.secondlife.com usages are indeed impossible to distinguish, but basically the rule with a cap is, if you know it, you can use it. There should be no deeper decision-making process on this side of the equation. Cap.secondlife.com capabilities tend to be fairly long-lived, but not infinitely long-lived, and they can be revoked at any time, so you cannot rely on them as a stable API. The decision-making process about whether to share a cap url that you have should hinge on what the cap does, and how it was granted to you, and whether you want other people to do the same things that you can do with it. In the case of caps in the map api, apparently some Linden made the decision that they can be public, because the information that they grant access to is public, and they don't grant any ability to change any internal data structures. In the case of reg api caps, you would definitely not want to share them, because a person holding one of your caps can do things in your name! You will be able to distinguish caps to a simulator, since they don't go to cap.secondlife.com. It's unlikely that you'd really come across one of these by accident, but you similarly do not want to share them. > Much love to whoever finds a home for this information on the wiki (and > actually posts it). > > True! -RYaN From monkowsk at watson.ibm.com Thu Sep 6 15:15:53 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Sep 6 15:15:57 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46E0660F.9020509@lindenlab.com> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> <46E0660F.9020509@lindenlab.com> Message-ID: <46E07C19.2010108@watson.ibm.com> Way ahead of ya Rob. See http://wiki.secondlife.com/wiki/Category:Feature_Requests under topic "Tracking New Features that you are working on." Feel free to modify it. Mike Rob Lanphier wrote: > Could someone volunteer to capture this somewhere on the wiki? I'm > happy to review for accuracy. > > Rob From iridium at lindenlab.com Thu Sep 6 15:21:44 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Thu Sep 6 15:22:25 2007 Subject: [sldev] [META] *IMPORTANT* New PJIRA Perms In-Reply-To: <46E07C19.2010108@watson.ibm.com> References: <46DE090B.8060905@lindenlab.com> <1ds4ds4t5Jtitdu4kzLeQ56w.alissa_sabre@yahoo.co.jp> <20070906113505.GA15043@bruno.sbruno> <46E0660F.9020509@lindenlab.com> <46E07C19.2010108@watson.ibm.com> Message-ID: <46E07D78.5070501@lindenlab.com> Nice work. Thanks, Mike. Mike Monkowski wrote: > Way ahead of ya Rob. See > http://wiki.secondlife.com/wiki/Category:Feature_Requests under topic > "Tracking New Features that you are working on." Feel free to modify it. > > Mike > > Rob Lanphier wrote: >> Could someone volunteer to capture this somewhere on the wiki? I'm >> happy to review for accuracy. >> >> Rob > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From monkowsk at watson.ibm.com Thu Sep 6 15:25:31 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Sep 6 15:25:32 2007 Subject: [sldev] Voice libraries tntk.dll and srtp.dll Message-ID: <46E07E5B.5030208@watson.ibm.com> I am in the process of trying to document some of the Voice code, and it appears to me that tntk.dll and srtp.dll (which is used by tntk.dll) are not used by SLVoice or any other module. They are part of the DiamondWare distribution, but don't appear to be used by SLVoiceAgent. I can rename them and Voice works just fine. Can someone at Linden verify this? Mike From anthony at lindenlab.com Thu Sep 6 16:26:44 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Sep 6 16:26:46 2007 Subject: [sldev] Source release for release branch 2007-Sep-06 Message-ID: <46E08CB4.4070909@lindenlab.com> Hey Everyone, We're going to start doing weekly dated snapshots of the internal release branch. Please be aware that this is a snapshot in time, so it may not build and it has not fully passed QA. As usual though, let us know of any issues. Release branch source available here: https://wiki.secondlife.com/wiki/Source_downloads#2007-Sep-06 Checksums: 89a1032f2150b97a9c7ebf13079da265 slviewer-darwin-libs-20070906a.tar.gz 9a8aba97f16cfaf76e3f6c98afd0979b slviewer-linux-libs-20070906a.tar.gz 81a27d476ca48562169d599fba4721c6 slviewer-src-20070906a.tar.gz 5f6c96dc9828c31eaa4b9a2022322c95 slviewer-artwork-20070906a.zip 945a4c4f7dc15e047b51f180b9cea746 slviewer-src-20070906a.zip a8f18b202ed7cf4a49e0a9c0a882a59e slviewer-win32-libs-20070906a.zip SVN checkout: Robla will send email when this is available. Enjoy. -Anthony From jhurliman at wsu.edu Thu Sep 6 16:31:35 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Sep 6 16:31:40 2007 Subject: [sldev] Voice libraries tntk.dll and srtp.dll In-Reply-To: <46E07E5B.5030208@watson.ibm.com> References: <46E07E5B.5030208@watson.ibm.com> Message-ID: <46E08DD7.3010303@wsu.edu> Mike Monkowski wrote: > I am in the process of trying to document some of the Voice code, and > it appears to me that tntk.dll and srtp.dll (which is used by > tntk.dll) are not used by SLVoice or any other module. They are part > of the DiamondWare distribution, but don't appear to be used by > SLVoiceAgent. I can rename them and Voice works just fine. Can > someone at Linden verify this? > > Mike srtp is the Secure RTP library (http://srtp.sf.net/) and I don't think anyone ever figured out what tntk.dll is. I don't think either of them are actually used, it is likely optional Vivox features that SL does not make use of or unreferenced libraries in a package of them. If you ever figure out what SLVoiceAgent actually does can you document it here? http://wiki.secondlife.com/wiki/Voice I assigned the JIRA task of providing documentation for the voice protocol to myself based on Rob's comment, but if you are going to tackle some of the work for me go right ahead ;-). John Hurliman From robla at lindenlab.com Thu Sep 6 18:22:37 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 6 18:22:45 2007 Subject: [sldev] sldev<=>Second Life name decoder ring Message-ID: <46E0A7DD.6000204@lindenlab.com> Hi all, A lot of us post to this mailing list under our real name, while participating on JIRA and wiki under our Second Life name. Even those that don't use their real name here may be using an alias that's different from said person's Second Life name. So, in the interest of trying to keep all of this straight, I've started a page here: https://wiki.secondlife.com/wiki/SLDev_Resident_Names If you post to this list under a name other than your resident name, please add it to the list. Thanks! Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/273d7f8e/signature.pgp From sllists at boroon.dasgupta.ch Fri Sep 7 06:04:13 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Sep 7 06:04:23 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <200709062235.52857.dale@daleglass.net> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> <200709061934.44785.dale@daleglass.net> <66bc8ec50709061233q72492ce9jdfe88ed1831f604c@mail.gmail.com> <200709062235.52857.dale@daleglass.net> Message-ID: <51473.83.180.254.242.1189170253.squirrel@datendelphin.net> > On Thursday 06 September 2007 21:33:40 Tobias Lang wrote: >> first revision of the 1-18-3 branch. It merges s.th. but I get compiler >> errors afterwards so s.th. must be wrong. > I don't have a file called s.th in my tree. Where is it and what errors do > you get? I guess this should translate to "[...] It merges *something* but [...]". Btw, thunderbird seems to believe s.th to be a domain and hyperlinks it to http://s.th/ :-P cheers Boroondas From dale at daleglass.net Fri Sep 7 07:07:09 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 07:09:08 2007 Subject: [sldev] Re: Problems merging new LL code with SVK source version control In-Reply-To: <51473.83.180.254.242.1189170253.squirrel@datendelphin.net> References: <66bc8ec50709060844w69590e07ib3689730f1537a94@mail.gmail.com> <200709062235.52857.dale@daleglass.net> <51473.83.180.254.242.1189170253.squirrel@datendelphin.net> Message-ID: <200709071607.18036.dale@daleglass.net> On Friday 07 September 2007 15:04:13 Boroondas Gupte wrote: > I guess this should translate to "[...] It merges *something* but > [...]". Right, didn't know about that abbreviation. > > Btw, thunderbird seems to believe s.th to be a domain and hyperlinks it > to http://s.th/ :-P Thailand TLD. http://en.wikipedia.org/wiki/.th -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070907/53eb3bd9/attachment.pgp From hakushakukun at gmail.com Fri Sep 7 12:13:06 2007 From: hakushakukun at gmail.com (Adric R) Date: Fri Sep 7 12:13:09 2007 Subject: [sldev] Errors while building RC Message-ID: <781e4b420709071213u6b59846bhc9f6e2aeed916ba2@mail.gmail.com> I'm trying to build a ReleaseForDownload of 1.18.3 in VS2003 and I keep getting the same 73 errors. I've triple checked all the third party libraries are there, and I've followed all the instructions on the wiki, so I'm a bit at a loss. I've posted the error list at https://wiki.secondlife.com/wiki/User:McCabe_Maxsted . If you wouldn't mind having a look, any help would be appreciated. -- Adric (aka McCabe Maxsted) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070907/3a812c07/attachment.htm From nicholaz at blueflash.cc Fri Sep 7 12:30:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Sep 7 12:31:03 2007 Subject: [sldev] Errors while building RC In-Reply-To: <781e4b420709071213u6b59846bhc9f6e2aeed916ba2@mail.gmail.com> References: <781e4b420709071213u6b59846bhc9f6e2aeed916ba2@mail.gmail.com> Message-ID: <46E1A6EB.2090002@blueflash.cc> Hmm, check Newview, Properties, Linker, Input if you have llmozlib.lib and ws2_32.lib there. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Adric R wrote: > I'm trying to build a ReleaseForDownload of 1.18.3 in VS2003 and I keep > getting the same 73 errors. I've triple checked all the third party > libraries are there, and I've followed all the instructions on the wiki, > so I'm a bit at a loss. I've posted the error list at > https://wiki.secondlife.com/wiki/User:McCabe_Maxsted . If you wouldn't > mind having a look, any help would be appreciated. > > -- Adric (aka McCabe Maxsted) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Fri Sep 7 14:18:00 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 7 14:18:05 2007 Subject: [sldev] [POLICY] New mailing list keywords posted Message-ID: <46E1C008.9010006@lindenlab.com> Hi folks, At yesterday's meeting, we talked quite a bit about the mailing list traffic and the keywords (MISC-642), and while there wasn't jubilation and excitement, I think we've got a reasonable starting point here: https://wiki.secondlife.com/wiki/SLDev The transcript for this meeting is here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-09-06 (and I also posted the prior week's meeting, too) Please direct follow-ups to this page: https://wiki.secondlife.com/wiki/Talk:SLDev Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070907/4232111b/signature.pgp From jessesa at gmail.com Fri Sep 7 16:14:34 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Fri Sep 7 16:14:36 2007 Subject: [sldev][POLICY]Weekly Meetings Message-ID: Apologies if this should have been in Meta instead. I am over the purchasing department of a small firm and use a high end program for pulling BOM's off of ACAD files/tracking/multing/purchasing/shipping. Although I only work 40 hours per week, to get everything done in the alloted time I count my time in man-minutes, not man-hours. The difference between placing an order for steel and keeping the shop fed with work or not sometimes boils down to 5-10 minutes. I have been away from the community for several months and for the first time I read the log from the weekly sldev meeting. I am sorry but I was shocked. Is it always like this? This must be incredibly frustrating for the 3 Lindens in attendance to waste 3 hours in such a fashion. 3 man hours, nearly 1/10 of a full week gone. Such a simple item on the agenda; what tags to use? Rob did a good job in trying to keep the meeting on track and on target but didn't succeed. Has the weekly meeting become a waste of time? Is there a more efficient way of acheiving the same goals. With the advent of Tags, couldn't the same thing be accomplished here in the mailing list now? The vast majority of the mailing list members will never be able to attend the weekly meeting due to conflicts with our work schedules anyway. Jesse aka Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070907/974aedf9/attachment.htm From jhurliman at wsu.edu Fri Sep 7 16:37:20 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Sep 7 16:37:35 2007 Subject: [sldev] [POLICY] New mailing list keywords posted In-Reply-To: <46E1C008.9010006@lindenlab.com> References: <46E1C008.9010006@lindenlab.com> Message-ID: <46E1E0B0.402@wsu.edu> Rob Lanphier wrote: > Please direct follow-ups to this page: > https://wiki.secondlife.com/wiki/Talk:SLDev > > Rob > Is there a tutorial somewhere on how to use a wiki for conversation? In my e-mail client I have a threaded discussion view, new chat is pushed in to my inbox in realtime, I can apply filters to move things to my trash or highlight threads and messages, and manually tag threads and messages. I don't know how to do any of this with a wiki. To make matters worse, whenever I read a wiki it is directed at a general audience of "the reader", so when two people on the same page are disagreeing they never address each other directly and instead try to persuade the general reader that the other person doesn't know what they are talking about. On talk pages some people indent when replying and some people use line breaks, some people sign their comments and some don't (or forget). People might post something at the top of the page, the bottom, start a new section in the middle, and there is nothing tying everything together to give you a feel of the timeline. Without reading through every diff in the history it is hard to see who said what, and peoples comments often get changed or deleted and lost unless you are in the habit of reading through every changelog for every wiki page you read. John Hurliman From robla at lindenlab.com Fri Sep 7 16:58:28 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 7 16:58:44 2007 Subject: [sldev][POLICY]Weekly Meetings In-Reply-To: References: Message-ID: <46E1E5A4.8070802@lindenlab.com> On 9/7/07 4:14 PM, Jesse Barnett wrote: > > Apologies if this should have been in Meta instead. > This is fine. POLICY is kind of a subset of META. I /almost/ merged the two for the sake of simplicity. > [...]I have been away from the community for several months and for > the first time I read the log from the weekly sldev meeting. Welcome back! > I am sorry but I was shocked. Is it always like this? This must be > incredibly frustrating for the 3 Lindens in attendance to waste 3 > hours in such a fashion. 3 man hours, nearly 1/10 of a full week gone. > Such a simple item on the agenda; what tags to use? Doing that same multiplication exercise over a list of 550 makes me think it might be worth it if we can regularly save a portion of those people time. Of those, 52 of them are Lindens. Moreover, I haven't given up on the other guidelines. But it was probably a bit much. > Rob did a good job in trying to keep the meeting on track and on > target but didn't succeed. You're giving me way too much credit....I should have wrapped it up much sooner. > Has the weekly meeting become a waste of time? Is there a more > efficient way of acheiving the same goals. With the advent of Tags, > couldn't the same thing be accomplished here in the mailing list now? > This last meeting was hopefully not fully representative of the general utility. Real-time interaction is useful, and there's a lot of use in eating our own dogfood for this type of meeting. It's also generally a better place to diffuse a flamewar than sticking with the mailing list. It could be much better, though. Getting things on the agenda beforehand, and using it as a way of unblocking stalled mailing list conversations can be really useful. Even those that can't attend can get something useful out of making sure the agenda is crisp and relevant. We'll sometimes put stuff on the agenda, but we're relying on the community to set the agenda. This has historically worked better for the bug triages than it has for this meeting, but I'm hoping that someone will be wiling to pitch in on making this meeting better. > The vast majority of the mailing list members will never be able to > attend the weekly meeting due to conflicts with our work schedules > anyway. > For many residents in North America (Central Time and westward), this is an inopportune time, but given that Second Life is global, there are others for whom this works just fine for. There are inevitably times which don't work for someone, so we pick a time that's at least convenient for us, and hope that we can pick up as many people as possible. I'm usually on irc.efnet.org #opensl pretty much anytime I have my work laptop on, so that's another real-time mechanism that often works outside of normal business hours. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070907/1acf2678/signature.pgp From tshephard at gmail.com Fri Sep 7 17:06:30 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Sep 7 17:06:32 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers Message-ID: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> http://secondlife.reuters.com/stories/2007/09/06/rival-grids-threaten-lindens-monopoly-on-sl-technology/ For those who are looking for something to test their Clients against, this might be the way to go. Cheers, Tim. From seg at haxxed.com Fri Sep 7 17:10:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 7 17:10:28 2007 Subject: [sldev] [POLICY] New mailing list keywords posted In-Reply-To: <46E1E0B0.402@wsu.edu> References: <46E1C008.9010006@lindenlab.com> <46E1E0B0.402@wsu.edu> Message-ID: <1189210216.2798.148.camel@localhost> Is there a tutorial somewhere on how to use a wiki for conversation? In my e-mail client I have a threaded discussion view, new chat is pushed in to my inbox in realtime, I can apply filters to move things to my trash or highlight threads and messages, and manually tag threads and messages. I don't know how to do any of this with a wiki. To make matters worse, whenever I read a wiki it is directed at a general audience of "the reader", so when two people on the same page are disagreeing they never address each other directly and instead try to persuade the general reader that the other person doesn't know what they are talking about. I agree! On talk pages some people indent when replying and some people use line breaks, some people sign their comments and some don't (or forget). People might post something at the top of the page, the bottom, start a new section in the middle, and there is nothing tying everything together to give you a feel of the timeline. Without reading through every diff in the history it is hard to see who said what, and peoples comments often get changed or deleted and lost unless you are in the habit of reading through every changelog for every wiki page you read. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070907/a06d041a/attachment-0001.pgp From kerdezixe at gmail.com Fri Sep 7 18:59:02 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Sep 7 18:59:05 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> Message-ID: <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> On 9/8/07, Tim Shephard wrote: > http://secondlife.reuters.com/stories/2007/09/06/rival-grids-threaten-lindens-monopoly-on-sl-technology/ > > For those who are looking for something to test their Clients against, > this might be the way to go. I don't like how this article is written, biased. The main problem about secondlife is scalability. In fact, SecondLife official servers and OpenSim have exactly the same problems. Linden Lab have some troubles with the huge central asset servers. I copy/paste opensim : "While there's no centralized inventory server, meaning that an avatar on DeepGrid can't take objects from one region into another, users can cross region boundaries seamlessly, experiencing no disruption as their client connects to servers on opposite sides of the world." Understand : "We don't have any problem with this features, because it's not implemented". If i remember correctly, the sim crossing problem appeared when the grid started to grow very quickly. "About 300 servers have installed Frisby's open source Second Life server code, called OpenSim." ""Second Life is a game of Russian Roulette with the login server." ... My fact : "DeepGrid is a game of Russian Roulette to find a running server". I'm not against OpenSim nor LindenLab servers, i like both, they are just not playing on the same playground... they are just ... not ... competitors. E.g : OpenSim could be very nice for intranet or small scale grid. If you read the reuter's article without I.T knowledge you just read : "OpenSim did better in 2 months than Linden Lab in many year". And i just can't accept that, it's just wrong. I worked as syadmin on heavy load clusters. Not the kind of HPC supercluster with very well defined workload, but the kind of cluster to handle angry mob with never-ending feature adding and fixing. And i don't blame LL for their problem, as i don't blame coders when they say "I assumed that the world's fastest hardware will be fast enough to handle this very simple data logging. So, yes, our 10 millions users cluster is down because of a race condition in this standard logging library"... See what i mean ? -- kerunix Flan From dale at daleglass.net Fri Sep 7 18:54:25 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 19:13:42 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <1189210216.2798.148.camel@localhost> References: <46E1C008.9010006@lindenlab.com> <46E1E0B0.402@wsu.edu> <1189210216.2798.148.camel@localhost> Message-ID: <200709080354.32546.dale@daleglass.net> On Saturday 08 September 2007 02:10:16 Callum Lerwick wrote: > I agree! > > On talk pages some people indent when replying and some people use line > breaks, some people sign their comments and some don't (or forget). > People might post something at the top of the page, the bottom, start a > new section in the middle, and there is nothing tying everything > together to give you a feel of the timeline. Without reading through > every diff in the history it is hard to see who said what, and peoples > comments often get changed or deleted and lost unless you are in the > habit of reading through every changelog for every wiki page you read. Agree too. I still don't get why use a wiki for discussions when it's about the most inconvenient way of having one there is online. But well, I already said all I wanted on that subject months ago on that talk page. I'm not opposed to moving discussion elsewhere per se, but seriously, why a wiki? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/e652027a/attachment.pgp From tshephard at gmail.com Fri Sep 7 19:22:20 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Sep 7 19:22:23 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> Message-ID: <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> Well, if OpenSim moves to a model where all inventory is open, like images on a web page, but not transferable (enforced by DMCA), then this whole concept of central inventory servers becomes irrelevant. Inventory can be free .. in order to get it, you need to visit Coke Island or IBMLand or whatever. People will write plugins for the client and server, but everything else, like images, will be basically free. And maybe we'll have some bytecode that will phone home to check if it is registered, but this concept of a centrally managed inventory server? I think it was an error in judgement.. On 9/7/07, Laurent Laborde wrote: > On 9/8/07, Tim Shephard wrote: > > http://secondlife.reuters.com/stories/2007/09/06/rival-grids-threaten-lindens-monopoly-on-sl-technology/ > > > > For those who are looking for something to test their Clients against, > > this might be the way to go. > > I don't like how this article is written, biased. > The main problem about secondlife is scalability. > > In fact, SecondLife official servers and OpenSim have exactly the same problems. > > Linden Lab have some troubles with the huge central asset servers. > I copy/paste opensim : "While there's no centralized inventory server, > meaning that an avatar on DeepGrid can't take objects from one region > into another, users can cross region boundaries seamlessly, > experiencing no disruption as their client connects to servers on > opposite sides of the world." > > Understand : "We don't have any problem with this features, because > it's not implemented". > > If i remember correctly, the sim crossing problem appeared when the > grid started to grow very quickly. > > "About 300 servers have installed Frisby's open source Second Life > server code, called OpenSim." ""Second Life is a game of Russian > Roulette with the login server." ... > My fact : "DeepGrid is a game of Russian Roulette to find a running server". > > I'm not against OpenSim nor LindenLab servers, i like both, they are > just not playing on the same playground... they are just ... not ... > competitors. E.g : OpenSim could be very nice for intranet or small > scale grid. > > If you read the reuter's article without I.T knowledge you just read : > "OpenSim did better in 2 months than Linden Lab in many year". And i > just can't accept that, it's just wrong. > > I worked as syadmin on heavy load clusters. Not the kind of HPC > supercluster with very well defined workload, but the kind of cluster > to handle angry mob with never-ending feature adding and fixing. > > And i don't blame LL for their problem, as i don't blame coders when > they say "I assumed that the world's fastest hardware will be fast > enough to handle this very simple data logging. So, yes, our 10 > millions users cluster is down because of a race condition in this > standard logging library"... See what i mean ? > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tshephard at gmail.com Fri Sep 7 19:30:30 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Sep 7 19:30:31 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <200709080354.32546.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <46E1E0B0.402@wsu.edu> <1189210216.2798.148.camel@localhost> <200709080354.32546.dale@daleglass.net> Message-ID: <3b19a500709071930p4d30f659ydc47ee786f347013@mail.gmail.com> Because it sucks, makes it hard to follow, and discourages further conversation that undermines the Authority of Linden Lab and let's the community organize. Ebay did the same thing with their message boards. Seriously people, why are we even having this conversation? On 9/7/07, Dale Glass wrote: > On Saturday 08 September 2007 02:10:16 Callum Lerwick wrote: > > I agree! > > > > On talk pages some people indent when replying and some people use line > > breaks, some people sign their comments and some don't (or forget). > > People might post something at the top of the page, the bottom, start a > > new section in the middle, and there is nothing tying everything > > together to give you a feel of the timeline. Without reading through > > every diff in the history it is hard to see who said what, and peoples > > comments often get changed or deleted and lost unless you are in the > > habit of reading through every changelog for every wiki page you read. > > Agree too. > > I still don't get why use a wiki for discussions when it's about the most > inconvenient way of having one there is online. But well, I already said > all I wanted on that subject months ago on that talk page. > > I'm not opposed to moving discussion elsewhere per se, but seriously, why a > wiki? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From labrat.hb at gmail.com Fri Sep 7 19:46:40 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Sep 7 19:46:44 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <3b19a500709071930p4d30f659ydc47ee786f347013@mail.gmail.com> References: <46E1C008.9010006@lindenlab.com> <46E1E0B0.402@wsu.edu> <1189210216.2798.148.camel@localhost> <200709080354.32546.dale@daleglass.net> <3b19a500709071930p4d30f659ydc47ee786f347013@mail.gmail.com> Message-ID: Well it's something I've been working on for a little while.. mostly just for the hell of it. But if people want to use it: http://www.mysldev.com/ There are still some issues and a few tests I need to work out... as well as getting a different theme..... but it's there if people wanna use it. On 9/7/07, Tim Shephard wrote: > > Because it sucks, makes it hard to follow, and discourages further > conversation that undermines the Authority of Linden Lab and let's the > community organize. > > Ebay did the same thing with their message boards. > > Seriously people, why are we even having this conversation? > > On 9/7/07, Dale Glass wrote: > > On Saturday 08 September 2007 02:10:16 Callum Lerwick wrote: > > > I agree! > > > > > > On talk pages some people indent when replying and some people use > line > > > breaks, some people sign their comments and some don't (or forget). > > > People might post something at the top of the page, the bottom, start > a > > > new section in the middle, and there is nothing tying everything > > > together to give you a feel of the timeline. Without reading through > > > every diff in the history it is hard to see who said what, and peoples > > > comments often get changed or deleted and lost unless you are in the > > > habit of reading through every changelog for every wiki page you read. > > > > Agree too. > > > > I still don't get why use a wiki for discussions when it's about the > most > > inconvenient way of having one there is online. But well, I already said > > all I wanted on that subject months ago on that talk page. > > > > I'm not opposed to moving discussion elsewhere per se, but seriously, > why a > > wiki? > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070907/a74a32f7/attachment.htm From hakushakukun at gmail.com Fri Sep 7 19:48:08 2007 From: hakushakukun at gmail.com (Adric R) Date: Fri Sep 7 19:48:11 2007 Subject: [sldev] Errors while building RC In-Reply-To: <46E1A6EB.2090002@blueflash.cc> References: <781e4b420709071213u6b59846bhc9f6e2aeed916ba2@mail.gmail.com> <46E1A6EB.2090002@blueflash.cc> Message-ID: <781e4b420709071948i402463a2wd8a8a37341c5858c@mail.gmail.com> That did it. Thanks a lot, Nick. On 9/7/07, Nicholaz Beresford wrote: > > > Hmm, check Newview, Properties, Linker, Input if you have llmozlib.lib and > ws2_32.lib there. > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Adric R wrote: > > I'm trying to build a ReleaseForDownload of 1.18.3 in VS2003 and I keep > > getting the same 73 errors. I've triple checked all the third party > > libraries are there, and I've followed all the instructions on the wiki, > > so I'm a bit at a loss. I've posted the error list at > > https://wiki.secondlife.com/wiki/User:McCabe_Maxsted . If you wouldn't > > mind having a look, any help would be appreciated. > > > > -- Adric (aka McCabe Maxsted) > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- "Work is love made visible." ? Kahlil Gibran "We will not walk in fear, one of another. We will not be driven by fear into an age of unreason if we dig deep in our history and doctrine and remember that we are not descended from fearful men, not from men who feared to write, to speak, to associate and to defend causes which were for the moment unpopular. We can deny our heritage and our history, but we cannot escape responsibility for the result. There is no way for a citizen of the Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070907/595d835a/attachment-0001.htm From dale at daleglass.net Fri Sep 7 19:55:57 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 19:56:07 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: References: <46E1C008.9010006@lindenlab.com> <3b19a500709071930p4d30f659ydc47ee786f347013@mail.gmail.com> Message-ID: <200709080456.02815.dale@daleglass.net> On Saturday 08 September 2007 04:46:40 Harold Brown wrote: > Well it's something I've been working on for a little while.. mostly > just for the hell of it. But if people want to use it: > http://www.mysldev.com/ > > There are still some issues and a few tests I need to work out... as > well as getting a different theme..... but it's there if people wanna > use it. > Interesting. I'd prefer a mailing list though. I think there are advantages over a forum for that, mainly that if the server goes down the messages aren't going to vanish from my mail server, server performance is less important, and that it makes it possible to crosspost here, which avoids splitting the community. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/659a2ed7/attachment.pgp From labrat.hb at gmail.com Fri Sep 7 20:03:51 2007 From: labrat.hb at gmail.com (Thraxis) Date: Fri Sep 7 20:03:54 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted Message-ID: <1189220631.m2f.3977@www.mysldev.com> Well... interesting enough... once I test everything.... I can turn forums into mailing lists. -------------------- m2f -------------------- Read this topic online here: http://www.mysldev.com/sldev/viewtopic.php?p=3977#3977 -------------------- m2f -------------------- From seg at haxxed.com Fri Sep 7 20:18:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 7 20:18:35 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <200709080456.02815.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <3b19a500709071930p4d30f659ydc47ee786f347013@mail.gmail.com> <200709080456.02815.dale@daleglass.net> Message-ID: <1189221500.2798.152.camel@localhost> On Sat, 2007-09-08 at 04:55 +0200, Dale Glass wrote: > On Saturday 08 September 2007 04:46:40 Harold Brown wrote: > > Well it's something I've been working on for a little while.. mostly > > just for the hell of it. But if people want to use it: > > http://www.mysldev.com/ > > > > There are still some issues and a few tests I need to work out... as > > well as getting a different theme..... but it's there if people wanna > > use it. > > > > Interesting. > > I'd prefer a mailing list though. I think there are advantages over a forum > for that, mainly that if the server goes down the messages aren't going to > vanish from my mail server, server performance is less important, and that > it makes it possible to crosspost here, which avoids splitting the > community. My opinion still stands: https://lists.secondlife.com/pipermail/sldev/2007-April/001431.html But hey, if you can seamlessly gateway it so that people who like that crap can have it if they want it, then more power to you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070907/2b9ab287/attachment.pgp From dale at daleglass.net Fri Sep 7 20:22:09 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 20:22:24 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <200709080456.02815.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <200709080456.02815.dale@daleglass.net> Message-ID: <200709080522.19215.dale@daleglass.net> On Saturday 08 September 2007 04:55:57 Dale Glass wrote: > Interesting. > > I'd prefer a mailing list though. I think there are advantages over a > forum for that, mainly that if the server goes down the messages aren't > going to vanish from my mail server, server performance is less > important, and that it makes it possible to crosspost here, which avoids > splitting the community. Actually I just found my webhost has nice mailing list features, so I thought I'd give it a try and made some. Here: http://lists.daleglass.net/listinfo.cgi/sldev-announce-daleglass.net http://lists.daleglass.net/listinfo.cgi/sldev-misc-daleglass.net sldev-misc is intended to be for any misc discussion that's not completely offtopic. sldev-announce is for announcements of new versions of whatever you're working on. This shouldn't conflict with this list. I don't intend to try to move the main discussion there, just the things that aren't welcome here. This is currently an experiment, and I'm still setting things up, so tell me if anything isn't working the way it should. And I accept suggestions for more lists or anything related to them, of course. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/5a6c52b6/attachment.pgp From labrat.hb at gmail.com Fri Sep 7 20:34:59 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Sep 7 20:35:03 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <200709080522.19215.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <200709080456.02815.dale@daleglass.net> <200709080522.19215.dale@daleglass.net> Message-ID: OK... forget I posted anything... The whole reason I had started that project was because it did allow a bridge between the mailing list and a forum... and it allowed for a single point of communication... And now we've got 2 more mailing lists... Is Nicholas going to start some? Or anyone else? We need centralized communication... not 500 mailing lists, wiki's, blogs, forums, etc to follow. On 9/7/07, Dale Glass wrote: > > On Saturday 08 September 2007 04:55:57 Dale Glass wrote: > > Interesting. > > > > I'd prefer a mailing list though. I think there are advantages over a > > forum for that, mainly that if the server goes down the messages aren't > > going to vanish from my mail server, server performance is less > > important, and that it makes it possible to crosspost here, which avoids > > splitting the community. > > Actually I just found my webhost has nice mailing list features, so I > thought I'd give it a try and made some. > > Here: > > http://lists.daleglass.net/listinfo.cgi/sldev-announce-daleglass.net > http://lists.daleglass.net/listinfo.cgi/sldev-misc-daleglass.net > > sldev-misc is intended to be for any misc discussion that's not completely > offtopic. > > sldev-announce is for announcements of new versions of whatever you're > working on. > > This shouldn't conflict with this list. I don't intend to try to move the > main discussion there, just the things that aren't welcome here. > > This is currently an experiment, and I'm still setting things up, so tell > me if anything isn't working the way it should. And I accept suggestions > for more lists or anything related to them, of course. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070907/73303c45/attachment.htm From kerdezixe at gmail.com Fri Sep 7 20:36:26 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Sep 7 20:36:29 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> Message-ID: <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> On 9/8/07, Tim Shephard wrote: > but this > concept of a centrally managed inventory server? I think it was an > error in judgement.. So where do you store the inventory if not on a specialized asset server (which is a cluster anyway) ? On sim server ? aren't they already overloaded ? And how do you decide and manage where is stored every single prims, script, texture of your inventory, on a ... central server ? What's happening when a sim go down/restart (which is probably happening every single minute) ? how do you balance the load ? And ... just... where do you simply *store* the inventory data anyway, physically ? On the sim where the said prims has been created ? i can't imagine the insane load on Sandbox sim. Will you need to have raid 5 array on every sim server to prevent the awefull content loss ? (yes, hardware failure DOES happen and it's also archiotect and coder's job to handle this case (as well as sysadmin job, of course)). I don't understand what you mean, sorry. Could you explain please ? -- kerunix Flan From dale at daleglass.net Fri Sep 7 20:55:13 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 20:55:48 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: References: <46E1C008.9010006@lindenlab.com> <200709080522.19215.dale@daleglass.net> Message-ID: <200709080555.43475.dale@daleglass.net> On Saturday 08 September 2007 05:34:59 Harold Brown wrote: > OK... forget I posted anything... > > The whole reason I had started that project was because it did allow a > bridge between the mailing list and a forum... and it allowed for a > single point of communication... Well, it's simply a personal preference of mine, no offence intended if you took any. Feel free to use that gateway on my lists of course (assuming somebody subscribes, don't hurry with that just yet) > And now we've got 2 more mailing lists... > > Is Nicholas going to start some? Or anyone else? We need centralized > communication... not 500 mailing lists, wiki's, blogs, forums, etc to > follow. Fair enough. I'm doing it currently as an experiment. I suggested lists myself, so I thought I could as well go and do that instead of sitting here grumbling here about my dislike of the wiki for discussions. Personally I want mailing lists, but they don't have to be mine. I'll move to another list if somebody comes up with a more popular one, and support consolidation efforts. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/c9db995b/attachment.pgp From dale at daleglass.net Fri Sep 7 21:11:19 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 7 21:11:30 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> Message-ID: <200709080611.25404.dale@daleglass.net> On Saturday 08 September 2007 04:22:20 Tim Shephard wrote: > Well, if OpenSim moves to a model where all inventory is open, like > images on a web page, but not transferable (enforced by DMCA), then > this whole concept of central inventory servers becomes irrelevant. Heh. Enforced by DMCA. What about countries without it, and how would the DMCA apply anyway in a system with no effective protection? I doubt very much it applies to something like downloading a picture from a website. > Inventory can be free .. in order to get it, you need to visit Coke > Island or IBMLand or > whatever. Hm? Don't we have this already? Lots of free stuff in SL > People will write plugins for the client and server, but everything > else, like images, will be basically free. And maybe we'll have some > bytecode that will phone home to check if it is registered, Heh, and how are you going to enforce that? > but this > concept of a centrally managed inventory server? I think it was an > error in judgement.. Well, how are you going to do it otherwise? An alternative seems to simply copy everything about an object to the new region. When you cross a region in a car, all its prims, textures, scripts, sounds, etc get uploaded to the new sim. That sounds like some major border crossing problems to me. It also makes a lot of caching impossible as with no central server there's no universal ID for an object (probably fixable by using content based hashes) Inventory becomes complicated, if there's no central server, where is it? On the user's computer? And what if they log in from another box, or lose their local copy? Then add lots and lots of possibilities for griefing to this system. Sims which change every texture on you to something disgusting, except to yourself. Sims that corrupt data slightly as it passes through them. Sims that monitor chat on all channels and actions of all scripts. Now don't get me wrong, this is very cool, but by removing a central server you'll remove one set of problems, but also put a lot of new annoying ones in their place. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/ced30929/attachment-0001.pgp From tshephard at gmail.com Fri Sep 7 21:58:04 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Sep 7 21:58:06 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <200709080611.25404.dale@daleglass.net> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <200709080611.25404.dale@daleglass.net> Message-ID: <3b19a500709072158q548fdbf2tcf873bcaa2974e52@mail.gmail.com> ok, you're right, Linden Lab is going to have a billion gazillion pentabyte harddrives to manage the entire world's inventory. That scales so well - I mean really, it's worked out great so far. On 9/7/07, Dale Glass wrote: > On Saturday 08 September 2007 04:22:20 Tim Shephard wrote: > > Well, if OpenSim moves to a model where all inventory is open, like > > images on a web page, but not transferable (enforced by DMCA), then > > this whole concept of central inventory servers becomes irrelevant. > Heh. Enforced by DMCA. What about countries without it, and how would the > DMCA apply anyway in a system with no effective protection? I doubt very > much it applies to something like downloading a picture from a website. > > > Inventory can be free .. in order to get it, you need to visit Coke > > Island or IBMLand or > > whatever. > Hm? Don't we have this already? Lots of free stuff in SL > > > > People will write plugins for the client and server, but everything > > else, like images, will be basically free. And maybe we'll have some > > bytecode that will phone home to check if it is registered, > Heh, and how are you going to enforce that? > > > > but this > > concept of a centrally managed inventory server? I think it was an > > error in judgement.. > Well, how are you going to do it otherwise? > > An alternative seems to simply copy everything about an object to the new > region. When you cross a region in a car, all its prims, textures, > scripts, sounds, etc get uploaded to the new sim. That sounds like some > major border crossing problems to me. > > It also makes a lot of caching impossible as with no central server there's > no universal ID for an object (probably fixable by using content based > hashes) > > Inventory becomes complicated, if there's no central server, where is it? > On the user's computer? And what if they log in from another box, or lose > their local copy? > > Then add lots and lots of possibilities for griefing to this system. Sims > which change every texture on you to something disgusting, except to > yourself. Sims that corrupt data slightly as it passes through them. Sims > that monitor chat on all channels and actions of all scripts. > > > Now don't get me wrong, this is very cool, but by removing a central server > you'll remove one set of problems, but also put a lot of new annoying ones > in their place. > > From tshephard at gmail.com Fri Sep 7 21:59:45 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Sep 7 21:59:47 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <3b19a500709072158q548fdbf2tcf873bcaa2974e52@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <200709080611.25404.dale@daleglass.net> <3b19a500709072158q548fdbf2tcf873bcaa2974e52@mail.gmail.com> Message-ID: <3b19a500709072159s36798bd3m2aa862fab3505ee9@mail.gmail.com> btw, that was just me doing reductio ad absurdum. if an assumption leads to an obvious fallacy, that assumption can be proved false. I wasn't trying to be a cheeky monkey :) On 9/7/07, Tim Shephard wrote: > ok, you're right, Linden Lab is going to have a billion gazillion > pentabyte harddrives to manage the entire world's inventory. That > scales so well - I mean really, it's worked out great so far. > > On 9/7/07, Dale Glass wrote: > > On Saturday 08 September 2007 04:22:20 Tim Shephard wrote: > > > Well, if OpenSim moves to a model where all inventory is open, like > > > images on a web page, but not transferable (enforced by DMCA), then > > > this whole concept of central inventory servers becomes irrelevant. > > Heh. Enforced by DMCA. What about countries without it, and how would the > > DMCA apply anyway in a system with no effective protection? I doubt very > > much it applies to something like downloading a picture from a website. > > > > > Inventory can be free .. in order to get it, you need to visit Coke > > > Island or IBMLand or > > > whatever. > > Hm? Don't we have this already? Lots of free stuff in SL > > > > > > > People will write plugins for the client and server, but everything > > > else, like images, will be basically free. And maybe we'll have some > > > bytecode that will phone home to check if it is registered, > > Heh, and how are you going to enforce that? > > > > > > > but this > > > concept of a centrally managed inventory server? I think it was an > > > error in judgement.. > > Well, how are you going to do it otherwise? > > > > An alternative seems to simply copy everything about an object to the new > > region. When you cross a region in a car, all its prims, textures, > > scripts, sounds, etc get uploaded to the new sim. That sounds like some > > major border crossing problems to me. > > > > It also makes a lot of caching impossible as with no central server there's > > no universal ID for an object (probably fixable by using content based > > hashes) > > > > Inventory becomes complicated, if there's no central server, where is it? > > On the user's computer? And what if they log in from another box, or lose > > their local copy? > > > > Then add lots and lots of possibilities for griefing to this system. Sims > > which change every texture on you to something disgusting, except to > > yourself. Sims that corrupt data slightly as it passes through them. Sims > > that monitor chat on all channels and actions of all scripts. > > > > > > Now don't get me wrong, this is very cool, but by removing a central server > > you'll remove one set of problems, but also put a lot of new annoying ones > > in their place. > > > > > From seg at haxxed.com Fri Sep 7 22:00:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 7 22:01:02 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> Message-ID: <1189227653.2798.228.camel@localhost> On Sat, 2007-09-08 at 03:59 +0200, Laurent Laborde wrote: > If you read the reuter's article without I.T knowledge you just read : > "OpenSim did better in 2 months than Linden Lab in many year". And i > just can't accept that, it's just wrong. Yes, the article is typical shallow sensationalist journalism that freely insinuates whatever happens to be... sensational. But this does provide an excuse to say something I was going to say at this week's meeting, but I *ahem* cut myself off realizing I was getting rather off the topic of the bug we were supposed to be discussing: (As my email address shows, I'm Seg btw) https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-09-06 One of the major things preventing a full-blown fork of Second Life is our dependence on the Linden grid. Once a viable alternative comes about, either through a ground up re-engineering, or LL releasing its source, (it appears both are on the way) that reason will be gone. With the way Rob (I don't want to pick solely on him but he's the one I see most) seems to want to "manage" the community, sometimes I think the grid dependence is the only thing stopping a fork from happening already. And the messages turning up even as I sit here writing this are only confirming it. https://lists.secondlife.com/pipermail/sldev/2007-September/004492.html https://lists.secondlife.com/pipermail/sldev/2007-September/004498.html I'd rather a fork didn't happen, and I think I just realized why. Red Hat has already managed to take a formerly closed commercial development project (Red Hat Linux) and spin it off into an (IMHO) successful community project (Fedora). Though the reality is, the initial spinoff was a complete disaster, (See the infamous EAT YOUR BRAAAANE post: http://lwn.net/Articles/83360/) and it was only turned around through years of determined work by key individuals within Red Hat, and full community involvement only achieved with the release of Fedora 7. I'd hate to see Linden Labs blunder on, not learn from Red Hat's mistakes and quite possibly get itself killed in the process. But I'm really not seeing any Warren Togamis or Max Spevacks within Linden Lab. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/b29f7919/attachment.pgp From seg at haxxed.com Fri Sep 7 22:13:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 7 22:14:01 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <200709080611.25404.dale@daleglass.net> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <200709080611.25404.dale@daleglass.net> Message-ID: <1189228438.2798.235.camel@localhost> On Sat, 2007-09-08 at 06:11 +0200, Dale Glass wrote: > It also makes a lot of caching impossible as with no central server there's > no universal ID for an object (probably fixable by using content based > hashes) A content hash, of course. > Inventory becomes complicated, if there's no central server, where is it? > On the user's computer? And what if they log in from another box, or lose > their local copy? P2P-ish technology. Its nothing but a big distributed cache anyway. It will become as basic an internet service as DNS is. All ISPs will run a "seed" farm for its customers. Or at least contract it out to some really big seed farms. :) > Then add lots and lots of possibilities for griefing to this system. Sims > which change every texture on you to something disgusting, except to > yourself. Sims that corrupt data slightly as it passes through them. Sims > that monitor chat on all channels and actions of all scripts. > > > Now don't get me wrong, this is very cool, but by removing a central server > you'll remove one set of problems, but also put a lot of new annoying ones > in their place. Identify all avatars by a PGP key. Build a trust web with your friends. All assets referenced or belonging to an avatar get signed with that avatar's key. Combined with the referencing based on content hash, ta da, can't slip anything in without detection. All the pieces are there, you just have to put them together. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/a6faf9b1/attachment.pgp From kerdezixe at gmail.com Fri Sep 7 22:25:40 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Sep 7 22:25:43 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <1189228438.2798.235.camel@localhost> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <200709080611.25404.dale@daleglass.net> <1189228438.2798.235.camel@localhost> Message-ID: <8a1bfe660709072225l19e72b44n1133f901c0fda254@mail.gmail.com> On 9/8/07, Callum Lerwick wrote: > On Sat, 2007-09-08 at 06:11 +0200, Dale Glass wrote: > > It also makes a lot of caching impossible as with no central server there's > > no universal ID for an object (probably fixable by using content based > > hashes) > > A content hash, of course. > > > Inventory becomes complicated, if there's no central server, where is it? > > On the user's computer? And what if they log in from another box, or lose > > their local copy? > > P2P-ish technology. Its nothing but a big distributed cache anyway. It > will become as basic an internet service as DNS is. All ISPs will run a > "seed" farm for its customers. Or at least contract it out to some > really big seed farms. :) As far as i know, Linden Lab is already using a distributed farm of squid proxy cache. (squid was designed to be distributed). They could be on sim server if they sim load wasn't so high. You also have a local cache. And P2P, like bittorent, do have some kind of central server too. Bittorent is less centralized, and much more pain to find content. It's not reliable like LL asset server, and our inventory certainly need reliability. What i want, really, is the abbility to setup a squid server at home to cache all the content. I certainly know how to setup a squid server at home, i have the hardware, i just don't know how to setup everything to make it work like a SL content cache. And it's a must have for a company too... or even... an ISP ? (like the good old internet with ISP running farms of proxy to save bandwidth). I'm sure it will happen. the question is "why isn't it happening already ?" -- Ker2x From alissa_sabre at yahoo.co.jp Sat Sep 8 00:16:16 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 8 00:16:25 2007 Subject: [sldev] Translation of wiki contents In-Reply-To: <46D46AB9.2010602@lindenlab.com> References: <46D46AB9.2010602@lindenlab.com> Message-ID: <83ds4s0vs0m7GwwuJ4kJkb8c.alissa_sabre@yahoo.co.jp> > >> Guidelines [for editing translated pages] are here: > >> https://wiki.secondlife.com/wiki/Project_talk:I18n > > The basic idea regarding translated wiki pages generally seems fine. > > It is essentially the same way as mediawiki.org site. > > Should we follow the instruction there? > 1. Try to establish consistent, sensible guidelines > 2. Make a good faith effort to work together with others, then do what > makes sense to you > 3. When possible, use existing best practices rather than being too clever > 4. If the guidelines/project seems abandoned, claim it as your own, and > be bold I first tried to add something to the original page Rob pointed out. However, after some thinking, I found that the pages Project:I18N and its discussion page are not intended to cover the "I18N issues regarding the project (i.e., SL wiki)", but the are for "A group activity called "I18N Project"... I guess the author of this page didn't know the purpose of the project name space feature of MediaWiki... As a result, I wrote a separate page for the guidelines on SL wiki content translation. It is on: http://wiki.secondlife.com/wiki/Project:Languages I tried to follow (few) existing practices on SL wiki. The guideline I wrote is a some _loose_ version of the one used in MediaWiki web site. Comments are welcome (on its associated discussion page.) I've not yet started the actual translation work, because I was busy thinking on this guidelines... *sigh* Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From nicholaz at blueflash.cc Sat Sep 8 01:37:10 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 01:37:24 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> Message-ID: <46E25F36.5070303@blueflash.cc> Laurent Laborde wrote: > So where do you store the inventory if not on a specialized asset > server (which is a cluster anyway) ? > > On sim server ? aren't they already overloaded ? On the client. I'm amazed that for an Open Source project like OpenSim everybody still thinks the assets need protection. If it were me, I'd start that thing with client side full perm inventory. The only things that need to reside on the server are prims which are located there or which are attached to an avatar and the latter only temporary, as long as the avatar is there. Nick From nicholaz at blueflash.cc Sat Sep 8 01:41:14 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 01:41:27 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <200709080522.19215.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <200709080456.02815.dale@daleglass.net> <200709080522.19215.dale@daleglass.net> Message-ID: <46E2602A.5080002@blueflash.cc> Dale Glass wrote: > On Saturday 08 September 2007 04:55:57 Dale Glass wrote: > Interesting. > > I'd prefer a mailing list though. I think there are advantages over a > forum for that, mainly that if the server goes down the messages aren't > going to vanish from my mail server, server performance is less > important, and that it makes it possible to crosspost here, which avoids > splitting the community. Well, just for the record, my preference in format based on my communiation habits is clearly Forums. Nick From nicholaz at blueflash.cc Sat Sep 8 01:58:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 01:58:37 2007 Subject: [sldev] Errors while building RC In-Reply-To: <781e4b420709071948i402463a2wd8a8a37341c5858c@mail.gmail.com> References: <781e4b420709071213u6b59846bhc9f6e2aeed916ba2@mail.gmail.com> <46E1A6EB.2090002@blueflash.cc> <781e4b420709071948i402463a2wd8a8a37341c5858c@mail.gmail.com> Message-ID: <46E2642F.2040606@blueflash.cc> Adric R wrote: > That did it. Thanks a lot, Nick. Yw :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kerdezixe at gmail.com Sat Sep 8 02:31:58 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Sep 8 02:32:01 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <46E25F36.5070303@blueflash.cc> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> <46E25F36.5070303@blueflash.cc> Message-ID: <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> On 9/8/07, Nicholaz Beresford wrote: > > Laurent Laborde wrote: > > So where do you store the inventory if not on a specialized asset > > server (which is a cluster anyway) ? > > > > On sim server ? aren't they already overloaded ? > > On the client. I'm amazed that for an Open Source project like > OpenSim everybody still thinks the assets need protection. If it > were me, I'd start that thing with client side full perm inventory. And when you logout ? And even if i don't logout... how do i stream content of my 20 sims with my 128/2048 ADSL line to 150 concurent user ? Content have to be stored somewhere else than the client. On sim (with the problems said earlier) or on dedicated asset servers. -- kerunix Flan From jhurliman at wsu.edu Sat Sep 8 03:18:20 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 03:18:23 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> <46E25F36.5070303@blueflash.cc> <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> Message-ID: <46E276EC.1030705@wsu.edu> Laurent Laborde wrote: > On 9/8/07, Nicholaz Beresford wrote: > >> Laurent Laborde wrote: >> >>> So where do you store the inventory if not on a specialized asset >>> server (which is a cluster anyway) ? >>> >>> On sim server ? aren't they already overloaded ? >>> >> On the client. I'm amazed that for an Open Source project like >> OpenSim everybody still thinks the assets need protection. If it >> were me, I'd start that thing with client side full perm inventory. >> > > And when you logout ? > When you log out then there is no need for your inventory to be connected to the grid any more, since the only person who has access to your inventory is yourself. Things like offline inventory offers would probably go away though, unless one of the sims temporarily stored the assets that are supposed to be transferred and got ahold of you the next time you logged in to that sim. That has some messy edge cases though. > And even if i don't logout... how do i stream content of my 20 sims > with my 128/2048 ADSL line to 150 concurent user ? > Prims that are in a simulator (ie, have LocalIDs) are not the same as prims on the asset server which is not the same as items in your inventory that link to prims on the asset server. No one is suggesting that you host 20 simulators on your ADSL line, or constantly stream large amounts of data from your local inventory to multiple people. > Content have to be stored somewhere else than the client. > On sim (with the problems said earlier) or on dedicated asset servers. > > Not true at all, there are many different ways you could implement a distributed grid architecture that involved storing inventory on the client. To achieve most of them would require throwing out the idea of protected assets and the notion of selling prims to other avatars, so it might not be a path that Linden Labs is interested in pursuing but they are still workable ideas for an open grid. I have some more specific thoughts on how better decentralization and scalability could be achieved but I'll save them for next Thursday. John Hurliman From secret.argent at gmail.com Sat Sep 8 03:19:28 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 8 04:19:39 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <20070908024814.A5C0D41B120@stupor.lindenlab.com> References: <20070908024814.A5C0D41B120@stupor.lindenlab.com> Message-ID: <31FA26B2-01D0-4A99-B4A4-B0CDE5DF99BC@gmail.com> From: "Tim Shephard" > Well, if OpenSim moves to a model where all inventory is open, like > images on a web page, but not transferable (enforced by DMCA), then > this whole concept of central inventory servers becomes irrelevant. They don't even have the ability to keep inventory across sims on the same server! Not to mention that inventory includes your whole avatar. Without permanent inventory, every time you log on you're Ruth again, and your inventory is *at most* whatever someone using the same account name happened to have the last time they were in that sim. If someone sets up a grid (and if they're IBM or Coke they'll have to) they'll need an inventory server for that grid. Whether your inventory is stored on your computer by your client, or a central inventory server, or CAP links back to the sim you acquired the content in, you have to be able to retain inventory across sims within a given grid. Otherwise this isn't like the web, it's like the bulletin board systems of the '70s and '80s. The ability to see the same content from anywhere no matter where you started is what MAKES the web the web instead of a bunch of disconnected servers. And it's what makes the grid the grid. A grid without inventory, no matter who's running it, isn't a grid at all. It's like a thin client when the network's down. They'll get an inventory mechanism of some kind working. They'll have to. From secret.argent at gmail.com Sat Sep 8 03:23:11 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 8 04:23:19 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <20070908041133.98E7B41B1F7@stupor.lindenlab.com> References: <20070908041133.98E7B41B1F7@stupor.lindenlab.com> Message-ID: So now we have a wiki, and mailing lists, and BBS/Forum servers. You know, this kind of fragmentation is why Usenet (and, later, Fidonet) were developed in the first place. I wonder how long it'll be before this technology gets re-reinvented. From nicholaz at blueflash.cc Sat Sep 8 04:30:10 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 04:30:26 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <46E276EC.1030705@wsu.edu> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> <46E25F36.5070303@blueflash.cc> <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> <46E276EC.1030705@wsu.edu> Message-ID: <46E287C2.3060403@blueflash.cc> John Hurliman wrote: > To achieve most of them would require throwing out the idea of > protected assets and the notion of selling prims to other avatars. That's what I think. The idea of protecting assets is a really interesting one when it meets the field of open source. It's so deeply ingrained into SL (well, code is law) that people don't even question it anymore. But when writing Open Source and spending hours and weeks on code that itself is GPL, MIT and whatnot, it sounds a bit odd to me when in designing the content storage, the one of the major design goals (or obstacles) is to allow people to make what they build inside that project "closed source". To me that's like creating an open image or sound or media format and basing major design decisions on the question if it will lend itself to DRM. Nick From kerdezixe at gmail.com Sat Sep 8 04:39:58 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Sep 8 04:40:02 2007 Subject: [sldev] Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <46E287C2.3060403@blueflash.cc> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> <46E25F36.5070303@blueflash.cc> <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> <46E276EC.1030705@wsu.edu> <46E287C2.3060403@blueflash.cc> Message-ID: <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> On 9/8/07, Nicholaz Beresford wrote: > > But when writing Open Source and spending hours and weeks on code > that itself is GPL, MIT and whatnot, it sounds a bit odd to me > when in designing the content storage, the one of the major design > goals (or obstacles) is to allow people to make what they build > inside that project "closed source". That's just right managment... like a good old filesystem, protected memory, privilegied network port (<1024), ... I don't see anything wrong here. -- Keeunix Flan From secret.argent at gmail.com Sat Sep 8 03:40:07 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 8 04:40:17 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <20070908083723.DF93541B211@stupor.lindenlab.com> References: <20070908083723.DF93541B211@stupor.lindenlab.com> Message-ID: From: "Tim Shephard" > ok, you're right, Linden Lab is going to have a billion gazillion > pentabyte harddrives to manage the entire world's inventory. That > scales so well - I mean really, it's worked out great so far. It works for google. :) In any case, regardless of whether you've got Linden Labs inventory on Fred's Grid, Fred's going to need inventory to remain saved from one sim to the next on *his* grid. The lack of an inventory server in OpenSIM *will* have to be addressed. I agree with Nicolasz that client-side inventory support will be part of it, but they will also need grid-side inventory as well. Not because of copyright, but because of efficiency and mobility. You don't want to have to build your inventory from scratch when you visit FredGrid from soneone else's computer, or have the dozen textures in each of the 300 prims in your Chameleon Grand Dragon avatar re-uploaded every time you log in to the DragonHome grid. From alissa_sabre at yahoo.co.jp Sat Sep 8 05:10:25 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 8 05:10:38 2007 Subject: [sldev] Limiting the length of string inconsistently Message-ID: <7buJ7ds4dY7s8vdsbs04Gc8x.alissa_sabre@yahoo.co.jp> I filed a new JIRA issue, VWR-2367. It is on the maximum message length of a Group Notice. The point is, that, when editing the notice, the maximum length of the message is limited by the number of _characters_. When the notice is sent, the lower messaging layer checks the maximum length by the number of _bytes_. When editing, the maximum length is 511 characters. The lower layer limits the maximum by 1200 bytes (including some overheads). Since, one Japanese character occupy three bytes in UTF-8, Japanese Group Notice messages with more than about 400 characters are truncated when sent. I can imagine three approaches to fix it. Which fix is best? I want to know your opinions. (a) Extend the messaging maximum to cover the worst case maximum. Because, a character can occupy four bytes in UTF-8 as a maximum, 511 characters can be up to 2044 bytes. Enlarge the lower layer limit to this value (plus some overhead.) (b) Reduce the UI (editing) limit to the value that is guaranteed to pass the lower layer limit in worst case. That is 1200 (minus some overhead) divided by four, i.e., around 250. (c) Add a feature to a UI component (LLTextEditor) to limit the maximum size in bytes as opposed to in characters, and set that limit to a value around 1000. If the way we should go is (b) or (c) above, I can write a fix. However, if the correct fix is (a), I don't think it's doable by open source developers, since I guess the server-side code should be updated in sync. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Sat Sep 8 04:20:53 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 8 05:21:10 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <20070908114020.1367D41B24B@stupor.lindenlab.com> References: <20070908114020.1367D41B24B@stupor.lindenlab.com> Message-ID: <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> Let's use tags, fellas? John Hurliman: > When you log out then there is no need for your inventory to be > connected to the grid any more, since the only person who has > access to > your inventory is yourself. Unless you leave a script behind that contains some code like: llSetTexture(llList2String(texture_uuids, i++)); Now clearly this could be changed to: llSetTexture(llList2String(texture_urls, i++)); Or something, but the point is that there's a need to get hold of data that is neither in the sim nor in your client. > Not true at all, there are many different ways you could implement a > distributed grid architecture that involved storing inventory on the > client. Well, "... storing inventory in a distributed manner...". It has to be stored *somewhere*, and it needs to be stored somewhere that doesn't depend on some random laptop (that you haven't yet realized is sitting at the bottom of your swimming pool, because your wifi is down as well) being online. From adam at gwala.net Sat Sep 8 06:31:19 2007 From: adam at gwala.net (Adam Frisby) Date: Sat Sep 8 06:33:19 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <31FA26B2-01D0-4A99-B4A4-B0CDE5DF99BC@gmail.com> References: <20070908024814.A5C0D41B120@stupor.lindenlab.com> <31FA26B2-01D0-4A99-B4A4-B0CDE5DF99BC@gmail.com> Message-ID: <46E2A427.7070402@gwala.net> Heh - first half of that article is a tad sensationalist - opensim wont be competing with LL for a _long_ while (the two months came from a unrelated question about using OpenSim for teaching) - grid design isnt really on any of the opensim dev's radar - it's an insanely complex topic that leads only to madness. Adam Argent Stonecutter wrote: > From: "Tim Shephard" > >> Well, if OpenSim moves to a model where all inventory is open, like >> images on a web page, but not transferable (enforced by DMCA), then >> this whole concept of central inventory servers becomes irrelevant. > > > They don't even have the ability to keep inventory across sims on the > same server! > > Not to mention that inventory includes your whole avatar. Without > permanent inventory, every time you log on you're Ruth again, and your > inventory is *at most* whatever someone using the same account name > happened to have the last time they were in that sim. If someone sets > up a grid (and if they're IBM or Coke they'll have to) they'll need an > inventory server for that grid. > > Whether your inventory is stored on your computer by your client, or a > central inventory server, or CAP links back to the sim you acquired the > content in, you have to be able to retain inventory across sims within > a given grid. Otherwise this isn't like the web, it's like the bulletin > board systems of the '70s and '80s. The ability to see the same content > from anywhere no matter where you started is what MAKES the web the web > instead of a bunch of disconnected servers. > > And it's what makes the grid the grid. > > A grid without inventory, no matter who's running it, isn't a grid at > all. It's like a thin client when the network's down. > > They'll get an inventory mechanism of some kind working. They'll have to. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From formica at messinalug.org Sat Sep 8 06:39:03 2007 From: formica at messinalug.org (Roberto Marino) Date: Sat Sep 8 06:39:14 2007 Subject: [sldev] Plugins Architecture Message-ID: This is my first "post" on this ML. This is the question: Is there, to this day, a working plugins architecture on SL viewer? Cheers R. -- Roberto (aka formica) Marino Computer Engineering Student Free Software User - Me|Lug Member --> formica@messinalug.org <-- http://www.messinalug.org -- GnuPG key ID: 641AE37D -- Per favore non mandatemi allegati in Word o PowerPoint. Si veda http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070908/214efe3b/attachment.htm From dale at daleglass.net Sat Sep 8 07:18:34 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 8 07:18:59 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <1189227653.2798.228.camel@localhost> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <1189227653.2798.228.camel@localhost> Message-ID: <200709081618.53279.dale@daleglass.net> On Saturday 08 September 2007 07:00:53 Callum Lerwick wrote: > And the messages turning up even as I sit here writing this are only > confirming it. > > https://lists.secondlife.com/pipermail/sldev/2007-September/004492.html > https://lists.secondlife.com/pipermail/sldev/2007-September/004498.html > > I'd rather a fork didn't happen, and I think I just realized why. > [snip] Just to make things clear: I'm not trying to start a fork. I'm just trying to provide a place for things LL doesn't want here. So I made a list for misc discussion that wouldn't be welcome here. Say, if you want to debate licensing feel free to do it there. And sldev-announce came from people's wish to see people post updates on new versions of their stuff. I currently have no intention of creating a second sldev list to replace this one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/82073467/attachment.pgp From dale at daleglass.net Sat Sep 8 07:23:21 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 8 07:23:38 2007 Subject: [sldev] Re: [POLICY] New mailing list keywords posted In-Reply-To: <46E2602A.5080002@blueflash.cc> References: <46E1C008.9010006@lindenlab.com> <200709080522.19215.dale@daleglass.net> <46E2602A.5080002@blueflash.cc> Message-ID: <200709081623.27295.dale@daleglass.net> On Saturday 08 September 2007 10:41:14 Nicholaz Beresford wrote: > Well, just for the record, my preference in format based on my > communiation habits is clearly Forums. So what do you think about using both with a gateway? I never used that setup, so I don't know how well it works in practice. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/2f3f05ae/attachment.pgp From dale at daleglass.net Sat Sep 8 07:38:57 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 8 07:39:08 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <1189228438.2798.235.camel@localhost> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <200709080611.25404.dale@daleglass.net> <1189228438.2798.235.camel@localhost> Message-ID: <200709081639.02519.dale@daleglass.net> On Saturday 08 September 2007 07:13:58 Callum Lerwick wrote: > On Sat, 2007-09-08 at 06:11 +0200, Dale Glass wrote: > > It also makes a lot of caching impossible as with no central server > > there's no universal ID for an object (probably fixable by using > > content based hashes) > > A content hash, of course. Ok, but do you want to preserve ownership on your grid? Say, who is the owner or the creator of a texture or object on this grid? If it goes by content hash there can't be two separate copies by different people. Take a box for instance. The second box rezzed will have the same hash as the first one. Does that give them the same LLUUID? If not, where does that LLUUID come from? > P2P-ish technology. Its nothing but a big distributed cache anyway. It > will become as basic an internet service as DNS is. All ISPs will run a > "seed" farm for its customers. Or at least contract it out to some > really big seed farms. :) P2P from where to where? Example situations: Situation A: I login in sim A, obtain a house and save it to my inventory. I cross to sim B, don't stop there and don't do anything, and cross to C. I try to rez the house in sim C. How does it get rezzed? Situation B: I login in sim A, obtain a house and save it to my inventory. I logout, log back in to some completely different part of the grid, 6 months later. I try to rez the house. How does it get rezzed? Does it get rezzed at all? Easiest way to do it seems to have the user keep the inventory and transmit it to the sim on rez, but that means that you lose your inventory if anything happens to your computer. If on the other hand, inventory is held by the sim that gave it to you, then that means it's lost if that sim is removed. Also there either needs to be a central DB to figure out which sim has the data, or you have the same problem as above. > Identify all avatars by a PGP key. Build a trust web with your friends. > All assets referenced or belonging to an avatar get signed with that > avatar's key. Combined with the referencing based on content hash, ta > da, can't slip anything in without detection. > > All the pieces are there, you just have to put them together. :) While I really like PGP that doesn't sound like a very friendly system :-) TrustNet is hard enough to explain already. I have to agree with Laurent here. This could be very cool, but it won't be a competitor to LL. It'll be a completely different beast. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/7fbee2a7/attachment-0001.pgp From nicholaz at blueflash.cc Sat Sep 8 07:58:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 07:58:42 2007 Subject: [sldev] Re: [POLICY] New mailing lists/forum (was: mailing list keywords posted) In-Reply-To: <200709081623.27295.dale@daleglass.net> References: <46E1C008.9010006@lindenlab.com> <200709080522.19215.dale@daleglass.net> <46E2602A.5080002@blueflash.cc> <200709081623.27295.dale@daleglass.net> Message-ID: <46E2B896.9080200@blueflash.cc> Dale Glass wrote: > On Saturday 08 September 2007 10:41:14 Nicholaz Beresford wrote: >> Well, just for the record, my preference in format based on my >> communiation habits is clearly Forums. > > So what do you think about using both with a gateway? I never used that > setup, so I don't know how well it works in practice. Oh, I'm basically okay with lists too. The gateway on mysldved is nice, I didn't even know something like that existed. I can handle either, but my preference is simply forums, because it's easier to ignore unwanted threads, stuff is archived in a contextual form and easily searched etc. I also found them easier to moderate splitting threads with a new topic, moving threads between sections etc. But basically I'll go where the interesting action is and would contribute just like where it comes natural to me, like I'm posting some stuff on the blog and others on the list here, based on the audience. I've subscribed to your lists and the mysldev forum and will just hop between them. Stuff like that can't be planned anyway, it just happens and IMHO most of it has more to do with the general atmosphere rather than the technical format. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Sat Sep 8 08:07:20 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 08:07:35 2007 Subject: [sldev] Re: [POLICY] New mailing lists/forum (was: mailing list keywords posted) In-Reply-To: References: <46E1C008.9010006@lindenlab.com> <200709080456.02815.dale@daleglass.net> <200709080522.19215.dale@daleglass.net> Message-ID: <46E2BAA8.5030305@blueflash.cc> Harold Brown wrote: > Is Nicholas going to start some? Or anyone else? We need centralized > communication... not 500 mailing lists, wiki's, blogs, forums, etc to > follow. Well, most of what happens here is based on less than 20 people. Whereever they move, most the action will be. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From lenglish5 at cox.net Sat Sep 8 08:47:36 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 08:47:38 2007 Subject: [sldev] Limiting the length of string inconsistently In-Reply-To: <7buJ7ds4dY7s8vdsbs04Gc8x.alissa_sabre@yahoo.co.jp> References: <7buJ7ds4dY7s8vdsbs04Gc8x.alissa_sabre@yahoo.co.jp> Message-ID: <46E2C418.7050403@cox.net> Top-posting: this issue applies to just about any bit of UTF-8 text, including llSetText or any other text that has an arbitrarily short built-in limit. I haven't tested Japanese kanji with GUI elements like dialog text-entry, but I suspect it applies there as well. Alissa Sabre wrote: > I filed a new JIRA issue, VWR-2367. > > It is on the maximum message length of a Group Notice. The point is, > that, when editing the notice, the maximum length of the message is > limited by the number of _characters_. When the notice is sent, the > lower messaging layer checks the maximum length by the number of > _bytes_. > > When editing, the maximum length is 511 characters. The lower layer > limits the maximum by 1200 bytes (including some overheads). Since, > one Japanese character occupy three bytes in UTF-8, Japanese Group > Notice messages with more than about 400 characters are truncated when > sent. > > I can imagine three approaches to fix it. Which fix is best? I want > to know your opinions. > > (a) Extend the messaging maximum to cover the worst case maximum. > Because, a character can occupy four bytes in UTF-8 as a maximum, > 511 characters can be up to 2044 bytes. Enlarge the lower layer > limit to this value (plus some overhead.) > > (b) Reduce the UI (editing) limit to the value that is guaranteed to > pass the lower layer limit in worst case. That is 1200 (minus > some overhead) divided by four, i.e., around 250. > > (c) Add a feature to a UI component (LLTextEditor) to limit the > maximum size in bytes as opposed to in characters, and set that > limit to a value around 1000. > > If the way we should go is (b) or (c) above, I can write a fix. > However, if the correct fix is (a), I don't think it's doable by open > source developers, since I guess the server-side code should be > updated in sync. > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From bbyer at mm.st Sat Sep 8 08:54:45 2007 From: bbyer at mm.st (Ben Byer) Date: Sat Sep 8 08:54:50 2007 Subject: [sldev] property rights in distributed systems In-Reply-To: <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709071859h7ea5d1dcg32636b11c3f25546@mail.gmail.com> <3b19a500709071922o2cb80935p824df7051d65d78d@mail.gmail.com> <8a1bfe660709072036p3a7d6f72g1d32d7224abb7958@mail.gmail.com> <46E25F36.5070303@blueflash.cc> <8a1bfe660709080231s3389c764x26bc81b16cec4288@mail.gmail.com> <46E276EC.1030705@wsu.edu> <46E287C2.3060403@blueflash.cc> <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> Message-ID: On Sep 8, 2007, at 4:39 AM, Laurent Laborde wrote: > On 9/8/07, Nicholaz Beresford wrote: >> >> But when writing Open Source and spending hours and weeks on code >> that itself is GPL, MIT and whatnot, it sounds a bit odd to me >> when in designing the content storage, the one of the major design >> goals (or obstacles) is to allow people to make what they build >> inside that project "closed source". > > That's just right managment... like a good old filesystem, protected > memory, privilegied network port (<1024), ... Nope. All three examples you just named are cases where the operating system is enforcing some rules for the benefit of the user (owner) of the system. Accordingly, all can by bypassed in some way by a local user. The "DRM" or property rights issue is the complete opposite -- it's my computer trying to prevent me from doing something I might want to do (copy objects I didn't create). -b From lenglish5 at cox.net Sat Sep 8 09:00:21 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 09:00:25 2007 Subject: [sldev] [VIEWER} Mac madness Message-ID: <46E2C715.40000@cox.net> I wonder how many people are using Macs to write patches? I've noticed at least two issues that appear to be Mac-specific. The first is a minor annoyance and I'm not proficient enough in using the xCode IDE to figure out how to fix it. The "Development" target, designed to facilitate debugging, causes runtime errors at the lanuch of the client, so I have to use the "Deployment" target instead. The second one is a killer, at least with the OpenSource version of 1.18.3.2. Using a pristine build with no modifications, I get severe texture issues in at least one sculptie: a modable version of Qarl's ant sculpty that was used to test the libsl sculptie-importing script. The problem does NOT appear in the pre-built RC Mac client. The problems appear in both the sulptie-maps (they look like random garbage in some of the prims) and the textures that go on various prims (instead of ant-grey, they're bright, mono-colors). Again, this happens in the home-brew, but pristine build, but not the pre-built version. I've done the usual stuff like clear cache, check for RAM and disk hardware/format/etc errors. I've also rebuilt the entire client from scratch. Same problem. Mac G5 dual 2.0 system with 2.5 GB of RAM, running xCode IDE 2.4.1, no special settings, deployment build. I'll submit a jira with the screenshots of both the pre-built and home-built versions. If any Mac developer wants a copy of the ant, I can send it to them for testing. A windows PC person noticed SLIGHT errors with the ant on their home-brew client vs the pre-built, bit nothing like what I get on the Mac. Just a heads up. Lawson AKA Saijanai Kuhn From lenglish5 at cox.net Sat Sep 8 09:05:26 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 09:05:27 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <46E2C715.40000@cox.net> References: <46E2C715.40000@cox.net> Message-ID: <46E2C846.4090700@cox.net> Lawson English wrote: > [...] > > I'll submit a jira with the screenshots of both the pre-built and > home-built versions. If any Mac developer wants a copy of the ant, I > can send it to them for testing. A windows PC person noticed SLIGHT > errors with the ant on their home-brew client vs the pre-built, bit > nothing like what I get on the Mac. Just to emphasize: this is NOT Qarl's original ant, but a separate copy that was uploaded to test the libsl upload script. From dale at daleglass.net Sat Sep 8 09:06:03 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 8 09:06:14 2007 Subject: [sldev] Re: property rights in distributed systems In-Reply-To: References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> Message-ID: <200709081806.10015.dale@daleglass.net> On Saturday 08 September 2007 17:54:45 Ben Byer wrote: > Nope. > > All three examples you just named are cases where the operating > system is enforcing some rules for the benefit of the user (owner) of > the system. Accordingly, all can by bypassed in some way by a local > user. Never used a multi-user Linux system? Shared hosting, parents managing a system for their children, etc work exactly this way: You're subject to somebody else's will. If the admin doesn't want you to read /etc/fstab then you can't and there's no way you can bypass it (excluding explots, but that's a different topic). > The "DRM" or property rights issue is the complete opposite -- it's > my computer trying to prevent me from doing something I might want to > do (copy objects I didn't create). But it's not "your computer". In SL it's LL's asset server, on a shared hosting system is the provider's server, in a family it'd be the parents' computer. This isn't DRM. DRM stops the rightful owner from doing what they want with their own content. But that's got nothing to do with a situation where you're using something that actually isn't your in the first place. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/47c6e659/attachment.pgp From dale at daleglass.net Sat Sep 8 09:19:35 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Sep 8 09:19:59 2007 Subject: [sldev] [META] Announcing: unofficial sldev-misc and sldev-announce lists Message-ID: <200709081819.53754.dale@daleglass.net> Hi! Due to the recent discussion about the level of traffic on this list, as well as some discontent with the wiki, I decided to implement my previous suggestion to add more lists. The new lists are: sldev-misc for various misc discussion related to development. This would be pretty much everything that isn't welcome on sldev, such as long discussions about licensing, caching, etc. http://lists.daleglass.net/listinfo.cgi/sldev-announce-daleglass.net sldev-announce is for everybody to announce the status of their own work. Post here about new releases, new features in your viewers, etc. http://lists.daleglass.net/listinfo.cgi/sldev-misc-daleglass.net Additional lists can be easily created if people request them. I don't currently plan to provide an alternative for this list. At the time I'm perfectly fine with all discussion happening on the list, but since there's still this attempt to move discussions to the wiki, I decided to provide the lists. I promise a very unrestrictive moderation policy. Basically, so long people are happy, so am I. There won't be any limit on length of discussions that aren't completely offtopic or degenerate into a flamewar. You can count on me not stepping in if everybody seems to be OK with whatever is going on. Keywords are currently not required on my lists, I'm including the [MISC] one to comply with sldev policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/b482f24b/attachment.pgp From bbyer at mm.st Sat Sep 8 09:52:34 2007 From: bbyer at mm.st (Ben Byer) Date: Sat Sep 8 09:52:39 2007 Subject: [sldev] Re: property rights in distributed systems In-Reply-To: <200709081806.10015.dale@daleglass.net> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> <200709081806.10015.dale@daleglass.net> Message-ID: On Sep 8, 2007, at 9:06 AM, Dale Glass wrote: > On Saturday 08 September 2007 17:54:45 Ben Byer wrote: >> Nope. >> >> All three examples you just named are cases where the operating >> system is enforcing some rules for the benefit of the user (owner) of >> the system. Accordingly, all can by bypassed in some way by a local >> user. > > Never used a multi-user Linux system? I think I read about that somewhere. > Shared hosting, parents managing a system for their children, etc work > exactly this way: You're subject to somebody else's will. If the admin > doesn't want you to read /etc/fstab then you can't and there's no > way you > can bypass it (excluding explots, but that's a different topic). ... but that's not what I'm talking about ... (read on) >> The "DRM" or property rights issue is the complete opposite -- it's >> my computer trying to prevent me from doing something I might want to >> do (copy objects I didn't create). > > But it's not "your computer". In SL it's LL's asset server, on a > shared > hosting system is the provider's server, in a family it'd be the > parents' > computer. I was specifically trying to address the P2P scenario mentioned earlier in this thread -- where there is no central asset server, and instead every computer gets to peek at every bit of data, and therefore it *is* "your computer". In that case, you can't prevent a hacked client from copying the data. From dzonatas at dzonux.net Sat Sep 8 09:54:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 8 09:53:39 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: References: Message-ID: <46E2D3B9.1070709@dzonux.net> The closest we have to this is the binary plug-ins as posted about earlier on this list. A more dynamic model may have finally been agreed upon based on python and mono extensions. Python is already available, as in under approved licenses and a ready module, to add into the viewer. It just needs hooks to make it active. Roberto Marino wrote: > This is my first "post" on this ML. This is the question: > Is there, to this day, a working plugins architecture on SL viewer? > > Cheers > R. > > -- > Roberto (aka formica) Marino > Computer Engineering Student > Free Software User - Me|Lug Member > --> formica@messinalug.org <-- > http://www.messinalug.org > -- > GnuPG key ID: 641AE37D > -- > Per favore non mandatemi allegati in Word o PowerPoint. > Si veda http://www.gnu.org/philosophy/no-word-attachments.html > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070908/7a7128e1/attachment.htm From lenglish5 at cox.net Sat Sep 8 09:57:34 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 09:57:35 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: <46E2D3B9.1070709@dzonux.net> References: <46E2D3B9.1070709@dzonux.net> Message-ID: <46E2D47E.80300@cox.net> Dzonatas wrote: > The closest we have to this is the binary plug-ins as posted about > earlier on this list. > > A more dynamic model may have finally been agreed upon based on python > and mono extensions. Python is already available, as in under approved > licenses and a ready module, to add into the viewer. It just needs > hooks to make it active. Many people prefer Lua to python for simple scripting purposes. The WoW GUI uses it for scripting, for instance. I know of at least 3 people who are implementing their own client builds that use Lua. Not sure how many have started working on a client that uses Python. From seg at haxxed.com Sat Sep 8 11:28:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 8 11:33:19 2007 Subject: [sldev] Re: Exciting reuter's post about OpenSim - project to create open source version of SL Servers In-Reply-To: <200709081639.02519.dale@daleglass.net> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <200709080611.25404.dale@daleglass.net> <1189228438.2798.235.camel@localhost> <200709081639.02519.dale@daleglass.net> Message-ID: <1189276129.777.35.camel@localhost.localdomain> On Sat, 2007-09-08 at 16:38 +0200, Dale Glass wrote: > On Saturday 08 September 2007 07:13:58 Callum Lerwick wrote: > > On Sat, 2007-09-08 at 06:11 +0200, Dale Glass wrote: > > > It also makes a lot of caching impossible as with no central server > > > there's no universal ID for an object (probably fixable by using > > > content based hashes) > > > > A content hash, of course. > Ok, but do you want to preserve ownership on your grid? That's up to the creator of the asset, to sign their work in some way. Its what people already do. > Say, who is the owner or the creator of a texture or object on this grid? > If it goes by content hash there can't be two separate copies by different > people. > > Take a box for instance. The second box rezzed will have the same hash as > the first one. Does that give them the same LLUUID? If not, where does > that LLUUID come from? You tag the asset with some kind of meta-data, which becomes part of the asset thus part of the hash. This can be as simple as signing your name in the corner of a texture, (Yeah yeah, wouldn't work so well if the texture is tiled, but this would work nicely on avatar textures which have areas that aren't shown.) or putting your name in the scripts you write. > > P2P-ish technology. Its nothing but a big distributed cache anyway. It > > will become as basic an internet service as DNS is. All ISPs will run a > > "seed" farm for its customers. Or at least contract it out to some > > really big seed farms. :) > > P2P from where to where? Example situations: > > Situation A: > I login in sim A, obtain a house and save it to my inventory. > I cross to sim B, don't stop there and don't do anything, and cross to C. > I try to rez the house in sim C. > > How does it get rezzed? Well, from your own point of view, its retrieved from your own cache. Others query the "asset mesh", of which you participate in, so you can seed your own assets. > Situation B: > I login in sim A, obtain a house and save it to my inventory. > I logout, log back in to some completely different part of the grid, 6 > months later. > I try to rez the house. > > How does it get rezzed? Does it get rezzed at all? You rez it from your own storage, if you happen to still have a copy. Otherwise your client, and other people's clients query the asset mesh for your asset. If its not out there, well its your own damn fault for not keeping a copy. :) > Easiest way to do it seems to have the user keep the inventory and transmit > it to the sim on rez, but that means that you lose your inventory if > anything happens to your computer. Unless a copy is still out in the mesh somewhere. But if you really care about something, its up to you to ensure a copy is retained somewhere, somehow. Its really no different from now. Except that if you have or make something that's popular enough, everyone else will mirror it for you, for free. :) " Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) " --Linus Torvalds, 1996-07-20 > If on the other hand, inventory is held by the sim that gave it to you, > then that means it's lost if that sim is removed. The sim could very well also participate in the asset mesh, making itself the preferred point of contact for clients connected to it, but it wouldn't be required. No different from running apache and sendmail on the same box. > Also there either needs > to be a central DB to figure out which sim has the data, or you have the > same problem as above. Easy. A Kademlia based DB. http://en.wikipedia.org/wiki/Kademlia > > Identify all avatars by a PGP key. Build a trust web with your friends. > > All assets referenced or belonging to an avatar get signed with that > > avatar's key. Combined with the referencing based on content hash, ta > > da, can't slip anything in without detection. > > > > All the pieces are there, you just have to put them together. :) > > While I really like PGP that doesn't sound like a very friendly system :-) > TrustNet is hard enough to explain already. It doesn't have to be any more complex that the existing "offer friendship" system. This would possibly be a separate trust web from "normal" PGP though. The trust web is just a bonus, really. Identifying avatars via a public key, is the key thing. :) > I have to agree with Laurent here. This could be very cool, but it won't be > a competitor to LL. It'll be a completely different beast. Just like the internet vs. Compuserve. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/dea61498/attachment.pgp From kelly at lindenlab.com Sat Sep 8 12:52:54 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Sat Sep 8 12:53:01 2007 Subject: [sldev] Limiting the length of string inconsistently In-Reply-To: <46E2C418.7050403@cox.net> References: <7buJ7ds4dY7s8vdsbs04Gc8x.alissa_sabre@yahoo.co.jp> <46E2C418.7050403@cox.net> Message-ID: <46E2FD96.4020408@lindenlab.com> First, for those that haven't looked, group notices are IMs. The path of an IM looks something like: Viewer -(udp)-> Sim of sender *-(tcp)-> Sim of receiver -(udp)-> Viewer | *-(udp)-> Dataserver -(mysql)-> DB The dataserver is actually on the same host as the sim of the sender. The key point here is that several pieces of this journey are UDP which means we must contend with MTU. We are usually pretty conservative about our MTU packet size, and 1200 bytes sounds about right once you factor in the other meta data that travels with the message. There is a new system in place for each of the UDP steps above, but IMs do not (yet) use them: * For viewer -> sim there is the caps system * For sim -> dataserver a key scaling project currently in progress is to replace the dataserver with a set of light weight and scalable web services. These use TCP/IP and not UDP. * For sim -> viewer there is the 'event queue' You are right that none of these can be completed by open source devs right now. The second one (dataserver) will get handled very soon, and the other two may not be too difficult. However, until they are done (and priorities being what they are I'm not sure the time table for that) I think (b) or (c) are the viable options. I kind of prefer (c) since it is more flexible and doesn't limit more than actually needed. - Kelly Lawson English wrote: > Top-posting: this issue applies to just about any bit of UTF-8 text, > including llSetText or any other text that has an arbitrarily short > built-in limit. I haven't tested Japanese kanji with GUI elements like > dialog text-entry, but I suspect it applies there as well. > > > Alissa Sabre wrote: >> I filed a new JIRA issue, VWR-2367. >> >> It is on the maximum message length of a Group Notice. The point is, >> that, when editing the notice, the maximum length of the message is >> limited by the number of _characters_. When the notice is sent, the >> lower messaging layer checks the maximum length by the number of >> _bytes_. >> >> When editing, the maximum length is 511 characters. The lower layer >> limits the maximum by 1200 bytes (including some overheads). Since, >> one Japanese character occupy three bytes in UTF-8, Japanese Group >> Notice messages with more than about 400 characters are truncated when >> sent. >> >> I can imagine three approaches to fix it. Which fix is best? I want >> to know your opinions. >> >> (a) Extend the messaging maximum to cover the worst case maximum. >> Because, a character can occupy four bytes in UTF-8 as a maximum, >> 511 characters can be up to 2044 bytes. Enlarge the lower layer >> limit to this value (plus some overhead.) >> >> (b) Reduce the UI (editing) limit to the value that is guaranteed to >> pass the lower layer limit in worst case. That is 1200 (minus >> some overhead) divided by four, i.e., around 250. >> >> (c) Add a feature to a UI component (LLTextEditor) to limit the >> maximum size in bytes as opposed to in characters, and set that >> limit to a value around 1000. >> >> If the way we should go is (b) or (c) above, I can write a fix. >> However, if the correct fix is (a), I don't think it's doable by open >> source developers, since I guess the server-side code should be >> updated in sync. >> >> Alissa Sabre >> -------------------------------------- >> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >> http://pr.mail.yahoo.co.jp/toolbar/ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From bboomslang at googlemail.com Sat Sep 8 13:22:58 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sat Sep 8 13:23:00 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <46E2C715.40000@cox.net> References: <46E2C715.40000@cox.net> Message-ID: <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> HI, it's the pesky OpenJPEG library. It can't decode stuff it encoded itself if it is uncompressed JPEG2000. This is not Mac specific, but is a problem with all pure opensource builds. I'd love to be able to build SL against the libkdu stuff (which is what the official client uses - a commercial JPEG 2000 library), but so far no luck with that. If anybody has a hint on how to do that, I would be quite happy, because it's the biggest problem with the Mac build of the client so far. There is a jira on that allready: https://jira.secondlife.com:443/browse/VWR-1815 Another problem I stumbled over is that several mouse cursors are missing - some show up, some don't. Haven't looked into that for now, due to the OpenJPEG problems being essentially a show-stopper for what I want to do (build mac clients based on nicholaz' patches). The third thing I noticed is that even with 1.18.3 the XCode project files build universal and deployment with all symbols linked and so produce monstrous executables - it's one click in the project file to only link essential symbols and get to the normal executable sizes, though. bye, Barney On 9/8/07, Lawson English wrote: > I wonder how many people are using Macs to write patches? I've noticed > at least two issues that appear to be Mac-specific. The first is a minor > annoyance and I'm not proficient enough in using the xCode IDE to figure > out how to fix it. The "Development" target, designed to facilitate > debugging, causes runtime errors at the lanuch of the client, so I have > to use the "Deployment" target instead. > > The second one is a killer, at least with the OpenSource version of > 1.18.3.2. Using a pristine build with no modifications, I get severe > texture issues in at least one sculptie: a modable version of Qarl's ant > sculpty that was used to test the libsl sculptie-importing script. The > problem does NOT appear in the pre-built RC Mac client. > > The problems appear in both the sulptie-maps (they look like random > garbage in some of the prims) and the textures that go on various prims > (instead of ant-grey, they're bright, mono-colors). Again, this happens > in the home-brew, but pristine build, but not the pre-built version. > > I've done the usual stuff like clear cache, check for RAM and disk > hardware/format/etc errors. I've also rebuilt the entire client from > scratch. Same problem. > > Mac G5 dual 2.0 system with 2.5 GB of RAM, running xCode IDE 2.4.1, no > special settings, deployment build. > > I'll submit a jira with the screenshots of both the pre-built and > home-built versions. If any Mac developer wants a copy of the ant, I can > send it to them for testing. A windows PC person noticed SLIGHT errors > with the ant on their home-brew client vs the pre-built, bit nothing > like what I get on the Mac. > > Just a heads up. > > Lawson > > AKA Saijanai Kuhn > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Sat Sep 8 13:46:55 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 13:46:57 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> Message-ID: <46E30A3F.6040208@cox.net> Barney Boomslang wrote: > [...] > > The third thing I noticed is that even with 1.18.3 the XCode project > files build universal and deployment with all symbols linked and so > produce monstrous executables - it's one click in the project file to > only link essential symbols and get to the normal executable sizes, > though. > > bye, Barney > Thanks for the heads up concerning the JPEG2000 issues. RE: the compiler flags, which ones are they? I'm a newbie to xCode, and I'm still wading through _The xCode Book_. Thanks, Lawson From sllists at boroon.dasgupta.ch Sat Sep 8 13:51:47 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Sep 8 13:51:54 2007 Subject: [sldev] [VIEWER] KDU with self-compiled client In-Reply-To: <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> Message-ID: <47565.83.180.254.242.1189284707.squirrel@datendelphin.net> Ooops, this should have gone to the list: (So I can be corrected in case this is wrong) > HI, > I'd love to be able to > build SL against the libkdu stuff (which is what the official client > uses - a commercial JPEG 2000 library), but so far no luck with that. I think you can just take the library from an existing binary installation of SL and drop it to the same place of your self-compiled one (after compiling). The source has the code for calling both of those libraries, and as far as I know, will switch to KDU when it detects it's there. Boroondas From lenglish5 at cox.net Sat Sep 8 14:03:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 14:03:16 2007 Subject: [sldev] [VIEWER] KDU with self-compiled client In-Reply-To: <47565.83.180.254.242.1189284707.squirrel@datendelphin.net> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> <47565.83.180.254.242.1189284707.squirrel@datendelphin.net> Message-ID: <46E30E13.3080806@cox.net> Boroondas Gupte wrote: > Ooops, this should have gone to the list: > (So I can be corrected in case this is wrong) > >> HI, >> I'd love to be able to >> build SL against the libkdu stuff (which is what the official client >> uses - a commercial JPEG 2000 library), but so far no luck with that. >> > > I think you can just take the library from an existing binary installation > of SL and drop it to the same place of your self-compiled one (after > compiling). The source has the code for calling both of those libraries, > and as far as I know, will switch to KDU when it detects it's there. > > Boroondas > > IF that is the case, then I believe that xCode has the capability to do a conditional compile of the source. If the library already exists, link that in, else compile the source and link THAT instead. Mind you, I haven't a clue how to write the script to accomplish this. It should be a standard shell script to control gcc though. From seg at haxxed.com Sat Sep 8 14:45:26 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 8 14:45:33 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> Message-ID: <1189287926.2798.239.camel@localhost> On Sat, 2007-09-08 at 22:22 +0200, Barney Boomslang wrote: > HI, > > it's the pesky OpenJPEG library. It can't decode stuff it encoded > itself if it is uncompressed JPEG2000. This is not Mac specific, but > is a problem with all pure opensource builds. I'd love to be able to > build SL against the libkdu stuff (which is what the official client > uses - a commercial JPEG 2000 library), but so far no luck with that. > If anybody has a hint on how to do that, I would be quite happy, > because it's the biggest problem with the Mac build of the client so > far. There is a jira on that allready: > > https://jira.secondlife.com:443/browse/VWR-1815 There's a bug lurking in the lossless encoder, which I seem to have yet to nail. The "fix" for now is to use lossy encoding instead, which we should be using most of the time anyway: https://jira.secondlife.com/browse/VWR-1475 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/f2971f7d/attachment.pgp From nicholaz at blueflash.cc Sat Sep 8 14:51:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 8 14:52:06 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <46E2C846.4090700@cox.net> References: <46E2C715.40000@cox.net> <46E2C846.4090700@cox.net> Message-ID: <46E31979.1050408@blueflash.cc> The was a problem in the Windows viewer with llkdu. Dunno if it's related to what you're seeing, but there seem to have been a borked or outdated version in the lib packet for homebrews. Under Windows, copying llkdu.dll from the RC release folder did work. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Lawson English wrote: > Lawson English wrote: >> [...] >> >> I'll submit a jira with the screenshots of both the pre-built and >> home-built versions. If any Mac developer wants a copy of the ant, I >> can send it to them for testing. A windows PC person noticed SLIGHT >> errors with the ant on their home-brew client vs the pre-built, bit >> nothing like what I get on the Mac. > Just to emphasize: this is NOT Qarl's original ant, but a separate copy > that was uploaded to test the libsl upload script. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jhurliman at wsu.edu Sat Sep 8 15:22:07 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 15:22:11 2007 Subject: [sldev] Re: property rights in distributed systems In-Reply-To: <200709081806.10015.dale@daleglass.net> References: <3b19a500709071706w51ffdc4lf96e97452c3a9948@mail.gmail.com> <8a1bfe660709080439r104bdfbapf712317dcc6014d2@mail.gmail.com> <200709081806.10015.dale@daleglass.net> Message-ID: <46E3208F.90402@wsu.edu> Dale Glass wrote: > On Saturday 08 September 2007 17:54:45 Ben Byer wrote: > >> Nope. >> >> All three examples you just named are cases where the operating >> system is enforcing some rules for the benefit of the user (owner) of >> the system. Accordingly, all can by bypassed in some way by a local >> user. >> > > Never used a multi-user Linux system? > > Shared hosting, parents managing a system for their children, etc work > exactly this way: You're subject to somebody else's will. If the admin > doesn't want you to read /etc/fstab then you can't and there's no way you > can bypass it (excluding explots, but that's a different topic). > > >> The "DRM" or property rights issue is the complete opposite -- it's >> my computer trying to prevent me from doing something I might want to >> do (copy objects I didn't create). >> > > But it's not "your computer". In SL it's LL's asset server, on a shared > hosting system is the provider's server, in a family it'd be the parents' > computer. > > This isn't DRM. DRM stops the rightful owner from doing what they want with > their own content. But that's got nothing to do with a situation where > you're using something that actually isn't your in the first place. > It definitely is DRM. If people really wanted to protect their assets they would never create or distribute them outside of a private island, never let anyone see them. But the problem is copyright holders want to distribute their content to a certain degree (allowing people to see their work, allowing people to have no modify no copy versions, etc) but keep it protected at the same time. An example would be a website that lets you stream videos you can watch, but measures are taken to prevent you from saving the stream to your hard drive. Same problem in Second Life, where you are trying to achieve a level of DRM that is impossible (see the Copybot discussions). There are two slightly related but different things going on here. On one hand you have assets that really should never go in to the hands of other people (private scripts) and the asset server will never send those files to unauthorized clients. That becomes slightly more difficult with distributed assets but it is not an unsolvable problem with notions of trust levels of simulators and public key crypto (only trusted sims are given decryption keys to run your private scripts). On the other hand you have to send content to people such as sounds, textures, animations, and primitives but you don't want them to be able to store the data they are receiving to the hard drive. There's no point in even spending energy trying to figure out how to protect this side of things since the current system is just a set of bitmasks asking nicely not to do certain things. Just like rogue browsers can disable javascript protection of right-clicking and saving images, a modified SL client can bypass any of those friendly requests. John Hurliman From jhurliman at wsu.edu Sat Sep 8 15:29:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 15:29:21 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <1189287926.2798.239.camel@localhost> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> <1189287926.2798.239.camel@localhost> Message-ID: <46E3223C.6000306@wsu.edu> Callum Lerwick wrote: > On Sat, 2007-09-08 at 22:22 +0200, Barney Boomslang wrote: > >> HI, >> >> it's the pesky OpenJPEG library. It can't decode stuff it encoded >> itself if it is uncompressed JPEG2000. This is not Mac specific, but >> is a problem with all pure opensource builds. I'd love to be able to >> build SL against the libkdu stuff (which is what the official client >> uses - a commercial JPEG 2000 library), but so far no luck with that. >> If anybody has a hint on how to do that, I would be quite happy, >> because it's the biggest problem with the Mac build of the client so >> far. There is a jira on that allready: >> >> https://jira.secondlife.com:443/browse/VWR-1815 >> > > There's a bug lurking in the lossless encoder, which I seem to have yet > to nail. The "fix" for now is to use lossy encoding instead, which we > should be using most of the time anyway: > > https://jira.secondlife.com/browse/VWR-1475 Ugh, thanks for the heads up on this. Unfortunately I think the cat is already out of the bag as every time I login to SL my IM inbox is full with messages from people using "SL Image Upload" that allows sculpty builders to upload lossless images. I don't have the time right now to reverse engineer an interface in to the llkdu.dll library, so open source clients are going to be out of luck when viewing lossless sculpties. Encoder problem or not, Kakadu is able to successfully decode the images in to the original data while the OpenJPEG decoder creates a mess. Making the decoder more resilient would fix this issue as well. John Hurliman From jhurliman at wsu.edu Sat Sep 8 15:34:15 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 15:34:18 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: <46E2D47E.80300@cox.net> References: <46E2D3B9.1070709@dzonux.net> <46E2D47E.80300@cox.net> Message-ID: <46E32367.7060203@wsu.edu> Lawson English wrote: > Dzonatas wrote: >> The closest we have to this is the binary plug-ins as posted about >> earlier on this list. >> >> A more dynamic model may have finally been agreed upon based on >> python and mono extensions. Python is already available, as in under >> approved licenses and a ready module, to add into the viewer. It just >> needs hooks to make it active. > Many people prefer Lua to python for simple scripting purposes. The > WoW GUI uses it for scripting, for instance. > > I know of at least 3 people who are implementing their own client > builds that use Lua. Not sure how many have started working on a > client that uses Python. Anything that supports embedding Mono will be able to run IronPython code. From lenglish5 at cox.net Sat Sep 8 15:44:00 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 15:44:02 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: <46E32367.7060203@wsu.edu> References: <46E2D3B9.1070709@dzonux.net> <46E2D47E.80300@cox.net> <46E32367.7060203@wsu.edu> Message-ID: <46E325B0.2080503@cox.net> John Hurliman wrote: > Lawson English wrote: >> Dzonatas wrote: >>> The closest we have to this is the binary plug-ins as posted about >>> earlier on this list. >>> >>> A more dynamic model may have finally been agreed upon based on >>> python and mono extensions. Python is already available, as in under >>> approved licenses and a ready module, to add into the viewer. It >>> just needs hooks to make it active. >> Many people prefer Lua to python for simple scripting purposes. The >> WoW GUI uses it for scripting, for instance. >> >> I know of at least 3 people who are implementing their own client >> builds that use Lua. Not sure how many have started working on a >> client that uses Python. > > Anything that supports embedding Mono will be able to run IronPython > code. I know that mono support is the long-term plan for scripting. However, mono isn't available on the sims yet, letalone in the client. Some people are working on scripting solutions today, rather than 6-18 months from now. From jhurliman at wsu.edu Sat Sep 8 15:45:46 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 15:45:52 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> References: <20070908114020.1367D41B24B@stupor.lindenlab.com> <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> Message-ID: <46E3261A.5000000@wsu.edu> Argent Stonecutter wrote: > >> Not true at all, there are many different ways you could implement a >> distributed grid architecture that involved storing inventory on the >> client. > > Well, "... storing inventory in a distributed manner...". It has to be > stored *somewhere*, and it needs to be stored somewhere that doesn't > depend on some random laptop (that you haven't yet realized is sitting > at the bottom of your swimming pool, because your wifi is down as > well) being online. You don't need a special concept of an "inventory" to have a grid. For appearance, clients are already telling new simulators all 218 of their appearance parameters when they enter and giving them the location of your baked outfit textures. Having simulators temporarily host your baked textures (and implementing some mirorring in case on simulator drops offline, and requesting the client to rebake in a worst case scenario) would solve the appearance problem. As far as inventory goes, just make it files on your hard drive. When I sit down in an Internet cafe and fire up a browser I don't have an inventory on hand*, but I'm still able to use the web. "... storing inventory in a distributed manner..." sounds like a nice idea, but it is not essential to building a metaverse. It could be offered as a third party service instead of built in to the grid code. * Actually a lot of sites like Google homepage keep persistent settings for me, which is the equivalent of keeping some inventory on a single simulator. John Hurliman From jhurliman at wsu.edu Sat Sep 8 15:49:48 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 15:49:51 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: <46E325B0.2080503@cox.net> References: <46E2D3B9.1070709@dzonux.net> <46E2D47E.80300@cox.net> <46E32367.7060203@wsu.edu> <46E325B0.2080503@cox.net> Message-ID: <46E3270C.2050906@wsu.edu> Lawson English wrote: > John Hurliman wrote: >> Lawson English wrote: >>> Dzonatas wrote: >>>> The closest we have to this is the binary plug-ins as posted about >>>> earlier on this list. >>>> >>>> A more dynamic model may have finally been agreed upon based on >>>> python and mono extensions. Python is already available, as in >>>> under approved licenses and a ready module, to add into the viewer. >>>> It just needs hooks to make it active. >>> Many people prefer Lua to python for simple scripting purposes. The >>> WoW GUI uses it for scripting, for instance. >>> >>> I know of at least 3 people who are implementing their own client >>> builds that use Lua. Not sure how many have started working on a >>> client that uses Python. >> >> Anything that supports embedding Mono will be able to run IronPython >> code. > I know that mono support is the long-term plan for scripting. However, > mono isn't available on the sims yet, letalone in the client. Some > people are working on scripting solutions today, rather than 6-18 > months from now. > _______________________________________________ No one has ever said that Mono support is the long term plan for client scripting. If you have a source for that please post it because this is the first time I've heard that. Mono support on the simulators has nothing at all to do with support in the client, and "some people" are working on client scripting solutions based on Mono today. John Hurliman From adam at gwala.net Sat Sep 8 15:49:47 2007 From: adam at gwala.net (Adam Frisby) Date: Sat Sep 8 15:51:47 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <46E3261A.5000000@wsu.edu> References: <20070908114020.1367D41B24B@stupor.lindenlab.com> <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> <46E3261A.5000000@wsu.edu> Message-ID: <46E3270B.3080906@gwala.net> Just a note -- there are opensim mailing lists which are probably a more suitable venue for this discussion than the LL SL-DEV mailing list (as I think this is supposed to be viewer-only really). opensim-dev >> https://lists.berlios.de/mailman/listinfo/opensim-dev Adam John Hurliman wrote: > Argent Stonecutter wrote: > >> >>> Not true at all, there are many different ways you could implement a >>> distributed grid architecture that involved storing inventory on the >>> client. >> >> >> Well, "... storing inventory in a distributed manner...". It has to be >> stored *somewhere*, and it needs to be stored somewhere that doesn't >> depend on some random laptop (that you haven't yet realized is sitting >> at the bottom of your swimming pool, because your wifi is down as >> well) being online. > > > You don't need a special concept of an "inventory" to have a grid. For > appearance, clients are already telling new simulators all 218 of their > appearance parameters when they enter and giving them the location of > your baked outfit textures. Having simulators temporarily host your > baked textures (and implementing some mirorring in case on simulator > drops offline, and requesting the client to rebake in a worst case > scenario) would solve the appearance problem. As far as inventory goes, > just make it files on your hard drive. When I sit down in an Internet > cafe and fire up a browser I don't have an inventory on hand*, but I'm > still able to use the web. > > "... storing inventory in a distributed manner..." sounds like a nice > idea, but it is not essential to building a metaverse. It could be > offered as a third party service instead of built in to the grid code. > > * Actually a lot of sites like Google homepage keep persistent settings > for me, which is the equivalent of keeping some inventory on a single > simulator. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Sat Sep 8 16:12:09 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 16:12:14 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <46E3270B.3080906@gwala.net> References: <20070908114020.1367D41B24B@stupor.lindenlab.com> <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> <46E3261A.5000000@wsu.edu> <46E3270B.3080906@gwala.net> Message-ID: <46E32C49.2090303@wsu.edu> I never got the memo that it was a viewer-only mailing list, and it seems like an appropriate discussion to have leading up to the meeting on Thursday. John Adam Frisby wrote: > Just a note -- there are opensim mailing lists which are probably a > more suitable venue for this discussion than the LL SL-DEV mailing > list (as I think this is supposed to be viewer-only really). > > opensim-dev >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > Adam > > John Hurliman wrote: > >> Argent Stonecutter wrote: >> >>> >>>> Not true at all, there are many different ways you could implement a >>>> distributed grid architecture that involved storing inventory on the >>>> client. >>> >>> >>> Well, "... storing inventory in a distributed manner...". It has to >>> be stored *somewhere*, and it needs to be stored somewhere that >>> doesn't depend on some random laptop (that you haven't yet realized >>> is sitting at the bottom of your swimming pool, because your wifi is >>> down as well) being online. >> >> >> You don't need a special concept of an "inventory" to have a grid. >> For appearance, clients are already telling new simulators all 218 of >> their appearance parameters when they enter and giving them the >> location of your baked outfit textures. Having simulators temporarily >> host your baked textures (and implementing some mirorring in case on >> simulator drops offline, and requesting the client to rebake in a >> worst case scenario) would solve the appearance problem. As far as >> inventory goes, just make it files on your hard drive. When I sit >> down in an Internet cafe and fire up a browser I don't have an >> inventory on hand*, but I'm still able to use the web. >> >> "... storing inventory in a distributed manner..." sounds like a nice >> idea, but it is not essential to building a metaverse. It could be >> offered as a third party service instead of built in to the grid code. >> >> * Actually a lot of sites like Google homepage keep persistent >> settings for me, which is the equivalent of keeping some inventory on >> a single simulator. >> >> John Hurliman >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From lenglish5 at cox.net Sat Sep 8 16:24:08 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 16:24:10 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... Message-ID: <46E32F18.2070303@cox.net> I know that everyone wants HTML on a prim, but it seems to me that SVG on a prim, as a vector graphcis format, not a webpage format, would be ideal as a texture for SL. All you would need to do is disallow any URL reference except "local host" and define local host as the prim (or linkset) inventory and let it access notecards of a specific name in that inventory. A further refinement would be to allow LSL to be evoked by URLs defined in a given graphic. Those in turn could evoke webpages, of course, but that's not what the feature would be used for. Imagine huds with animated svg buttons and pictures that could evoke LSL callbacks in a given prim. The concept is so powerful, that it should be part of the viewer's own GUI, I think. Perhaps this would give us a scriptable GUI "for free" though I'm not sure how well SVG handles popdown menus and so on. From blindwanderer at gmail.com Sat Sep 8 17:29:14 2007 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sat Sep 8 17:29:17 2007 Subject: [sldev] Limiting the length of string inconsistently In-Reply-To: <46E2FD96.4020408@lindenlab.com> References: <7buJ7ds4dY7s8vdsbs04Gc8x.alissa_sabre@yahoo.co.jp> <46E2C418.7050403@cox.net> <46E2FD96.4020408@lindenlab.com> Message-ID: <89ca6da00709081729y52cafb7ape15d3e95e9856cf@mail.gmail.com> I prefer (c) as well, however annoying byte limits are (as compared to character limits) they better represent the underlying limitations. On 9/8/07, Kelly Linden wrote: > > First, for those that haven't looked, group notices are IMs. The path > of an IM looks something like: > > Viewer -(udp)-> Sim of sender *-(tcp)-> Sim of receiver -(udp)-> Viewer > | > *-(udp)-> Dataserver -(mysql)-> DB > > The dataserver is actually on the same host as the sim of the sender. > The key point here is that several pieces of this journey are UDP which > means we must contend with MTU. We are usually pretty conservative > about our MTU packet size, and 1200 bytes sounds about right once you > factor in the other meta data that travels with the message. > > There is a new system in place for each of the UDP steps above, but IMs > do not (yet) use them: > * For viewer -> sim there is the caps system > * For sim -> dataserver a key scaling project currently in progress is > to replace the dataserver with a set of light weight and scalable web > services. These use TCP/IP and not UDP. > * For sim -> viewer there is the 'event queue' > > You are right that none of these can be completed by open source devs > right now. The second one (dataserver) will get handled very soon, and > the other two may not be too difficult. However, until they are done > (and priorities being what they are I'm not sure the time table for > that) I think (b) or (c) are the viable options. I kind of prefer (c) > since it is more flexible and doesn't limit more than actually needed. > > - Kelly > > Lawson English wrote: > > Top-posting: this issue applies to just about any bit of UTF-8 text, > > including llSetText or any other text that has an arbitrarily short > > built-in limit. I haven't tested Japanese kanji with GUI elements like > > dialog text-entry, but I suspect it applies there as well. > > > > > > Alissa Sabre wrote: > >> I filed a new JIRA issue, VWR-2367. > >> > >> It is on the maximum message length of a Group Notice. The point is, > >> that, when editing the notice, the maximum length of the message is > >> limited by the number of _characters_. When the notice is sent, the > >> lower messaging layer checks the maximum length by the number of > >> _bytes_. > >> > >> When editing, the maximum length is 511 characters. The lower layer > >> limits the maximum by 1200 bytes (including some overheads). Since, > >> one Japanese character occupy three bytes in UTF-8, Japanese Group > >> Notice messages with more than about 400 characters are truncated when > >> sent. > >> > >> I can imagine three approaches to fix it. Which fix is best? I want > >> to know your opinions. > >> > >> (a) Extend the messaging maximum to cover the worst case maximum. > >> Because, a character can occupy four bytes in UTF-8 as a maximum, > >> 511 characters can be up to 2044 bytes. Enlarge the lower layer > >> limit to this value (plus some overhead.) > >> > >> (b) Reduce the UI (editing) limit to the value that is guaranteed to > >> pass the lower layer limit in worst case. That is 1200 (minus > >> some overhead) divided by four, i.e., around 250. > >> > >> (c) Add a feature to a UI component (LLTextEditor) to limit the > >> maximum size in bytes as opposed to in characters, and set that > >> limit to a value around 1000. > >> > >> If the way we should go is (b) or (c) above, I can write a fix. > >> However, if the correct fix is (a), I don't think it's doable by open > >> source developers, since I guess the server-side code should be > >> updated in sync. > >> > >> Alissa Sabre > >> -------------------------------------- > >> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > >> http://pr.mail.yahoo.co.jp/toolbar/ > >> > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > >> > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From alissa_sabre at yahoo.co.jp Sat Sep 8 17:36:32 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 8 17:36:46 2007 Subject: [sldev] [POLICY] New mailing list keywords posted In-Reply-To: <46E1E0B0.402@wsu.edu> References: <46E1E0B0.402@wsu.edu> Message-ID: <1kwLds8ev4fYJez7du9ds41Q.alissa_sabre@yahoo.co.jp> > Is there a tutorial somewhere on how to use a wiki for conversation? I don't know the tutorial, but just glancing at Wikipedia may be a help, because SL wiki and Wikipedia share a same platform, MediaWiki. On MediaWiki, the general understanding is that the discussion should be on the discussion (or talk) pages. Article pages are not the place for the discussion, but for the conclusions (or, the latest proposal.) Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From kerdezixe at gmail.com Sat Sep 8 17:53:05 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Sep 8 17:53:08 2007 Subject: [sldev] Re: [META] Exciting reuter's post about OpenSim In-Reply-To: <46E3261A.5000000@wsu.edu> References: <20070908114020.1367D41B24B@stupor.lindenlab.com> <479C3E47-4A5F-40C5-B57B-FE38DB97735E@gmail.com> <46E3261A.5000000@wsu.edu> Message-ID: <8a1bfe660709081753s885c62fwa3a48f6ac96c21ae@mail.gmail.com> On 9/9/07, John Hurliman wrote: > > "... storing inventory in a distributed manner..." sounds like a nice > idea, but it is not essential to building a metaverse. It could be > offered as a third party service instead of built in to the grid code. > > * Actually a lot of sites like Google homepage keep persistent settings > for me, which is the equivalent of keeping some inventory on a single > simulator. The secondlife client is a thin client. For me, a simulator server is a thin server. Both shouldn't hold any critical data (such as content). This solution come with problems, but it's the best approach, imho. You also save a lot of money using the "thin server" approach. (no ECC memory, no raid, no redondent power, cheap maintenance, ...) And with the future of multi-multi-multi-core cpu, it will be event better. (1 memory, 1 network card, a lot of core with 1 sim per core). IBM and Sun have the same approach about hardware for virtual world. -- kerunix Flan From bboomslang at googlemail.com Sat Sep 8 18:32:09 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sat Sep 8 18:32:11 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <46E30A3F.6040208@cox.net> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> <46E30A3F.6040208@cox.net> Message-ID: <347b550f0709081832m15c21d2by579b0742e5a0b53c@mail.gmail.com> Hi, you just go to the build settings for the project and check the "only link essential symbols" there. bye, Barney On 9/8/07, Lawson English wrote: > Barney Boomslang wrote: > > [...] > > > > The third thing I noticed is that even with 1.18.3 the XCode project > > files build universal and deployment with all symbols linked and so > > produce monstrous executables - it's one click in the project file to > > only link essential symbols and get to the normal executable sizes, > > though. > > > > bye, Barney > > > > Thanks for the heads up concerning the JPEG2000 issues. RE: the compiler > flags, which ones are they? I'm a newbie to xCode, and I'm still wading > through _The xCode Book_. > > Thanks, > > Lawson > From lenglish5 at cox.net Sat Sep 8 18:45:53 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 18:45:53 2007 Subject: [VWR]Re: [sldev] Plugins Architecture In-Reply-To: <46E3270C.2050906@wsu.edu> References: <46E2D3B9.1070709@dzonux.net> <46E2D47E.80300@cox.net> <46E32367.7060203@wsu.edu> <46E325B0.2080503@cox.net> <46E3270C.2050906@wsu.edu> Message-ID: <46E35051.2040506@cox.net> John Hurliman wrote: > Lawson English wrote: >> John Hurliman wrote: >>> Lawson English wrote: >>>> Dzonatas wrote: >>>>> The closest we have to this is the binary plug-ins as posted about >>>>> earlier on this list. >>>>> >>>>> A more dynamic model may have finally been agreed upon based on >>>>> python and mono extensions. Python is already available, as in >>>>> under approved licenses and a ready module, to add into the >>>>> viewer. It just needs hooks to make it active. >>>> Many people prefer Lua to python for simple scripting purposes. The >>>> WoW GUI uses it for scripting, for instance. >>>> >>>> I know of at least 3 people who are implementing their own client >>>> builds that use Lua. Not sure how many have started working on a >>>> client that uses Python. >>> >>> Anything that supports embedding Mono will be able to run IronPython >>> code. >> I know that mono support is the long-term plan for scripting. >> However, mono isn't available on the sims yet, letalone in the >> client. Some people are working on scripting solutions today, rather >> than 6-18 months from now. >> _______________________________________________ > > No one has ever said that Mono support is the long term plan for > client scripting. If you have a source for that please post it because > this is the first time I've heard that. Mono support on the simulators > has nothing at all to do with support in the client, and "some people" > are working on client scripting solutions based on Mono today. > Bryan O'Sullivan wrote: > Lawson English wrote: >> Is there a design team or thread for how to add scripting to the >> client, ala Lua and/or Python and/or Perl etc? > > We're in the early stages of kicking this idea around internally. As > you might know, we're going to switch to Mono for LSL scripting on the > server side; that's overwhelmingly likely to be the direction we'll > take on the viewer side, too, because of its multilingual capabilities. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Sat Sep 8 18:47:54 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 18:47:55 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <347b550f0709081832m15c21d2by579b0742e5a0b53c@mail.gmail.com> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> <46E30A3F.6040208@cox.net> <347b550f0709081832m15c21d2by579b0742e5a0b53c@mail.gmail.com> Message-ID: <46E350CA.5090203@cox.net> Barney Boomslang wrote: > Hi, > > you just go to the build settings for the project and check the "only > link essential symbols" there. > [...] > >> Thanks for the heads up concerning the JPEG2000 issues. RE: the compiler >> flags, which ones are they? I'm a newbie to xCode, and I'm still wading >> through _The xCode Book_. >> >> Thanks, >> >> Lawson >> >> > > Thanks. L. From alissa_sabre at yahoo.co.jp Sat Sep 8 18:49:11 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 8 18:49:24 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <46E2C715.40000@cox.net> References: <46E2C715.40000@cox.net> Message-ID: <1s37ds4dtkds4e14e0ddY90m.alissa_sabre@yahoo.co.jp> > I wonder how many people are using Macs to write patches? I'm doing. Mine is an Intel Mac mini, not PowerPC, however. > The "Development" target, designed to facilitate > debugging, causes runtime errors at the lanuch of the client, so I have > to use the "Deployment" target instead. If you experience the error 100%, I'm not having the issue. Development target generally works fine for me. It sometimes crushes (1 out of 10 runs, or something like that) if I run the Development binary under gdb. I filed the issue as VWR-2190. > The second one is a killer, > I'll submit a jira with the screenshots of both the pre-built and > home-built versions. If any Mac developer wants a copy of the ant, I can > send it to them for testing. I want that object for testing. If you are OK, I think it's better to put that object somewhere in-world and include the slurl to the object in your JIRA filing. Ah! Somewhere in Hippotropolis should be good for the purpose. I'm happy to provide some of my fief for the pupose. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Sat Sep 8 19:12:19 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 8 19:12:26 2007 Subject: [sldev] [META] Exciting reuter's post about OpenSim In-Reply-To: <20070909002917.D9E8041B122@stupor.lindenlab.com> References: <20070909002917.D9E8041B122@stupor.lindenlab.com> Message-ID: <791FF44D-FADC-4E68-86A2-988F9E6E1167@gmail.com> > You don't need a special concept of an "inventory" to have a grid. That's fine for people who don't mind playing as "Ruth", but without either a much more sophisticated avatar model or the ability to have my attachments available, I can't present myself in-world as I want to. I might as well be in There or Warcrack. Second Life or Open Sim, without inventory it loses most of its attraction. > "... storing inventory in a distributed manner..." sounds like a nice > idea, but it is not essential to building a metaverse. It could be > offered as a third party service instead of built in to the grid code. It's the biggest shortcoming of OpenSim for me, so big that it hadn't even occurred to me that anyone would neglect it. :) And it's not particularly difficult. We already have a distributed data store that, for any given person, can be as reliable as they're willing to make it. Hint: instead of identifying an object/ texture/... by a UUID, you identify it by a URL. You whole inventory could be a URL for a directory. To rez something in world. the sim would fetch that URL, generate a UUID for its cached copy, and send that out. When you move on to the next sim, it could pass the cached copy over, so it maintains its state. From lenglish5 at cox.net Sat Sep 8 19:12:45 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 19:12:47 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <1s37ds4dtkds4e14e0ddY90m.alissa_sabre@yahoo.co.jp> References: <46E2C715.40000@cox.net> <1s37ds4dtkds4e14e0ddY90m.alissa_sabre@yahoo.co.jp> Message-ID: <46E3569D.9020509@cox.net> Alissa Sabre wrote: >> I wonder how many people are using Macs to write patches? >> > > I'm doing. > > Mine is an Intel Mac mini, not PowerPC, however. > > >> The "Development" target, designed to facilitate >> debugging, causes runtime errors at the lanuch of the client, so I have >> to use the "Deployment" target instead. >> > > If you experience the error 100%, I'm not having the issue. > Development target generally works fine for me. It sometimes crushes > (1 out of 10 runs, or something like that) if I run the Development > binary under gdb. I filed the issue as VWR-2190. > > Thanks for the reference. Mine is 100% though. G5 not intel. >> The second one is a killer, >> > > >> I'll submit a jira with the screenshots of both the pre-built and >> home-built versions. If any Mac developer wants a copy of the ant, I can >> send it to them for testing. >> > > I want that object for testing. > > Others in this thread say its a known problem but... > If you are OK, I think it's better to put that object somewhere > in-world and include the slurl to the object in your JIRA filing. > > Ah! Somewhere in Hippotropolis should be good for the purpose. I'm > happy to provide some of my fief for the pupose. > -------------------------------------- > I'll leave it on your land, or send you a copy. It has full permissions for modding. Someone has already made a stab at an avatar using it, and a pet ant should be a fun thing. Been meaning to animate it but haven't gotten around to it. It should be used more often throughout the world, IMHO, but the no-mod version has made that more difficult to do. From seg at haxxed.com Sat Sep 8 19:23:41 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 8 19:23:49 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E32F18.2070303@cox.net> References: <46E32F18.2070303@cox.net> Message-ID: <1189304621.2798.242.camel@localhost> On Sat, 2007-09-08 at 16:24 -0700, Lawson English wrote: > I know that everyone wants HTML on a prim, but it seems to me that SVG > on a prim, as a vector graphcis format, not a webpage format, would be > ideal as a texture for SL. This would take about 5 minutes of coding, using librsvg. Seriously. (Not counting the fact we can't mod the grid. How much checking do the asset servers do on uploads, anyway...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070908/24be7a17/attachment.pgp From gigstaggart at gmail.com Sat Sep 8 20:26:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Sep 8 20:27:22 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <1189304621.2798.242.camel@localhost> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> Message-ID: <46E36801.3030307@gmail.com> Callum Lerwick wrote: > On Sat, 2007-09-08 at 16:24 -0700, Lawson English wrote: >> I know that everyone wants HTML on a prim, but it seems to me that SVG >> on a prim, as a vector graphcis format, not a webpage format, would be >> ideal as a texture for SL. > > This would take about 5 minutes of coding, using librsvg. > > Seriously. > > (Not counting the fact we can't mod the grid. How much checking do the > asset servers do on uploads, anyway...) Yes, this is something I've been pimping for a long time. It's one of the main reason I'm pushing for some kind of extensible data from the servers, so the open source community can go ahead and just write SVG on a prim and send it to LL as a complete package. A 3D metaverse is fine, but INFORMATION is largely still 2D. Some kind of dynamic vector texturing on a prim to allow for 2D information and algorithmic graphical presentation would be a huge boon, and really push SL to the next level. We can't be bigger than the web if all we have a pretty raster statically textured prims to look at! -Jason From jhurliman at wsu.edu Sat Sep 8 20:31:03 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Sep 8 20:31:12 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <1189304621.2798.242.camel@localhost> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> Message-ID: <46E368F7.70008@wsu.edu> Callum Lerwick wrote: > On Sat, 2007-09-08 at 16:24 -0700, Lawson English wrote: > >> I know that everyone wants HTML on a prim, but it seems to me that SVG >> on a prim, as a vector graphcis format, not a webpage format, would be >> ideal as a texture for SL. >> > > This would take about 5 minutes of coding, using librsvg. > > Seriously. > > (Not counting the fact we can't mod the grid. How much checking do the > asset servers do on uploads, anyway...) > > ------------------------------------------------------------------------ There is no need to modify the grid to do this. I have made specialty prims similar to this for commercial projects (not using SVG though), and while it would be much easier with Qarl's custom attributes bits it is still possible with what we have today. I think the "we can't do anything unless you rewrite the grid" meme was started by people who lack imagination. To answer your question about asset uploads, some of the asset types do either no checking or very minimal checking and it is trivial to embed custom data. If you have specific questions about any of it contact me off-list as I'm not sure uploading arbitrary assets and mangling prim data are on-topic for the list, though I would really like to see a custom client with SVG support. John Hurliman From labrat.hb at gmail.com Sat Sep 8 20:38:50 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sat Sep 8 20:38:55 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E368F7.70008@wsu.edu> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> <46E368F7.70008@wsu.edu> Message-ID: On 9/8/07, John Hurliman wrote: > > > trivial to embed custom data. If you have specific questions about any > of it contact me off-list as I'm not sure uploading arbitrary assets and > mangling prim data are on-topic for the list, though I would really like > to see a custom client with SVG support. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev And once again for the whole list..... I for one would hate for discussions of this sort to get dragged off into secrecy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070908/d7658ee6/attachment.htm From lenglish5 at cox.net Sat Sep 8 23:27:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 8 23:27:50 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> <46E368F7.70008@wsu.edu> Message-ID: <46E39265.6050405@cox.net> Harold Brown wrote: > > > On 9/8/07, *John Hurliman* > wrote: > > > trivial to embed custom data. If you have specific questions about any > of it contact me off-list as I'm not sure uploading arbitrary > assets and > mangling prim data are on-topic for the list, though I would > really like > to see a custom client with SVG support. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > And once again for the whole list..... > > > > I for one would hate for discussions of this sort to get dragged off > into secrecy. I see no reason why it should be anyway. SVG on a prim, assuming that no webaccess is allowed via URLs, should be relatively trivial to implement. Its possible that some threading issue might make it a tad more difficult, but still, compared to adding voice, or revising the design the viewer to sit on a real GUI g\framework, it should be trivial. And it would open up a LOT of new possibilities for education and so on. a version of it that would allow setting svg via LSL functions as well as by reference to notecards, would give you the long-sought-after interactive text on a prim, though the scripted version would need to be limited in its size and complexity. Maybe not more than 512 bytes or 1K bytes of svg code per face to be stored in custom prim properties... From labrat.hb at gmail.com Sat Sep 8 23:46:11 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sat Sep 8 23:46:13 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E39265.6050405@cox.net> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> <46E368F7.70008@wsu.edu> <46E39265.6050405@cox.net> Message-ID: John was talking about implementing something now... without dealing with having server side changes made by LL's to support it. What you're discussing will need commitment by LL's to implement. Hence his reason for wishing to take it off list as it would be using prim data and asset storage in ways that they are currently not intended. Like perhapse uploading an SVG file as an uncompressed image file. Or some other asset type that isn't verrified by the server. On 9/8/07, Lawson English wrote: > > Harold Brown wrote: > > > > > > On 9/8/07, *John Hurliman* > > wrote: > > > > > > trivial to embed custom data. If you have specific questions about > any > > of it contact me off-list as I'm not sure uploading arbitrary > > assets and > > mangling prim data are on-topic for the list, though I would > > really like > > to see a custom client with SVG support. > > > > John Hurliman > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > And once again for the whole list..... > > > > > > > > I for one would hate for discussions of this sort to get dragged off > > into secrecy. > I see no reason why it should be anyway. SVG on a prim, assuming that no > webaccess is allowed via URLs, should be relatively trivial to > implement. Its possible that some threading issue might make it a tad > more difficult, but still, compared to adding voice, or revising the > design the viewer to sit on a real GUI g\framework, it should be trivial. > > And it would open up a LOT of new possibilities for education and so on. > a version of it that would allow setting svg via LSL functions as well > as by reference to notecards, would give you the long-sought-after > interactive text on a prim, though the scripted version would need to be > limited in its size and complexity. Maybe not more than 512 bytes or 1K > bytes of svg code per face to be stored in custom prim properties... > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070908/de4cb34b/attachment.htm From alissa_sabre at yahoo.co.jp Sun Sep 9 05:45:42 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun Sep 9 05:45:50 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E32F18.2070303@cox.net> References: <46E32F18.2070303@cox.net> Message-ID: <1kw7fd4eY68xwwQJ4L5cc5s.alissa_sabre@yahoo.co.jp> > I know that everyone wants HTML on a prim No. You are wrong. I don't want it, at least. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From dale at daleglass.net Sun Sep 9 05:56:16 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Sep 9 05:56:33 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: References: <46E32F18.2070303@cox.net> <46E39265.6050405@cox.net> Message-ID: <200709091456.22541.dale@daleglass.net> On Sunday 09 September 2007 08:46:11 Harold Brown wrote: > John was talking about implementing something now... without dealing > with having server side changes made by LL's to support it. > > What you're discussing will need commitment by LL's to implement. > > Hence his reason for wishing to take it off list as it would be using > prim data and asset storage in ways that they are currently not > intended. > > Like perhapse uploading an SVG file as an uncompressed image file. Or > some other asset type that isn't verrified by the server. > If you want to take this off-list, try mine: http://lists.daleglass.net/listinfo.cgi/sldev-misc-daleglass.net It's precisely the sort of thing I was thinking of when I made it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070909/bd7fd22c/attachment.pgp From lenglish5 at cox.net Sun Sep 9 06:37:21 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 9 06:37:23 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI Message-ID: <46E3F711.2000700@cox.net> I'm trying to devise a simple floater interface for my next project (keyword floater for LSL) and I noticed that clipping for the GUI appears to be a cooperative affair, rather than enforced by the view hierarchy of a given floater. Is this because OpenGL's clipping routines are slow/inappropriate for GUI development without a lot of work, or merely a legacy of SL's haphazard development history? I'm asking because I'm used to a GUI framework enforcing a bit of discipline on what is drawn on the screen where and it is disconcerting to see buttons moving in all directions at random on the screen outside the parent window if you get a flag or xml parameter wrong. In the long run, if possible, I think that the GUI needs to be revised from top to bottom in order to enforce a traditional GUI view hierarchy, including inherited clipping rectangles and even regions. I can see no reason why we can't have round windows if we want them for some purpose. Certainly, if the client-world interface converges the way I think it could (and probably should), I can foresee plenty of situations where the interface should be more organic in appearance which would require "windows" that have no set-in-stone shape, and a clip-view-hierarchy would be far more important in such a situation. From lenglish5 at cox.net Sun Sep 9 06:59:17 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 9 06:59:19 2007 Subject: [sldev] [VIEWER] GUI xml documentation and/or insights Message-ID: <46E3FC35.4000503@cox.net> So... how many have managed to figure out how the various xml GUI elements work? How does one work with the xml template for the LLScrollListCtrl class, for example (that being what I'm trying to work with right now)? Is there a central location for this info? Are the Lindens required to parse the xml files and decipher what a given GUI thingie does, or is there some notes available internally that give them hints? If the former, why don't they keep notes? If the latter why aren't they available to the rest of us? And regardless, why aren't there categories for contributing the missing documentation listed in the wiki? Early morning frustrations. Lawson From seg at haxxed.com Sun Sep 9 09:57:42 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 9 09:57:45 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <46E3F711.2000700@cox.net> References: <46E3F711.2000700@cox.net> Message-ID: <1189357062.4289.7.camel@localhost> On Sun, 2007-09-09 at 06:37 -0700, Lawson English wrote: > In the long run, if possible, I think that the GUI needs to be revised > from top to bottom in order to enforce a traditional GUI view hierarchy, > including inherited clipping rectangles and even regions. I can see no > reason why we can't have round windows if we want them for some purpose. > Certainly, if the client-world interface converges the way I think it > could (and probably should), I can foresee plenty of situations where > the interface should be more organic in appearance which would require > "windows" that have no set-in-stone shape, and a clip-view-hierarchy > would be far more important in such a situation. I'd like to see slviewer use Cairo for... well every last thing it possibly can. Rendering GUI widgets and, hey... maybe Cairo can solve all our text rendering problems! http://cairographics.org/ http://cairographics.org/samples/ And the whiz-bang OpenGL example page: http://cairographics.org/OpenGL/ Cairo's text rendering is based on Pango: http://www.pango.org/ Which nicely wraps the use of native fonts on Window and OSX, and fontconfig on X11. I'd put code where my mouth is on this but I'm really doing plenty of that as it is. :) (OpenJPEG, OpenAL...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070909/d51a360a/attachment.pgp From robla at lindenlab.com Sun Sep 9 10:26:07 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Sep 9 10:26:15 2007 Subject: [sldev] [VIEWER] GUI xml documentation and/or insights In-Reply-To: <46E3FC35.4000503@cox.net> References: <46E3FC35.4000503@cox.net> Message-ID: <46E42CAF.5060308@lindenlab.com> On 9/9/07 6:59 AM, Lawson English wrote: > So... how many have managed to figure out how the various xml GUI > elements work? How does one work with the xml template for the > LLScrollListCtrl class, for example (that being what I'm trying to > work with right now)? The info we have now is here: https://wiki.secondlife.com/wiki/Linguistic_QA_with_the_Second_Life_Viewer ...but that's probably not what you're looking for. Better documentation is on the roadmap: https://wiki.secondlife.com/wiki/User_Interface_Roadmap > Is there a central location for this info? Are the Lindens required to > parse the xml files and decipher what a given GUI thingie does, or is > there some notes available internally that give them hints? If the > former, why don't they keep notes? If the latter why aren't they > available to the rest of us? It's a relatively immature component of the system. > And regardless, why aren't there categories for contributing the > missing documentation listed in the wiki? Because you haven't created them ;-) Try this: https://wiki.secondlife.com/wiki/Viewer_architecture Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070909/567fe760/signature.pgp From lenglish5 at cox.net Sun Sep 9 10:26:34 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 9 10:26:38 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <1189357062.4289.7.camel@localhost> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> Message-ID: <46E42CCA.5060605@cox.net> Callum Lerwick wrote: > On Sun, 2007-09-09 at 06:37 -0700, Lawson English wrote: > >> In the long run, if possible, I think that the GUI needs to be revised >> from top to bottom in order to enforce a traditional GUI view hierarchy, >> including inherited clipping rectangles and even regions. I can see no >> reason why we can't have round windows if we want them for some purpose. >> Certainly, if the client-world interface converges the way I think it >> could (and probably should), I can foresee plenty of situations where >> the interface should be more organic in appearance which would require >> "windows" that have no set-in-stone shape, and a clip-view-hierarchy >> would be far more important in such a situation. >> > > I'd like to see slviewer use Cairo for... well every last thing it > possibly can. Rendering GUI widgets and, hey... maybe Cairo can solve > all our text rendering problems! > > http://cairographics.org/ > http://cairographics.org/samples/ > > And the whiz-bang OpenGL example page: > > http://cairographics.org/OpenGL/ > > Cairo's text rendering is based on Pango: > > http://www.pango.org/ > > Which nicely wraps the use of native fonts on Window and OSX, and > fontconfig on X11. > > I'd put code where my mouth is on this but I'm really doing plenty of > that as it is. :) (OpenJPEG, OpenAL...) > Cairo certainly seems useful, and it is crossplatform, open source, and so on. As a MacOS X user, I'm kinda uncomfortable with the lack of true ATSUI support, but Apple chose to orphan its superior font technology during the NeXT takeover (probably in return for support from Adobe in the backroom political battles) and if Apple won't support a technology, why should open source people who have probably never even heard of it? The fact that MacOS X support itself is an afterthought merely reflects market forces. AFterall, everyone knows that GTK is used by more consumers... ;-) ALl that aside, Cairo, DOES seem like a good thing to use. What specifically have been reasons why the LIndens aren't interested? Lack of resources? Lack of experience? Time and energy already spent on a different system? What does using Cairo give them that using OpenGL doesn't? Pango text-handlign is a separate issue, according to the website hype... From secret.argent at gmail.com Sun Sep 9 11:13:06 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 9 11:13:12 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <20070909135920.AC26041B040@stupor.lindenlab.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> Message-ID: <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> From: "Harold Brown" > John was talking about implementing something now... without > dealing with > having server side changes made by LL's to support it. > What you're discussing will need commitment by LL's to implement. The client can read a notecard. SVG is text and can be put in a notecard without any special handling... 'uploading' SVG would just be a shortcut for creating a new text notecard (something that would be useful anyway). A special UUID can be designated as "this UUID means look for a notecard called 'face$facenum.svg' in the prim". Another can be "this UUID means look at the description on this prim and interpret it as SVG". References in the SVG would be to notecards in the same prim. You don't need to play silly games with asset uploads to make this work. The trickiest thing I could see being reasonable to do might be to have the UUID on the face being the UUID of a notecard or prim, if the sim will let you get away with that. And even that seems a bit dodgy to me. Anyway, I would rather have something based on interfaces like this that almost certainly won't break than ones that can. PS: I agree with Alissa. I would rather not see HTML on a prim except as something like a new parcel media texture type. HTML is too expensive to render. From gigstaggart at gmail.com Sun Sep 9 17:14:49 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 9 17:15:09 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E39824.1070507@wsu.edu> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> <46E368F7.70008@wsu.edu> <46E37FD2.3090902@gmail.com> <46E39824.1070507@wsu.edu> Message-ID: <46E48C79.9090502@gmail.com> Here's an exchange between me and John that was meant for the list but went private due to my screwup. John Hurliman wrote: > Jason Giglio wrote: >> John Hurliman wrote: >>> There is no need to modify the grid to do this. I have made specialty >>> prims similar to this for commercial projects (not using SVG though), >>> and while it would be much easier with Qarl's custom attributes bits >>> it is still possible with what we have today. I think the "we can't >>> do anything unless you rewrite the grid" meme was started by people >>> who lack imagination. To answer your question about asset uploads, >>> some of the asset types do either no checking or very minimal >>> checking and it is trivial to embed custom data. If you have specific >>> questions about any of it contact me off-list as I'm not sure >>> uploading arbitrary assets and mangling prim data are on-topic for >>> the list, though I would really like to see a custom client with SVG >>> support. >>> >>> John Hurliman >> >> Jamming this information into a bogus texture isn't really what I'd >> call a "ready to go feature". >> >> Our goal should be making patches that LL can accept, not hacking our >> way through the system creating more "legacy misfeatures" like >> invisiprims. >> > > You can have whatever goal you want, my goal is to implement features > that clients request by the deadlines they request them, and it never > seems to coincide with the timeline LL has for proposed features. > >> If LL allows corrupt textures now and we start using them for this, >> then LL has to accept corrupt textures (or textures for faces that >> don't exist) forever. I don't think that situation benefits LL or us. > > I'm pretty sure they don't have to do anything at all, *especially* not > providing lifetime service for a third party feature. The grid changes > nearly every week and I am fixing libsecondlife or adding new feature > support to it every week to try and keep up. If a hack feature is > properly implemented as a real feature I definitely won't be > complaining, and it will likely take less time to update the code then > it does to write this e-mail. > >> >> We really need some kind of way to extend the service and jam some >> arbitrary data on the server (be it data meant for a prim face, or >> just plain asset data), for this stuff to really take off. >> >> We need this extensible framework. Anything less is just hacks and >> hurts everyone in the long run. >> >> -Jason > > I'm sorry if my hacks are hurting you or anyone, personally I think they > are serving as good proofs of concept. If we implement SVG on a prim > using non-standard methods, by the time Qarl's patch is live it will > only take a few minutes to modify the code and submit a patch to JIRA > instead of saying "ok lets get started on this now". > > (Feel free to CC this to the list if the personal reply was unintentional) > > John > From seg at haxxed.com Sun Sep 9 18:57:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 9 18:57:46 2007 Subject: [sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI... In-Reply-To: <46E48C79.9090502@gmail.com> References: <46E32F18.2070303@cox.net> <1189304621.2798.242.camel@localhost> <46E368F7.70008@wsu.edu> <46E37FD2.3090902@gmail.com> <46E39824.1070507@wsu.edu> <46E48C79.9090502@gmail.com> Message-ID: <1189389458.4289.8.camel@localhost> On Sun, 2007-09-09 at 20:14 -0400, Jason Giglio wrote: > Here's an exchange between me and John that was meant for the list but > went private due to my screwup. I strongly suggest bumping this thread over to Dale's sldev-misc list, if it continues. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070909/78e352c1/attachment.pgp From kerdezixe at gmail.com Sun Sep 9 19:31:53 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sun Sep 9 19:31:57 2007 Subject: [sldev] [META] Steam Hardware survey Message-ID: <8a1bfe660709091931h3de44fa9s77ed03d256852622@mail.gmail.com> yet another steam survey : http://www.steampowered.com/status/survey.html This survey began on May 30th, 2007. This page last updated: 8:01pm PST (04:01 GMT), August 21 2007 What's interesting here ? - Around 75% of users have less than 1GB of ram (which is the minimum to run SL, imho) - 75% are still single-core cpu. - NVidia > ATI - At least 52% of gfx card support Shader Model 3 - A insane amount of players run really outdated drivers. - A majority of players run 17" screen or less (wtf?!) - around 50% of pci-express cards - 1.19% of user have multi-GPU (with 95% of SLI and 5% of crossfire ... *LOL@ATI*) - 70% have 256MB or less of VRAM - 3.16% of multi-screen (i tought it was less than that) - 82% of card support 2x and 4x MSAA. (when will we have AA support in SL ? Forcing the driver to use AA isn't fun nor easy for a lot of ppl) - 70% of user have a microphone - 90% of Windows XP (steam don't run on Linux or MacOS X) - 2.31% of user support DirectX 10 (Vista + Gfx Card) - 99.36% support SSE - 84.76% support SSE2 My config for SL : - Q6600 Quadcore, 2.4Ghz overclocked at 3Ghz - 2GB RAM @1333Mhz - one 8800GTX 768MB overclocked at GTX Ultra speed - Windows Vista 32 bits, latest gfx drivers - 20" 4:3 screen @ 1400x1050 Tweaked NVidia driver (using nHancer) for SecondLife, all forced in the driver because SL doesn't support natively some of thoses features : 16x CSAA (8 color + 16 cv samples) 16x Anisitropic Filtering High Quality texture filtering -3.00 Forced negative LOD BIAS Forced DXT3 (im not sure it have any effect here) It could be nice to have the possibility to support natively thoses features in SL instead of playing with the driver registry. Maybe in the debug setting ? I can't play without AntiAliasing anymore, honnest, it's SO nicer :D I play at 1400x1050 Windowed, 0.875 UI Size, 128 to 196m draw distance. Average FPS 30~60. Up to ~150FPS. All details maximum (object, terrain, avatar, etc ...) PS : sorry if the keyword in subject is wrong, i can't find the list of keywords. -- Ker2x From rdw at lindenlab.com Sun Sep 9 21:09:35 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Sun Sep 9 21:09:48 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <46E42CCA.5060605@cox.net> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> <46E42CCA.5060605@cox.net> Message-ID: <46E4C37F.4070500@lindenlab.com> Lawson English wrote: > > ALl that aside, Cairo, DOES seem like a good thing to use. What > specifically have been reasons why the LIndens aren't interested? Lack > of resources? Lack of experience? Time and energy already spent on a > different system? > > What does using Cairo give them that using OpenGL doesn't? Pango > text-handlign is a separate issue, according to the website hype... All of the above, plus Cairo wasn't mature until very recently (read: less than four years ago). Shit, we still have our container classes from pre-STL days, as you may recall. It's really hard to justify replacing an entire subsystem with another, given that different subsystems are causing grid-wide problems and need to be fixed yesterday. :-) I love Cairo, FWIW. -RYaN From lenglish5 at cox.net Sun Sep 9 21:42:10 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 9 21:42:11 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <46E4C37F.4070500@lindenlab.com> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> <46E42CCA.5060605@cox.net> <46E4C37F.4070500@lindenlab.com> Message-ID: <46E4CB22.4010503@cox.net> Ryan Williams (Which) wrote: > Lawson English wrote: > >> ALl that aside, Cairo, DOES seem like a good thing to use. What >> specifically have been reasons why the LIndens aren't interested? Lack >> of resources? Lack of experience? Time and energy already spent on a >> different system? >> >> What does using Cairo give them that using OpenGL doesn't? Pango >> text-handlign is a separate issue, according to the website hype... >> > All of the above, plus Cairo wasn't mature until very recently (read: > less than four years ago). Shit, we still have our container classes > from pre-STL days, as you may recall. It's really hard to justify > replacing an entire subsystem with another, given that different > subsystems are causing grid-wide problems and need to be fixed > yesterday. :-) > > I love Cairo, FWIW. > I don't see that using Cairo gains anything over raw OpenGL calls at this point. Pango would be another issue, but last I read it wasn't mature on Macs, which is silly, given that Apple was a major investor in Adobe, launched the DTP industry, etc., so a cross-platform text-handling system that cant work on Macs is a joke in my eyes. Assuming that Pango works equally well on all three OS's, I'd vote for using it to replace what SL uses currently. The clip-rect issue should be fixable, but I'm not sure how easily. My *intuition* suggests that fixing it at the lowest level of the framework-hierarchy should percolate throughout the entire hierarchy with minimal rewrites, but, in every case thus far, my intuition about the SL framework has been proven horribly wrong. Every single case. :-( From seg at haxxed.com Sun Sep 9 21:51:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 9 21:51:43 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <46E4CB22.4010503@cox.net> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> <46E42CCA.5060605@cox.net> <46E4C37F.4070500@lindenlab.com> <46E4CB22.4010503@cox.net> Message-ID: <1189399892.4289.18.camel@localhost> On Sun, 2007-09-09 at 21:42 -0700, Lawson English wrote: > I don't see that using Cairo gains anything over raw OpenGL calls at > this point. The idea would be that this would make it easy to render NOT using OpenGL. And flip back and forth between the two, like say when going fullscreen. For a start, I'd really like the giant map window to NOT cover up the 3D view, and be an independent window. Rendering it with Cairo would make it easy to render without OpenGL. But given that desktop-wide OpenGL based rendering seems to be the future, maybe we don't need to bother. Just open up another OpenGL window. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070909/a535c791/attachment.pgp From robla at lindenlab.com Mon Sep 10 00:11:16 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Sep 10 00:11:25 2007 Subject: [sldev] Updated snapshots of several branches on svn.secondlife.com Message-ID: <46E4EE14.6050304@lindenlab.com> Hi all, In order to better tease out the different type of maintenance fixes we typically do, we've split up our internal maintenance branch into several branches: * maint-ui o UI specific maintenance tasks * maint-renderA o Render specific maintenance tasks * maint-viewer o Other viewer only maintenance tasks o e.g. viewer crashes, audio, misc * maintenance o Tasks that involve server-side changes o Tasks that affect shared viewer / server libraries o Tasks that in any way affect messaging Details for this will be here: https://wiki.secondlife.com/wiki/Source_branches Snapshots of these branches will be published periodically, with most showing up tonight (except for maint-render, which hasn't seen any real action yet). I just published snapshots for maint-ui, maint-viewer, maintenance, release, and Branch_1-18-3-Viewer at svn.secondlife.com Details about using svn.secondlife.com are available here: https://wiki.secondlife.com/wiki/Subversion Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/2c30e980/signature.pgp From lenglish5 at cox.net Mon Sep 10 00:40:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 00:40:50 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <1189399892.4289.18.camel@localhost> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> <46E42CCA.5060605@cox.net> <46E4C37F.4070500@lindenlab.com> <46E4CB22.4010503@cox.net> <1189399892.4289.18.camel@localhost> Message-ID: <46E4F501.8070605@cox.net> Callum Lerwick wrote: > On Sun, 2007-09-09 at 21:42 -0700, Lawson English wrote: > >> I don't see that using Cairo gains anything over raw OpenGL calls at >> this point. >> > > The idea would be that this would make it easy to render NOT using > OpenGL. And flip back and forth between the two, like say when going > fullscreen. > > For a start, I'd really like the giant map window to NOT cover up the 3D > view, and be an independent window. Rendering it with Cairo would make > it easy to render without OpenGL. > > But given that desktop-wide OpenGL based rendering seems to be the > future, maybe we don't need to bother. Just open up another OpenGL > window. > Are things that different between Macs and PC's? The Map window on the Mac is resizeable and moveable. Isn't it that way on the PC? From corax at ravenscall.net Mon Sep 10 08:05:18 2007 From: corax at ravenscall.net (Corax) Date: Mon Sep 10 07:52:44 2007 Subject: [sldev] [META] Steam Hardware survey In-Reply-To: <8a1bfe660709091931h3de44fa9s77ed03d256852622@mail.gmail.com> References: <8a1bfe660709091931h3de44fa9s77ed03d256852622@mail.gmail.com> Message-ID: <46E55D2E.6050209@ravenscall.net> Laurent Laborde wrote: > My config for SL : > - Q6600 Quadcore, 2.4Ghz overclocked at 3Ghz > - 2GB RAM @1333Mhz > - one 8800GTX 768MB overclocked at GTX Ultra speed > - Windows Vista 32 bits, latest gfx drivers > - 20" 4:3 screen @ 1400x1050 > > Tweaked NVidia driver (using nHancer) for SecondLife, all forced in > the driver because SL doesn't support natively some of thoses features > : > 16x CSAA (8 color + 16 cv samples) > 16x Anisitropic Filtering > High Quality texture filtering > -3.00 Forced negative LOD BIAS > Forced DXT3 (im not sure it have any effect here) > > It could be nice to have the possibility to support natively thoses > features in SL instead of playing with the driver registry. Maybe in > the debug setting ? > I can't play without AntiAliasing anymore, honnest, it's SO nicer :D > > I play at 1400x1050 Windowed, 0.875 UI Size, 128 to 196m draw distance. > Average FPS 30~60. Up to ~150FPS. > All details maximum (object, terrain, avatar, etc ...) > And now for the opposite perspective... PIII 866 512M pc133 sdram Geforce2 64M, AGP 2x Linux LFS 6.1.1 compiled with PIII optimizations 17" CRT @ 1024x768, 32bpp Standard Linux Nvidia "legacy" driver I run SL windowed and maximized, 64-128 draw distance depending on location. Frame rate varies from about 30 max (no objects in view) down to about 0.4 with average running around 5. All details medium. The more objects there are within my draw distance, the slower my frame rate. Some locations are pretty much unusable due to low frame rates (<1) and ping times of up to 10 seconds. One thing about my system, I notice even the slightest improvement made! Corax From secret.argent at gmail.com Mon Sep 10 08:42:05 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 10 08:42:12 2007 Subject: [sldev] Re: [META] OpenGL clipping in the GUI In-Reply-To: <20070910145247.D20BA41B04D@stupor.lindenlab.com> References: <20070910145247.D20BA41B04D@stupor.lindenlab.com> Message-ID: <325EA120-46A1-401A-9887-D4ADD1BE3098@gmail.com> From: Lawson English > I don't see that using Cairo gains anything over raw OpenGL calls at > this point. Pango would be another issue, but last I read it wasn't > mature on Macs, which is silly, given that Apple was a major > investor in > Adobe, launched the DTP industry, etc., so a cross-platform > text-handling system that cant work on Macs is a joke in my eyes. Adobe has kicked Apple in the privates on more than one occasion. They almost killed Rhapsody two ways, and dragged their heels on the Intel port of Photoshop despite having gotten a clear message from Apple that the classic Mac OS API was headed for the dumpster back in 1997. So don't expect more than minimal Mac support from Adobe on *anything*. [note tag change] From secret.argent at gmail.com Mon Sep 10 08:46:49 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 10 08:46:53 2007 Subject: [sldev] Re: Updated snapshots of several branches on svn.secondlife.com In-Reply-To: <20070910145247.D20BA41B04D@stupor.lindenlab.com> References: <20070910145247.D20BA41B04D@stupor.lindenlab.com> Message-ID: <197DD203-C427-4CD3-85B0-BD881FCAC476@gmail.com> Rob Lanhier writes: > Details about using svn.secondlife.com are available here: > https://wiki.secondlife.com/wiki/Subversion I have not been able to make a connection to SVN using a proxy yet... for some reason SVN requires extensions to HTTP that are not commonly supported. Is it possible to get it to stick to GET/POST/CONNECT or to listen on a high port? From alissa_sabre at yahoo.co.jp Mon Sep 10 09:11:50 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Sep 10 09:12:04 2007 Subject: Japanese bugs, was Re: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <46E03A94.3040309@lindenlab.com> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> <46E03A94.3040309@lindenlab.com> Message-ID: <2YozYoPrk8rr8rk8rkPrrn1.alissa_sabre@yahoo.co.jp> For those who may concern, > I'll take a look at your patch. I updated my patch. It is available as an attachment to VWR-250. Patched binary is also available as always: For Windows: http://alissa-sabre.cocolog-nifty.com/files/IME-20070909-Win32.zip For MacOS: http://alissa-sabre.cocolog-nifty.com/files/ime-20070909-Mac.zip * VWR-250 is on improvement of Chinese/Japanese/Korean input. > I did some of the same work on > positioning the IME input where the text carat is located in text fields > and editors. I haven't submitted the code yet as it's only partially > working - it won't follow the field around correctly if you drag a > floating window. I don't think you can do it (i.e., candidate window follows the moving of the SL (LLUI) window) on MacOS. I want to know the technique if you can. My solution is to fix (or confirm or commit, whichever terminology you prefer) the preedit (or active input or composition) before the LLUI window is about to move. (That's why I needed yet another onFocusLost callback, if you remember. My latest version is based on the Richard's suggestion.) Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From seg at haxxed.com Mon Sep 10 09:13:42 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 09:13:50 2007 Subject: [sldev] [META] Steam Hardware survey In-Reply-To: <46E55D2E.6050209@ravenscall.net> References: <8a1bfe660709091931h3de44fa9s77ed03d256852622@mail.gmail.com> <46E55D2E.6050209@ravenscall.net> Message-ID: <1189440822.4289.49.camel@localhost> On Mon, 2007-09-10 at 11:05 -0400, Corax wrote: > One thing about my system, I notice even the slightest improvement made! A pet peeve of mine. The programmers being paid, are paid well enough that they can buy the latest, shiny-est hardware and/or are provided with it. So they happily write volumes of code on their shiny hardware, and never test it on anything the average non-programmer has. (Or a not well paid programmer ;P) And it inevitably runs like crap. I've made a point of, at the very least, testing every OpenJPEG patch I make on both my fastest machine, a "mere" Athlon 64 3000+, and a fairly low end machine, at least by SL standards, my mobile Celeron 1.3. (P3 based) If it hurts performance on the Celeron, its no good. A tiny change to the way memory is accessed can make a huge difference on a Celeron, which have tiny caches by definition, but won't make a lick of difference on an Athlon, known for their ample L1 caches. Murphy's law being what it is, a programmer not carefully testing on a Celeron will inevitably write code that thrashes the cache horribly, eats up gigs of ram, and they will never notice it on their 8gb Quad Extreme Athlon X2 Core 2 Trio whatever-the-hell. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/c824eaeb/attachment.pgp From rdw at lindenlab.com Mon Sep 10 09:29:29 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Sep 10 09:29:32 2007 Subject: [sldev] Re: Updated snapshots of several branches on svn.secondlife.com In-Reply-To: <197DD203-C427-4CD3-85B0-BD881FCAC476@gmail.com> References: <20070910145247.D20BA41B04D@stupor.lindenlab.com> <197DD203-C427-4CD3-85B0-BD881FCAC476@gmail.com> Message-ID: <46E570E9.8060803@lindenlab.com> Argent Stonecutter wrote: > Rob Lanhier writes: >> Details about using svn.secondlife.com are available here: >> https://wiki.secondlife.com/wiki/Subversion > > I have not been able to make a connection to SVN using a proxy yet... > for some reason SVN requires extensions to HTTP that are not commonly > supported. Is it possible to get it to stick to GET/POST/CONNECT or to > listen on a high port? > Have you checked this out: http://subversion.tigris.org/faq.html#proxy ? It'll mostly help you if you can fiddle with the configuration of your proxy. -RYaN From alissa_sabre at yahoo.co.jp Mon Sep 10 09:35:51 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Sep 10 09:36:11 2007 Subject: [sldev] [VIEWER] GUI xml documentation and/or insights In-Reply-To: <46E42CAF.5060308@lindenlab.com> References: <46E42CAF.5060308@lindenlab.com> Message-ID: <74s2mdscdsee06dsdnaxe04e.alissa_sabre@yahoo.co.jp> Rob, I have a question. > The info we have now is here: > https://wiki.secondlife.com/wiki/Linguistic_QA_with_the_Second_Life_Viewer This page redirects to another page "How to Localize Your World". The page says LL welcomes residents' UI translation to other languages. However, during an internationalization triage on 2007-07-27, Jaime Linden said that LL doesn't accept translations for new languages until skinning project is done. (See http://wiki.secondlife.com/wiki/Bug_triage/2007-07-27/Transcript#Feature_Request_Patches) The wiki page discusses skinning project and suggests a possibility to wait for it, but the overall tone of the page seems encouraging translations. Are you accepting new language translations now or you are not? If you are, why early efforts such as Swedish (VWR-774) and Traditional Chinese (VWR-1293) are just left? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From lynnewu.public at gmail.com Mon Sep 10 09:40:17 2007 From: lynnewu.public at gmail.com (Lynne Wu) Date: Mon Sep 10 09:40:19 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> Message-ID: <46E57371.70201@gmail.com> Why is it too expensive to render? Cycles? Resources? Is http://www.ubrowser.com not a realistic interpretation of this idea? Thanks Argent Stonecutter wrote: > ... > > PS: I agree with Alissa. I would rather not see HTML on a prim except > as something like a new parcel media texture type. HTML is too > expensive to render. > From seg at haxxed.com Mon Sep 10 09:49:05 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 09:49:07 2007 Subject: [sldev] Second Life Open Source Enforcement Agency Message-ID: <1189442945.4289.65.camel@localhost> I hereby appoint myself OpenJPEG Czar of the Second Life Open Source Enforcement Agency. (SLOSEA?) Anyone got a problem with that? :) Now that OpenJPEG is up to what I feel is an acceptable level of performance, (though getting it all upstream is still ongoing) I am broadening my mission to achieving 100% stability. My first act as OpenJPEG Czar is VWR-2383: http://jira.secondlife.com/browse/VWR-2383 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/48183c04/attachment.pgp From lenglish5 at cox.net Mon Sep 10 09:57:36 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 09:57:41 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <46E57371.70201@gmail.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <46E57371.70201@gmail.com> Message-ID: <46E57780.7030002@cox.net> Lynne Wu wrote: > Why is it too expensive to render? Cycles? Resources? Is > http://www.ubrowser.com not a realistic interpretation of this idea? > Thanks > > Argent Stonecutter wrote: >> ... >> >> PS: I agree with Alissa. I would rather not see HTML on a prim except >> as something like a new parcel media texture type. HTML is too >> expensive to render. >> There are ill-formed webpages that can bring most browsers (any browser?) to its knees. Imagine if someone used such a webpage as a live texture and rezzed them all over a sim. I'm sure the same kind of thing could happen with an SVG file, but you could test for infinite loop timeouts and the like easier in a closed system like svg with no web access, as opposed to an open html browser. From lenglish5 at cox.net Mon Sep 10 10:01:35 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 10:01:35 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <46E57371.70201@gmail.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <46E57371.70201@gmail.com> Message-ID: <46E5786F.8030007@cox.net> Lynne Wu wrote: > Why is it too expensive to render? Cycles? Resources? Is > http://www.ubrowser.com not a realistic interpretation of this idea? > Thanks > > Argent Stonecutter wrote: >> ... >> >> PS: I agree with Alissa. I would rather not see HTML on a prim except >> as something like a new parcel media texture type. HTML is too >> expensive to render. >> XUL sounds like fun though. From nicholaz at blueflash.cc Mon Sep 10 10:08:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 10 10:08:56 2007 Subject: [sldev] Second Life Open Source Enforcement Agency In-Reply-To: <1189442945.4289.65.camel@localhost> References: <1189442945.4289.65.camel@localhost> Message-ID: <46E57A1A.1020304@blueflash.cc> His OpenJPEG Highness, just give me a bunch of source files to download and I'll make you a project file for VS2003/VS2005 and will code it into my viewers. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Callum Lerwick wrote: > I hereby appoint myself OpenJPEG Czar of the Second Life Open Source > Enforcement Agency. (SLOSEA?) Anyone got a problem with that? :) > > Now that OpenJPEG is up to what I feel is an acceptable level of > performance, (though getting it all upstream is still ongoing) I am > broadening my mission to achieving 100% stability. > > My first act as OpenJPEG Czar is VWR-2383: > > http://jira.secondlife.com/browse/VWR-2383 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sl at phoca.com Mon Sep 10 10:18:20 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Mon Sep 10 10:19:08 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> Message-ID: <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> Can't the prim just contain a note card of a special naming scheme and automatically read/apply it? Then absolutely NO sim/asset server intervention is required. Farallon ----- Original Message ----- From: "Argent Stonecutter" To: Sent: Sunday, September 09, 2007 11:13 AM Subject: [sldev] Re: [VIEWER] SVG on a prim > From: "Harold Brown" >> John was talking about implementing something now... without dealing >> with >> having server side changes made by LL's to support it. > >> What you're discussing will need commitment by LL's to implement. > > The client can read a notecard. SVG is text and can be put in a notecard > without any special handling... 'uploading' SVG would just be a shortcut > for creating a new text notecard (something that would be useful anyway). > A special UUID can be designated as "this UUID means look for a notecard > called 'face$facenum.svg' in the prim". Another can be "this UUID means > look at the description on this prim and interpret it as SVG". References > in the SVG would be to notecards in the same prim. You don't need to play > silly games with asset uploads to make this work. > > The trickiest thing I could see being reasonable to do might be to have > the UUID on the face being the UUID of a notecard or prim, if the sim > will let you get away with that. And even that seems a bit dodgy to me. > > Anyway, I would rather have something based on interfaces like this that > almost certainly won't break than ones that can. > > PS: I agree with Alissa. I would rather not see HTML on a prim except as > something like a new parcel media texture type. HTML is too expensive to > render. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kelly at lindenlab.com Mon Sep 10 11:05:14 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Mon Sep 10 11:05:18 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> Message-ID: <46E5875A.1080708@lindenlab.com> SL - Farallon Greyskin wrote: > Can't the prim just contain a note card of a special naming scheme and > automatically read/apply it? > > Then absolutely NO sim/asset server intervention is required. > > Farallon Object inventory is only sent to viewers when the object is selected, you do not automatically receive the contents of every object in view (or even of most). - Kelly From lenglish5 at cox.net Mon Sep 10 11:05:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 11:05:19 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> Message-ID: <46E5875B.70705@cox.net> SL - Farallon Greyskin wrote: > Can't the prim just contain a note card of a special naming scheme and > automatically read/apply it? > > Then absolutely NO sim/asset server intervention is required. > That would be too easy... There's already a multi-texture option, right? If the SVG$name$facenum.svg card exists, it would automatically overlay the existing texture specified by $facenum. Duplicate facenums would be ignored... The same could apply to an SVG$name$hovertext.svg card. These could be overridden by llSetSVG(cardname, facenum), where facenum would include -1 for hovertext, and -2 for ALL faces. -3 for hvertext + ALL faces? hmmm. overkill, but why not? L. From lenglish5 at cox.net Mon Sep 10 11:21:22 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 11:21:24 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <46E5875A.1080708@lindenlab.com> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <01235CC68FB9460EBE288AFAF06C1CB9@SanMiguel> <46E5875A.1080708@lindenlab.com> Message-ID: <46E58B22.3040200@cox.net> Kelly Linden wrote: > SL - Farallon Greyskin wrote: > >> Can't the prim just contain a note card of a special naming scheme and >> automatically read/apply it? >> >> Then absolutely NO sim/asset server intervention is required. >> >> Farallon >> > Object inventory is only sent to viewers when the object is selected, > you do not automatically receive the contents of every object in view > (or even of most). > > The way I interpreted his suggestion is that a notecard with a special name with is dealt with as possible svg code that is automatically used in the prim texture. Just drop the card in, and its dealt with as a call to llSetText is: it sets a prim property. Change the card/add a new card, and the property changes. The presence of the card: SVG$name$facenum.svg is dealt with as as an automatic call of this type: llSetSVG(cardname, facenum); where facenum 0-x sets it for an individual face, facenum -1 sets it for all faces facenum -2 sets it for hover text facenum -3 sets it for all faces + hover text. duplicate facenums in a card name are ignored. The call is made only once, unless/until the card is changed/deleted. A deletion means the next card with the same facenum is used. explict facenums >= 0 override a facenum of -1 and -3. An explicit LSL call overrides the equivalent automatic evocation. L From bos at lindenlab.com Mon Sep 10 11:27:59 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Sep 10 11:28:02 2007 Subject: [sldev] [VIEWER} Mac madness In-Reply-To: <1189287926.2798.239.camel@localhost> References: <46E2C715.40000@cox.net> <347b550f0709081322k6fb68176ob0a557b43ea6b778@mail.gmail.com> <1189287926.2798.239.camel@localhost> Message-ID: <46E58CAF.9020505@lindenlab.com> Callum Lerwick wrote: > There's a bug lurking in the lossless encoder, which I seem to have yet > to nail. The "fix" for now is to use lossy encoding instead, which we > should be using most of the time anyway: > > https://jira.secondlife.com/browse/VWR-1475 I am itching to have a go at this, but it would be really nice to have a tagged release to work with, instead of an SVN revision and a pile of patches. Any idea when we might expect to see a release with your improvements? References: <1189442945.4289.65.camel@localhost> Message-ID: <46E58ECE.8010800@lindenlab.com> Callum Lerwick wrote: > Now that OpenJPEG is up to what I feel is an acceptable level of > performance, (though getting it all upstream is still ongoing) I am > broadening my mission to achieving 100% stability. OK, you scratch my back and I'll scratch yours. Is there a single place I can get the necessary bits from? I'd prefer to rebuild a more modern and useful version of OpenJPEG than the one we currently ship with. Hi there devs, The UI Bug Triage agenda is up on the wiki and awaiting your input if you have any. Otherwise, I'll see you tomorrow at 10 am. Benjamin Linden's office is our meeting location as usual. Iridium From secret.argent at gmail.com Mon Sep 10 11:58:01 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 10 11:58:06 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <20070910170137.91ADD41AFD9@stupor.lindenlab.com> References: <20070910170137.91ADD41AFD9@stupor.lindenlab.com> Message-ID: <8309BED9-0BC5-4D83-8FAC-A37EFCD63695@gmail.com> From: Lynne Wu > Why is [HTML] too expensive to render? Cycles? Resources? Is > http://www.ubrowser.com not a realistic interpretation of this > idea? Thanks First, HTML is intrinsically difficult to render, because HTML documents are laid out dynamically. Rendering a page of HTML is comparable to typesetting a page for printing. It's only been about a decade that computers capable of doing that kind of layout in real time have been cheap enough for "everyone". Second, the gecko engine is a relatively heavyweight one. Third, HTML as a texture on a prim means that you have to be prepared for a situation where there are hundreds of HTML textures being updated concurrently within draw distance. Just about any mall will have an environment like that. That means hundreds of instances of the gecko rendering engine running *in addition to* everything else SL is doing. What this means is that HTML on a prim will need to be limited to at most a few surfaces visible to any given avatar. As an extension of the media-texture model HTML is fine. As a way to render arbitrary text on an arbitrary prim, a method that does static fixed layout is far preferred. PS: I even *less* want to see XUL in SL. From lenglish5 at cox.net Mon Sep 10 12:03:04 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 12:03:06 2007 Subject: [sldev] [META] patching design issues Message-ID: <46E594E8.7040702@cox.net> I've created a simple patch that implements this feature request in a very wonky way: http://jira.secondlife.com/browse/VWR-2039 It basically allows chat and history to honor the chat size set in preferences. It is wonky, because it goes into the LLTextEditor initialization method and special cases the font size there. I've got a couple of extern global variables it tests to make sure that the preset variable object exists before it is used. Those sit in a wonkytextfontsizepatch.h file currently. The wonky code lives in the current initialization method inside LLTextEditor::LLTextEditor I COULD: 1) keep the wonky code in the existing initialization method. 2) create a new method that is called from within the initialization method 3) create a wrapper method that does the font modification then calls the existing text manipulation method, and make sure that all existing code uses that wrapper instead of LLTextEditor. 4) create a new LLTextEditor instantiation method and put the wonky code in that then pass all args save the original fontsize onto a renamed method with all the current code, as is, in the renamed method. None of these are very nice,. Which is the least not-nice strategy to use? I'm favoring option 4 as the easiest to maintain: LLTextEditor::LLTextEditor(blarg) { // test/set font size LLTextEditorOld(blarg); } LLTextEditor::LLTextEditorOld(blarg){//original code} Comments? This could be used as a pattern for similar patches, I think. L. From lenglish5 at cox.net Mon Sep 10 12:20:39 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 10 12:20:40 2007 Subject: [sldev] [ANN] UI Bug Triage Agenda is up! In-Reply-To: <46E59012.8040409@lindenlab.com> References: <46E59012.8040409@lindenlab.com> Message-ID: <46E59907.8060608@cox.net> Iridium Linden wrote: > Hi there devs, > The UI Bug Triage agenda is up on the wiki and awaiting your input if > you have any. Otherwise, I'll see you tomorrow at 10 am. Benjamin > Linden's office is our meeting location as usual. > Iridium Dont forget to include the URL with announcements about new content in a URL... From secret.argent at gmail.com Mon Sep 10 12:56:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 10 12:57:04 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <20070910190010.8953141B12A@stupor.lindenlab.com> References: <20070910190010.8953141B12A@stupor.lindenlab.com> Message-ID: <42A9A9B6-BE88-457B-ADCC-7E2E564C466E@gmail.com> From: Kelly Linden > Object inventory is only sent to viewers when the object is selected, > you do not automatically receive the contents of every object in view > (or even of most). Hence my suggestion of using a special texture key to indicate that the object contains inventory for rendering on that face. This still doesn't involve any asset server magic. From gigstaggart at gmail.com Mon Sep 10 13:13:43 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 10 13:14:06 2007 Subject: [sldev] Re: [VIEWER] SVG on a prim In-Reply-To: <46E57780.7030002@cox.net> References: <20070909135920.AC26041B040@stupor.lindenlab.com> <115BBEC7-C768-473C-8A35-D80050F7291D@gmail.com> <46E57371.70201@gmail.com> <46E57780.7030002@cox.net> Message-ID: <46E5A577.6080408@gmail.com> Lawson English wrote: > Lynne Wu wrote: >> Why is it too expensive to render? Cycles? Resources? Is >> http://www.ubrowser.com not a realistic interpretation of this idea? >> Thanks >> >> Argent Stonecutter wrote: >>> ... >>> >>> PS: I agree with Alissa. I would rather not see HTML on a prim except >>> as something like a new parcel media texture type. HTML is too >>> expensive to render. >>> > There are ill-formed webpages that can bring most browsers (any > browser?) to its knees. Imagine if someone used such a webpage as a live > texture and rezzed them all over a sim. > On a more fundamental level, "Tag Soup HTML" has infinite ways that it can be broken, since there is no guarantee of correctness, and even worse, browsers are expected to accept this tag soup that doesn't come near validating. XML based things like SVG have a well-formedness guarantee that make them so much simpler to deal with. If it fails, you simply reject the entire thing. This is why a usable web browser is 25-30 megs and a usable SVG library is 200k. -Jason From blakar at gmail.com Mon Sep 10 14:08:32 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Sep 10 14:08:35 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 Message-ID: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> I'm looking for people who want to go over my proposed particle fixes/optimisations. There's a zip attached to VWR-418 on JIRA that contains 4 patches. They are numbered and can be applied in that order to 1.18.3.2. What it contains: dead code removal, most notably: - removal of all isparticle() stuff as it doesn't do a thing - removal of mextents and all the related calculations as the values are overwritten whenever they are requested VWR-2164: This fixes particle alpha transition. Specific bugs: - particles can't currently fade in -> fixed - particles don't fade out to the correct value if end value is not 0 -> fixed VWR-418: This focuses on particle generation. This should fix most of the issues where the particle system is overloaded. Note that the system is adaptive. Depending on the amount of particles vs max particles a reference variable is updated. This variable is in turn used to limit particle generations. Some of the limits that'll be set: - Particles that are too small to be useful are not generated at all - Particles that are invisible when generated and require you to travel towards them faster than a threshold are not generated (threshold will depend on load) - Particle sources that are very taxing get tougher restrictions (e.g. a particle system which parameters would result in it having 2k particles simultenously in transit will be aggressively cut down while at the same time one generating only 20 is left alone). (limit will depend on load) There's also a bug fix for the fact that simulation may get to generate particles twice. VWR-983: This focuses on particle updates. This should fix the issues where particles go out of sync and end up where they should not be according to timing. This is done by keeping accurate timing for particles that are invisible (and hence get updated only every 8 grames). And a bug is fixed that caused particles not to be updated every time another particle was moved to another group or deleted. Have fun :) I've other fixes and some performance stuff left but I think that the above would be a nice start (it'll give quite a bit of visual impact already). Dirk aka Blakar Ogre From mrfrans at gmail.com Mon Sep 10 15:04:14 2007 From: mrfrans at gmail.com (Frans) Date: Mon Sep 10 15:04:17 2007 Subject: [sldev] [ANN] UI Bug Triage Agenda is up! In-Reply-To: <46E59907.8060608@cox.net> References: <46E59012.8040409@lindenlab.com> <46E59907.8060608@cox.net> Message-ID: <7765f2c60709101504g5dafb1f3g81decf10d27e05ba@mail.gmail.com> http://wiki.secondlife.com/wiki/Bug_triage/UI_Agenda On 9/10/07, Lawson English wrote: > > Iridium Linden wrote: > > Hi there devs, > > The UI Bug Triage agenda is up on the wiki and awaiting your input if > > you have any. Otherwise, I'll see you tomorrow at 10 am. Benjamin > > Linden's office is our meeting location as usual. > > Iridium > > > Dont forget to include the URL with announcements about new content in a > URL... > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Jeroen Frans Executive Director The Vesuvius Group Skype: vesuviusgroup Phone: +17024253344 http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070911/b96cd815/attachment.htm From seg at haxxed.com Mon Sep 10 17:12:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 17:12:16 2007 Subject: [sldev] Second Life Open Source Enforcement Agency In-Reply-To: <46E58ECE.8010800@lindenlab.com> References: <1189442945.4289.65.camel@localhost> <46E58ECE.8010800@lindenlab.com> Message-ID: <1189469533.4289.110.camel@localhost> On Mon, 2007-09-10 at 11:37 -0700, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > > Now that OpenJPEG is up to what I feel is an acceptable level of > > performance, (though getting it all upstream is still ongoing) I am > > broadening my mission to achieving 100% stability. > > OK, you scratch my back and I'll scratch yours. > > Is there a single place I can get the necessary bits from? I'd prefer > to rebuild a more modern and useful version of OpenJPEG than the one we > currently ship with. Well, just getting up to 1.2 from the web site would be a fine start. http://www.openjpeg.org/index.php?menu=download There was an ABI break between 1.1 (and 1.1.1?) and 1.2, if the client were dynamic linked against 1.2, test builds could be dropped in easily. However it looks like an API change may have just been merged a few days ago. Ugh. I haven't yet checked if this affects slviewer. I'd really just like to start seeing bug reports against the latest stable release, with useful backtraces. If you're anxious for a new release I can see if upstream is up for it, after a couple more patches I really want to get in first. The buffer underrun fix/workaround above all, and Dzonatas' vectorized DWT is long overdue. :) I submitted my big memset patch a bit ago, but it hasn't been merged yet. It seems eliminating the opj_malloc wrappers may be controversial. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/bc57e885/attachment.pgp From seg at haxxed.com Mon Sep 10 17:25:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 17:25:56 2007 Subject: [sldev] Second Life Open Source Enforcement Agency In-Reply-To: <46E57A1A.1020304@blueflash.cc> References: <1189442945.4289.65.camel@localhost> <46E57A1A.1020304@blueflash.cc> Message-ID: <1189470353.4289.119.camel@localhost> On Mon, 2007-09-10 at 19:08 +0200, Nicholaz Beresford wrote: > His OpenJPEG Highness, If anyone else wants titles, feel free to pick one. }:) (Though I guess you're already the Minister of Mad Patching :) > just give me a bunch of source files to download and I'll > make you a project file for VS2003/VS2005 and will code > it into my viewers. Hmmm, Dale tried to build against SVN, and ran in to a lot of uglyness. I realized I really ought to get LL to improve the state of the library pack. :) Once its dynamic linking, assuming no ABI/API changes, (bleh) it should be much easier to give you and Dale cutting edge builds to try. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/ffdb027d/attachment.pgp From seg at haxxed.com Mon Sep 10 19:58:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 19:58:37 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> Message-ID: <1189479504.4289.122.camel@localhost> On Mon, 2007-09-10 at 23:08 +0200, Dirk Moerenhout wrote: > VWR-2164: > This fixes particle alpha transition. Specific bugs: > - particles can't currently fade in -> fixed > - particles don't fade out to the correct value if end value is not 0 -> fixed Ahahahaha. My Fedora bubbles have been broken since what, 1.14? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/dbc96cac/attachment-0001.pgp From seg at haxxed.com Mon Sep 10 20:27:48 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 10 20:27:51 2007 Subject: [sldev] [VIEWER] OpenGL clipping in the GUI In-Reply-To: <46E4F501.8070605@cox.net> References: <46E3F711.2000700@cox.net> <1189357062.4289.7.camel@localhost> <46E42CCA.5060605@cox.net> <46E4C37F.4070500@lindenlab.com> <46E4CB22.4010503@cox.net> <1189399892.4289.18.camel@localhost> <46E4F501.8070605@cox.net> Message-ID: <1189481268.4289.123.camel@localhost> On Mon, 2007-09-10 at 00:40 -0700, Lawson English wrote: > Are things that different between Macs and PC's? The Map window on the > Mac is resizeable and moveable. Isn't it that way on the PC? Yeah, but its still a prisoner of the main window, isn't it? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070910/ab171b2a/attachment.pgp From 1337mail at gmail.com Tue Sep 11 09:07:18 2007 From: 1337mail at gmail.com (Michael Miller) Date: Tue Sep 11 09:07:21 2007 Subject: [sldev] Getting list of popular locations Message-ID: <2c99c46e0709110907i53104587i26104bc50c8cba1f@mail.gmail.com> I'm just starting to get familiar with the SL source. My goal right now is to get a list of popular locations(on the entire map, or as many as I can get in a reasonable ammount of time). However, I'm having trouble doing this. I see that in the worldmapviewer's case, the viewer sends out a message(setting the global message variable) for popular locations. How is this message result retrieved? Is there a better way to do this? Thanks, Mike From nicholaz at blueflash.cc Tue Sep 11 09:26:54 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 11 09:27:10 2007 Subject: [sldev] Getting list of popular locations In-Reply-To: <2c99c46e0709110907i53104587i26104bc50c8cba1f@mail.gmail.com> References: <2c99c46e0709110907i53104587i26104bc50c8cba1f@mail.gmail.com> Message-ID: <46E6C1CE.6090207@blueflash.cc> Maybe going through Search, Popular would be easier? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Michael Miller wrote: > I'm just starting to get familiar with the SL source. My goal right > now is to get a list of popular locations(on the entire map, or as > many as I can get in a reasonable ammount of time). However, I'm > having trouble doing this. I see that in the worldmapviewer's case, > the viewer sends out a message(setting the global message variable) > for popular locations. How is this message result retrieved? Is there > a better way to do this? > > Thanks, > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Tue Sep 11 11:22:27 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 11 11:22:51 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> Message-ID: <46E6DCE3.4020102@gmail.com> Dirk Moerenhout wrote: > I've other fixes and some performance stuff left but I think that the > above would be a nice start (it'll give quite a bit of visual impact > already). Hi Dirk, great stuff. Consider fixing llCollisionSprite while you are at it. It's been broken for ages, ever since the legacy particles were removed. -Jason From soft at lindenlab.com Tue Sep 11 13:58:32 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 11 13:58:34 2007 Subject: [sldev] [VIEWER] Minimized Windows In-Reply-To: <2F9D759E-414E-4F7C-B392-FE6146202572@gmail.com> References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> <46DA95F6.5000200@blueflash.cc> <2F9D759E-414E-4F7C-B392-FE6146202572@gmail.com> Message-ID: <9e6e5c9e0709111358k7a17745at54c628bfa575dd70@mail.gmail.com> On 9/2/07, Argent Stonecutter wrote: > On 02-Sep-2007, at 05:52, Nicholaz Beresford wrote: > > I think in the voice viewer I've seen code that looked > > like it would allow minimized windows to be moved (and > > even remembered)? I'm not sure, but with the voice release > > there was a lot of new code in the llui project. > > Nod, that seems to work. It's still annoying that it picks the > absolutely worst possible corner to start placing the minimized > windows in. I'm being a pest: Is there a JIRA on this? :) From ashea at ups.com Tue Sep 11 14:08:29 2007 From: ashea at ups.com (ashea@ups.com) Date: Tue Sep 11 14:09:06 2007 Subject: [sldev] Where to Start? Message-ID: Hi All, I want to start looking at the source code and I am slightly confused as to which to download. What is the current stable release? And does anyone have any suggestions for a newbie? Thanks, Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070911/17e7e393/attachment.htm From soft at lindenlab.com Tue Sep 11 14:24:02 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 11 14:24:04 2007 Subject: [sldev] [SOURCE] llkdu.dll in 1.18.3.2 windows library pack broken? In-Reply-To: <46DD8AFE.6090108@blueflash.cc> References: <46DD8AFE.6090108@blueflash.cc> Message-ID: <9e6e5c9e0709111424j3eb054fbyec39eed936bae6fa@mail.gmail.com> On 9/4/07, Nicholaz Beresford wrote: > > I just had a few crashes rebaking and uploading and found > that it seems that the llkdu.dll that comes with the release > libs for Windows seems to be different from the one coming > with the viewer. Replacing one with the other did fix > the problems. We've repacked this for all three platforms - will be part of the next library drop. Thanks! From zhaoke at islab.org Tue Sep 11 14:26:44 2007 From: zhaoke at islab.org (Ken Zhao) Date: Tue Sep 11 14:26:46 2007 Subject: [sldev] Where to Start? In-Reply-To: References: Message-ID: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> Hey Ashea, There's no stable open source viewer for downloading. but u can download the latest ALPHA open source viewer from here: http://secure-web4.secondlife.com/community/linux-alpha.php if u a newbie, so u need to know what the code does via studying the related programming language and working internals. On 9/12/07, ashea@ups.com wrote: > > Hi All, I want to start looking at the source code and I am slightly > confused as to which to download. What is the current stable release? And > does anyone have any suggestions for a newbie? > > Thanks, > Anthony > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Ken Zhao (ken march in sl) http://islab.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/67cb9152/attachment.htm From monkowsk at watson.ibm.com Tue Sep 11 14:49:43 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 11 14:49:50 2007 Subject: [sldev] Where to Start? In-Reply-To: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> References: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> Message-ID: <46E70D77.1090809@watson.ibm.com> Anthony, I think perhaps Ken misread your note. Ken is saying that there is no stable viewer built from the open source code. This is true. The binaries of the viewer are built by Linden from source in another repository and then the code is copied to the open source repository. But I think you're asking where to find open source code for a stable viewer. In that case, look at http://wiki.secondlife.com/wiki/Source_downloads 1.18.2.0 is the latest release, but 1.18.3.2 is the latest release candidate, which is pretty stable. I'm also guessing that you mean a newbie to the SecondLife open source project, not a newbie to programming. If so, a good place to start is http://wiki.secondlife.com/wiki/Open_Source_Portal Mike Ken Zhao wrote: > Hey Ashea, > > There's no stable open source viewer for downloading. but u can > download the latest ALPHA open source viewer from here: > http://secure-web4.secondlife.com/community/linux-alpha.php > > if u a newbie, so u need to know what the code does via studying the > related programming language and working internals. > > On 9/12/07, *ashea@ups.com * > wrote: > > Hi All, I want to start looking at the source code and I am slightly > confused as to which to download. What is the current stable > release? And does anyone have any suggestions for a newbie? > > Thanks, > Anthony From blakar at gmail.com Tue Sep 11 15:05:47 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Sep 11 15:05:53 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <46E6DCE3.4020102@gmail.com> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> <46E6DCE3.4020102@gmail.com> Message-ID: <7992d0d60709111505h2005fed9x3505c555bda10723@mail.gmail.com> I've gone over the 1.13 code (before rewrite) a bit but I don't seem to find immediately something that is specific to llCollisionSprite. If I understand correctly what is supposed to happen I wonder whether this is client side. The collision is detected on the sim right? Anybody have an idea what it sends to initialise the particle source? Does it still send something? I guess I could set up SLProxy and try to find out but it'll take some time before I'm going to plan that in. Dirk aka Blakar Ogre On 9/11/07, Jason Giglio wrote: > Dirk Moerenhout wrote: > > I've other fixes and some performance stuff left but I think that the > > above would be a nice start (it'll give quite a bit of visual impact > > already). > > Hi Dirk, great stuff. Consider fixing llCollisionSprite while you are at > it. It's been broken for ages, ever since the legacy particles were > removed. > > -Jason > > From robla at lindenlab.com Tue Sep 11 15:07:35 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Sep 11 15:07:43 2007 Subject: [sldev] [VIEWER] GUI xml documentation and/or insights In-Reply-To: <74s2mdscdsee06dsdnaxe04e.alissa_sabre@yahoo.co.jp> References: <46E42CAF.5060308@lindenlab.com> <74s2mdscdsee06dsdnaxe04e.alissa_sabre@yahoo.co.jp> Message-ID: <46E711A7.8010905@lindenlab.com> Hi Alissa, Thanks for pointing out the disconnect. We're having a conversation about how to provide the right level of encouragement, given where we're at today in our ability to accept contributions. We don't want to scare anyone off or discourage anyone, but we want to make sure everyone has the right expectations of what we'll be able to officially incorporate in the near term. Given what you've heard from Jaime, what would you recommend we put on the linguistic QA wiki page? Rob On 9/10/07 9:35 AM, Alissa Sabre wrote: > Rob, I have a question. > > >> The info we have now is here: >> https://wiki.secondlife.com/wiki/Linguistic_QA_with_the_Second_Life_Viewer >> > > This page redirects to another page "How to Localize Your World". The > page says LL welcomes residents' UI translation to other languages. > > However, during an internationalization triage on 2007-07-27, Jaime > Linden said that LL doesn't accept translations for new languages > until skinning project is done. (See http://wiki.secondlife.com/wiki/Bug_triage/2007-07-27/Transcript#Feature_Request_Patches) > > The wiki page discusses skinning project and suggests a possibility to > wait for it, but the overall tone of the page seems encouraging > translations. > > Are you accepting new language translations now or you are not? > > If you are, why early efforts such as Swedish (VWR-774) and > Traditional Chinese (VWR-1293) are just left? > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070911/007fb805/signature.pgp From soft at lindenlab.com Tue Sep 11 15:15:22 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 11 15:15:24 2007 Subject: [sldev] [Ann] SLDev-Traffic #26 Message-ID: <9e6e5c9e0709111515t7e310747t558dc296ca790278@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_26 SLDev-Traffic number 26 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From nicholaz at blueflash.cc Tue Sep 11 15:17:21 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 11 15:17:36 2007 Subject: [sldev] Where to Start? In-Reply-To: References: Message-ID: <46E713F1.50502@blueflash.cc> Starting with source code for the viewer I'd recommend 1.18.3.2 It's not the latest official stable, but does fairly well and if you are doing something based on that it won't be broken by version changes. Start here: http://wiki.secondlife.com/wiki/Get_source_and_compile and then use 1.18.2.0 or 1.18.3.2 for the source/library and artwork packages and you're going. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ ashea@ups.com wrote: > Hi All, I want to start looking at the source code and I am slightly > confused as to which to download. What is the current stable release? > And does anyone have any suggestions for a newbie? > > Thanks, > Anthony > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From seg at haxxed.com Tue Sep 11 15:46:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 11 15:46:36 2007 Subject: [sldev] Where to Start? In-Reply-To: <46E70D77.1090809@watson.ibm.com> References: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> <46E70D77.1090809@watson.ibm.com> Message-ID: <1189550792.4289.165.camel@localhost> On Tue, 2007-09-11 at 17:49 -0400, Mike Monkowski wrote: > Anthony, I think perhaps Ken misread your note. Ken is saying that > there is no stable viewer built from the open source code. This is > true. The binaries of the viewer are built by Linden from source in > another repository and then the code is copied to the open source > repository. This seems like twisted reasoning to me. The release viewers are built from the same codebase as the source release, so it seems inaccurate to characterize the source code as "not being stable". The Linux build specifically, however, is still considered Alpha by LL. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070911/aac0d693/attachment-0001.pgp From bos at lindenlab.com Tue Sep 11 16:01:33 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Sep 11 16:01:35 2007 Subject: [sldev] Second Life Open Source Enforcement Agency In-Reply-To: <1189469533.4289.110.camel@localhost> References: <1189442945.4289.65.camel@localhost> <46E58ECE.8010800@lindenlab.com> <1189469533.4289.110.camel@localhost> Message-ID: <46E71E4D.8040101@lindenlab.com> Callum Lerwick wrote: > Well, just getting up to 1.2 from the web site would be a fine start. > > http://www.openjpeg.org/index.php?menu=download I've built the Linux client against 1.2, repackaged as a shared object. I've also rebuilt the Mac client against 1.2. However, I'm not going to repackage that as a shared object, because we don't currently ship any third-party libraries as .dylib files on OS X, and I really don't want to know anything more than I currently do about Mach-O. We're currently puzzling out whether we can build and package the Windows viewer against a DLL of OpenJPEG. I have to defer to my colleagues who can stomach Windows for that. References: <1189442945.4289.65.camel@localhost> <46E58ECE.8010800@lindenlab.com> <1189469533.4289.110.camel@localhost> <46E71E4D.8040101@lindenlab.com> Message-ID: <46E72599.9070508@lindenlab.com> Bryan O'Sullivan wrote: > We're currently puzzling out whether we can build and package the > Windows viewer against a DLL of OpenJPEG. I have to defer to my > colleagues who can stomach Windows for that. OK, Windows DLL and Linux shared object of OpenJPEG 1.2 are checked into our maintenance branch. They'll show up in a release in due course. References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> <46DA95F6.5000200@blueflash.cc> <2F9D759E-414E-4F7C-B392-FE6146202572@gmail.com> <9e6e5c9e0709111358k7a17745at54c628bfa575dd70@mail.gmail.com> Message-ID: <46E72779.30308@dzonux.net> Soft Linden wrote: > On 9/2/07, Argent Stonecutter wrote: > >> On 02-Sep-2007, at 05:52, Nicholaz Beresford wrote: >> >>> I think in the voice viewer I've seen code that looked >>> like it would allow minimized windows to be moved (and >>> even remembered)? I'm not sure, but with the voice release >>> there was a lot of new code in the llui project. >>> >> Nod, that seems to work. It's still annoying that it picks the >> absolutely worst possible corner to start placing the minimized >> windows in. >> > > I'm being a pest: Is there a JIRA on this? :) Yep, it is even internal. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070911/f93b5284/attachment.htm From soft at lindenlab.com Tue Sep 11 17:24:09 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Sep 11 17:24:10 2007 Subject: [sldev] [VIEWER] Minimized Windows In-Reply-To: References: <20070901190009.8E2DE41B089@stupor.lindenlab.com> <46DA95F6.5000200@blueflash.cc> <2F9D759E-414E-4F7C-B392-FE6146202572@gmail.com> <9e6e5c9e0709111358k7a17745at54c628bfa575dd70@mail.gmail.com> Message-ID: <9e6e5c9e0709111724m76417ca1wccdfb59e8c1c6010@mail.gmail.com> On 9/11/07, Argent Stonecutter wrote: > On 11-Sep-2007, at 15:58, Soft Linden wrote: > > I'm being a pest: Is there a JIRA on this? :) > > Several, like https://jira.secondlife.com/browse/VWR-2306 > > All listed as "resolved" as if dragging windows (and dragging them > again every time you log in) is the same as changing the minimize > location. Coolness. That one was needs-more-info, but it's definitely got it, so I'll just make it open and sneakily push it RXward. From dale at daleglass.net Wed Sep 12 01:33:50 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Sep 12 01:34:01 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars Message-ID: <200709121033.55622.dale@daleglass.net> I've been working on various improvements to make moderation as fast and convenient and possible. Now I've added: An avatar list, which allows finding people quickly, as well as performing actions like ejecting from land on multiple people at once. An option to log the owner and location of speaking objects, for tracking down spam and objects trying to impersonate an avatar. An "event log", currently tracking particle emission, and soon sounds as well. This allows to figure out who is the one flooding the area in particles near instantly. Here's a picture of this in action (not released yet): http://daleglass.net/images/screenshots/particles3.png So I got to test all this in practice yesterday during an attack on Luskwood. Result was: As intended, this makes it very quick and easy to find the attacker and ban them. But that's not much good. I teleported to Lusk, saw the particles, and issued the command to ban the owner of particle spamming self-replicating objectsr maybe 5 seconds after I saw the particles. But the practical result was about zilch because the attacker wasn't on Luskwood land (probably nowhere near as well) in the first place. So somebody who possibly never intended to enter Luskwood land got banned from there and was still causing problems just fine. This is not good. My suggestion to fix this: Automatically temporarily add to everybody's mute list the avatars banned from the parcel, while the avatar remains on the parcel. This will mean that while you're on the parcel where somebody is banned, they or their particles won't be seen if they're hovering right outside the banline. This should be an option, so that the area's moderators can see what is really going on if needed. This needs to be on by default, because otherwise it's ineffective. In principle, part of this can be implemented quite easily by requesting the parcel's banlist each time a parcel border is crossed (could have a delay to save some performance impact and avoid unnecessary banlist fetches while flying around). LL's help would be needed so that when somebody updates the banlist all the viewers in the parcel automatically get their list updated. How does this sound? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/04fed8f3/attachment.pgp From ashea at ups.com Wed Sep 12 06:16:14 2007 From: ashea at ups.com (ashea@ups.com) Date: Wed Sep 12 06:16:37 2007 Subject: [sldev] Where to Start? References: <46E713F1.50502@blueflash.cc> Message-ID: Is there a good description on what parts of SL are handled on the server and what parts are done on the client? Are there any architecture diagrams? Or flowcharts? -----Original Message----- From: Nicholaz Beresford [mailto:nicholaz@blueflash.cc] Sent: Tuesday, September 11, 2007 6:17 PM To: Shea Anthony (seq1ajs) Cc: SLDev@lists.secondlife.com Subject: Re: [sldev] Where to Start? Starting with source code for the viewer I'd recommend 1.18.3.2 It's not the latest official stable, but does fairly well and if you are doing something based on that it won't be broken by version changes. Start here: http://wiki.secondlife.com/wiki/Get_source_and_compile and then use 1.18.2.0 or 1.18.3.2 for the source/library and artwork packages and you're going. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ ashea@ups.com wrote: > Hi All, I want to start looking at the source code and I am slightly > confused as to which to download. What is the current stable release? > And does anyone have any suggestions for a newbie? > > Thanks, > Anthony > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Wed Sep 12 06:20:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 06:21:05 2007 Subject: [sldev] Where to Start? In-Reply-To: References: <46E713F1.50502@blueflash.cc> Message-ID: <46E7E7BB.8080707@blueflash.cc> https://wiki.secondlife.com/wiki/Open_Source_Portal (left side, "Learn"). I have not see much more besides that (doesn't mean that it does not exist). Personally I learned most hands on, the main_loop() in viewer.cpp is a good starting point or just looking at the names of the .cpp files. Nick ashea@ups.com wrote: > Is there a good description on what parts of SL are handled on the > server and what parts are done on the client? Are there any architecture > diagrams? Or flowcharts? > > -----Original Message----- > From: Nicholaz Beresford [mailto:nicholaz@blueflash.cc] > Sent: Tuesday, September 11, 2007 6:17 PM > To: Shea Anthony (seq1ajs) > Cc: SLDev@lists.secondlife.com > Subject: Re: [sldev] Where to Start? > > > Starting with source code for the viewer I'd recommend > 1.18.3.2 > > It's not the latest official stable, but does fairly well and if you are > doing something based on that it won't be broken by version changes. > > Start here: http://wiki.secondlife.com/wiki/Get_source_and_compile > and then use 1.18.2.0 or 1.18.3.2 for the source/library and artwork > packages and you're going. > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > ashea@ups.com wrote: >> Hi All, I want to start looking at the source code and I am slightly >> confused as to which to download. What is the current stable release? >> And does anyone have any suggestions for a newbie? >> >> Thanks, >> Anthony >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From ashea at ups.com Wed Sep 12 06:49:20 2007 From: ashea at ups.com (ashea@ups.com) Date: Wed Sep 12 06:49:51 2007 Subject: [sldev] Where to Start? References: <46E713F1.50502@blueflash.cc> <46E7E7BB.8080707@blueflash.cc> Message-ID: Thanks, Do you know if there is a way to display (popup) a small html form in the UI so that an object in-world could request information from the user? I know you could just send a link to the browser, but I would like to stay in the UI, or maybe theme an IE window to give the illusion that we are still in the UI. -----Original Message----- From: Nicholaz Beresford [mailto:nicholaz@blueflash.cc] Sent: Wednesday, September 12, 2007 9:21 AM To: Shea Anthony (seq1ajs) Cc: SLDev@lists.secondlife.com Subject: Re: [sldev] Where to Start? https://wiki.secondlife.com/wiki/Open_Source_Portal (left side, "Learn"). I have not see much more besides that (doesn't mean that it does not exist). Personally I learned most hands on, the main_loop() in viewer.cpp is a good starting point or just looking at the names of the .cpp files. Nick ashea@ups.com wrote: > Is there a good description on what parts of SL are handled on the > server and what parts are done on the client? Are there any > architecture diagrams? Or flowcharts? > > -----Original Message----- > From: Nicholaz Beresford [mailto:nicholaz@blueflash.cc] > Sent: Tuesday, September 11, 2007 6:17 PM > To: Shea Anthony (seq1ajs) > Cc: SLDev@lists.secondlife.com > Subject: Re: [sldev] Where to Start? > > > Starting with source code for the viewer I'd recommend > 1.18.3.2 > > It's not the latest official stable, but does fairly well and if you > are doing something based on that it won't be broken by version changes. > > Start here: http://wiki.secondlife.com/wiki/Get_source_and_compile > and then use 1.18.2.0 or 1.18.3.2 for the source/library and artwork > packages and you're going. > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > ashea@ups.com wrote: >> Hi All, I want to start looking at the source code and I am slightly >> confused as to which to download. What is the current stable release? >> And does anyone have any suggestions for a newbie? >> >> Thanks, >> Anthony >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kerdezixe at gmail.com Wed Sep 12 07:20:13 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Sep 12 07:20:23 2007 Subject: [sldev] Where to Start? In-Reply-To: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> References: <7eb2650f0709111426w67c527b3x1a7f038622f4599@mail.gmail.com> Message-ID: <8a1bfe660709120720j717ee939gc7cf01ec4f4ba4b3@mail.gmail.com> On 9/11/07, Ken Zhao wrote: > Hey Ashea, > > There's no stable open source viewer for downloading. but u can download > the latest ALPHA open source viewer from here: > http://secure-web4.secondlife.com/community/linux-alpha.php He didn't mentioned that he specifically wanted the Linux version of SL client. (being "stable" isn't speficic to linux, ya'know ? :D ) -- kerunix Flan From rogier at corp.telexs.nl Wed Sep 12 08:33:59 2007 From: rogier at corp.telexs.nl (rogier@corp.telexs.nl) Date: Wed Sep 12 08:33:47 2007 Subject: [sldev] Permissions Message-ID: <46E806E7.1010104@corp.telexs.nl> By reading other SL list, i got an idea: Let's throw away the annoying no transfer permission setting on objects/scripts. Since this SL this is also representing RL in a way. In RL, one can do whatever he/she likes with a bought product. E.g. give it away to someone, either free, or for a price. When i want to give my tv away, i'm free to do so. Is this a good idea, to rip out this permission in SL? I think so. Also i'm thinking about the mod permission. E.g. make it only for scripts inside objects.. not the object itself. Same example, if i want to adjust the looks of my TV, i'm free to do so. (e.g. replace knobs, paint it, casemod it) The scripts however, can be no mod, since e.g. i in RL can't recreate the print plates inside a tv, nor the chips. Let's hear your thoughts. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nik at terminaldischarge.net Wed Sep 12 08:42:49 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Wed Sep 12 08:43:22 2007 Subject: [sldev] Permissions In-Reply-To: <46E806E7.1010104@corp.telexs.nl> References: <46E806E7.1010104@corp.telexs.nl> Message-ID: <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> I have often thought the No Transfer permission was a bit of a daft permission. But there will have been reasons why this was put in, at least I hope so, beyond what I and perhaps you can see. Nik > By reading other SL list, i got an idea: > > Let's throw away the annoying no transfer permission setting on > objects/scripts. Since this SL this is also representing RL in a way. > In RL, one can do whatever he/she likes with a bought product. E.g. give > it away to someone, either free, or for a price. > When i want to give my tv away, i'm free to do so. > Is this a good idea, to rip out this permission in SL? I think so. > Also i'm thinking about the mod permission. E.g. make it only for > scripts inside objects.. not the object itself. > Same example, if i want to adjust the looks of my TV, i'm free to do so. > (e.g. replace knobs, paint it, casemod it) > The scripts however, can be no mod, since e.g. i in RL can't recreate > the print plates inside a tv, nor the chips. > > > Let's hear your thoughts. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blackhat at blackhatdesign.com Wed Sep 12 09:08:34 2007 From: blackhat at blackhatdesign.com (Black Hat Design) Date: Wed Sep 12 09:09:05 2007 Subject: [sldev] Permissions In-Reply-To: <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> References: <46E806E7.1010104@corp.telexs.nl> <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> Message-ID: <00e001c7f557$2be5aa60$6500a8c0@MUDDY> Maybe.. Just Maybe, it is so you cannot take a copiable item, keep a copy for yourself and then sell the other one! -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of nik@terminaldischarge.net I have often thought the No Transfer permission was a bit of a daft permission. But there will have been reasons why this was put in, at least I hope so, beyond what I and perhaps you can see. Nik > By reading other SL list, i got an idea: > > Let's throw away the annoying no transfer permission setting on > objects/scripts. Since this SL this is also representing RL in a way. > In RL, one can do whatever he/she likes with a bought product. E.g. > give it away to someone, either free, or for a price. > When i want to give my tv away, i'm free to do so. > Is this a good idea, to rip out this permission in SL? I think so. > Also i'm thinking about the mod permission. E.g. make it only for > scripts inside objects.. not the object itself. > Same example, if i want to adjust the looks of my TV, i'm free to do so. > (e.g. replace knobs, paint it, casemod it) The scripts however, can be > no mod, since e.g. i in RL can't recreate the print plates inside a > tv, nor the chips. > > > Let's hear your thoughts. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.15/1002 - Release Date: 9/11/2007 5:46 PM From nicholaz at blueflash.cc Wed Sep 12 09:18:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 09:18:23 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? Message-ID: <46E8113D.4070406@blueflash.cc> I've spent a bit of time lately on the beta grid, but it seems to be down ATM. Which lead me to the question if it will remain there and open to the public (technically probably being obsolete with the het grid?) Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From storm.thunders at gmail.com Wed Sep 12 09:57:25 2007 From: storm.thunders at gmail.com (Storm Thunders) Date: Wed Sep 12 09:57:28 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E8113D.4070406@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> Message-ID: <403d5c650709120957i50fa53faic7a330816cd613f@mail.gmail.com> On a related note: Is there a list, page, or something where we can see the status/maintenance plans for aditi? On 9/12/07, Nicholaz Beresford wrote: > > > I've spent a bit of time lately on the beta grid, but it > seems to be down ATM. Which lead me to the question if > it will remain there and open to the public (technically > probably being obsolete with the het grid?) > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/4e55c910/attachment.htm From lenglish5 at cox.net Wed Sep 12 10:10:17 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 12 10:10:24 2007 Subject: [sldev] Where to Start? In-Reply-To: References: <46E713F1.50502@blueflash.cc> <46E7E7BB.8080707@blueflash.cc> Message-ID: <46E81D79.9000607@cox.net> ashea@ups.com wrote: > Thanks, Do you know if there is a way to display (popup) a small html > form in the UI so that an object in-world could request information from > the user? I know you could just send a link to the browser, but I would > like to stay in the UI, or maybe theme an IE window to give the illusion > that we are still in the UI. > ctrl-t at the login screen will evoke a simple floater which uses floater_text.xml You still end up with the log-in window fetching the login splash page via html, but many are able to disable that by editing skins/xui/en-us/panel_login.xml and removing the URL to http://secondlife.com/app/login/. This didn't work for me in my Mac build (hangs the viewer when the client is evoked in the xCode debugger), so the ultimate thing is to "#define LL_LIBXUL_ENABLED 0" in llpreprocessor.h, which takes mozlib out of the compile. It also requires a rebuild of the entire client, so I'd try the other fix first. From rdw at lindenlab.com Wed Sep 12 10:40:22 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Sep 12 10:42:27 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E8113D.4070406@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> Message-ID: <46E82486.6080804@lindenlab.com> Nicholaz Beresford wrote: > > I've spent a bit of time lately on the beta grid, but it > seems to be down ATM. Which lead me to the question if > it will remain there and open to the public (technically > probably being obsolete with the het grid?) I seem to recall some chatter about aditi being down for a database freshening (i.e. agni's database is copied to aditi). This operation apparently takes a long time. I haven't heard anything that indicates that aditi will be shut down or made non-public. Even with het-grid, it still has plenty of utility. We could clearly do a better job of telegraphing planned downtimes, though. -RYaN From iridium at lindenlab.com Wed Sep 12 10:56:38 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Wed Sep 12 10:57:25 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E8113D.4070406@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> Message-ID: <46E82856.8090906@lindenlab.com> This is a very good question, Nicholaz and thanks for bringing it to our attention. Which is right, as far as I know. The beta grid will remain active, but in a small way, Het-Grid will detract from test grid's importance as you have already surmised. However, as Which noted, beta grid will still be used for testing new features and that contribution is of tremendous importance to the community as a whole. Nicholaz Beresford wrote: > > I've spent a bit of time lately on the beta grid, but it > seems to be down ATM. Which lead me to the question if > it will remain there and open to the public (technically > probably being obsolete with the het grid?) > > > Nick > From josh at lindenlab.com Wed Sep 12 11:35:20 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Sep 12 11:34:43 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E8113D.4070406@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> Message-ID: <46E83168.2030708@lindenlab.com> Nicholaz Beresford wrote: > I've spent a bit of time lately on the beta grid, but it > seems to be down ATM. Yeah, we were doing a database snapshot update, which takes several hours. We announced it to folks in the beta grid at the time, but not more broadly. It's an infrequent enough operation and affects few enough residents that we don't have formalized communication channels for it. > Which lead me to the question if > it will remain there and open to the public (technically > probably being obsolete with the het grid?) We still need it for testing at least two classes of testing: * Central service changes that Het Grid won't help with (it's hard for a singleton to be heterogeneous). And of course, yes, there are longer term architectural plans to eliminate that sort of broad dependency on a single unit. A lot of the grid-of-the-future work that Zero Linden talks about as his office hours lead in this direction. * Testing things that aren't even ready for Het Grid yet, either because they're still in internal testing (the beta grid is our biggest test grid, so we use that when things are getting "close" to ready) or because we're worried about behavior on the main grid and need some eyeballs before it gets there. (A permission exploit on even a single region on the main grid would be a bad thing.) From seg at haxxed.com Wed Sep 12 11:48:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 11:48:59 2007 Subject: [sldev] Permissions In-Reply-To: <00e001c7f557$2be5aa60$6500a8c0@MUDDY> References: <46E806E7.1010104@corp.telexs.nl> <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> <00e001c7f557$2be5aa60$6500a8c0@MUDDY> Message-ID: <1189622927.18800.10.camel@localhost> On Wed, 2007-09-12 at 11:08 -0500, Black Hat Design wrote: > Maybe.. Just Maybe, it is so you cannot take a copiable item, keep a copy > for yourself and then sell the other one! Yes, if there was no "no transfer", people selling stuff would have to set it "no copy". Which, if its modifyable, means you can't make a backup before you mod it. "no transfer" is the lesser evil IMHO. But still evil. People selling stuff mod/no-copy should be dragged out in the street and shot. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/ba51f637/attachment-0001.pgp From seg at haxxed.com Wed Sep 12 11:55:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 11:55:22 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E8113D.4070406@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> Message-ID: <1189623318.18800.15.camel@localhost> On Wed, 2007-09-12 at 18:18 +0200, Nicholaz Beresford wrote: > I've spent a bit of time lately on the beta grid, but it > seems to be down ATM. Which lead me to the question if > it will remain there and open to the public (technically > probably being obsolete with the het grid?) Considering my interest in debugging OpenJPEG, it is very discouraging to have to spend real L$ on broken uploads. Either the beta grid stays, the upload tax goes away, or I get very annoyed. ;P The fourth option is of course a third party asset server. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/3b5ea156/attachment.pgp From seg at haxxed.com Wed Sep 12 12:16:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 12:16:14 2007 Subject: [sldev] Is something seriously wrong with Hippotropolis? Message-ID: <1189624571.18800.32.camel@localhost> Okay, this is really annoying. Yesterday, my client deadlocked as it occasionally does, so I killed it and tried to log back in. I got the usual "The system is logging you out right now. Your account will not be available until (now + 5 minutes)". Five minutes pass. I get the same thing. A half hour passes. Same thing. An hour passes. Same thing. I give up, go out to dinner then go to bed. I get up today, and log in for a bit. I idle while I check email and such, and eventually notice I've gone redmapped. So I close the client, and try to log back in. Great, not again! Its been like 4 hours now, and I still can't log in. All the while, my wife and my roomate can log in just fine, so its specifically my account. (And they see me as online, though the map indicates I'm way off in the far left corner of the grid as it always does when it doesn't actually know where someone is.) What's the damn deal? Both times I was in Hippotropolis, I've never had this problem anywhere else, is there something wrong with the sim? Or am I just unlucky? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/2d391a16/attachment.pgp From nicholaz at blueflash.cc Wed Sep 12 12:35:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 12:35:22 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E83168.2030708@lindenlab.com> References: <46E8113D.4070406@blueflash.cc> <46E83168.2030708@lindenlab.com> Message-ID: <46E83F69.60409@blueflash.cc> Joshua Bell wrote: > Nicholaz Beresford wrote: >> I've spent a bit of time lately on the beta grid, but it >> seems to be down ATM. > Yeah, we were doing a database snapshot update, which takes several > hours. We announced it to folks in the beta grid at the time, but not > more broadly. It's an infrequent enough operation and affects few enough > residents that we don't have formalized communication channels for it. Not a problem at all ... I was just wondering if it was going offline forever of something. Thanks for the quick answers everybody. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From labrat.hb at gmail.com Wed Sep 12 12:40:34 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Sep 12 12:40:37 2007 Subject: [sldev] Is something seriously wrong with Hippotropolis? In-Reply-To: <1189624571.18800.32.camel@localhost> References: <1189624571.18800.32.camel@localhost> Message-ID: Have you tried logging in to a different region? Sometimes a region will ghost your account and you can't sign back in to that region until it reboots. But you can log in to other regions just fine. On 9/12/07, Callum Lerwick wrote: > > Okay, this is really annoying. Yesterday, my client deadlocked as it > occasionally does, so I killed it and tried to log back in. I got the > usual "The system is logging you out right now. Your account will not be > available until (now + 5 minutes)". Five minutes pass. I get the same > thing. A half hour passes. Same thing. An hour passes. Same thing. I > give up, go out to dinner then go to bed. > > I get up today, and log in for a bit. I idle while I check email and > such, and eventually notice I've gone redmapped. So I close the client, > and try to log back in. Great, not again! Its been like 4 hours now, and > I still can't log in. All the while, my wife and my roomate can log in > just fine, so its specifically my account. (And they see me as online, > though the map indicates I'm way off in the far left corner of the grid > as it always does when it doesn't actually know where someone is.) > > What's the damn deal? Both times I was in Hippotropolis, I've never had > this problem anywhere else, is there something wrong with the sim? Or am > I just unlucky? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/be4778ff/attachment.htm From nicholaz at blueflash.cc Wed Sep 12 12:51:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 12:51:22 2007 Subject: [sldev] Is something seriously wrong with Hippotropolis? In-Reply-To: <1189624571.18800.32.camel@localhost> References: <1189624571.18800.32.camel@localhost> Message-ID: <46E84329.4070904@blueflash.cc> Hippo Land seems fine. Nobody here, no visible ghosts. I see you online though... an IM and teleport offer went through though. But try to login somewhere else via slurl. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Callum Lerwick wrote: > Okay, this is really annoying. Yesterday, my client deadlocked as it > occasionally does, so I killed it and tried to log back in. I got the > usual "The system is logging you out right now. Your account will not be > available until (now + 5 minutes)". Five minutes pass. I get the same > thing. A half hour passes. Same thing. An hour passes. Same thing. I > give up, go out to dinner then go to bed. > > I get up today, and log in for a bit. I idle while I check email and > such, and eventually notice I've gone redmapped. So I close the client, > and try to log back in. Great, not again! Its been like 4 hours now, and > I still can't log in. All the while, my wife and my roomate can log in > just fine, so its specifically my account. (And they see me as online, > though the map indicates I'm way off in the far left corner of the grid > as it always does when it doesn't actually know where someone is.) > > What's the damn deal? Both times I was in Hippotropolis, I've never had > this problem anywhere else, is there something wrong with the sim? Or am > I just unlucky? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Wed Sep 12 13:03:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 12 13:03:20 2007 Subject: [sldev] Permissions In-Reply-To: <20070912184902.3DC4D41B219@stupor.lindenlab.com> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> Message-ID: <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> The original intent of the SL permissions system was that people could make objects that acted like physical objects (transferrable, but not copyable, with the right of first sale that you get from physical objects), and objects that acted like licensed software (copyable, but not transferrable, so you can back them up but not resell them). The right to *break* objects that you bought was originally there: if you buy a no-mod object you could take it apart... pull stuff out of the inventory... but not put it back together again. At some point someone convinced LL that this was an "exploit". I don't know the details, they have never to my knowledge been published, but suddenly I found that I couldn't buy a plane, and turn it into a prop by pulling the scripts out to reduce lag and prevent people from getting annoying "you can't ride me, you're not the owner" messages when they sat on it. At one point I bought a Tiny avatar that was broken, The anim script wasn't working. And the creator wasn't answered. No problem, I pulled the animations out of it and put them in another prim, along with a copy of Franimation Overrider. If something like that had happened after it became impossible to pull stuff out of no-mod objects I'd have been stuck. They also stopped you from even being able to *reset* scripts in no- mod objects. This also made it possible for someone to create objects that were completely no-perm, by putting inventory in with mixed rights. That breaks the SL permissions system. But only for no-mod objects. So... From: Callum Lerwick > People selling stuff mod/no-copy should be dragged out in the > street and > shot. People selling stuff no-mod need to really have a hell of a product before I'll even *consider* buying it any more. I had preferred to avoid no-mod objects when there was an alternative before this happened, but now... no way. Copy, no-copy, I don't care. If it's not mod you'll have to peddle it to someone else. And if I ever make a no-copy product, I guess you'll have to haul me out in the street, because it sure as hell isn't going to be no-mod. Not unless LL fixes permissions, exploit or no exploit. From monkowsk at watson.ibm.com Wed Sep 12 13:08:20 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Sep 12 13:08:24 2007 Subject: [sldev] Is something seriously wrong with Hippotropolis? In-Reply-To: <1189624571.18800.32.camel@localhost> References: <1189624571.18800.32.camel@localhost> Message-ID: <46E84733.4070008@watson.ibm.com> Callum Lerwick wrote: ... > I still can't log in. All the while, my wife and my roomate can log in > just fine, so its specifically my account. (And they see me as online, > though the map indicates I'm way off in the far left corner of the grid > as it always does when it doesn't actually know where someone is.) Interesting. I was in Hippotropolis sometime in the last couple days to test out some code, and your avatar (Seg Baphomet) happened to be near to me (Mm Alder). There was another avatar up on the platform and I put the cursor over it to see who it was, and it was you again! I thought you had figured out some trick. Strange things can happen in a land built for hackers. :-) Mike From seg at haxxed.com Wed Sep 12 13:19:02 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 13:19:09 2007 Subject: [sldev] Is something seriously wrong with Hippotropolis? In-Reply-To: References: <1189624571.18800.32.camel@localhost> Message-ID: <1189628342.18800.35.camel@localhost> On Wed, 2007-09-12 at 12:40 -0700, Harold Brown wrote: > Have you tried logging in to a different region? > > Sometimes a region will ghost your account and you can't sign back in > to that region until it reboots. But you can log in to other regions > just fine. Nope, makes no difference. I'm filing a support request, seeing as "can't login" is one of the few things I'm allowed support on. Lets see if that does any good. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/af1c4464/attachment.pgp From seg at haxxed.com Wed Sep 12 13:33:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 13:34:02 2007 Subject: [sldev] Permissions In-Reply-To: <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> Message-ID: <1189629238.18800.42.camel@localhost> On Wed, 2007-09-12 at 15:03 -0500, Argent Stonecutter wrote: > From: Callum Lerwick > > People selling stuff mod/no-copy should be dragged out in the > > street and > > shot. > > People selling stuff no-mod need to really have a hell of a product > before I'll even *consider* buying it any more. I had preferred to > avoid no-mod objects when there was an alternative before this > happened, but now... no way. Copy, no-copy, I don't care. If it's not > mod you'll have to peddle it to someone else. > > And if I ever make a no-copy product, I guess you'll have to haul me > out in the street, because it sure as hell isn't going to be no-mod. > > Not unless LL fixes permissions, exploit or no exploit. Yeah, people selling no-mod should probably be shot too. If I bought it, I damn well expect to be able to customize it. Sigh, I look forward to the future free grid, where all this DRM bullcrap trying to prop up a toy economy will be made moot. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/6801c666/attachment-0001.pgp From sl at phoca.com Wed Sep 12 13:38:31 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Wed Sep 12 13:38:38 2007 Subject: [sldev] Permissions In-Reply-To: <46E806E7.1010104@corp.telexs.nl> References: <46E806E7.1010104@corp.telexs.nl> Message-ID: It's entirely possible for vendors to sell things mod/transfer and several do. Furniture makers for example frequently do. There is a problem with that though. Both through bugs in SL and through fumbled fingers of the owner, mod objects can get destroyed when modding them. If the object was no copy, This creates a situation where the vender is CONSTANTLY fielding complaints from customers for new replacements. Thus the mod/copy/no trans permission set is commonly used. It allows users to make multiple copies and be able to retrieve originals if something breaks. Also, if you want a person to be able to use multiples of an object like a plant or chair for their own use then you set the object copy, but if it was copy/trans then you will have just completely given away the object and it will end up in the freebie bins and for sale by other people. So if you want to give copy permission then you have to block transfer unless your goal was to give something away free to the entire grid (Which of course a lot of people do) Except for poor permission interaction in linked and contained objects and bugs in the permission system which still exist today, the idea of the mod/copy/transfer permission set are good and transfer should definitely not be removed. If there are any changes to the permission system (other than fixes for current brokenness like mod/copy objects going no mod when they are taken from world when they contain a no mod script) it would be nice to be able to do things like set an object for sale /permanently/ rather than just for one generation, and possibly allow a temp transfer so that everything could be set to "gift" and then the owner could give it away and people could regift etc until someone "claimed" it... Farallon ----- Original Message ----- From: To: Sent: Wednesday, September 12, 2007 8:33 AM Subject: [sldev] Permissions > By reading other SL list, i got an idea: > > Let's throw away the annoying no transfer permission setting on > objects/scripts. Since this SL this is also representing RL in a way. > In RL, one can do whatever he/she likes with a bought product. E.g. give > it away to someone, either free, or for a price. > When i want to give my tv away, i'm free to do so. > Is this a good idea, to rip out this permission in SL? I think so. > Also i'm thinking about the mod permission. E.g. make it only for scripts > inside objects.. not the object itself. > Same example, if i want to adjust the looks of my TV, i'm free to do so. > (e.g. replace knobs, paint it, casemod it) > The scripts however, can be no mod, since e.g. i in RL can't recreate the > print plates inside a tv, nor the chips. > > > Let's hear your thoughts. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Wed Sep 12 13:57:38 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Sep 12 13:57:44 2007 Subject: [sldev] How fast can packets be sent to the grid? Message-ID: <200709122257.38770.dale@daleglass.net> I'm going to start soon work on two new features: keeping starts of object rezzing, and object search by owner. Both need to know who owns every object in sight, and since that data isn't currently sent for all the objects automatically, I'll have to query the information for every object seen. That's a lot of requests. Now the question is: If I'm going to suddenly submit a LOT of queries at once to the grid, do I need to throttle them? I can just submit a request for everything without owner info in my queue (which could be 100 requests at once say), limit it to X requests per second, don't send a new request until the previous one has been replied to or timed out, etc. So what would be the proper way of doing this? From secret.argent at gmail.com Wed Sep 12 14:37:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 12 14:37:30 2007 Subject: [sldev] Re: Permissions (Callum Lerwick) In-Reply-To: <20070912203402.D270841B229@stupor.lindenlab.com> References: <20070912203402.D270841B229@stupor.lindenlab.com> Message-ID: <81F527A5-92A5-451D-AFD6-7CFA3AA8510E@gmail.com> > Yeah, people selling no-mod should probably be shot too. If I > bought it, > I damn well expect to be able to customize it. So if they sell it no-copy, they get shot either way? > Sigh, I look forward to the future free grid, where all this DRM > bullcrap trying to prop up a toy economy will be made moot. I dunno, personally I like having a working economy in-game. I just think it ought to stick to the rules they set out at the start, or they should justify why they're disabling things with more than "mumble mumble exploit". From trevor at gridbug.org Wed Sep 12 14:59:27 2007 From: trevor at gridbug.org (Trevor Powell) Date: Wed Sep 12 14:59:40 2007 Subject: [sldev] Permissions In-Reply-To: <1189629238.18800.42.camel@localhost> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> <1189629238.18800.42.camel@localhost> Message-ID: <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> On 13/09/2007, at 6:33 AM, Callum Lerwick wrote: > On Wed, 2007-09-12 at 15:03 -0500, Argent Stonecutter wrote: >>> People selling stuff mod/no-copy should be dragged out in the >>> street and >>> shot. > > Yeah, people selling no-mod should probably be shot too. If I > bought it, > I damn well expect to be able to customize it. Can you guys take the gratuitous homicide threats off-list, please? I mean, honestly. Trevor From giff at electricsheepcompany.com Wed Sep 12 15:30:10 2007 From: giff at electricsheepcompany.com (Giff Constable) Date: Wed Sep 12 15:30:12 2007 Subject: [sldev] Permissions In-Reply-To: <1189622927.18800.10.camel@localhost> References: <46E806E7.1010104@corp.telexs.nl> <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> <00e001c7f557$2be5aa60$6500a8c0@MUDDY> <1189622927.18800.10.camel@localhost> Message-ID: <9b6fd9920709121530k67175091pb5b01f5eb49d6632@mail.gmail.com> In real life you can't make an instantaneous, no-cost copy of everything you own. Real life analogies are not applicable here. Yes the SL permissions system is frustrating and could improve. However, we have no transfer so that people can make items copy-able, and there are good reasons to make items copy-able. If everything is both copy and transfer, there would be no such thing as a for-profit content business in Second Life. Frankly I've heard good reasons for every permutation of those three permissions checkboxes. If anything, people want more choice -- like the ability to set mod/copy/transfer but no resale (i.e. no reselling freebies), or to put things out in pub domain or creative commons and have that be clear. (and for the record, I have no problem with people reselling "transferable" items) To give an example, high-end prefabs tend to sell "mod/copy/no trans" because people modify and then wreck their purchases and need to start over, but a lot of newbie prefabs go "mod/no copy/transfer" because 1. a lot of newbies change houses quickly and want to resell, and 2. a lot of prefab makers were discovering scam artists would buy one house and then start placing them all over SL for different users for free or for money. You might find it annoying, but you can choose not buy the product rather than trying to shove your rules down someone else's throat. The right thing to do is give people options as to what kind of permissions *they* choose to attach to their intellectual property and to their business. Linden Lab doesn't tell scripters that every script they write in Second Life has to be open source. Scripters have a choice. -- Forseti On 9/12/07, Callum Lerwick wrote: > > On Wed, 2007-09-12 at 11:08 -0500, Black Hat Design wrote: > > Maybe.. Just Maybe, it is so you cannot take a copiable item, keep a > copy > > for yourself and then sell the other one! > > Yes, if there was no "no transfer", people selling stuff would have to > set it "no copy". Which, if its modifyable, means you can't make a > backup before you mod it. > > "no transfer" is the lesser evil IMHO. But still evil. > > People selling stuff mod/no-copy should be dragged out in the street and > shot. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/5f14f587/attachment.htm From seg at haxxed.com Wed Sep 12 15:58:43 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 15:58:47 2007 Subject: [sldev] Re: Permissions (Callum Lerwick) In-Reply-To: <81F527A5-92A5-451D-AFD6-7CFA3AA8510E@gmail.com> References: <20070912203402.D270841B229@stupor.lindenlab.com> <81F527A5-92A5-451D-AFD6-7CFA3AA8510E@gmail.com> Message-ID: <1189637923.18800.54.camel@localhost> On Wed, 2007-09-12 at 16:37 -0500, Argent Stonecutter wrote: > > Yeah, people selling no-mod should probably be shot too. If I > > bought it, > > I damn well expect to be able to customize it. > > So if they sell it no-copy, they get shot either way? Yes! :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/2cc5f3a0/attachment.pgp From seg at haxxed.com Wed Sep 12 16:02:03 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 16:02:06 2007 Subject: [sldev] Permissions In-Reply-To: <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> <1189629238.18800.42.camel@localhost> <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> Message-ID: <1189638123.18800.59.camel@localhost> On Thu, 2007-09-13 at 07:59 +1000, Trevor Powell wrote: > Can you guys take the gratuitous homicide threats off-list, please? > > I mean, honestly. Being effectively banned from the grid can make one homicidal. No, I *still* can't log in. *starts passing out FREE SEG stickers* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/bd3e5942/attachment.pgp From dale at daleglass.net Wed Sep 12 16:10:05 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Sep 12 16:10:21 2007 Subject: [sldev] Permissions In-Reply-To: <1189638123.18800.59.camel@localhost> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> <1189638123.18800.59.camel@localhost> Message-ID: <200709130110.10554.dale@daleglass.net> On Thursday 13 September 2007 01:02:03 Callum Lerwick wrote: > On Thu, 2007-09-13 at 07:59 +1000, Trevor Powell wrote: > > Can you guys take the gratuitous homicide threats off-list, please? > > > > I mean, honestly. > > Being effectively banned from the grid can make one homicidal. > > No, I *still* can't log in. > > *starts passing out FREE SEG stickers* Make an alt? But that sure sucks. Can't we get rid of this login timeout thing? If it thinks you're still in make it kill the session it thinks exist when you try a new login. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/60f44eb6/attachment-0001.pgp From roamingryozu at gmail.com Wed Sep 12 16:17:31 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Sep 12 16:17:33 2007 Subject: [sldev] Permissions In-Reply-To: <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <1A865BBB-ED92-41CB-94C6-E51736E530D9@gmail.com> <1189629238.18800.42.camel@localhost> <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> Message-ID: <5eff6d3b0709121617m2f64b9d1q51709c8826bf84af@mail.gmail.com> I take a bit of insult here with whoever calls the SL economy a toy economy. I've been living off of my income from SL for a year now. Honestly though, I'd hate to see them go, but I do think permissions will likely see their way out eventually. Depends on how the OS community decides to deal with the issue when they begin hosting their own grids. On 9/12/07, Trevor Powell wrote: > > > On 13/09/2007, at 6:33 AM, Callum Lerwick wrote: > > > On Wed, 2007-09-12 at 15:03 -0500, Argent Stonecutter wrote: > >>> People selling stuff mod/no-copy should be dragged out in the > >>> street and > >>> shot. > > > > Yeah, people selling no-mod should probably be shot too. If I > > bought it, > > I damn well expect to be able to customize it. > > > Can you guys take the gratuitous homicide threats off-list, please? > > I mean, honestly. > > > Trevor > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/2db614f5/attachment.htm From dale at daleglass.net Wed Sep 12 16:28:27 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Sep 12 16:28:49 2007 Subject: [sldev] Permissions In-Reply-To: <1189638123.18800.59.camel@localhost> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> <1189638123.18800.59.camel@localhost> Message-ID: <200709130128.33946.dale@daleglass.net> On Thursday 13 September 2007 01:02:03 Callum Lerwick wrote: > *starts passing out FREE SEG stickers* http://daleglass.net/images/screenshots/free_seg.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/f1f846e6/attachment.pgp From soft at lindenlab.com Wed Sep 12 16:40:09 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Sep 12 16:40:11 2007 Subject: [sldev] Thursday Open Source Meeting Message-ID: <9e6e5c9e0709121640u68d4cccfw895375777ebacfbe@mail.gmail.com> The Thursaday Open Source meeting takes place at 2pm in Hippotropolis. As always - feel free to add items to the agenda! https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From roamingryozu at gmail.com Wed Sep 12 16:46:50 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Sep 12 16:46:52 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <200709121033.55622.dale@daleglass.net> References: <200709121033.55622.dale@daleglass.net> Message-ID: <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> Another feature to throw into that would be to, effective immediately upon banning from the land, return all objects owned by that person. As far as the muting thing goes. I don't think the server should ever tell my personal client's mute list to add someone to it without me knowing. On the other hand, I think you're right in the idea that a person who is banned from a parcel should have no effect on or visibility by persons within that area. Nice set up you got there with the particle tracker Dale. Only thing I can think to suggest is that the particle system itself isn't so blatantly displayed... Might upset some scripters/particle makers with that. On 9/12/07, Dale Glass wrote: > > I've been working on various improvements to make moderation as fast and > convenient and possible. > > Now I've added: > > An avatar list, which allows finding people quickly, as well as performing > actions like ejecting from land on multiple people at once. > > An option to log the owner and location of speaking objects, for tracking > down spam and objects trying to impersonate an avatar. > > An "event log", currently tracking particle emission, and soon sounds as > well. This allows to figure out who is the one flooding the area in > particles near instantly. Here's a picture of this in action (not released > yet): http://daleglass.net/images/screenshots/particles3.png > > > So I got to test all this in practice yesterday during an attack on > Luskwood. Result was: As intended, this makes it very quick and easy to > find the attacker and ban them. But that's not much good. > > I teleported to Lusk, saw the particles, and issued the command to ban the > owner of particle spamming self-replicating objectsr maybe 5 seconds after > I saw the particles. But the practical result was about zilch because the > attacker wasn't on Luskwood land (probably nowhere near as well) in the > first place. So somebody who possibly never intended to enter Luskwood > land got banned from there and was still causing problems just fine. This > is not good. > > > My suggestion to fix this: Automatically temporarily add to everybody's > mute list the avatars banned from the parcel, while the avatar remains on > the parcel. This will mean that while you're on the parcel where somebody > is banned, they or their particles won't be seen if they're hovering right > outside the banline. > > This should be an option, so that the area's moderators can see what is > really going on if needed. This needs to be on by default, because > otherwise it's ineffective. > > > In principle, part of this can be implemented quite easily by requesting > the parcel's banlist each time a parcel border is crossed (could have a > delay to save some performance impact and avoid unnecessary banlist > fetches while flying around). > > LL's help would be needed so that when somebody updates the banlist all > the > viewers in the parcel automatically get their list updated. > > > How does this sound? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/14637b24/attachment.htm From seg at haxxed.com Wed Sep 12 16:58:03 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 16:58:25 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> Message-ID: <1189641483.18800.61.camel@localhost> On Wed, 2007-09-12 at 19:46 -0400, Andre Roche wrote: > Nice set up you got there with the particle tracker Dale. Only thing > I can think to suggest is that the particle system itself isn't so > blatantly displayed... Might upset some scripters/particle makers > with that. Client > Rendering > Info Displays > Particles -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/056f3917/attachment.pgp From secret.argent at gmail.com Wed Sep 12 17:01:15 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 12 17:01:20 2007 Subject: [sldev] Re: {META] Permissions and login timeouts. In-Reply-To: <20070912231023.9EB1941B09D@stupor.lindenlab.com> References: <20070912231023.9EB1941B09D@stupor.lindenlab.com> Message-ID: Forseti Svarog?: > Frankly I've heard good reasons for every permutation of those three > permissions checkboxes. If anything, people want more choice -- > like the > ability to set mod/copy/transfer but no resale (i.e. no reselling > freebies), That's not technically possible to implement without outrageous restrictions on llGiveInventory() that would break everyone's scripted vendors. An alternative that would work would be to set a "royalty price" on the object... you can sell it to someone but they have to pay *at least* the royalty price to get it, with the payment split between the creator and the owner based on the royalty terms. > or to put things out in pub domain or creative commons and have > that be > clear. I think it's clear enough just putting that in the documentation (like, you know, in the real world), and yet you have things like the X-Flight debacle and people selling no-mod objects containing custom versions of the Franimation Overrider... which is a no-no under the letter of the GPL2. Dale Glass: > Can't we get rid of this login timeout thing? If it thinks you're > still in > make it kill the session it thinks exist when you try a new login. I Hereby Endorse This Product And/or Service From 1337mail at gmail.com Wed Sep 12 17:13:56 2007 From: 1337mail at gmail.com (Michael Miller) Date: Wed Sep 12 17:13:58 2007 Subject: [sldev] Collision detection Message-ID: <2c99c46e0709121713g1da20c38jb99f725199b9f2be@mail.gmail.com> How does Second Life do collision detection(i.e. when your avatar moves into some object in its way)? Can I find out when a collision like this happens, and what object is colliding with my avatar(with dimensions/coordinates)? If so, how? Thanks, Mike From giff at electricsheepcompany.com Wed Sep 12 17:26:51 2007 From: giff at electricsheepcompany.com (Giff Constable) Date: Wed Sep 12 17:26:53 2007 Subject: [sldev] Re: {META] Permissions and login timeouts. In-Reply-To: References: <20070912231023.9EB1941B09D@stupor.lindenlab.com> Message-ID: <9b6fd9920709121726rbcfc126ja6f962e0ae824c7a@mail.gmail.com> Yes I agree. For that part of my email, I was just passing on the general wishes I hear. I'm not one of these people who thinks LL needs to twist itself sideways protecting nearly unprotectable IP like textures, but I do think a pragmatic middle ground is healthy. I do feel pretty strongly that having a baseline way for IP owners to establish what the parameters of use are without having to pull everyone into court is useful for the functioning and growth of this world. And I feel strongly that every IP owner should be able to make their own decisions on their IP, and we, as buyers, have a choice not to buy. I bet that when we eventually get to private grids, we'll see a proliferation of worlds (or attempted worlds) with different governance and commerce schemes, and that's cool. People can try to create their own utopias. This is kind of off-topic for sldev though so I'll stop here. Cheers Forseti On 9/12/07, Argent Stonecutter wrote: > > Forseti Svarog?: > > Frankly I've heard good reasons for every permutation of those three > > permissions checkboxes. If anything, people want more choice -- > > like the > > ability to set mod/copy/transfer but no resale (i.e. no reselling > > freebies), > > That's not technically possible to implement without outrageous > restrictions on llGiveInventory() that would break everyone's > scripted vendors. An alternative that would work would be to set a > "royalty price" on the object... you can sell it to someone but they > have to pay *at least* the royalty price to get it, with the payment > split between the creator and the owner based on the royalty terms. > > > or to put things out in pub domain or creative commons and have > > that be > > clear. > > I think it's clear enough just putting that in the documentation > (like, you know, in the real world), and yet you have things like the > X-Flight debacle and people selling no-mod objects containing custom > versions of the Franimation Overrider... which is a no-no under the > letter of the GPL2. > > Dale Glass: > > Can't we get rid of this login timeout thing? If it thinks you're > > still in > > make it kill the session it thinks exist when you try a new login. > > I Hereby Endorse This Product And/or Service > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070912/9ef9be7a/attachment-0001.htm From 1337mail at gmail.com Wed Sep 12 17:27:54 2007 From: 1337mail at gmail.com (Michael Miller) Date: Wed Sep 12 17:27:56 2007 Subject: [sldev] Improving the source code Message-ID: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> To all: I think most people on this list can agree that the SL code is a bit old. It lacks the usage of major accepted libraries now(boost::thread for example), and has many hacks littered throughout the code. At the time that the SL client was created, these limitations probably spawned the subpar code. But now that we have high-quality, efficient, fast libraries to use, we can ditch a lot of the code. Off the top of my head, I'd say LLThread and LLMutex could both be ditched by switching to boost::thread, eliminating a lot of unnecessary code. In addition to making use of high-quality 3rd party libraries, much of the code's underlying structure can be improved. For example, the message system has many limitations. Most notably, I encountered the limitation of one function callback per message. This is a very bad limitation to have, as it prohibits(or makes harder, anyway) extensions to the SL source. I think that updating the code is a great way to show Lindens that the open source community can be useful. A lot of people have been, well, let's say not too enthusiastic of Lindens response to user submitted patches. Let's revamp the client, and show them that we can do something useful! I propose we make a list(on the wiki, maybe) of major source code imrprovements that are needed. Then, we can delegate the tasks out, and start working on them. I think that within even just a few months, we can have a significantly more "solid" version of code than the current client. From secret.argent at gmail.com Wed Sep 12 17:42:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 12 17:42:20 2007 Subject: [sldev] Re: [META] Permissions In-Reply-To: <20070913002656.E461841B238@stupor.lindenlab.com> References: <20070913002656.E461841B238@stupor.lindenlab.com> Message-ID: From: "Andre Roche" > Honestly though, I'd hate to see them go, but I do think > permissions will > likely see their way out eventually. Depends on how the OS community > decides to deal with the issue when they begin hosting their own > grids. I think permissions may well end up being a distinguishing point *and* an advantage for the SL grid. From nicholaz at blueflash.cc Wed Sep 12 18:07:15 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 18:07:31 2007 Subject: [sldev] Permissions In-Reply-To: <200709130128.33946.dale@daleglass.net> References: <20070912184902.3DC4D41B219@stupor.lindenlab.com> <944BE133-AB92-486E-97EB-0D685F9B4272@gridbug.org> <1189638123.18800.59.camel@localhost> <200709130128.33946.dale@daleglass.net> Message-ID: <46E88D43.7040904@blueflash.cc> I want one!!! (Full Perm I assume) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dale Glass wrote: > On Thursday 13 September 2007 01:02:03 Callum Lerwick wrote: >> *starts passing out FREE SEG stickers* > > http://daleglass.net/images/screenshots/free_seg.jpg > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Wed Sep 12 18:15:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 12 18:15:47 2007 Subject: [sldev] Improving the source code In-Reply-To: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> References: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> Message-ID: <46E88F32.10701@blueflash.cc> Michael Miller wrote: > Let's revamp the client, and show them that we can do > something useful! I can't help it but this reasoning sounds pretty backward. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From lenglish5 at cox.net Wed Sep 12 20:44:27 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 12 20:44:30 2007 Subject: [sldev] Re: [META] Improving the source code In-Reply-To: <46E88F32.10701@blueflash.cc> References: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> <46E88F32.10701@blueflash.cc> Message-ID: <46E8B21B.30204@cox.net> Nicholaz Beresford wrote: > > Michael Miller wrote: >> Let's revamp the client, and show them that we can do >> something useful! > > I can't help it but this reasoning sounds pretty backward. > > Unless you're hoping to be hired by Linden Labs of course... ;-) Parts of the code, such as the GUI, ARE being redesigned internally. Benjamin Linden has helped set this agenda, with input from many of us. There are still at least a few things missing from the user interface roadmap, though, which is where most of my meager abilities lie. I am sure there are many changes planned on the level of the client architecture that haven't, publicly at least, been vetted by the open source community as thoroughly as the user interface stuff has been. It might be good to start drawing up nice little boxes with arrows showing data flow, class hierarchies, and so on, both for the existing client (a spaghetti mess will show up, I suspect) and for a hypothetical redesigned client. Replacing one threading library with another might tidy up things a bit, but I suspect that the REAL design flaws are at a more fundamental level (given what I have seen of the GUI framework) and that any replacement of threading, etc, libraries, unless it is a trivial task to complete, should be made during the implementation of the redesigned client, rather than piecemeal. Case in point being the GUI framework, which is hopelessly entangled, as is. The UI roadmap calls for sufficient refactoring to eventually provide a viewerless GUI test-client AND a GUI-less client library that can be ported to other systems in a form other than as a standalone application in home workstations (Second Life on an iPhone III?) This is a double-plus good thing, and is essential for any REAL redesign of both the viewer AND the GUI framework to take place. But that doesn't mean that we can't start discussing these issues and drawing pretty boxes and sharing them now, rather than waiting until the initial divorce of the GUI and viewer is complete. Certainly, I'll be buttonholing Benjamin regularly with my pie-in-the-sky user interface ideas (like optionally linking WindLight themes to GUI skins when you enter a new sim, for example, with HUD controls that modify the appearance of the GUI clientside. Howabout combat sims, where the explosions not only light up the sky, but also are reflected on the pitted-metal, military-HUD-like client GUI. Or the Goth Masquerade sim that does the same with lightning and creepy-looking GUI textures? ). L. From seg at haxxed.com Wed Sep 12 20:53:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 12 20:53:51 2007 Subject: [sldev] Re: [META] Improving the source code In-Reply-To: <46E8B21B.30204@cox.net> References: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> <46E88F32.10701@blueflash.cc> <46E8B21B.30204@cox.net> Message-ID: <1189655626.18800.64.camel@localhost> On Wed, 2007-09-12 at 20:44 -0700, Lawson English wrote: > Nicholaz Beresford wrote: > > > > Michael Miller wrote: > >> Let's revamp the client, and show them that we can do > >> something useful! > > > > I can't help it but this reasoning sounds pretty backward. > > > > > Unless you're hoping to be hired by Linden Labs of course... ;-) Meh, he speaks as if we all aren't already diligently hacking away at our own personal pet peeves. Patch or GTFO. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070912/1152e31b/attachment.pgp From lenglish5 at cox.net Wed Sep 12 21:08:50 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 12 21:08:53 2007 Subject: [sldev] Re: [META] Improving the source code In-Reply-To: <1189655626.18800.64.camel@localhost> References: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> <46E88F32.10701@blueflash.cc> <46E8B21B.30204@cox.net> <1189655626.18800.64.camel@localhost> Message-ID: <46E8B7D2.5000008@cox.net> Callum Lerwick wrote: > On Wed, 2007-09-12 at 20:44 -0700, Lawson English wrote: > >> Nicholaz Beresford wrote: >> >>> Michael Miller wrote: >>> >>>> Let's revamp the client, and show them that we can do >>>> something useful! >>>> >>> I can't help it but this reasoning sounds pretty backward. >>> >>> >>> >> Unless you're hoping to be hired by Linden Labs of course... ;-) >> > > Meh, he speaks as if we all aren't already diligently hacking away at > our own personal pet peeves. > > Patch or GTFO. :) > Patching is ll very well, but there's patching the code, and revamping the design, and in the long run, both need to be done. LL will likely set the design agenda for a long time, if not forever, but that doesn't mean we can't present our ideas and make our case why they are good ones. L. From kamilion at gmail.com Thu Sep 13 01:50:01 2007 From: kamilion at gmail.com (Kamilion) Date: Thu Sep 13 01:50:11 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> Message-ID: Personally, I wouldn't mind it it popped up the little blue box on the bottom normally reserved for "Some Person has come online" that said "Some Person has been auto-muted". As long as the user has a fair chance of being informed of an action, it's perfectly fine for the server to automatically perform actions that benefit the user. However, the mute should also be automatically removed either after X hours or when leaving the parcel or simulator. Any automated action should be undone after it's no longer needed. Just my two cents. ;) On 9/12/07, Andre Roche wrote: > Another feature to throw into that would be to, effective immediately upon > banning from the land, return all objects owned by that person. As far as > the muting thing goes. I don't think the server should ever tell my > personal client's mute list to add someone to it without me knowing. On the > other hand, I think you're right in the idea that a person who is banned > from a parcel should have no effect on or visibility by persons within that > area. > > Nice set up you got there with the particle tracker Dale. Only thing I can > think to suggest is that the particle system itself isn't so blatantly > displayed... Might upset some scripters/particle makers with that. > > > On 9/12/07, Dale Glass wrote: > > > > I've been working on various improvements to make moderation as fast and > > convenient and possible. > > > > Now I've added: > > > > An avatar list, which allows finding people quickly, as well as performing > > actions like ejecting from land on multiple people at once. > > > > An option to log the owner and location of speaking objects, for tracking > > down spam and objects trying to impersonate an avatar. > > > > An "event log", currently tracking particle emission, and soon sounds as > > well. This allows to figure out who is the one flooding the area in > > particles near instantly. Here's a picture of this in action (not released > > yet): > http://daleglass.net/images/screenshots/particles3.png > > > > > > So I got to test all this in practice yesterday during an attack on > > Luskwood. Result was: As intended, this makes it very quick and easy to > > find the attacker and ban them. But that's not much good. > > > > I teleported to Lusk, saw the particles, and issued the command to ban the > > owner of particle spamming self-replicating objectsr maybe 5 seconds after > > I saw the particles. But the practical result was about zilch because the > > attacker wasn't on Luskwood land (probably nowhere near as well) in the > > first place. So somebody who possibly never intended to enter Luskwood > > land got banned from there and was still causing problems just fine. This > > is not good. > > > > > > My suggestion to fix this: Automatically temporarily add to everybody's > > mute list the avatars banned from the parcel, while the avatar remains on > > the parcel. This will mean that while you're on the parcel where somebody > > is banned, they or their particles won't be seen if they're hovering right > > outside the banline. > > > > This should be an option, so that the area's moderators can see what is > > really going on if needed. This needs to be on by default, because > > otherwise it's ineffective. > > > > > > In principle, part of this can be implemented quite easily by requesting > > the parcel's banlist each time a parcel border is crossed (could have a > > delay to save some performance impact and avoid unnecessary banlist > > fetches while flying around). > > > > LL's help would be needed so that when somebody updates the banlist all > the > > viewers in the parcel automatically get their list updated. > > > > > > How does this sound? > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dale at daleglass.net Thu Sep 13 03:15:56 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 13 03:16:01 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> Message-ID: <20070913101555.GA26259@bruno.sbruno> On Thu, Sep 13, 2007 at 01:50:01AM -0700, Kamilion wrote: > Personally, I wouldn't mind it it popped up the little blue box on the > bottom normally reserved for "Some Person has come online" that said > "Some Person has been auto-muted". As long as the user has a fair > chance of being informed of an action, it's perfectly fine for the > server to automatically perform actions that benefit the user. I like that idea, will do that :-) > However, the mute should also be automatically removed either after X > hours or when leaving the parcel or simulator. Any automated action > should be undone after it's no longer needed. It'll be automatically applied when you change parcel, and undone when you leave it. Another idea: Extend muting avatars to muting their objects as well. Maybe even make banned avatars' objects invisible if they're outside the parcel. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/05200fac/attachment-0001.pgp From secret.argent at gmail.com Thu Sep 13 06:02:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 13 06:02:27 2007 Subject: [sldev] Re: [VIEWER] Suggestion to improve moderation capabilities: auto-mute banned avatars (Dale Glass) In-Reply-To: <20070913101605.8573C41B0C8@stupor.lindenlab.com> References: <20070913101605.8573C41B0C8@stupor.lindenlab.com> Message-ID: <8091E5D6-C342-42F4-9E88-F1E44B0654D3@gmail.com> Dale Glass wrote: >> However, the mute should also be automatically removed either after X >> hours or when leaving the parcel or simulator. Any automated action >> should be undone after it's no longer needed. > It'll be automatically applied when you change parcel, and undone when > you leave it. How about extending this to allow a parcel owner to set some attribute in whatever mechanism you're using to implement this (some scripted object, I assume) to mark an adjacent parcel's contents (by parcel boundaries, since the client already has this capability) as being muted. So if I have a giant toilet or spinny box next door, people using your client won't see them. This would also act as a prototype for playing with the user interface for some of the ideas that have been presented for sim-side privacy controls. Like, displaying some particle system at the location of muted avatars (I vote for a pac-man ghost sprite). From monkowsk at watson.ibm.com Thu Sep 13 07:43:46 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Sep 13 07:43:50 2007 Subject: [sldev] Thursday Open Source Meeting In-Reply-To: <9e6e5c9e0709121640u68d4cccfw895375777ebacfbe@mail.gmail.com> References: <9e6e5c9e0709121640u68d4cccfw895375777ebacfbe@mail.gmail.com> Message-ID: <46E94CA2.5090903@watson.ibm.com> > Open Source Meeting/Agenda > From Second Life Wiki > Jump to: navigation, search > > < Open Source Meeting > > Open source meeting - Thursday, 2pm PT. > > Teleport to the Linden Open Source Project headquarters. > > > [edit] Agenda > > * FREE SEG I love it! :-) From mdepascale at dii.unisi.it Thu Sep 13 08:46:53 2007 From: mdepascale at dii.unisi.it (Maurizio de Pascale) Date: Thu Sep 13 08:47:06 2007 Subject: [sldev] adding support for a new input device to the SL viewer Message-ID: <46E95B6D.2080703@dii.unisi.it> Hi everybody, I'm working at adding support to the SL viewer for a new input device. the short term goal, in order to learn how the input system is designed, is to just replace the mouse (actually provide a non mutually exclusive alternative). the long term goal is to have the new device controlling operations not handled by the mouse. can anyone point me to the sources/classes/functions building up the input system or provide docs on this? working on the short goal: So far, by tracing an execution, I've seen that mouse input are received through standard window messages (i'm working on windows version) by the LLWindowWin32 class and then passed up to LLViewerWindow class through the handleMouseXXX methods. it seems to me that the two invocations in the main loop: > gKeyboard->scanKeyboard(); > LLViewerJoystick::scanJoystick(); do not handle mouse input. are this correct? additionally, what is the best way to proceed: 1) use the new device state to generate and post mouse messages on the queue and have them handled as coming out from the mouse? 2) calling directly the handleMouseXXX methods? 3) ignoring the mouse input handling and calling directly "what's called from" handleMouseXXX methods to have viewer react accordingly? at a first glance, for the long term, having a class like LLViewerJoystick looks like the way to go. Am I right? Thank You in advance, every suggestion will be really appreciated. regards, Maurizio de Pascale mdepascale@dii.unisi.it From odysseus654 at gmail.com Thu Sep 13 09:19:05 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Thu Sep 13 09:19:07 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <20070913101555.GA26259@bruno.sbruno> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> <20070913101555.GA26259@bruno.sbruno> Message-ID: <1674f6c70709130919q2358a13dt7fddda84a238437f@mail.gmail.com> On 9/13/07, Dale Glass wrote: > > > However, the mute should also be automatically removed either after X > > hours or when leaving the parcel or simulator. Any automated action > > should be undone after it's no longer needed. > It'll be automatically applied when you change parcel, and undone when > you leave it. Just my couple cents, I would almost like to see this "parcel mute list" maintained separately from the user mute list. That way we don't end up with problems like we do with touch() events in LSL. What happens if a user redmaps or leaves the parcel in an uncontrolled fashion? We don't exactly want to be fixing bugs here regarding failure to un-mess up their mute list... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070913/eaa2a67c/attachment.htm From monkowsk at watson.ibm.com Thu Sep 13 10:40:37 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Sep 13 10:40:40 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: <46E95B6D.2080703@dii.unisi.it> References: <46E95B6D.2080703@dii.unisi.it> Message-ID: <46E97615.70300@watson.ibm.com> Maurizio de Pascale wrote: > can anyone point me to the sources/classes/functions building up the > input system or provide docs on this? If it's not on the Wiki, it probably doesn't exist. Since open source for SecondLife is relatively new, there's a lot that's not documented yet. My approach has been to document first then start coding. I have found doxygen, http://www.stack.nl/~dimitri/doxygen/index.html , very useful for navigating around the code. Mike From seg at haxxed.com Thu Sep 13 10:45:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 13 10:45:28 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: <46E95B6D.2080703@dii.unisi.it> References: <46E95B6D.2080703@dii.unisi.it> Message-ID: <1189705520.18800.80.camel@localhost> On Thu, 2007-09-13 at 17:46 +0200, Maurizio de Pascale wrote: > additionally, what is the best way to proceed: > 1) use the new device state to generate and post mouse messages on the > queue and have them handled as coming out from the mouse? > 2) calling directly the handleMouseXXX methods? > 3) ignoring the mouse input handling and calling directly "what's called > from" handleMouseXXX methods to have viewer react accordingly? > > at a first glance, for the long term, having a class like > LLViewerJoystick looks like the way to go. Am I right? The entire input layer needs to be abstracted such that events from joysticks, keyboards, gamepads, mice and whatever else can be quickly and easily bound to any function desired. Like you can do in Quake, Doom, Unreal, Half Life and pretty much every other game on the planet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/b18549e5/attachment.pgp From bos at lindenlab.com Thu Sep 13 11:12:36 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Sep 13 11:12:38 2007 Subject: [sldev] Improving the source code In-Reply-To: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> References: <2c99c46e0709121727r2b0fe8c6xd380a2794840b3a6@mail.gmail.com> Message-ID: <46E97D94.9070105@lindenlab.com> Michael Miller wrote: > I think that updating the code is a great way to show Lindens that the > open source community can be useful. We're always receptive to patches. If you want a hint regarding stuff that I'd personally love to see cleaned up, but that isn't broken enough to qualify for a substantial amount of internal effort, take a look at the pre-STL collection classes. Replacing even one of those with an appropriate use of an STL container would be very welcome, and I think that it will also give you an appreciation for why we don't generally leap all over refactoring work, for better or worse. (In other words, I'd recommend being very conservative in your initial approach.) References: <46E95B6D.2080703@dii.unisi.it> Message-ID: <20070913111428.03f976d1@superserver> On Thu, 13 Sep 2007 17:46:53 +0200 Maurizio de Pascale wrote: > I'm working at adding support to the SL viewer for a new input device. > the short term goal, in order to learn how the input system is > designed, is to just replace the mouse (actually provide a non > mutually exclusive alternative). > the long term goal is to have the new device controlling operations > not handled by the mouse. This is what I've just started looking into. I recently acquired a set of 3D modeling devices, basically a large 'keypad' with controllable LEDs in each key and another box with 8 high-resolution sensing knobs. I can currently send knob changes as XML-RPC to an in-world script but that's slow so I'm interested in putting some code into the client that somehow is able to communicate more fluidly with in-world scripts. I suggested on the Linden feature request forum that they could provide a general device input menu that lets you map perhaps different types of game controller inputs as 'input channels' which can be received by scripts in-world, as either boolean states or integer values. I suggested it could support standard game controllers as well as MIDI devices, where one could say use sliders from a Fostex VM200 console to control stage-lighting in- game. The possibilities are pretty endless, but my suggestion didn't get as many votes as I hoped it would. :) Bunny Brewster From ashea at ups.com Thu Sep 13 11:50:00 2007 From: ashea at ups.com (ashea@ups.com) Date: Thu Sep 13 11:50:43 2007 Subject: [sldev] adding support for a new input device to the SL viewer References: <46E95B6D.2080703@dii.unisi.it> <20070913111428.03f976d1@superserver> Message-ID: I've been following this list for a few weeks now and I think some people have the wrong idea about open source. First, we don't need permission or approval of Linden Labs to make patches or add new features and we can totally rewrite any portions that we want to. Anyone can make changes and distribute their own version of the viewer. This hopefully will inspire competition in building "a better mouse trap". Linden is only involved if you want your ideas and patches included in their build. But if you have ideas that Linden doesn't want to use, then go ahead and incorporate them into your own build. This is the whole idea of open source. The open market will decide which build they want to use. Anthony -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Negroponte J. Rabit Sent: Thursday, September 13, 2007 2:14 PM To: sldev@lists.secondlife.com Subject: Re: [sldev] adding support for a new input device to the SL viewer On Thu, 13 Sep 2007 17:46:53 +0200 Maurizio de Pascale wrote: >> The possibilities are pretty endless, but my suggestion didn't get as many votes as I hoped it would. :) Bunny Brewster _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From rabit at audicity.com Thu Sep 13 12:15:55 2007 From: rabit at audicity.com (Negroponte J. Rabit) Date: Thu Sep 13 12:16:00 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: References: <46E95B6D.2080703@dii.unisi.it> <20070913111428.03f976d1@superserver> Message-ID: <20070913121555.67b30cfc@superserver> You are very correct. My submission to the feature request form was made before the viewer was open-sourced, however. Also, while it may sound nice to have people hacking and distributing their own customized versions of the viewer, there is a potential disaster on Linden Labs hands if users began running untrusted, potentially trojaned software to log into their Second Life account. Bunny Brewster On Thu, 13 Sep 2007 14:50:00 -0400 wrote: > I've been following this list for a few weeks now and I think some > people have the wrong idea about open source. First, we don't need > permission or approval of Linden Labs to make patches or add new > features and we can totally rewrite any portions that we want to. > Anyone can make changes and distribute their own version of the > viewer. This hopefully will inspire competition in building "a better > mouse trap". Linden is only involved if you want your ideas and > patches included in their build. But if you have ideas that Linden > doesn't want to use, then go ahead and incorporate them into your own > build. This is the whole idea of open source. The open market will > decide which build they want to use. > > Anthony > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Negroponte J. > Rabit > Sent: Thursday, September 13, 2007 2:14 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] adding support for a new input device to the SL > viewer > > On Thu, 13 Sep 2007 17:46:53 +0200 > Maurizio de Pascale wrote: > > >> The possibilities are pretty endless, but my suggestion didn't get > >> as > many votes as I hoped it would. :) > > Bunny Brewster > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From secret.argent at gmail.com Thu Sep 13 12:16:59 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 13 12:17:01 2007 Subject: [sldev] RE: [META] adding support for a new input device to the SL viewer In-Reply-To: <20070913185044.639E141B249@stupor.lindenlab.com> References: <20070913185044.639E141B249@stupor.lindenlab.com> Message-ID: <19CF5813-65F7-4DC6-B1C1-8031A832714D@gmail.com> Anthony writes: > I've been following this list for a few weeks now and I think some > people have the wrong idea about open source. First, we don't need > permission or approval of Linden Labs to make patches or add new > features and we can totally rewrite any portions that we want to. > Anyone > can make changes and distribute their own version of the viewer. This > hopefully will inspire competition in building "a better mouse trap". > Linden is only involved if you want your ideas and patches included in > their build. But if you have ideas that Linden doesn't want to use, > then > go ahead and incorporate them into your own build. This is the whole > idea of open source. The open market will decide which build they want > to use. On the one hand, yes, you're right... a completely Linden-independent fork of the viewer could be implemented. On the other hand... that doesn't mean it would be practical to have, long term, dozens of versions of the viewer maintained independently and continually having to be resynced. On the gripping hand, you still need to have the resulting fork remain compatible with the Linden servers, so it's going to have to track changes in the Linden tree. SL is "open source", but it's not an "open system", because the protocol and server behavior are under a single company's control. From ettore_pasquini at 3dconnexion.com Thu Sep 13 14:06:33 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Thu Sep 13 14:06:43 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: <46E95B6D.2080703@dii.unisi.it> Message-ID: On 9/13/07 8:46 AM, "Maurizio de Pascale" wrote: > I'm working at adding support to the SL viewer for a new input device. > the short term goal, in order to learn how the input system is designed, > is to just replace the mouse (actually provide a non mutually exclusive > alternative). > the long term goal is to have the new device controlling operations not > handled by the mouse. I've been working on something like this on and off for a while (whenever I have some free time) and currently I have a solution more or less working for controlling the avatar, edit mode and flycam for Windows and OS X. Maybe we can work together... > can anyone point me to the sources/classes/functions building up the > input system or provide docs on this? not much is available: https://wiki.secondlife.com/wiki/How_movement_works https://wiki.secondlife.com/wiki/How_the_camera_works > So far, by tracing an execution, I've seen that mouse input are received > through standard window messages (i'm working on windows version) by the > LLWindowWin32 class and then passed up to LLViewerWindow class through > the handleMouseXXX methods. > > it seems to me that the two invocations in the main loop: >> gKeyboard->scanKeyboard(); >> LLViewerJoystick::scanJoystick(); > do not handle mouse input. > > are this correct? I think so - my approach was not to follow the mouse events flow because it was just too crazy and platform specific. To get something moving (quick and dirty style) I just added a scanDevice() call after scanJoystick, but that's bad as well. The best approach I think depends on what kind of device you're working on: if you're working with joysticks, 3D mice or other N degrees of freedom devices I say LLViewerJoystick is a good class to expand. That's what I'm doing right now. > additionally, what is the best way to proceed: > 1) use the new device state to generate and post mouse messages on the > queue and have them handled as coming out from the mouse? > 2) calling directly the handleMouseXXX methods? > 3) ignoring the mouse input handling and calling directly "what's called > from" handleMouseXXX methods to have viewer react accordingly? > > at a first glance, for the long term, having a class like > LLViewerJoystick looks like the way to go. Am I right? Hacking the event system with fake mouse events seem the way to Event Hell IMO. This is what I did/am doing (I plan on posting some patches in a few days): - As you know the viewer already uses DirectInput on windows for the flycam. On OS X I'm using the HID manager, and I believe there is a library on Linux to handle HID devices. - I developed an open source library to have a cross-platform API to access the device. The implementation is DI on Win and HID on OS X, any other platforms can be added by just implementing a few functions. This makes viewer code unaware of the underlying implementation. - I am refactoring the joystick implementation to use the above library. Sorry if this is too vague - expect a patch soon. Ettore -- http://www.3dconnexion.com/ From roamingryozu at gmail.com Thu Sep 13 14:23:55 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Thu Sep 13 14:23:59 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> Message-ID: <5eff6d3b0709131423s773423cckd5c5985e072f2420@mail.gmail.com> I still don't think I'd be satisfied with that. Scenario 1: Me and a friend are IMing each other while on a parcel. Some admin decides to ban him for whatever reason, but not me. I'm not longer able to IM him, or sort out just why he was banned, or even who banned him. Scenario 2: I'm speaking with a customer over IM, while exploring various areas of SL. I walk onto a parcel where that user had been banned. After many minutes of frustration wondering why the conversation died and the user is not replying, I have to leave the parcel again or manually unmute them to continue the conversation. Any notification could very well be missed, or flooded away by other notifications. There are ways to work around these, such as not including IMs in this server made mute list, however I don't believe that's a suitable answer. I'm all for controlling my own experience, not arbitrary control of my experience by someone else. >Another idea: Extend muting avatars to muting their objects as well. Maybe even make banned avatars' objects invisible if they're outside the parcel. This on the other hand, I'd fully support. If I mute someone, I don't want to hear their objects either, probably. Though I'd also like to know that someone has muted me. I've had occasions where trying to help a customer who didn't receive their purchase, turns out they had muted me for whatever reason before making the purchase, and now I couldn't even figure out how to tell them this except through object IM. It's muting is a tricky thing to handle. On 9/13/07, Kamilion wrote: > > Personally, I wouldn't mind it it popped up the little blue box on the > bottom normally reserved for "Some Person has come online" that said > "Some Person has been auto-muted". As long as the user has a fair > chance of being informed of an action, it's perfectly fine for the > server to automatically perform actions that benefit the user. > However, the mute should also be automatically removed either after X > hours or when leaving the parcel or simulator. Any automated action > should be undone after it's no longer needed. > > Just my two cents. ;) > > On 9/12/07, Andre Roche wrote: > > Another feature to throw into that would be to, effective immediately > upon > > banning from the land, return all objects owned by that person. As far > as > > the muting thing goes. I don't think the server should ever tell my > > personal client's mute list to add someone to it without me knowing. On > the > > other hand, I think you're right in the idea that a person who is banned > > from a parcel should have no effect on or visibility by persons within > that > > area. > > > > Nice set up you got there with the particle tracker Dale. Only thing I > can > > think to suggest is that the particle system itself isn't so blatantly > > displayed... Might upset some scripters/particle makers with that. > > > > > > On 9/12/07, Dale Glass wrote: > > > > > > I've been working on various improvements to make moderation as fast > and > > > convenient and possible. > > > > > > Now I've added: > > > > > > An avatar list, which allows finding people quickly, as well as > performing > > > actions like ejecting from land on multiple people at once. > > > > > > An option to log the owner and location of speaking objects, for > tracking > > > down spam and objects trying to impersonate an avatar. > > > > > > An "event log", currently tracking particle emission, and soon sounds > as > > > well. This allows to figure out who is the one flooding the area in > > > particles near instantly. Here's a picture of this in action (not > released > > > yet): > > http://daleglass.net/images/screenshots/particles3.png > > > > > > > > > So I got to test all this in practice yesterday during an attack on > > > Luskwood. Result was: As intended, this makes it very quick and easy > to > > > find the attacker and ban them. But that's not much good. > > > > > > I teleported to Lusk, saw the particles, and issued the command to ban > the > > > owner of particle spamming self-replicating objectsr maybe 5 seconds > after > > > I saw the particles. But the practical result was about zilch because > the > > > attacker wasn't on Luskwood land (probably nowhere near as well) in > the > > > first place. So somebody who possibly never intended to enter Luskwood > > > land got banned from there and was still causing problems just fine. > This > > > is not good. > > > > > > > > > My suggestion to fix this: Automatically temporarily add to > everybody's > > > mute list the avatars banned from the parcel, while the avatar remains > on > > > the parcel. This will mean that while you're on the parcel where > somebody > > > is banned, they or their particles won't be seen if they're hovering > right > > > outside the banline. > > > > > > This should be an option, so that the area's moderators can see what > is > > > really going on if needed. This needs to be on by default, because > > > otherwise it's ineffective. > > > > > > > > > In principle, part of this can be implemented quite easily by > requesting > > > the parcel's banlist each time a parcel border is crossed (could have > a > > > delay to save some performance impact and avoid unnecessary banlist > > > fetches while flying around). > > > > > > LL's help would be needed so that when somebody updates the banlist > all > > the > > > viewers in the parcel automatically get their list updated. > > > > > > > > > How does this sound? > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070913/b1c64ff3/attachment.htm From kamilion at gmail.com Thu Sep 13 14:50:50 2007 From: kamilion at gmail.com (Kamilion) Date: Thu Sep 13 14:50:55 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <1674f6c70709130919q2358a13dt7fddda84a238437f@mail.gmail.com> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> <20070913101555.GA26259@bruno.sbruno> <1674f6c70709130919q2358a13dt7fddda84a238437f@mail.gmail.com> Message-ID: On 9/13/07, Erik Anderson wrote: > > On 9/13/07, Dale Glass wrote: > > > However, the mute should also be automatically removed either after X > > > hours or when leaving the parcel or simulator. Any automated action > > > should be undone after it's no longer needed. > > It'll be automatically applied when you change parcel, and undone when > > you leave it. > > Just my couple cents, I would almost like to see this "parcel mute list" > maintained separately from the user mute list. That way we don't end up > with problems like we do with touch() events in LSL. What happens if a user > redmaps or leaves the parcel in an uncontrolled fashion? We don't exactly > want to be fixing bugs here regarding failure to un-mess up their mute > list... > If I'm second-guessing Dale correctly, I'm thinking that this is mostly all clientside. I'm guessing the mutelist would likely be in an array of some kind that just gets thrown away when a parcel change on the client is detected. > My suggestion to fix this: Automatically temporarily add to everybody's > mute list the avatars banned from the parcel When someone is banned from a parcel, clients on that parcel mute the banned resident, preventing griefers in the next parcel over from bothering anyone on the parcel the ban was set on. When you leave that parcel, the temporary mute list is dumped in favor of the new parcel's banlist. Boils down to: If you're banned on a parcel, everyone on that parcel automagically mutes you, even if you're not on the parcel. Muting of this type probably should not mute IMs specifically. > In principle, part of this can be implemented quite easily by requesting > the parcel's banlist each time a parcel border is crossed (could have a > delay to save some performance impact and avoid unnecessary banlist > fetches while flying around). Sounds to me like we need something like a way to query the server for a timestamp of when a parcel's banlist was last updated. This way, we can cache the banlist for frequently visited parcels, and be notified when the banlist has changed. Last I poked around with CAPS, they accept the connection, sit there, and basically either timeout or return data when something happens. Sounds like a dead simple addition on LL's side of one or two caps: deferred request for the return of the banlist modified-time-stamp, and immediate request. Reading some of the messages earlier this month about the public CAPS urls, they seem to be able to take HTTP GET values: https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=slRegionName&grid_x=997&grid_y=1002 So what we'd be looking at would be similar to: https://cap.secondlife.com/cap/0/941ff5db-4586-4b40-b533-ba62648118e2?var=slParcelBanTimeStamp&sim_name=Luskwood&parcel_id=398472947&now=1 [NOTE: THIS DOES NOT REALLY EXIST, IT'S JUST A MOCKUP] Hopefully this isn't too much to ask ;) However, if I'm not mistaken, progress on the client in this area has already been done: http://ablewhitman.org/blog/ Able Whitman's been working on his Mute Visibility patches for a while. Perhaps you should take a look at 'em and see if he's already implemented some of the bits you need to pull this off. Also, I'm sure OSLCC could benefit from Dale, Nick, and Able's patches. https://sourceforge.net/projects/oslcc Stamp out griefers: When they can't get their lulz from you anymore, they'll get bored and go find someone else to bother. Good Luck, Free Seg! From kamilion at gmail.com Thu Sep 13 14:59:10 2007 From: kamilion at gmail.com (Kamilion) Date: Thu Sep 13 14:59:13 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <5eff6d3b0709131423s773423cckd5c5985e072f2420@mail.gmail.com> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709121646r72258dc0s1b273643060ace3f@mail.gmail.com> <5eff6d3b0709131423s773423cckd5c5985e072f2420@mail.gmail.com> Message-ID: On 9/13/07, Andre Roche wrote: > Though I'd also like to know that someone has muted me. I've had occasions > where trying to help a customer who didn't receive their purchase, turns out > they had muted me for whatever reason before making the purchase, and now I > couldn't even figure out how to tell them this except through object IM. I've had that problem before. My poor solution: http://delta.slinked.net/second-life/sleek I just log in with an alt through SLeek and IM them. It's not pretty, or elegant, but it works. Free Seg! From dale at daleglass.net Thu Sep 13 15:06:57 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 13 15:07:10 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: References: <200709121033.55622.dale@daleglass.net> <1674f6c70709130919q2358a13dt7fddda84a238437f@mail.gmail.com> Message-ID: <200709140007.03010.dale@daleglass.net> On Thursday 13 September 2007 23:50:50 Kamilion wrote: > If I'm second-guessing Dale correctly, I'm thinking that this is > mostly all clientside. Right. > I'm guessing the mutelist would likely be in an array of some kind > that just gets thrown away when a parcel change on the client is > detected. That's the idea. > Sounds to me like we need something like a way to query the server for > a timestamp of when a parcel's banlist was last updated. This way, we > can cache the banlist for frequently visited parcels, and be notified > when the banlist has changed. Why a timestamp instead of a notification about that an avatar was banned sent to everybody on the parcel automatically? Then updates can be sent incrementally. The banlist can be very long in some places. Seems inefficient to reload it fully every time to just add an extra entry. > Stamp out griefers: When they can't get their lulz from you anymore, > they'll get bored and go find someone else to bother. That's the idea :-) If we can effectively defend ourselves grieifing becomes a lot more boring. The ideal situation IMO will be when I can issue a command and have that avatar be unable to cause any further trouble after that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/facfb523/attachment.pgp From dale at daleglass.net Thu Sep 13 15:11:40 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 13 15:11:52 2007 Subject: [sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars In-Reply-To: <5eff6d3b0709131423s773423cckd5c5985e072f2420@mail.gmail.com> References: <200709121033.55622.dale@daleglass.net> <5eff6d3b0709131423s773423cckd5c5985e072f2420@mail.gmail.com> Message-ID: <200709140011.45886.dale@daleglass.net> On Thursday 13 September 2007 23:23:55 Andre Roche wrote: > I still don't think I'd be satisfied with that. > > Scenario 1: Me and a friend are IMing each other while on a parcel. > Some admin decides to ban him for whatever reason, but not me. I'm not > longer able to IM him, or sort out just why he was banned, or even who > banned him. IM could be excluded. The main point is removing the very annoying ability of somebody sitting right outside your land to flood everybody present with junk on the main channel and particles. IMs are a much lesser problem, muting is easy and it's harder to disrupt the general activity of the area with it. > Though I'd also like to know that someone has muted me. I've had > occasions where trying to help a customer who didn't receive their > purchase, turns out they had muted me for whatever reason before making > the purchase, and now I couldn't even figure out how to tell them this > except through object IM. This sounds fairly easy, muted IMs still get logged, so all you need to do is to make your viewer automatically IM back with an automated reply saying you're being ignored. Some help from LL could be useful here: It'd be nice to have an "automated message" type for this, to be able to give it a different color, and to eliminate the possibility of a message loop by having one automated service replying to another. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/7e5a2c87/attachment.pgp From seg at haxxed.com Thu Sep 13 15:53:44 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 13 15:53:49 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: References: Message-ID: <1189724024.18800.83.camel@localhost> On Thu, 2007-09-13 at 14:06 -0700, Ettore Pasquini wrote: > - As you know the viewer already uses DirectInput on windows for the flycam. > On OS X I'm using the HID manager, and I believe there is a library on Linux > to handle HID devices. > - I developed an open source library to have a cross-platform API to access > the device. The implementation is DI on Win and HID on OS X, any other > platforms can be added by just implementing a few functions. This makes > viewer code unaware of the underlying implementation. > - I am refactoring the joystick implementation to use the above library. Is there a reason you can't just use SDL's joystick layer rather than reinventing more wheels? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/54bf219d/attachment.pgp From anthony at lindenlab.com Thu Sep 13 15:57:51 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Sep 13 15:57:54 2007 Subject: [sldev] Source release for RC 1.18.3.3 Message-ID: <46E9C06F.1030203@lindenlab.com> Hello Everyone, Here's the source drop for latest viewer release, which is Release Candidate version 1.18.3.3. We would normally also put out the release snapshot, but as it stands release is in a known bad state. A snapshot will be release tomorrow though even if we haven't caught anything, just to give everyone the weekend to look at it. 1.18.3.3 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.3.3 Release note information here: http://blog.secondlife.com/2007/09/13/now-available-release-candidate-viewer-update/ Checksums: 0da18744a1e78bd2133dc0aeb00c50b6 slviewer-darwin-libs-RC-1.18.3.3.tar.gz 278a03c1bb2e6615589654c8fbc51e52 slviewer-linux-libs-RC-1.18.3.3.tar.gz d8670c7e6e6f1c7abfbee7862dc7cd0f slviewer-src-RC-1.18.3.3.tar.gz ce0faf1005a8277f79c7780d7a7dfd37 slviewer-artwork-RC-1.18.3.3.zip b30cabb7116e90c3bd5218ad43f61363 slviewer-src-RC-1.18.3.3.zip 6b9cfbb1838f944c70360d3d2d89a37f slviewer-win32-libs-RC-1.18.3.3.zip SVN checkout: Rob will send email about this once it's up. Enjoy. -Anthony From bridie at lindenlab.com Thu Sep 13 16:01:43 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Thu Sep 13 16:01:40 2007 Subject: [sldev] Now Available: Release Candidate Viewer Update Message-ID: <46E9C157.1010508@lindenlab.com> Hi SLDev folks- An updated 1.18.3 RC Viewer is now available: http://www.secondlife.com/community/downloads-optional.php Source code drop coming soon, too. Thanks again for everyone's who's been providing feedback and filing bugs! --Bridie From bridie at lindenlab.com Thu Sep 13 16:04:30 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Thu Sep 13 16:04:28 2007 Subject: [sldev] Now Available: Release Candidate Viewer Update In-Reply-To: <46E9C157.1010508@lindenlab.com> References: <46E9C157.1010508@lindenlab.com> Message-ID: <46E9C1FE.3000900@lindenlab.com> And by 'soon', I mean 4 mins prior to my sending my previous email -- thank you Anthony! --Bridie Bridie Linden wrote: > Hi SLDev folks- > > An updated 1.18.3 RC Viewer is now available: > http://www.secondlife.com/community/downloads-optional.php > > Source code drop coming *soon*, too. > > Thanks again for everyone's who's been providing feedback and filing > bugs! > > --Bridie > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070913/c3ca9df9/attachment.htm From robla at lindenlab.com Thu Sep 13 17:19:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 13 17:20:10 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. Message-ID: <46E9D388.3030204@lindenlab.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070913/c0802678/signature-0001.pgp From nicholaz at blueflash.cc Fri Sep 14 04:32:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Sep 14 04:32:17 2007 Subject: [sldev] [VIEWER] Funky(?) source code change in 1.18.3.3 Message-ID: <46EA713B.2010600@blueflash.cc> Thoughts? --- sl1_18_3_2\linden-orig\indra/newview/llpanelgroupgeneral.cpp 2007-08-29 14:13:08.00 0000000 +0200 +++ sl1_18_3_3\linden-orig\indra/newview/llpanelgroupgeneral.cpp 2007-09-13 15:35:22.00 0000000 +0200 @@ -509,6 +512,8 @@ mChanged = FALSE; notifyObservers(); + notifyObservers(); + return true; } From robin.cornelius at gmail.com Fri Sep 14 05:08:17 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Sep 14 05:08:20 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components Message-ID: Hi Everyone, Sorry if this is documented some where, if so then please just send me there :-) Whats the current code base staus wrt 64 bit systems. Is it capable of being compiled for an Athlon 64 (specifically on linux in this instance)? and what about the libs as well, as i will of cause need 64bit libs as well. I don't mind loosing fmod as it dosn't work too well for me at the best of times. Whist i remember, i saw a while ago a message saying the viewer had been compiled completely with open source components including all the gstreamer stuff. All i remember was that this is done internally by the Lindens but i have not seen anything else about this since. Thanks, Robin From david at fries.net Fri Sep 14 05:37:55 2007 From: david at fries.net (David Fries) Date: Fri Sep 14 05:38:18 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: References: Message-ID: <20070914123755.GA11645@spacedout.fries.net> I have the viewer compiled and running in 64 bit mode on an x86_64 with Debian. There are a couple libraries required that don't come with the distribution that you have to compile yourself, but ignore all the build steps about copying (shudder) system include/library files to the source tree and apply the included patch. That lets it reference the system include files the way the are supposed to be included. It does compile and run as a 64 bit binary, though people occasionally break things. On Fri, Sep 14, 2007 at 01:08:17PM +0100, Robin Cornelius wrote: > Hi Everyone, > > Sorry if this is documented some where, if so then please just send me there :-) > > Whats the current code base staus wrt 64 bit systems. Is it capable of > being compiled for an Athlon 64 (specifically on linux in this > instance)? and what about the libs as well, as i will of cause need > 64bit libs as well. I don't mind loosing fmod as it dosn't work too > well for me at the best of times. > > Whist i remember, i saw a while ago a message saying the viewer had > been compiled completely with open source components including all the > gstreamer stuff. All i remember was that this is done internally by > the Lindens but i have not seen anything else about this since. > > Thanks, > > > Robin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- next part -------------- Index: indra/SConstruct =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/SConstruct,v retrieving revision 1.10 retrieving revision 1.2.2.11 diff -u -p -w -r1.10 -r1.2.2.11 --- indra/SConstruct 18 Jul 2007 00:32:05 -0000 1.10 +++ indra/SConstruct 18 Jul 2007 00:33:07 -0000 1.2.2.11 @@ -194,7 +194,7 @@ for build_target in targets: if arch == 'x86_64' and os.path.exists('/usr/lib64'): client_external_libs = [File('/usr/lib64/libresolv.a')] else: - client_external_libs = ['llresolv6'] + client_external_libs = [File('/usr/lib/libresolv.a')] else: client_external_libs = ['resolv'] @@ -262,21 +262,9 @@ for build_target in targets: cppflags += '-DAPPID=secondlife -DLL_SDL=1 ' if arch == 'x86_64' or arch == 'x86_64cross' or not enable_fmod: cppflags += '-DLL_FMOD=0 ' + cppflags += '-DLL_FMOD=0 ' cppflags += '-DLL_X11=1 -DLL_GTK=1 ' - if standalone: - include_dirs += [d[2:] for d in - pkgconfig('--cflags-only-I').split()] - else: - client_external_libs += [ 'gtk-x11-2.0' ] - incdirs = [ 'ELFIO', 'atk-1.0', 'glib-2.0', 'gtk-2.0', - 'llfreetype2', 'pango-1.0' ] - include_dirs += ['../libraries/' + system_str + '/include/' + d - for d in incdirs] - - if elfio: - client_external_libs += [ 'elfio' ] - else: - cppflags += '-DLL_ELFBIN=0 ' + client_external_libs += [ 'gtk-x11-2.0', 'ELFIO' ] # llmozlib stuff if enable_mozlib: @@ -363,6 +351,11 @@ for build_target in targets: LIBPATH = lib_path, LINKFLAGS = system_link_flags + '--no-keep-memory --reduce-memory-overheads ' ) + # Add include and library paths. + base_env.ParseConfig('pkg-config --cflags gtk+-2.0'); + # gtk-config --cflags'); + base_env.ParseConfig('freetype-config --cflags'); + ### Environments for various build types ### env = base_env.Copy(CFLAGS=releasefordownload_cflags, @@ -578,8 +571,8 @@ for build_target in targets: if arch != 'x86_64' and arch != 'x86_64cross': if enable_fmod: external_libs += [ 'fmod-3.75' ] - if buildtype == 'debug': - external_libs += ['tcmalloc', 'stacktrace'] + #if buildtype == 'debug': + #external_libs += ['tcmalloc', 'stacktrace'] external_libs.remove('cares') Index: indra/llcommon/llapr.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llapr.h,v retrieving revision 1.3 retrieving revision 1.1.2.3 diff -u -p -w -r1.3 -r1.1.2.3 --- indra/llcommon/llapr.h 9 Jul 2007 00:12:04 -0000 1.3 +++ indra/llcommon/llapr.h 9 Jul 2007 00:19:49 -0000 1.1.2.3 @@ -37,11 +37,11 @@ #include -#include "apr-1/apr_thread_proc.h" -#include "apr-1/apr_thread_mutex.h" -#include "apr-1/apr_getopt.h" -#include "apr-1/apr_signal.h" -#include "apr-1/apr_atomic.h" +#include +#include +#include +#include +#include #include "llstring.h" Index: indra/llcommon/llbase64.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llbase64.cpp,v retrieving revision 1.3 retrieving revision 1.1.2.3 diff -u -p -w -r1.3 -r1.1.2.3 --- indra/llcommon/llbase64.cpp 13 May 2007 01:26:21 -0000 1.3 +++ indra/llcommon/llbase64.cpp 13 May 2007 02:06:43 -0000 1.1.2.3 @@ -33,7 +33,7 @@ #include -#include "apr-1/apr_base64.h" +#include // static @@ -60,4 +60,3 @@ std::string LLBase64::encode(const U8* i } return output; } - Index: indra/llcommon/lldate.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/lldate.cpp,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llcommon/lldate.cpp 13 May 2007 01:26:21 -0000 1.2 +++ indra/llcommon/lldate.cpp 13 May 2007 02:06:43 -0000 1.1.2.2 @@ -31,7 +31,7 @@ #include "linden_common.h" #include "lldate.h" -#include "apr-1/apr_time.h" +#include #include #include Index: indra/llcommon/llsdserialize.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llsdserialize.cpp,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llcommon/llsdserialize.cpp 13 May 2007 01:26:21 -0000 1.2 +++ indra/llcommon/llsdserialize.cpp 13 May 2007 02:06:43 -0000 1.1.2.2 @@ -34,7 +34,7 @@ #include "llstreamtools.h" // for fullread #include -#include "apr-1/apr_base64.h" +#include #if !LL_WINDOWS #include // htonl & ntohl Index: indra/llcommon/llsdserialize_xml.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llsdserialize_xml.cpp,v retrieving revision 1.4 retrieving revision 1.1.2.4 diff -u -p -w -r1.4 -r1.1.2.4 --- indra/llcommon/llsdserialize_xml.cpp 9 Jul 2007 00:12:04 -0000 1.4 +++ indra/llcommon/llsdserialize_xml.cpp 9 Jul 2007 00:19:49 -0000 1.1.2.4 @@ -32,11 +32,11 @@ #include #include -#include "apr-1/apr_base64.h" +#include extern "C" { -#include "expat/expat.h" +#include } /** Index: indra/llcommon/llsys.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llsys.cpp,v retrieving revision 1.4 retrieving revision 1.1.2.4 diff -u -p -w -r1.4 -r1.1.2.4 --- indra/llcommon/llsys.cpp 18 Jul 2007 00:32:05 -0000 1.4 +++ indra/llcommon/llsys.cpp 18 Jul 2007 00:33:07 -0000 1.1.2.4 @@ -31,7 +31,7 @@ #include "llsys.h" #include -#include +#include #include "processor.h" Index: indra/llcommon/llthread.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llcommon/llthread.h,v retrieving revision 1.3 retrieving revision 1.1.2.3 diff -u -p -w -r1.3 -r1.1.2.3 --- indra/llcommon/llthread.h 9 Jul 2007 00:12:04 -0000 1.3 +++ indra/llcommon/llthread.h 9 Jul 2007 00:19:49 -0000 1.1.2.3 @@ -33,7 +33,7 @@ #include "llapp.h" #include "llmemory.h" -#include "apr-1/apr_thread_cond.h" +#include class LLThread; class LLMutex; =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llimage/llimagej2c.cpp,v retrieving revision 1.5 retrieving revision 1.3.2.2 diff -u -p -w -r1.5 -r1.3.2.2 --- indra/llimage/llimagej2c.cpp 13 May 2007 01:26:22 -0000 1.5 +++ indra/llimage/llimagej2c.cpp 13 May 2007 02:06:43 -0000 1.3.2.2 @@ -26,12 +26,18 @@ */ #include "linden_common.h" -#include -#include +#include +#include #include "lldir.h" #include "llimagej2c.h" #include "llmemtype.h" +#include "llthread.h" +#include "lltimer.h" + +#include +#include +#include typedef LLImageJ2CImpl* (*CreateLLImageJ2CFunction)(); typedef void (*DestroyLLImageJ2CFunction)(LLImageJ2CImpl*); Index: indra/llimage/llimagejpeg.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llimage/llimagejpeg.h,v retrieving revision 1.5 retrieving revision 1.3.2.2 diff -u -p -w -r1.5 -r1.3.2.2 --- indra/llimage/llimagejpeg.h 13 May 2007 01:26:22 -0000 1.5 +++ indra/llimage/llimagejpeg.h 13 May 2007 02:06:43 -0000 1.3.2.2 @@ -34,8 +34,8 @@ #include "llimage.h" extern "C" { -#include "jpeglib/jpeglib.h" -#include "jpeglib/jerror.h" +#include +#include } class LLImageJPEG : public LLImageFormatted Index: indra/llimagej2coj/llimagej2coj.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llimagej2coj/llimagej2coj.cpp,v retrieving revision 1.12 retrieving revision 1.9.2.4 diff -u -p -w -r1.12 -r1.9.2.4 --- indra/llimagej2coj/llimagej2coj.cpp 13 May 2007 01:26:22 -0000 1.12 +++ indra/llimagej2coj/llimagej2coj.cpp 13 May 2007 02:06:44 -0000 1.9.2.4 @@ -31,7 +31,7 @@ // this is defined so that we get static linking. #define OPJ_STATIC -#include "openjpeg/openjpeg.h" +#include #include "lltimer.h" #include "llmemory.h" Index: indra/llmessage/llfiltersd2xmlrpc.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/llfiltersd2xmlrpc.cpp,v retrieving revision 1.3 retrieving revision 1.1.2.3 diff -u -p -w -r1.3 -r1.1.2.3 --- indra/llmessage/llfiltersd2xmlrpc.cpp 13 May 2007 01:26:22 -0000 1.3 +++ indra/llmessage/llfiltersd2xmlrpc.cpp 13 May 2007 02:06:44 -0000 1.1.2.3 @@ -77,8 +77,8 @@ #include #include -#include -#include "apr-1/apr_base64.h" +#include +#include #include "llbuffer.h" #include "llbufferstream.h" Index: indra/llmessage/llhttpassetstorage.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/llhttpassetstorage.cpp,v retrieving revision 1.5 retrieving revision 1.1.2.5 diff -u -p -w -r1.5 -r1.1.2.5 --- indra/llmessage/llhttpassetstorage.cpp 9 Jul 2007 00:12:04 -0000 1.5 +++ indra/llmessage/llhttpassetstorage.cpp 9 Jul 2007 00:19:49 -0000 1.1.2.5 @@ -38,7 +38,7 @@ #include "llvfile.h" #include "llvfs.h" -#include "zlib/zlib.h" +#include const U32 MAX_RUNNING_REQUESTS = 1; const F32 MAX_PROCESSING_TIME = 0.005f; Index: indra/llmessage/lliopipe.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/lliopipe.h,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llmessage/lliopipe.h 13 May 2007 01:26:22 -0000 1.2 +++ indra/llmessage/lliopipe.h 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -33,7 +33,7 @@ #include #include -#include "apr-1/apr_poll.h" +#include #include "llsd.h" Index: indra/llmessage/lliosocket.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/lliosocket.h,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llmessage/lliosocket.h 13 May 2007 01:26:22 -0000 1.2 +++ indra/llmessage/lliosocket.h 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -40,8 +40,8 @@ */ #include "lliopipe.h" -#include "apr-1/apr_pools.h" -#include "apr-1/apr_network_io.h" +#include +#include #include "llchainio.h" class LLHost; Index: indra/llmessage/llmail.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/llmail.cpp,v retrieving revision 1.5 retrieving revision 1.1.2.5 diff -u -p -w -r1.5 -r1.1.2.5 --- indra/llmessage/llmail.cpp 27 May 2007 22:05:41 -0000 1.5 +++ indra/llmessage/llmail.cpp 27 May 2007 22:10:14 -0000 1.1.2.5 @@ -41,8 +41,8 @@ #include #include -#include "apr-1/apr_pools.h" -#include "apr-1/apr_network_io.h" +#include +#include #include "llapr.h" #include "llbase32.h" // IM-to-email address Index: indra/llmessage/llpumpio.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/llpumpio.cpp,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llmessage/llpumpio.cpp 13 May 2007 01:26:22 -0000 1.2 +++ indra/llmessage/llpumpio.cpp 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -32,7 +32,7 @@ #include "llpumpio.h" #include -#include "apr-1/apr_poll.h" +#include #include "llapr.h" #include "llmemtype.h" Index: indra/llmessage/llpumpio.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/llpumpio.h,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llmessage/llpumpio.h 13 May 2007 01:26:22 -0000 1.2 +++ indra/llmessage/llpumpio.h 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -36,7 +36,7 @@ #include #endif -#include "apr-1/apr_pools.h" +#include #include "llbuffer.h" #include "llframetimer.h" #include "lliopipe.h" Index: indra/llmessage/message.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llmessage/message.cpp,v retrieving revision 1.6 retrieving revision 1.1.2.6 diff -u -p -w -r1.6 -r1.1.2.6 --- indra/llmessage/message.cpp 18 Jul 2007 00:32:05 -0000 1.6 +++ indra/llmessage/message.cpp 18 Jul 2007 00:33:07 -0000 1.1.2.6 @@ -47,9 +47,9 @@ #include #include "llapr.h" -#include "apr-1/apr_portable.h" -#include "apr-1/apr_network_io.h" -#include "apr-1/apr_poll.h" +#include +#include +#include // linden library headers #include "indra_constants.h" Index: indra/llrender/llfont.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llrender/llfont.cpp,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llrender/llfont.cpp 13 May 2007 01:26:22 -0000 1.2 +++ indra/llrender/llfont.cpp 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -31,11 +31,7 @@ #include "llfont.h" // Freetype stuff -#if LL_LINUX // I had to do some work to avoid the system-installed FreeType headers... --ryan. -#include "llfreetype2/freetype/ft2build.h" -#else #include -#endif // For some reason, this won't work if it's not wrapped in the ifdef #ifdef FT_FREETYPE_H Index: indra/llwindow/llwindowsdl.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llwindow/llwindowsdl.cpp,v retrieving revision 1.5 retrieving revision 1.1.2.5 diff -u -p -w -r1.5 -r1.1.2.5 --- indra/llwindow/llwindowsdl.cpp 9 Jul 2007 00:12:04 -0000 1.5 +++ indra/llwindow/llwindowsdl.cpp 9 Jul 2007 00:19:49 -0000 1.1.2.5 @@ -556,6 +556,13 @@ BOOL LLWindowSDL::createContext(int x, i } mWindow = SDL_SetVideoMode(width, height, bits, sdlflags | SDL_FULLSCREEN); + if (!mWindow) + { + llwarns << "createContext: window creation failure. SDL: " << SDL_GetError() << llendl; + llwarns << "createContext: Trying again with 16 bit depth buffer" << llendl; + SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); + mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + } if (mWindow) { @@ -598,6 +605,13 @@ BOOL LLWindowSDL::createContext(int x, i llinfos << "createContext: creating window " << width << "x" << height << "x" << bits << llendl; mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + if (!mWindow) + { + llwarns << "createContext: window creation failure. SDL: " << SDL_GetError() << llendl; + llwarns << "createContext: Trying again with 16 bit depth buffer" << llendl; + SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); + mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + } if (!mWindow) { Index: indra/llxml/llxmlnode.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llxml/llxmlnode.h,v retrieving revision 1.3 retrieving revision 1.1.2.3 diff -u -p -w -r1.3 -r1.1.2.3 --- indra/llxml/llxmlnode.h 9 Jul 2007 00:12:04 -0000 1.3 +++ indra/llxml/llxmlnode.h 9 Jul 2007 00:19:49 -0000 1.1.2.3 @@ -30,7 +30,7 @@ #define LL_LLXMLNODE_H #define XML_STATIC -#include "expat/expat.h" +#include #include #include "indra_constants.h" Index: indra/llxml/llxmlparser.h =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llxml/llxmlparser.h,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/llxml/llxmlparser.h 13 May 2007 01:26:22 -0000 1.2 +++ indra/llxml/llxmlparser.h 13 May 2007 02:06:44 -0000 1.1.2.2 @@ -30,7 +30,7 @@ #define LL_LLXMLPARSER_H #define XML_STATIC -#include "expat/expat.h" +#include class LLXmlParser { Index: indra/newview/lluserauth.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/newview/lluserauth.cpp,v retrieving revision 1.2 retrieving revision 1.1.2.2 diff -u -p -w -r1.2 -r1.1.2.2 --- indra/newview/lluserauth.cpp 13 May 2007 01:26:22 -0000 1.2 +++ indra/newview/lluserauth.cpp 13 May 2007 02:06:45 -0000 1.1.2.2 @@ -42,7 +42,7 @@ // NOTE: MUST include these after otherincludes since queue gets redefined!?!! #include -#include +#include Index: indra/newview/llviewerobjectlist.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/newview/llviewerobjectlist.cpp,v retrieving revision 1.4 retrieving revision 1.1.2.4 diff -u -p -w -r1.4 -r1.1.2.4 --- indra/newview/llviewerobjectlist.cpp 13 May 2007 01:26:22 -0000 1.4 +++ indra/newview/llviewerobjectlist.cpp 13 May 2007 02:06:45 -0000 1.1.2.4 @@ -61,7 +61,7 @@ #include "u64.h" #include "llviewerimagelist.h" #include "lldatapacker.h" -#include +#include #include "object_flags.h" extern BOOL gVelocityInterpolate; Index: indra/newview/llviewerparcelmgr.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/newview/llviewerparcelmgr.cpp,v retrieving revision 1.12 retrieving revision 1.5.2.6 diff -u -p -w -r1.12 -r1.5.2.6 --- indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:32:05 -0000 1.12 +++ indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:33:07 -0000 1.5.2.6 @@ -181,7 +181,7 @@ LLViewerParcelMgr::~LLViewerParcelMgr() mCollisionSegments = NULL; // weird, this crashes if I use an array delete on it! - delete sPackedOverlay; + delete[] sPackedOverlay; sPackedOverlay = NULL; delete[] mAgentParcelOverlay; Index: indra/newview/llxmlrpctransaction.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/newview/llxmlrpctransaction.cpp,v retrieving revision 1.5 retrieving revision 1.1.2.5 diff -u -p -w -r1.5 -r1.1.2.5 --- indra/newview/llxmlrpctransaction.cpp 9 Jul 2007 00:12:04 -0000 1.5 +++ indra/newview/llxmlrpctransaction.cpp 9 Jul 2007 00:19:49 -0000 1.1.2.5 @@ -34,7 +34,7 @@ // Have to include these last to avoid queue redefinition! #include -#include +#include #include "viewer.h" Index: indra/newview/linux_tools/client-manifest-i686 =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/newview/linux_tools/client-manifest-i686,v retrieving revision 1.4 retrieving revision 1.2.2.1 diff -u -p -w -r1.4 -r1.2.2.1 --- indra/newview/linux_tools/client-manifest-i686 24 Feb 2007 18:30:21 -0000 1.4 +++ indra/newview/linux_tools/client-manifest-i686 24 Feb 2007 18:40:31 -0000 1.2.2.1 @@ -33,20 +33,20 @@ help/ skins/ res-sdl/ ../../scripts/messages/message_template.msg,app_settings/message_template.msg -#../../libraries/i686-linux/lib_release_client/libkdu_v42R.so,lib/libkdu_v42R.so -../../libraries/i686-linux/lib_release_client/libfmod-3.75.so,lib/libfmod-3.75.so -../../libraries/i686-linux/lib_release_client/libapr-1.so.0,lib/libapr-1.so.0 -../../libraries/i686-linux/lib_release_client/libaprutil-1.so.0,lib/libaprutil-1.so.0 -../../libraries/i686-linux/lib_release_client/libdb-4.2.so,lib/libdb-4.2.so -../../libraries/i686-linux/lib_release_client/libogg.so.0,lib/libogg.so.0 -../../libraries/i686-linux/lib_release_client/libvorbis.so.0,lib/libvorbis.so.0 -../../libraries/i686-linux/lib_release_client/libvorbisfile.so.0,lib/libvorbisfile.so.0 -../../libraries/i686-linux/lib_release_client/libvorbisenc.so.0,lib/libvorbisenc.so.0 -../../libraries/i686-linux/lib_release_client/libcurl.so.4,lib/libcurl.so.4 -../../libraries/i686-linux/lib_release_client/libcrypto.so.0.9.7,lib/libcrypto.so.0.9.7 -../../libraries/i686-linux/lib_release_client/libssl.so.0.9.7,lib/libssl.so.0.9.7 -../../libraries/i686-linux/lib_release_client/libexpat.so.1,lib/libexpat.so.1 -#../../libraries/i686-linux/lib_release_client/libstdc++.so.6,lib/libstdc++.so.6 -../../libraries/i686-linux/lib_release_client/libelfio.so,lib/libelfio.so -../../libraries/i686-linux/lib_release_client/libuuid.so,lib/libuuid.so.1 -../../libraries/i686-linux/lib_release_client/libSDL-1.2.so.0,lib/libSDL-1.2.so.0 +##../../libraries/i686-linux/lib_release_client/libkdu_v42R.so,lib/libkdu_v42R.so +#../../libraries/i686-linux/lib_release_client/libfmod-3.75.so,lib/libfmod-3.75.so +#../../libraries/i686-linux/lib_release_client/libapr-1.so.0,lib/libapr-1.so.0 +#../../libraries/i686-linux/lib_release_client/libaprutil-1.so.0,lib/libaprutil-1.so.0 +#../../libraries/i686-linux/lib_release_client/libdb-4.2.so,lib/libdb-4.2.so +#../../libraries/i686-linux/lib_release_client/libogg.so.0,lib/libogg.so.0 +#../../libraries/i686-linux/lib_release_client/libvorbis.so.0,lib/libvorbis.so.0 +#../../libraries/i686-linux/lib_release_client/libvorbisfile.so.0,lib/libvorbisfile.so.0 +#../../libraries/i686-linux/lib_release_client/libvorbisenc.so.0,lib/libvorbisenc.so.0 +#../../libraries/i686-linux/lib_release_client/libcurl.so.4,lib/libcurl.so.4 +#../../libraries/i686-linux/lib_release_client/libcrypto.so.0.9.7,lib/libcrypto.so.0.9.7 +#../../libraries/i686-linux/lib_release_client/libssl.so.0.9.7,lib/libssl.so.0.9.7 +#../../libraries/i686-linux/lib_release_client/libexpat.so.1,lib/libexpat.so.1 +##../../libraries/i686-linux/lib_release_client/libstdc++.so.6,lib/libstdc++.so.6 +#../../libraries/i686-linux/lib_release_client/libelfio.so,lib/libelfio.so +#../../libraries/i686-linux/lib_release_client/libuuid.so,lib/libuuid.so.1 +#../../libraries/i686-linux/lib_release_client/libSDL-1.2.so.0,lib/libSDL-1.2.so.0 From sean at dague.net Fri Sep 14 05:46:08 2007 From: sean at dague.net (Sean Dague) Date: Fri Sep 14 05:44:51 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46E9D388.3030204@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> Message-ID: <20070914124608.GY1471@dague.net> On Thu, Sep 13, 2007 at 05:19:20PM -0700, Rob Lanphier wrote: > Hi all, > > You may have noticed some strange activity on the wiki and on IRC and > other places about the Second Life Grid Architecture Working Group. > > https://wiki.secondlife.com/wiki/ArchWG_Mtg_1_Agenda > > Coupled with SL Views we held a first meeting to explain and discuss > LL's current view of the future architecture of Second Life. We've used > the wiki to distribute the raw notes for this first meeting. We'll be > working in the open on this mailing list (as this raw log should be > evidence of; I promised the people who attended that I'd send everyone a > copy of this transcript ASAP, and this is the best way I knew how to do > it). We're really looking forward to expanding the working group to > evolve the architecture of the Second Life Grid. > > Rob FYI, pipermail seems to be choking on the non multipart/mixed nature of this message (https://lists.secondlife.com/pipermail/sldev/2007-September/004702.html). It might be good to change in the infrastructure to use mhonarc instead, so that the archives can contain content which is digitally signed. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/ee0b6b83/attachment.pgp From alissa_sabre at yahoo.co.jp Fri Sep 14 06:13:15 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Sep 14 06:13:35 2007 Subject: [sldev] [VIEWER] Funky(?) source code change in 1.18.3.3 In-Reply-To: <46EA713B.2010600@blueflash.cc> References: <46EA713B.2010600@blueflash.cc> Message-ID: <1kwkfQ4s13kxnfx4u1ae0rs0.alissa_sabre@yahoo.co.jp> > Thoughts? My guess is that someone in LL merged some changes on another branch (e.g., that is to be 1.18.4) into the 1.18.3 branch, and svn just went wild. > mChanged = FALSE; > notifyObservers(); > > + notifyObservers(); > + > return true; > } -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Fri Sep 14 07:19:12 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 14 07:19:26 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components (David Fries) In-Reply-To: <20070914123818.4E12F41B10F@stupor.lindenlab.com> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> Message-ID: <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> From: David Fries > ignore all the build steps about copying (shudder) system include/ > library files to the source tree and apply the included patch. > That lets it reference the system include files the way the are > supposed to be included. If this is generally usable for more than just amd64, I hope the Lindens pick it up as well, because that always bugged me. Have you filed it as a patch in JIRA? Also, while I was reading through your patches, I noticed this: > --- indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:32:05 -0000 > 1.12 > +++ indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:33:07 -0000 > 1.5.2.6 > @@ -181,7 +181,7 @@ LLViewerParcelMgr::~LLViewerParcelMgr() > mCollisionSegments = NULL; > > // weird, this crashes if I use an array delete on it! > - delete sPackedOverlay; > + delete[] sPackedOverlay; > sPackedOverlay = NULL; > > delete[] mAgentParcelOverlay; > If you fixed whatever was breaking the array delete, you probably ought to remove the comment. :) I don't grok C++ enough to know if you've just masked an underlying problem or fixed it, but I figure it'd be interesting and educational if you can elaborate on this particular patch. :) From dale at daleglass.net Fri Sep 14 07:38:12 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 14 07:38:23 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components (David Fries) In-Reply-To: <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> Message-ID: <200709141638.17776.dale@daleglass.net> On Friday 14 September 2007 16:19:12 Argent Stonecutter wrote: > If you fixed whatever was breaking the array delete, you probably > ought to remove the comment. :) > > I don't grok C++ enough to know if you've just masked an underlying > problem or fixed it, but I figure it'd be interesting and educational > if you can elaborate on this particular patch. :) My understanding (I'm not a C++ expert by any measure though) is that the difference between delete and delete[] is that there's no metadata that indicates whether there's an array there or not, so you've got to use the right form of delete. For delete[] there would be a number of allocated elements somewhere. So using delete on an array probably deletes just the first element. A delete[] on something that isn't an array would result in reading some random number from where the array length should be, and deleting an arbitrary number of objects, very likely wreaking havoc. Reasons for delete working on an array and delete[] crashing? My guess is delete doesn't crash because it does an incomplete deletion. Maybe there's some memory corruption and it's not hitting it, or maybe the crash is in a destructor and it doesn't crash because it's not run. So I think that the delete instead of delete[] was just masking some other problem, like memory corruption or a problem in the destructor. I'd like to hear more info on this as well :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/855b1218/attachment.pgp From secret.argent at gmail.com Fri Sep 14 07:44:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 14 07:45:05 2007 Subject: [sldev] Re: [META] 64 bit status and open source components (David Fries) In-Reply-To: <200709141638.17776.dale@daleglass.net> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> <200709141638.17776.dale@daleglass.net> Message-ID: <8195EA2F-B783-481D-BF99-F858B3FA0F6C@gmail.com> On 14-Sep-2007, at 09:38, Dale Glass wrote: > My understanding (I'm not a C++ expert by any measure though) is > that the > difference between delete and delete[] is that there's no metadata > that > indicates whether there's an array there or not, so you've got to > use the > right form of delete. My god. I'm stunned. Out of all the various object oriented extensions to C, why did THIS one become the most popular? From dale at daleglass.net Fri Sep 14 08:06:48 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 14 08:07:06 2007 Subject: [sldev] Re: [META] 64 bit status and open source components (David Fries) In-Reply-To: <8195EA2F-B783-481D-BF99-F858B3FA0F6C@gmail.com> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <200709141638.17776.dale@daleglass.net> <8195EA2F-B783-481D-BF99-F858B3FA0F6C@gmail.com> Message-ID: <200709141707.01213.dale@daleglass.net> On Friday 14 September 2007 16:44:32 Argent Stonecutter wrote: > My god. I'm stunned. > > Out of all the various object oriented extensions to C, why did THIS > one become the most popular? It keeps programmers employed ;-) http://members.safe-t.net/jwalker/programming/interview.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/e22b1029/attachment.pgp From tao.takashi at googlemail.com Fri Sep 14 08:15:30 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Fri Sep 14 08:15:32 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46E9D388.3030204@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> Message-ID: <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> Hi! As I was part of the meeting yesterday I though I might shade some light in what actually was discussed there in form of a little introduction. I already posted some initial thoughts on my blog: http://taotakashi.wordpress.com/2007/09/14/linden-lab-reveals-the-future-of-second-life/ So basically it is all about the future of the SL grid. If you imagine a not so distant future in which virtual worlds are a part of everybody's life as it is now numbers of regions, numbers of users and concurrency will raise in the millions and billions. It should be clear that the current setup of the grid will not be able to cope with that (think central servers). The other issue is the requirements many companies and other institutions have regarding the grid. For instance many want to host their own content instead of letting Linden Lab to do that. This might be ok with marketing activities but might not be the case with confidential content for online collaboration. And as you also know there was a some talk recently about allowing sims hosted by 3rd parties connect to the Second Life grid. You on this list here are very aware of the issues involved with that. To solve all these problems a new grid architecture needs to be made. And this is what Zero Linden et. al. was presenting yesterday. I believe he will put up the slides on the wiki soon as they are sort of important to understand all this. More important is though that Linden Lab is not thinking about doing all this architectural work etc. alone in private but in fact it is a very open project and everybody is invited to participate. The first meeting needed to be a small group of people in order to get it started but it's not a fixed group and mostly participation drives the decision who might be part of the next meeting. Also no decisions have been made and nothing is set in stone yet (it also takes some time to understand all that and think about issues/problems anyway). Communication about this project will be done on the wiki, on Jira and on this list. So the usual communcation mechanisms will be used. There have been workitems defined during the first meeting like collecting use cases, thinking about possible altermative architectures and so on and all these need your input. You can find them in the chatlog attached in the initial mail if you search for "WORKITEM". **The architecture** I am not sure I got everything completely right but let me shortly describe the basic principles as I understood it. Basically we have right now the region as the main entry point for viewers to connect. They also act as proxies to the central servers such as user server, asset server and so on. With the projected numbers from above those central servers will not very likely be capable of handling this load. So the main approach is to split between agents and regions and Zero presented us with the Agent domain and Region doman. The Agent Domain knows everything about agents and the Region Domain knows everything about Regions. The agent domain consist of 3 parts: The agent services, the agent hosts and the agent store. The agent service contains stateless information about an agent (e.g. profile information), the agent host stores session information about a logged in avatar (where is the agent, which friends are online, status of the agent (busy?) ...) and the agent store stores the actual data about an agent, including inventory. All these might be separate boxes or a cluster of boxes, it doesn't matter to the architecture. The region domain consists of similar parts: Region services know stateless information about a region such as the name, Region hosts are basically what we call today simulators (OpenSim could be an implementation of such a region host) and Region Stores store information about a region such as the objects on the region, land information etc. Then there are some global services such as identity (important is to have only one identity and not one for every grid), location (actually better named topology as it defines which region is next to which), currency (L$ or something else) and search. Now there can be multiple agent domains and region domains and it's a question of trust which region domains lets agents from a specific agent domain in. One region and agent domain would be the one of Linden Lab and it might allow further agent domains (such as one of company x) to login to their region domain. If might even allow every agent domain but maybe with restricted access (no rezzing, ...) But I might get a bit too much into detail here. Just imagine that all this should be as flexible as possible. There are many hard problems such as topology and identity and probably many we don't see right now. And that's why discussion and use case scenarios are very important to have. I am not sure the chatlog makes more sense now but I hope it does. :-) And I might also describe this further on the wiki as soon as the slides are there and nobody else has done it already. I definitely hope that a lot of people will participate in this! It truly rocks :-) (and if I made any mistakes please correct me!) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070914/1d0e0c4c/attachment-0001.htm From bos at lindenlab.com Fri Sep 14 09:41:54 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Sep 14 09:46:04 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components (David Fries) In-Reply-To: <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> Message-ID: <46EAB9D2.8060000@lindenlab.com> Argent Stonecutter wrote: > If this is generally usable for more than just amd64, I hope the Lindens > pick it up as well, because that always bugged me. I haven't seen a patch that I recall, but I did a bunch of work a month or two ago to ensure that the viewer builds cleanly using system includes and libraries, by setting just a single flag when running scons. >> --- indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:32:05 >> -0000 1.12 >> +++ indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:33:07 >> -0000 1.5.2.6 >> @@ -181,7 +181,7 @@ LLViewerParcelMgr::~LLViewerParcelMgr() >> mCollisionSegments = NULL; >> >> // weird, this crashes if I use an array delete on it! >> - delete sPackedOverlay; >> + delete[] sPackedOverlay; >> sPackedOverlay = NULL; I don't know where that came from, but I made just this sort of change in our internal code a while ago. There had been a longstanding mismatch between an array constructor and this destructor. So you can consider this change "upstreamed" as of a month or two back :-) References: <46EA713B.2010600@blueflash.cc> <1kwkfQ4s13kxnfx4u1ae0rs0.alissa_sabre@yahoo.co.jp> Message-ID: <46EABC8F.4080402@lindenlab.com> Alissa Sabre wrote: >> Thoughts? >> > > My guess is that someone in LL merged some changes on another branch > (e.g., that is to be 1.18.4) into the 1.18.3 branch, and svn just went > wild. > Yep, came in with a patch to 1.18.3. Good catch! From seg at haxxed.com Fri Sep 14 10:25:05 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 14 10:25:13 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components (David Fries) In-Reply-To: <46EAB9D2.8060000@lindenlab.com> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> <46EAB9D2.8060000@lindenlab.com> Message-ID: <1189790705.6616.4.camel@localhost> On Fri, 2007-09-14 at 09:41 -0700, Bryan O'Sullivan wrote: > >> --- indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:32:05 > >> -0000 1.12 > >> +++ indra/newview/llviewerparcelmgr.cpp 18 Jul 2007 00:33:07 > >> -0000 1.5.2.6 > >> @@ -181,7 +181,7 @@ LLViewerParcelMgr::~LLViewerParcelMgr() > >> mCollisionSegments = NULL; > >> > >> // weird, this crashes if I use an array delete on it! > >> - delete sPackedOverlay; > >> + delete[] sPackedOverlay; > >> sPackedOverlay = NULL; > > I don't know where that came from, but I made just this sort of change > in our internal code a while ago. There had been a longstanding > mismatch between an array constructor and this destructor. So you can > consider this change "upstreamed" as of a month or two back :-) I found this one. Or rather, valgrind did. :) (Unless someone internally found it first...) https://jira.secondlife.com/browse/VWR-1586 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/540d347b/attachment.pgp From seg at haxxed.com Fri Sep 14 10:48:37 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 14 10:48:41 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: References: Message-ID: <1189792117.6616.18.camel@localhost> On Fri, 2007-09-14 at 13:08 +0100, Robin Cornelius wrote: > Hi Everyone, > > Sorry if this is documented some where, if so then please just send me there :-) > > Whats the current code base staus wrt 64 bit systems. Is it capable of > being compiled for an Athlon 64 (specifically on linux in this > instance)? and what about the libs as well, as i will of cause need > 64bit libs as well. I don't mind loosing fmod as it dosn't work too > well for me at the best of times. > > Whist i remember, i saw a while ago a message saying the viewer had > been compiled completely with open source components including all the > gstreamer stuff. All i remember was that this is done internally by > the Lindens but i have not seen anything else about this since. I have been RPM packaging slviewer ever since the initial source release, for i386 and x86_64, using only system libraries and no closed source. It works just fine. I have personally put a lot of time and effort into speeding up OpenJPEG, and I wrote a patch to use OpenAL for audio. (Which needs to get submitted, bleh.) Well, except post-1.18.0.6 has severe performance issues that seem to hit x86_64 particularly hard, which DOES seem to be VBO related, the limited heap profiles I was able to get did show an awful lot of ram being allocated by Mesa for vertexes. I think this might be the same bug: https://jira.secondlife.com/browse/VWR-2303 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/edbae9aa/attachment.pgp From lenglish5 at cox.net Fri Sep 14 11:05:14 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 14 11:05:17 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <20070914124608.GY1471@dague.net> References: <46E9D388.3030204@lindenlab.com> <20070914124608.GY1471@dague.net> Message-ID: <46EACD5A.6090904@cox.net> Sean Dague wrote: > On Thu, Sep 13, 2007 at 05:19:20PM -0700, Rob Lanphier wrote: > >> Hi all, >> >> You may have noticed some strange activity on the wiki and on IRC and >> other places about the Second Life Grid Architecture Working Group. >> >> https://wiki.secondlife.com/wiki/ArchWG_Mtg_1_Agenda >> >> Coupled with SL Views we held a first meeting to explain and discuss >> LL's current view of the future architecture of Second Life. We've used >> the wiki to distribute the raw notes for this first meeting. We'll be >> working in the open on this mailing list (as this raw log should be >> evidence of; I promised the people who attended that I'd send everyone a >> copy of this transcript ASAP, and this is the best way I knew how to do >> it). We're really looking forward to expanding the working group to >> evolve the architecture of the Second Life Grid. >> >> Rob >> > > FYI, pipermail seems to be choking on the non multipart/mixed nature of > this message > (https://lists.secondlife.com/pipermail/sldev/2007-September/004702.html). > > It might be good to change in the infrastructure to use mhonarc instead, > so that the archives can contain content which is digitally signed. > I got the mail just fine, but the Mac opened it with Maya (??!!!?). The content was fine, but for some reason .txt was seen a a Maya extension. L From seg at haxxed.com Fri Sep 14 11:10:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Sep 14 11:10:47 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components (David Fries) In-Reply-To: <200709141638.17776.dale@daleglass.net> References: <20070914123818.4E12F41B10F@stupor.lindenlab.com> <9564C9E7-E1FE-4956-A527-B98831971999@gmail.com> <200709141638.17776.dale@daleglass.net> Message-ID: <1189793440.6616.25.camel@localhost> On Fri, 2007-09-14 at 16:38 +0200, Dale Glass wrote: > I'd like to hear more info on this as well :-) The best I can seem to find right now: http://blogs.msdn.com/oldnewthing/archive/2004/02/04/67384.aspx Which is presumably talking about MSVC. gcc is apparently known for, at the very least, not crashing on mismatched deletes, it must be doing something different. :) I can't find what I googled up before on this, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/a5196132/attachment.pgp From secret.argent at gmail.com Fri Sep 14 12:29:33 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 14 12:29:42 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components In-Reply-To: <20070914190010.B7DCB41B152@stupor.lindenlab.com> References: <20070914190010.B7DCB41B152@stupor.lindenlab.com> Message-ID: <645E8FB2-BC96-443C-BB1E-4663815C470F@gmail.com> Callum Lerwick writes: > Well, except post-1.18.0.6 has severe performance issues that seem to > hit x86_64 particularly hard, which DOES seem to be VBO related, the > limited heap profiles I was able to get did show an awful lot of ram > being allocated by Mesa for vertexes. I think this might be the same > bug: > > https://jira.secondlife.com/browse/VWR-2303 But Mesa is the CPU-side OpenGL implementation, right? Mesa memory allocation would be expected to be associated with excessive memory allocation in the GPU on a system equipped with a recent nVidia card and using the nVidia driver... not the CPU. From liana at lindenlab.com Fri Sep 14 13:05:27 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Fri Sep 14 13:05:28 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> Message-ID: <46EAE987.9080009@lindenlab.com> Zero's slides are available at Hippotropolis 212, 13,24. Tao Takashi wrote: > Hi! > > As I was part of the meeting yesterday I though I might shade some > light in what actually was discussed there in form of a little > introduction. I already posted some initial thoughts on my blog: > http://taotakashi.wordpress.com/2007/09/14/linden-lab-reveals-the-future-of-second-life/ > > So basically it is all about the future of the SL grid. If you imagine > a not so distant future in which virtual worlds are a part of > everybody's life as it is now numbers of regions, numbers of users and > concurrency will raise in the millions and billions. It should be > clear that the current setup of the grid will not be able to cope with > that (think central servers). > > The other issue is the requirements many companies and other > institutions have regarding the grid. For instance many want to host > their own content instead of letting Linden Lab to do that. This might > be ok with marketing activities but might not be the case with > confidential content for online collaboration. And as you also know > there was a some talk recently about allowing sims hosted by 3rd > parties connect to the Second Life grid. You on this list here are > very aware of the issues involved with that. > > To solve all these problems a new grid architecture needs to be made. > And this is what Zero Linden et. al. was presenting yesterday. I > believe he will put up the slides on the wiki soon as they are sort of > important to understand all this. More important is though that Linden > Lab is not thinking about doing all this architectural work etc. alone > in private but in fact it is a very open project and everybody is > invited to participate. The first meeting needed to be a small group > of people in order to get it started but it's not a fixed group and > mostly participation drives the decision who might be part of the next > meeting. Also no decisions have been made and nothing is set in stone > yet (it also takes some time to understand all that and think about > issues/problems anyway). > > Communication about this project will be done on the wiki, on Jira and > on this list. So the usual communcation mechanisms will be used. There > have been workitems defined during the first meeting like collecting > use cases, thinking about possible altermative architectures and so on > and all these need your input. You can find them in the chatlog > attached in the initial mail if you search for "WORKITEM". > > > **The architecture** > > I am not sure I got everything completely right but let me shortly > describe the basic principles as I understood it. > > Basically we have right now the region as the main entry point for > viewers to connect. They also act as proxies to the central servers > such as user server, asset server and so on. With the projected > numbers from above those central servers will not very likely be > capable of handling this load. > > So the main approach is to split between agents and regions and Zero > presented us with the Agent domain and Region doman. The Agent Domain > knows everything about agents and the Region Domain knows everything > about Regions. > > The agent domain consist of 3 parts: The agent services, the agent > hosts and the agent store. > The agent service contains stateless information about an agent (e.g. > profile information), the agent host stores session information about > a logged in avatar (where is the agent, which friends are online, > status of the agent (busy?) ...) and the agent store stores the actual > data about an agent, including inventory. > > All these might be separate boxes or a cluster of boxes, it doesn't > matter to the architecture. > > The region domain consists of similar parts: Region services know > stateless information about a region such as the name, Region hosts > are basically what we call today simulators (OpenSim could be an > implementation of such a region host) and Region Stores store > information about a region such as the objects on the region, land > information etc. > > Then there are some global services such as identity (important is to > have only one identity and not one for every grid), location (actually > better named topology as it defines which region is next to which), > currency (L$ or something else) and search. > > Now there can be multiple agent domains and region domains and it's a > question of trust which region domains lets agents from a specific > agent domain in. One region and agent domain would be the one of > Linden Lab and it might allow further agent domains (such as one of > company x) to login to their region domain. If might even allow every > agent domain but maybe with restricted access (no rezzing, ...) > > But I might get a bit too much into detail here. Just imagine that all > this should be as flexible as possible. There are many hard problems > such as topology and identity and probably many we don't see right > now. And that's why discussion and use case scenarios are very > important to have. > > I am not sure the chatlog makes more sense now but I hope it does. :-) > > And I might also describe this further on the wiki as soon as the > slides are there and nobody else has done it already. > > I definitely hope that a lot of people will participate in this! It > truly rocks :-) > > (and if I made any mistakes please correct me!) > > -- Tao > > > -- > taotakashi@gmail.com > http://taotakashi.wordpress.com > http://worldofsl.com > > RL: Christian Scholz, cs@comlounge.net > http://mrtopf.de > > http://comlounge.net > http://comlounge.tv > http://mrtopf.tv > http://dev.comlounge.net > IRC: MrTopf/Tao_T > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070914/359caee3/attachment.htm From lenglish5 at cox.net Fri Sep 14 13:41:10 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 14 13:41:10 2007 Subject: [sldev] [VIEWER][META] Trying to use LLUICtrlFactory to create a custom panel or how I learned to love the Bomb Message-ID: <46EAF1E6.9050504@cox.net> Has anyone ever added a custom GUI widget to the SL GUI framework? OK, the background: Idea: create a replacement for that silly 200+ item drop down combobox at the bottom of hte LSL editor. Make it a floater with hierarchical categories based on what you find at the LSL wiki. Should be simple: just derive a new class from whatever is used to make the inventory floater in the client. Whoops. Nope. LLInventoryView is rather entangled with the client's need. Not designed for something simple... OK, there's bound to be a intermediate, simpler class... Nope. LLInventory bypasses LLScrollListCrtl and reinvents the wheel based on LLPanel. OK... So, lets roll our own faux outline class based on LLScrollListCrtl. OK, seems doable. Now, before we go much further, lets make sure we can create it using the LLUICtrolFactory widget thing... Uh-oh... Some checking around, I find that WIDGET_TYPE_SCROLL_LIST occurs 5 places in 4 files: llscrolllistctrl.h, llui.h, lluictrlfactory.cpp, llfloatereditui.cpp I can add the various references to WIDGET_TYPE_FAUX_OULINE_LIST no problem and create my own callback in various spots. I can see that I likely need to create several methods for my class: virtual EWidgetType getWidgetType() const { return WIDGET_TYPE_SCROLL_LIST; } virtual LLString getWidgetTag() const { return LL_SCROLL_LIST_CTRL_TAG; } virtual LLXMLNodePtr getXML(bool save_children = true) const; void setScrollListParameters(LLXMLNodePtr node); static LLView* fromXML(LLXMLNodePtr node, LLView *parent, LLUICtrlFactory *factory); The question: is that all? This seems relatively straightfoward by SL client standards, albeit annoyingly difficult for the single use that I would put it to, but given that I'm seeing many possible uses for a outline list class, even one as baby-fied as what I'm working on, it would be worth the work. Yes, I know that a outline list view is due out sometime "soon," but how soon? mono-time? And will it do what *I* want, but only some esoteric, SL-specific thing that one person out of 100,000 potential users wants? In addition to a better way of inserting keywords into LSL, I can see its utility in creating: A library of scripts, without having to go out to the asset server for each and every one of them, save when saving the selected library entry to a real script in inventory or the prim... A library of notes about avatars, events, places, etc, cached on the client's harddrive, so that they can be searched without using the asset server... A script creator, ala Hilaray Mason's, http://www.3greeneggs.com/autoscript/, would also benefit from a lightweight nested hierarchical list panel, I think. Some might say "its never been done, so no-one must want it," but note that it is impossible to do anything simple in the SL viewer without "rolling your own," including analyzing the convoluted nature of the interacting classes, so the most useful (usually the most simple) stuff never gets done, just the convoluted stuff, that is useful only to a select handful of people who need something complex. So again: what am I missing? Is there more to adding a new class type to the GUI factory than I have said? Is this documented anywhere, or am I again in virgin territory? ("here be dragons" reference goes here) L. From bridie at lindenlab.com Fri Sep 14 14:04:09 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Fri Sep 14 14:04:08 2007 Subject: [sldev] [VIEWER] Funky(?) source code change in 1.18.3.3 In-Reply-To: <46EABC8F.4080402@lindenlab.com> References: <46EA713B.2010600@blueflash.cc> <1kwkfQ4s13kxnfx4u1ae0rs0.alissa_sabre@yahoo.co.jp> <46EABC8F.4080402@lindenlab.com> Message-ID: <46EAF749.60602@lindenlab.com> Fixed in RC 1.18.3.4 - New viewer available here (w/one other fix): http://www.secondlife.com/community/downloads-optional.php Source coming soon. --Bridie Joshua Bell wrote: > Alissa Sabre wrote: >>> Thoughts? >>> >> >> My guess is that someone in LL merged some changes on another branch >> (e.g., that is to be 1.18.4) into the 1.18.3 branch, and svn just went >> wild. >> > Yep, came in with a patch to 1.18.3. Good catch! > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From anthony at lindenlab.com Fri Sep 14 14:24:30 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Fri Sep 14 14:24:34 2007 Subject: [sldev] Source release for RC 1.18.3.4 In-Reply-To: <46E9C06F.1030203@lindenlab.com> References: <46E9C06F.1030203@lindenlab.com> Message-ID: <46EAFC0E.7030309@lindenlab.com> Hello Everyone, Here's the source drop for latest viewer release, which is Release Candidate version 1.18.3.4. It looks like we've been able to clean up most of the release branch, so be on the lookout for a new dated snapshot later today. 1.18.3.4 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.3.4 Release note information here: http://blog.secondlife.com/2007/09/14/now-available-release-candidate-viewer-update/ Checksums: 86147b9afaac034b12bd5c169583df4c slviewer-darwin-libs-RC-1.18.3.4.tar.gz 26e9fcb79db326d4411a013ccd42ecf5 slviewer-linux-libs-RC-1.18.3.4.tar.gz 563f354bdab10ab31bb85fa08e6ec85e slviewer-src-RC-1.18.3.4.tar.gz f26207d21e6ef8b0f1ca046a2cff405b slviewer-artwork-RC-1.18.3.4.zip 8f185571cac26fffa9c8ab667d9957f3 slviewer-src-RC-1.18.3.4.zip 022b9b6d3a49c2307f3f33c4e31fe6fd slviewer-win32-libs-RC-1.18.3.4.zip SVN checkout: Rob will send email about this once it's up. Enjoy. -Anthony From simon at lindenlab.com Fri Sep 14 15:56:44 2007 From: simon at lindenlab.com (Dave Simmons (Simon)) Date: Fri Sep 14 15:56:46 2007 Subject: Japanese bugs, was Re: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <2YozYoPrk8rr8rk8rkPrrn1.alissa_sabre@yahoo.co.jp> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> <46E03A94.3040309@lindenlab.com> <2YozYoPrk8rr8rk8rkPrrn1.alissa_sabre@yahoo.co.jp> Message-ID: <46EB11AC.5080005@lindenlab.com> Hi Alissa - I added a comment about this to VWR-250, but can you upload a .zip of your source for the following files into that task? linden/indra/llcommon/llstring.cpp linden/indra/llcommon/llstring.h linden/indra/newview/llimpanel.cpp linden/indra/llwindow/llwindow.h linden/indra/llwindow/llwindowmacosx.cpp linden/indra/llwindow/llwindowmacosx.h linden/indra/llwindow/llwindowwin32.cpp linden/indra/llwindow/llwindowwin32.h linden/indra/llwindow/llpreeditor.h linden/indra/llui/llui.cpp linden/indra/llui/llui.h linden/indra/llui/lllineeditor.cpp linden/indra/llui/lllineeditor.h linden/indra/llui/lltexteditor.cpp linden/indra/llui/lltexteditor.h On Windows, I submitted the changes that put the IME window into the right position, but it just missed the latest merge into our release pipeline so it will be another week or two before it gets into the RC source. This is doing the call to ImmSetCompositionWindow() so it shows up in the correct place. Unfortunately, as you mentioned, Mac OS X doesn't seem to have the equivalent functionality so it will likely require the much more complicated code you have worked on. I looked in the patch, but I think it will be much easier to merge your changes with the full files. Thanks for all your work on this, - Dave (Simon Linden) Alissa Sabre wrote: > For those who may concern, > > >> I'll take a look at your patch. >> > > I updated my patch. It is available as an attachment to VWR-250. > > Patched binary is also available as always: > > For Windows: http://alissa-sabre.cocolog-nifty.com/files/IME-20070909-Win32.zip > For MacOS: http://alissa-sabre.cocolog-nifty.com/files/ime-20070909-Mac.zip > > * VWR-250 is on improvement of Chinese/Japanese/Korean input. > > >> I did some of the same work on >> positioning the IME input where the text carat is located in text fields >> and editors. I haven't submitted the code yet as it's only partially >> working - it won't follow the field around correctly if you drag a >> floating window. >> > > I don't think you can do it (i.e., candidate window follows the moving > of the SL (LLUI) window) on MacOS. I want to know the technique if > you can. > > My solution is to fix (or confirm or commit, whichever terminology you > prefer) the preedit (or active input or composition) before the LLUI > window is about to move. (That's why I needed yet another onFocusLost > callback, if you remember. My latest version is based on the > Richard's suggestion.) > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > From markl at lindenlab.com Fri Sep 14 15:44:11 2007 From: markl at lindenlab.com (Mark Lentczner) Date: Fri Sep 14 16:31:59 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46EAE987.9080009@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> Message-ID: <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> On Sep 14, 2007, at 1:05 PM, Liana Holmberg wrote: > Zero's slides are available at Hippotropolis 212, 13,24. And now up on the wiki: http://wiki.secondlife.com/wiki/ArchWG_Mtg_1_Slides - Zero Mark Lentczner Director, Studio Icehouse Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070914/72346fc5/attachment.htm From anthony at lindenlab.com Fri Sep 14 16:33:25 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Fri Sep 14 16:33:29 2007 Subject: [sldev] Source release for release branch 2007-Sep-14 In-Reply-To: <46E08CB4.4070909@lindenlab.com> References: <46E08CB4.4070909@lindenlab.com> Message-ID: <46EB1A45.3070206@lindenlab.com> Hey Everyone, Here's the next installment of the release branch's dated snapshot. Release branch source available here: https://wiki.secondlife.com/wiki/Source_downloads#2007-Sep-14 Checksums: c9115ca64875f7eeee8c7b65f843ddc4 slviewer-darwin-libs-20070914a.tar.gz f391d19ec059fed347c950b0c1198f11 slviewer-linux-libs-20070914a.tar.gz d1bbba59f2a4a27f6de3f976421fc544 slviewer-src-20070914a.tar.gz 6a7114ed5fc63325ad5c2ea1d26b4997 slviewer-artwork-20070914a.zip cb2d2af3c69ddf53a6feaf5e31deb81e slviewer-src-20070914a.zip fb9ce8fb5d5b2ec45a0ce338c4eca0b8 slviewer-win32-libs-20070914a.zip SVN checkout: Robla will send email when this is available. Enjoy. -Anthony From tao.takashi at googlemail.com Fri Sep 14 16:51:08 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Fri Sep 14 16:51:10 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> Message-ID: <23bbb49e0709141651n3dea10bdhc8426c526e38ea2f@mail.gmail.com> > Zero's slides are available at Hippotropolis 212, 13,24. > > > And now up on the wiki: > http://wiki.secondlife.com/wiki/ArchWG_Mtg_1_Slides > Great, I might write something together tomorrow then. Unless you have some text around them that is :-) If not I hope I get things right, esp. in the later slides it's not always that clear to me anymore .. And some place on the wiki might be nice. For now I might link it to the agenda. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070915/22a16cb2/attachment.htm From robla at lindenlab.com Fri Sep 14 16:54:28 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 14 16:54:40 2007 Subject: [sldev] Source release for RC 1.18.3.4 In-Reply-To: <46EAFC0E.7030309@lindenlab.com> References: <46E9C06F.1030203@lindenlab.com> <46EAFC0E.7030309@lindenlab.com> Message-ID: <46EB1F34.8070707@lindenlab.com> svn snapshots now released for 1.18.3.4 and the release snapshot from today: http://svn.secondlife.com/trac/linden/timeline Rob On 9/14/07 2:24 PM, Anthony Foster wrote: > Hello Everyone, > > Here's the source drop for latest viewer release, which is Release > Candidate version 1.18.3.4. It looks like we've been able to clean up > most of the release branch, so be on the lookout for a new dated > snapshot later today. > > 1.18.3.4 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.3.4 > > Release note information here: > http://blog.secondlife.com/2007/09/14/now-available-release-candidate-viewer-update/ > > > Checksums: > > 86147b9afaac034b12bd5c169583df4c slviewer-darwin-libs-RC-1.18.3.4.tar.gz > 26e9fcb79db326d4411a013ccd42ecf5 slviewer-linux-libs-RC-1.18.3.4.tar.gz > 563f354bdab10ab31bb85fa08e6ec85e slviewer-src-RC-1.18.3.4.tar.gz > f26207d21e6ef8b0f1ca046a2cff405b slviewer-artwork-RC-1.18.3.4.zip > 8f185571cac26fffa9c8ab667d9957f3 slviewer-src-RC-1.18.3.4.zip > 022b9b6d3a49c2307f3f33c4e31fe6fd slviewer-win32-libs-RC-1.18.3.4.zip > > > SVN checkout: Rob will send email about this once it's up. > > Enjoy. > -Anthony > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070914/9d0c2db0/signature.pgp From 1337mail at gmail.com Fri Sep 14 18:05:57 2007 From: 1337mail at gmail.com (Michael Miller) Date: Fri Sep 14 18:05:59 2007 Subject: [sldev] Teleportation woes Message-ID: <2c99c46e0709141805w31b11da5if23ac1b631a435aa@mail.gmail.com> I'm trying to get my client to automatically teleport to a location at the start of the game. The jist of the code is as such: if(gStartupState == STATE_STARTED) gAgent.teleportViaLocation(LLVector3d(98,143,120)); This(the teleportViaLocation method) generates the following message: 2007-09-15T01:00:09Z WARNING: teleportViaLocation: Using deprecated teleportlocationrequest. 2007-09-15T01:00:09Z WARNING: createXml: Alert: [CouldNotTeleportReason] 2007-09-15T01:00:09Z WARNING: createDialog: Alert: Could not teleport. Problem encountered processing your teleport request. You may need to log back in before you can teleport. If you continue to get this message, please check the Tech Support FAQ at: www.secondlife.com/support I have even tried waiting 60 seconds(while the game is fully running for some time) before executing this request. Is this due to the teleportViaLocation method? Am I calling it correctly? Should I be calling something else? Thanks, Mike From alissa_sabre at yahoo.co.jp Sat Sep 15 02:21:22 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 15 06:41:24 2007 Subject: Japanese bugs, was Re: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <46EB11AC.5080005@lindenlab.com> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> <46E03A94.3040309@lindenlab.com> <2YozYoPrk8rr8rk8rkPrrn1.alissa_sabre@yahoo.co.jp> <46EB11AC.5080005@lindenlab.com> Message-ID: <1dvsL40md3kwsGd4ds6dw4G.alissa_sabre@yahoo.co.jp> > I added a comment about this to VWR-250, but can you upload a .zip of > your source for the following files into that task? I'm somewhat busy now, but I think I can do it later today. If I have a time, I will upload the latest copy in my own repository, as well as the ones that I have already submitted on JIRA as a patch. The latest ones contains some minor bug fixes and some big refactoring. My own development is in the final cleanup phase now, and my original plan was to submit the final patch on the end of September. So, if you are to merge my changes manually, I recommend you to start with the latest one. I can submit further changes as a patch against your merged code when it is available. (Hopefully during the RC phase.) > On Windows, I submitted the changes that put the IME window into the > right position, but it just missed the latest merge into our release > pipeline so it will be another week or two before it gets into the RC > source. This is doing the call to ImmSetCompositionWindow() so it > shows up in the correct place. Hmm. I don't think it is the right direction. # Sorry for most of the sldev readers: the following discussion assumes you have some deep knowledge on how Chinese/Japanese/Korean input methods work on Windows and MacOS... If you are not familiar with these concepts, keep reading further can be a waste of time... :-) Using ImmSetCompositionWindow means that you rely on the IME's composition winodw and just controling the location of it. Is this correct? I have several reason why I think it is a right direction, but the first one is that we can't do the same thing on MacOS. MacOS has no such thing as composition window on Windows. MacOS provides a bottom line input window, but it is not a MacOS counter part of composition window. It is something like a famous kinput tool on X Window. As long as you rely on availability of composition winodw, you can't get the same functionality on MacOS. If you see my patch, you will find that ImmSetCompositionWindow is not used. Instead, my patch uses ImmGetCompositionString to extract composition string and pass it to LLTextEditor/LLLineEditor to draw the composition string at a right position. You can do the same thing on MacOS through slightly different interface: you receive an equivalent to the composition string (as well as related information such as clauses) as parameters to the kEventClassTextInput/kEventTextInputUpdateActiveInputArea Carbon event on MacOS. That's what my patch does essentially. I patched the LLLineEditor and LLTextEditor so that they can handle composition string, i.e., to receive composition string with clause information and to draw composition strings differently than the ordinary text contents. Some more methods (defined in a new abstract class LLPreeditor) are also added to facilitate more advanced input method features. You may think an LLPreeditor is our own implementation of the functionality provided by Windows composition window. I also patched LLWindowsWin32 and LLWindowMacOS so that they drive LLLineEditor and LLTextEditor through LLPreeditor interface to behave properly. Most of this job is done in LLWindowWin32::handleCompositionMessage on Windows and in a kEventClassTextInput/kEventTextInputUpdateActiveInputArea event handler on MacOS respectively. Other parts of my patch are to support advanced features of input methods, e.g., re-conversion and context-dependent conversion (aka, application document access from input methods.) > Unfortunately, as you mentioned, Mac OS X doesn't seem to have the > equivalent functionality so it will likely require the much more > complicated code you have worked on. Yes, it is complecated, but it gives users better typing experiences than to rely on compositioin window. So, I don't think it is a waste. The complecation is the necessary cost to provide better user experiences. If you are to merge the code, I'm happy to help you, but unfortunately, I'm leaving Japan tomorrow and will not back until Saturday. I hope I can read emails and access to SL jira/wiki during the trip, but I can't log in to SL or to use development environment during the period. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Sat Sep 15 06:43:53 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Sep 15 06:43:59 2007 Subject: Japanese bugs, was Re: [sldev] OS-SL Development Issues (was Upcoming viewer releases) In-Reply-To: <1dvsL40md3kwsGd4ds6dw4G.alissa_sabre@yahoo.co.jp> References: <74ds4dtbfc4dwcds4s5ur.alissa_sabre@yahoo.co.jp> <46D6F0B2.6070400@lindenlab.com> <1s0sdw9ePcdY46sYLkJvL7nf.alissa_sabre@yahoo.co.jp> <46E03A94.3040309@lindenlab.com> <2YozYoPrk8rr8rk8rkPrrn1.alissa_sabre@yahoo.co.jp> <46EB11AC.5080005@lindenlab.com> <1dvsL40md3kwsGd4ds6dw4G.alissa_sabre@yahoo.co.jp> Message-ID: <6YfLxc15cc5s6rkvtn8sG8kJ.alissa_sabre@yahoo.co.jp> Simon, > > can you upload a .zip of > > your source for the following files into that task? > > I think I can do it later today. I uploaded the zip file. It contains fewer files than you requested, because I removed those files that contained no input method related chagned. Hope this helps, Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From robin.cornelius at gmail.com Sat Sep 15 08:02:01 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 15 08:02:02 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: <20070914123755.GA11645@spacedout.fries.net> References: <20070914123755.GA11645@spacedout.fries.net> Message-ID: On 9/14/07, David Fries wrote: > I have the viewer compiled and running in 64 bit mode on an x86_64 > with Debian. There are a couple libraries required that don't come > with the distribution that you have to compile yourself, but ignore > all the build steps about copying (shudder) system include/library > files to the source tree and apply the included patch. That lets it > reference the system include files the way the are supposed to be > included. > Hi David, thanks for the info and patch, yes that will save a lot of messing about, one question though, what source tree is the patch based against. Tried against 1.18.2.0 and it failed on various files, i assume because its against a different base. Regards Robin From david at fries.net Sat Sep 15 09:26:31 2007 From: david at fries.net (David Fries) Date: Sat Sep 15 09:26:50 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: References: <20070914123755.GA11645@spacedout.fries.net> Message-ID: <20070915162631.GB11645@spacedout.fries.net> On Sat, Sep 15, 2007 at 04:02:01PM +0100, Robin Cornelius wrote: > Hi David, thanks for the info and patch, yes that will save a lot of > messing about, one question though, what source tree is the patch > based against. Tried against 1.18.2.0 and it failed on various files, > i assume because its against a different base. > > Regards > > Robin 1.18.0.6 -- David Fries http://fries.net/~david/ (PGP encryption key available) From tao.takashi at googlemail.com Sat Sep 15 11:55:34 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sat Sep 15 11:55:35 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46E9D388.3030204@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> Message-ID: <23bbb49e0709151155g1dba864gcc732eb677c24d87@mail.gmail.com> Hi! I started some wiki pages about this project, starting here: https://wiki.secondlife.com/wiki/Architecture_Working_Group (not sure this is the right/best name. I think we maybe need a better one ;-) ) For now I tried to briefly describe the proposed architecture and the basic decisions made by Linden Lab (REST, cHTTP, capabilities). Feel free to correct things where needed. What's missing is maybe some description of how to participate and some sort of capturing the discussion that was going on. I might think the best way would be to go via some top level usecases and go down from there, adding thoughts where needed on the discussion pages. I'd also think that one should step back a bit, define first about which things we are talking, what the actual top level elements of such a system are, what completely different use cases one might imagine and then go to more specific use cases from there. We do not need to write them down in detail with scenario, all exceptions etc. right now, maybe for some it might be important though when it comes to implementing them. I will try to come up with some initial use cases etc. later or tomorrow. (I don't want to wait 2 weeks until I can tell you what I can commit to as I might have forgotten most of it by then ;-). I also made a list of the workitems defined in the irc log here: https://wiki.secondlife.com/wiki/Workitems_for_Meeting_1 (should every workitem be a wiki page then actually?) cheers, Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070915/01dca151/attachment.htm From seg at haxxed.com Sat Sep 15 12:51:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Sep 15 12:51:42 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46E9D388.3030204@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> Message-ID: <1189885899.6616.38.camel@localhost> Too long, eventually got around to reading. :) > [2007-09-13 15:41:33] Tao_T: topology might get very interesting with different sized regions > [2007-09-13 15:41:41] robla: WORKITEM: a list of possible parameters to consider (e.g. region size: should they be somethign other than 256x256m) > [2007-09-13 15:48:01] robla: WORKITEM: if there are good use cases for topology changes to the architecture, capture > [2007-09-13 15:48:03] Tao_T: and extensible > [2007-09-13 15:48:34] Tao_T: might a 3D grid make sense? http://fourthdimensionally.ytmnd.com/ > [2007-09-13 15:48:47] robla: zero: we don't want to architecture where we bust up the world into tiny individual worlds > [2007-09-13 15:49:00] otakup0pe: Tao_T: who cares it woudl be awesome :D <_< > [2007-09-13 15:49:07] otakup0pe: can i haz tp ? > [2007-09-13 15:49:23] DrScofiel: virutal galaxies! > [2007-09-13 15:49:32] DrScofiel: virtual galaxies evne > [2007-09-13 15:49:34] DrScofiel: even > [2007-09-13 15:49:39] DrScofiel: (getting late) > [2007-09-13 15:49:39] Tao_T: Liana seems not to be here > [2007-09-13 15:49:56] liana: I"m in the conference room in SF. > [2007-09-13 15:50:10] robla: zero: the best example is the evolution of the space archipelego > [2007-09-13 15:50:39] Tao_T: otakup0pe: well, it would be nice to have somebody build "space" ;-) > [2007-09-13 15:50:58] otakup0pe: you mean stacking them vertically ? > [2007-09-13 15:51:00] Tao_T: or have something up in the air like skyboxes but more sky cities > [2007-09-13 15:52:01] Tao_T: I'd like to build another city on top of my existing one http://lolportall.ytmnd.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070915/992ccf98/attachment.pgp From secret.argent at gmail.com Sat Sep 15 13:13:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 15 13:13:11 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <20070915190010.38A9F41B28F@stupor.lindenlab.com> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> Message-ID: What is the motivation for splitting the regions up that way, particularly if a region host being down means that region is not accessible. I would have thought that the whole point to moving the region data from the region hosts to a back end would be to make the region hosts fungible. From tao.takashi at googlemail.com Sat Sep 15 14:22:18 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sat Sep 15 14:22:21 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> Message-ID: <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> 2007/9/15, Argent Stonecutter : > > What is the motivation for splitting the regions up that way, > particularly if a region host being down means that region is not > accessible. I would have thought that the whole point to moving the > region data from the region hosts to a back end would be to make the > region hosts fungible. As noted there is a workitem about thinking about different ways to split the system up. My guess is also that much of the existing simulator code can be reused that way. If you think about the region host as just some interface though you might have as much redundancy behind that interface as you like. So in fact it might be possible to split up a region completely different behind that. I also wonder how flexible a region implementation can be. Like if you want to create something like EVE Online with it you might have a solar system as a region with assets like space sations, planets etc. Avatars are mostly other space ships. A completely different viewer might be needed for that and thus there needs also some ways of specifying what the viewer needs to be capable of. Regarding region domains I actually think it's a good idea though. That way you can simply add your own regions to an existing grid and not central servers are needed. (except identity, topology etc. but these might also not be that central in fact but per region domain or per agent domain). I hope though that Linden Lab will add more about the motivation in the wiki. (like use cases :-) ) -- Tao _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070915/3e230627/attachment.htm From lenglish5 at cox.net Sat Sep 15 18:19:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 15 18:19:51 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> Message-ID: <46EC84B5.4050104@cox.net> Tao Takashi wrote: > > 2007/9/15, Argent Stonecutter >: > > What is the motivation for splitting the regions up that way, > particularly if a region host being down means that region is not > accessible. I would have thought that the whole point to moving the > region data from the region hosts to a back end would be to make the > region hosts fungible. > > > > As noted there is a workitem about thinking about different ways to > split the system up. > My guess is also that much of the existing simulator code can be > reused that way. > > If you think about the region host as just some interface though you > might have as much > redundancy behind that interface as you like. So in fact it might be > possible to split up a > region completely different behind that. > > I also wonder how flexible a region implementation can be. Like if you > want to create > something like EVE Online with it you might have a solar system as a > region with > assets like space sations, planets etc. Avatars are mostly other space > ships. > > A completely different viewer might be needed for that and thus there > needs > also some ways of specifying what the viewer needs to be capable of. > > Regarding region domains I actually think it's a good idea though. > That way you can > simply add your own regions to an existing grid and not central > servers are needed. > (except identity, topology etc. but these might also not be that > central in fact but per > region domain or per agent domain). > > I hope though that Linden Lab will add more about the motivation in > the wiki. > (like use cases :-) ) > Different topologies for region-connections would be incompatible with the LL design, of rectangular islands where people can walk/fly across borders at any point. 3D borders might be interesting, but in the long run, non-rectangular sims with various kinds of portal interfaces, will be the way to go, I think. Where available, no spaceship captain would ever take the "scenic route" of traveling at sublight speeds over any large distance. They'd use the handy space warp buoys (portals) instead. The appearance of vast distances would then be just a drawing convention, rather than travel time. This would also allow non-LL-style sims/regions/zones/whatevers to interact with the LL universe without having to conform to Linden sim conventions for topology, etc. In a sense, we do NOT want a "one size fits all" solution, save in the sense that everyone knows how to handle the transition between two different kinds of sims, including the issues of avatar clothing and accoutrements, appearance, possessions, and money. From hawk.carter at unix-dev.de Sun Sep 16 02:29:21 2007 From: hawk.carter at unix-dev.de (hawk carter) Date: Sun Sep 16 02:30:27 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid ArchitectureWorking Group. References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709151155g1dba864gcc732eb677c24d87@mail.gmail.com> Message-ID: <005001c7f844$28e55050$0301a8c0@main1> Just look onto the aviable cluster and grid solutions from diffrent technology providers. I build an Cluster for Webservices (1200 Server+), here some tips : 1. Blade Centers 2. Dedicated Loadbalancer (Server only with that function). 3. Traffic Shaping. 4. NO Vhosts for 3d Enviroments, each region = one dedicated server. To decrease the load on a physical Server. 5. and some more stuff. From tao.takashi at googlemail.com Sun Sep 16 02:30:48 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sun Sep 16 02:30:51 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46EC84B5.4050104@cox.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> <46EC84B5.4050104@cox.net> Message-ID: <23bbb49e0709160230w4a53ac96i67edee0ea6804dc1@mail.gmail.com> > Different topologies for region-connections would be incompatible with > the LL design, of rectangular islands where people can walk/fly across > borders at any point. > > 3D borders might be interesting, but in the long run, non-rectangular > sims with various kinds of portal interfaces, will be the way to go, I > think. Where available, no spaceship captain would ever take the "scenic > route" of traveling at sublight speeds over any large distance. They'd > use the handy space warp buoys (portals) instead. The appearance of vast > distances would then be just a drawing convention, rather than travel > time. > > This would also allow non-LL-style sims/regions/zones/whatevers to > interact with the LL universe without having to conform to Linden sim > conventions for topology, etc. > > In a sense, we do NOT want a "one size fits all" solution, save in the > sense that everyone knows how to handle the transition between two > different kinds of sims, including the issues of avatar clothing and > accoutrements, appearance, possessions, and money. Well, there might be a tradeoff between portal-like regions and contigous space. Both should actually be possible and LL made it clear in that meeting that they want a contigous space. So maybe there can be different types of region domains with different layouts and those which are compatible should be able to check this with each other. Internally of course every region domain could say that there are only portals if they wish to do so. I only wonder how to define the topology which means which region connects to which other esp. if both are in different region domains. And I agree that mostly everything should be possible with this architecture. Regarding money I think you simply have different account and each component can define which type of service it supports. -- Tao _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070916/724f57bb/attachment-0001.htm From hawk.carter at unix-dev.de Sun Sep 16 02:32:52 2007 From: hawk.carter at unix-dev.de (hawk carter) Date: Sun Sep 16 02:33:08 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life GridArchitectureWorking Group. References: <46E9D388.3030204@lindenlab.com><23bbb49e0709151155g1dba864gcc732eb677c24d87@mail.gmail.com> <005001c7f844$28e55050$0301a8c0@main1> Message-ID: <006d01c7f844$8e348660$0301a8c0@main1> Ahh well, and yes...and the code needs to be rewritten in my eyes. Hawk ----- Original Message ----- From: "hawk carter" Cc: "Second Life Developer Mailing List" Sent: Sunday, September 16, 2007 11:29 AM Subject: Re: [sldev] [ARCH] Raw notes from the Second Life GridArchitectureWorking Group. > Just look onto the aviable cluster and grid solutions from diffrent > technology providers. > > I build an Cluster for Webservices (1200 Server+), here some tips : > > 1. Blade Centers > 2. Dedicated Loadbalancer (Server only with that function). > 3. Traffic Shaping. > 4. NO Vhosts for 3d Enviroments, each region = one dedicated server. To > decrease the load on a physical Server. > 5. and some more stuff. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From bboomslang at googlemail.com Sun Sep 16 03:09:51 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sun Sep 16 03:09:53 2007 Subject: [sldev] Bugs in the Mac OS X Source tree Message-ID: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> Hey Mac-heads, please check the following jira bugs and vote if you think we Mac-heads should be able to do a full working build of the client, too ;) This one is critical: the cursors_mac directory is missing and viewer_manifest.py willingly ignores that, so we are missing several mouse cursors in the build (I wrote about that some time ago): http://jira.secondlife.com/browse/VWR-2482 The next one is about the giant executables the project file produces with Deployment or Universal builds: http://jira.secondlife.com/browse/VWR-2483 This one is the missing SecondLife icon for the application. This might be intentional of LL, but then there should be a word on it. http://jira.secondlife.com/browse/VWR-2484 Maybe an idea: put a readme in the source tree that actually states _why_ stuff is missing? And put comments into viewer_manifest.py about why parts of it are commented out, like the kakadu library - that one is a no-brainer, since we don't have redistribution rights for that. Oh, but you still deliver it (the library) with your libraries download ... bye, Barney From matthew.dowd at hotmail.co.uk Sun Sep 16 04:07:46 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Sep 16 04:07:47 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> Message-ID: I'm still playing catch up so this may have already been mentioned, but I think it would also be worth considering how the Region simulator (or rather components) maps to actual servers, and (as I think has been suggested) start considering computer grid computing based architectures (http://en.wikipedia.org/wiki/Grid_computing) to handle the region scalability problem (e.g. regions with >100 users). So for instance, initially a region sim with only a few users may be running on a compute node (which might be a cluster) alongside other regions. As the region gets busier it might move itself to a more powerful node or a node running fewer regions (or perhaps a dedicated node). At some point it might start splitting tasks - so the physic engine gets moved to one node, and the script engine to another. As the load really increases it may even split sub tasks - e.g. splitting the script engine between two nodes (of course, this may introduce communication latencies). I've worked with grid computing enough to know that the above is not trivial, and is much easier to express than actually do, but I think it worth considering this in the architecture discussions - at the very least the architecture should support the above even if not initially implement it. Matthew From: markl@lindenlab.comSubject: Re: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group.Date: Fri, 14 Sep 2007 15:44:11 -0700To: sldev@lists.secondlife.com; tao.takashi@googlemail.com On Sep 14, 2007, at 1:05 PM, Liana Holmberg wrote: Zero's slides are available at Hippotropolis 212, 13,24. And now up on the wiki: http://wiki.secondlife.com/wiki/ArchWG_Mtg_1_Slides - Zero Mark Lentczner Director, Studio Icehouse Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070916/e56547f0/attachment.htm From tao.takashi at googlemail.com Sun Sep 16 04:17:15 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sun Sep 16 04:17:17 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> Message-ID: <23bbb49e0709160417n4268f5edle9bfb52e4ce621a8@mail.gmail.com> Hi! I'm still playing catch up so this may have already been mentioned, but I > think it would also be worth considering how the Region simulator (or rather > components) maps to actual servers, and (as I think has been suggested) > start considering computer grid computing based architectures ( > http://en.wikipedia.org/wiki/Grid_computing) to handle the region > scalability problem (e.g. regions with >100 users). > The region hosts you see in the diagram can probably be anything, a single host, a cluster, whatever.. For a start there will probably be the simulators we know but later on people could experiment with more complex setups (and I guess at least folks like Intel, IBM or Sun will definitely want to use their technology which might support this). As I see it those boxes are just there for showing where interfaces need to be defined. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070916/2a81b771/attachment.htm From robin.cornelius at gmail.com Sun Sep 16 06:00:32 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Sep 16 06:00:34 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: <20070915162631.GB11645@spacedout.fries.net> References: <20070914123755.GA11645@spacedout.fries.net> <20070915162631.GB11645@spacedout.fries.net> Message-ID: On 9/15/07, David Fries wrote: > On Sat, Sep 15, 2007 at 04:02:01PM +0100, Robin Cornelius wrote: > > Hi David, thanks for the info and patch, yes that will save a lot of > > messing about, one question though, what source tree is the patch > > based against. Tried against 1.18.2.0 and it failed on various files, > > i assume because its against a different base. > > > > Regards > > > > Robin > > 1.18.0.6 > Ah that explains it, looking at the code the 1.18.2.0 tree is a lot cleaner in respect to what needs to be done and attached is a patch i used to get it to build on an AMD64 debian testing. Its pretty much a swap a few #include "foo.h" to #include and fiddle with the scons file slightly. Oh and debian has libapr in "apr-1.0/" not "apr-1/" and openjpeg and libxml-rpc got dropped into /usr/include and not /usr/include// so i patched the includes as it was quick and easy. Anyway if it is of interest to anyone its attached. With above patch i have built completely against Debian (testing/lenny) libs (except for jpeg2000 and xmlrpc-epi) I used STANDALONE=yes and I also specified ELFIO=no on the scons build so i assume the ELFIO and also the google-perftools are not being used although they are also present on my system. But i have run in to a major issue. Although i can get in world with my 64 bit build, i can't see anything, a few outlines, I can see the avatar name/group tags floating around. UI controls all seem ok, mini maps etc work. I assume a problem with the jpeg2000 lib stopping textures being rendered so its all a grey goo. Thanks for any help Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.patch Type: text/x-patch Size: 14615 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/c319acd5/sl-0001.bin From seg at haxxed.com Sun Sep 16 08:26:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 08:27:05 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <23bbb49e0709160230w4a53ac96i67edee0ea6804dc1@mail.gmail.com> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> <46EC84B5.4050104@cox.net> <23bbb49e0709160230w4a53ac96i67edee0ea6804dc1@mail.gmail.com> Message-ID: <1189956418.20962.4.camel@localhost> On Sun, 2007-09-16 at 11:30 +0200, Tao Takashi wrote: > Well, there might be a tradeoff between portal-like regions and > contigous space. Both should actually be possible and LL made it clear > in that meeting that they want a contigous space. There's no reason LL couldn't just interconnect their sims with 256x(inf) portals on each side of a 256x256x(inf) box and get something that appears and performs exactly like what they have now, while actually using the much more flexible portal system used by a hypothetical "everyone else". We're adding flexibility here, not removing it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/7073b509/attachment.pgp From dale at daleglass.net Sun Sep 16 08:39:27 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Sep 16 08:39:38 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <1189956418.20962.4.camel@localhost> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709160230w4a53ac96i67edee0ea6804dc1@mail.gmail.com> <1189956418.20962.4.camel@localhost> Message-ID: <200709161739.33611.dale@daleglass.net> On Sunday 16 September 2007 17:26:58 Callum Lerwick wrote: > On Sun, 2007-09-16 at 11:30 +0200, Tao Takashi wrote: > > Well, there might be a tradeoff between portal-like regions and > > contigous space. Both should actually be possible and LL made it clear > > in that meeting that they want a contigous space. > > There's no reason LL couldn't just interconnect their sims with > 256x(inf) portals on each side of a 256x256x(inf) box and get something > that appears and performs exactly like what they have now, while > actually using the much more flexible portal system used by a > hypothetical "everyone else". > > We're adding flexibility here, not removing it. One thing I'd like to see is on-demand grid reshaping. While I don't own any, my understanding is that currently moving a region is a slow process and involves specifically asking for it, as well as paying a fee. What I'd like is to give sim owners the possibility of connecting and disconnecting their regions at will, with the consent of all the people involved. Eg, want to throw a big party? 4 sim owners could agree with each other, connect their sims and have it ready in a few minutes. This could also create the possibility of people spontaneously creating their own mainland. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/0456e4a9/attachment.pgp From secret.argent at gmail.com Sun Sep 16 08:50:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 16 08:50:45 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <20070916093054.9861141B14B@stupor.lindenlab.com> References: <20070916093054.9861141B14B@stupor.lindenlab.com> Message-ID: <995DC26B-94F4-4231-8C88-381351BCE534@gmail.com> From: Lawson English > Different topologies for region-connections would be incompatible with > the LL design, of rectangular islands where people can walk/fly across > borders at any point. I think you and Tao have going off at a tangent for my question. There's nothing in the current design where a region has its resources locally and shares them with logically adjacent regions that prevents it from having non-grid-like connections to the other regions. My question wasn't "why not a grid", it was "why split the resources for regions up that way". From seg at haxxed.com Sun Sep 16 09:20:45 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 09:20:48 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46EC84B5.4050104@cox.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> <46EC84B5.4050104@cox.net> Message-ID: <1189959645.20962.49.camel@localhost> So, how many of us came to SL from MUCKs or MUSHs? :) I know I did. SL really is to MUCK/MUSH what WoW is to MUDs. Freeform socialization and all users are typically allowed to build. How many of us have built on a MU*? (I've mostly been on MUCKs, for all I know this is horribly wrong for the other ones... :) For those who don't know, usually you start out by "digging" a room. This creates a room, a room that exists with no intrinsic location. It is nothing but a dbref floating alone in the database. You give the room a location by then linking it to other rooms. The room's location becomes an illusion implied by its links to other rooms. The room itself still has no intrinsic location of its own. Naming the exits north, south, east, west, up or down is merely convention. The structure of a MU* is essentially a directed cycle graph. Which is real fun to try and create map out of if its creators haven't been careful to keep it an undirected graph. :) I imagine SL could work just the same. Users could freely "dig" any number of dimensions and build in them. Each dimension would give a user practically unlimited space. (How big is a double? :) Users could then freely link their dimensions together as they see fit using teleporters or portals. The dimensions could exist on the same simulator, or on completely separate ones. In fact, we could abstract things at the "dimension" level, and bounce dimensions around a simulator farm as needed. If no one is currently in a dimension, you could even serialize it to long term storage and shut it down entirely. Users would no longer have to compete for space. You would no longer be forced to live your second life next to an obnoxious neighbor. There would no longer be a market for land sales. The market would become the CPU cycles needed to simulate your dimension, as it should be. Suck it, Anshe. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/9d26198c/attachment.pgp From soft at lindenlab.com Sun Sep 16 09:31:21 2007 From: soft at lindenlab.com (Soft Linden) Date: Sun Sep 16 09:31:24 2007 Subject: [sldev] Teleportation woes In-Reply-To: <2c99c46e0709141805w31b11da5if23ac1b631a435aa@mail.gmail.com> References: <2c99c46e0709141805w31b11da5if23ac1b631a435aa@mail.gmail.com> Message-ID: <9e6e5c9e0709160931x4a908b85g7c632ca35b82eec6@mail.gmail.com> On 9/14/07, Michael Miller <1337mail@gmail.com> wrote: > I'm trying to get my client to automatically teleport to a location at > the start of the game. The jist of the code is as such: > > if(gStartupState == STATE_STARTED) > gAgent.teleportViaLocation(LLVector3d(98,143,120)); > > This(the teleportViaLocation method) generates the following message: > > 2007-09-15T01:00:09Z WARNING: teleportViaLocation: Using deprecated > teleportlocationrequest. > 2007-09-15T01:00:09Z WARNING: createXml: Alert: [CouldNotTeleportReason] > 2007-09-15T01:00:09Z WARNING: createDialog: Alert: Could not teleport. > Problem encountered processing your teleport request. You may > need to log back in before you can teleport. If you continue > to get this message, please check the Tech Support FAQ at: > www.secondlife.com/support > > I have even tried waiting 60 seconds(while the game is fully running > for some time) before executing this request. Is this due to the > teleportViaLocation method? Am I calling it correctly? Should I be > calling something else? With this kind of question, I usually start by asking where the code does something similar to what I want. Teleporting via the map dialog would seem to do it exactly, so I'd begin by looking at what happens when you click "teleport" there. The easiest way to find that code is to find the map UI file by searching for a visible string in the UI descriptions in indra/newview/skins/xui/en-us. "Copy slurl to clipboard" looks like a pretty unique string. When you find that file, look for two things. First, the name of the file. Somewhere in the code there will be a call to buildFloater() that takes the filename as an argument. Searching for this should get you to the right file. Also, inside the UI description file, look for the "Teleport" string. The element that identifies the label attribute (the visible part) will also have a name attribute, which is used for identifying that button in code. Search for that name in the source file that builds up that floater. >From there, you should see code that sets up a callback for when the teleport button is clicked. All you have to do now is set a breakpoint on the callback function and follow through in the debugger. That should put you right on top of the most current location teleport logic. From seg at haxxed.com Sun Sep 16 09:35:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 09:35:57 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: References: <20070914123755.GA11645@spacedout.fries.net> <20070915162631.GB11645@spacedout.fries.net> Message-ID: <1189960551.20962.52.camel@localhost> On Sun, 2007-09-16 at 14:00 +0100, Robin Cornelius wrote: > Its pretty much a swap a few #include "foo.h" to #include and > fiddle with the scons file slightly. Oh and debian has libapr in > "apr-1.0/" not "apr-1/" and openjpeg and libxml-rpc got dropped into > /usr/include and not /usr/include// so i patched the includes > as it was quick and easy. #include "foo.h" is AFAIK correct, pkgconfig should be setting up the needed paths. http://jira.secondlife.com/browse/VWR-2488 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/ada4d5de/attachment.pgp From seg at haxxed.com Sun Sep 16 09:42:35 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 09:42:40 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <200709161739.33611.dale@daleglass.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709160230w4a53ac96i67edee0ea6804dc1@mail.gmail.com> <1189956418.20962.4.camel@localhost> <200709161739.33611.dale@daleglass.net> Message-ID: <1189960955.20962.54.camel@localhost> On Sun, 2007-09-16 at 17:39 +0200, Dale Glass wrote: > One thing I'd like to see is on-demand grid reshaping. > > While I don't own any, my understanding is that currently moving a region > is a slow process and involves specifically asking for it, as well as > paying a fee. > > What I'd like is to give sim owners the possibility of connecting and > disconnecting their regions at will, with the consent of all the people > involved. Eg, want to throw a big party? 4 sim owners could agree with > each other, connect their sims and have it ready in a few minutes. > > This could also create the possibility of people spontaneously creating > their own mainland. This is exactly the kind of thing my proposed dimensional portal system is intended to enable. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/f2896053/attachment.pgp From labrat.hb at gmail.com Sun Sep 16 10:39:24 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Sep 16 10:39:26 2007 Subject: [sldev] Teleportation woes In-Reply-To: <9e6e5c9e0709160931x4a908b85g7c632ca35b82eec6@mail.gmail.com> References: <2c99c46e0709141805w31b11da5if23ac1b631a435aa@mail.gmail.com> <9e6e5c9e0709160931x4a908b85g7c632ca35b82eec6@mail.gmail.com> Message-ID: I'd look at the startup / login process. There is already code in place to handle teleporting to a specific location when entering the grid. in llstartup.cpp if ( LLURLSimString::sInstance.mSimString.length() ) { // record the location to start at next time gSavedSettings.setString( "NextLoginLocation", LLURLSimString:: sInstance.mSimString ); }; On 9/16/07, Soft Linden wrote: > > On 9/14/07, Michael Miller <1337mail@gmail.com> wrote: > > I'm trying to get my client to automatically teleport to a location at > > the start of the game. The jist of the code is as such: > > > > if(gStartupState == STATE_STARTED) > > gAgent.teleportViaLocation(LLVector3d(98,143,120)); > > > > This(the teleportViaLocation method) generates the following message: > > > > 2007-09-15T01:00:09Z WARNING: teleportViaLocation: Using deprecated > > teleportlocationrequest. > > 2007-09-15T01:00:09Z WARNING: createXml: Alert: [CouldNotTeleportReason] > > 2007-09-15T01:00:09Z WARNING: createDialog: Alert: Could not teleport. > > Problem encountered processing your teleport request. You may > > need to log back in before you can teleport. If > you continue > > to get this message, please check the Tech > Support FAQ at: > > www.secondlife.com/support > > > > I have even tried waiting 60 seconds(while the game is fully running > > for some time) before executing this request. Is this due to the > > teleportViaLocation method? Am I calling it correctly? Should I be > > calling something else? > > With this kind of question, I usually start by asking where the code > does something similar to what I want. Teleporting via the map dialog > would seem to do it exactly, so I'd begin by looking at what happens > when you click "teleport" there. The easiest way to find that code is > to find the map UI file by searching for a visible string in the UI > descriptions in indra/newview/skins/xui/en-us. "Copy slurl to > clipboard" looks like a pretty unique string. > > When you find that file, look for two things. First, the name of the > file. Somewhere in the code there will be a call to buildFloater() > that takes the filename as an argument. Searching for this should get > you to the right file. Also, inside the UI description file, look for > the "Teleport" string. The element that identifies the label attribute > (the visible part) will also have a name attribute, which is used for > identifying that button in code. Search for that name in the source > file that builds up that floater. > > >From there, you should see code that sets up a callback for when the > teleport button is clicked. All you have to do now is set a breakpoint > on the callback function and follow through in the debugger. That > should put you right on top of the most current location teleport > logic. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070916/4f5a005e/attachment-0001.htm From lenglish5 at cox.net Sun Sep 16 10:51:23 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 16 10:51:26 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <1189959645.20962.49.camel@localhost> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <23bbb49e0709151422hc034037o1f3a6bbed1856f34@mail.gmail.com> <46EC84B5.4050104@cox.net> <1189959645.20962.49.camel@localhost> Message-ID: <46ED6D1B.1080700@cox.net> Callum Lerwick wrote: > [...] > > Users would no longer have to compete for space. You would no longer be > forced to live your second life next to an obnoxious neighbor. There > would no longer be a market for land sales. The market would become the > CPU cycles needed to simulate your dimension, as it should be. Suck it, > Anshe. :) > And... You've just explained why Linden Labs won't support such an architecture within its own simulators, at least not in the near future: you don't threaten the income of your largest single customer with your far-off-plans for expansion. From dale at daleglass.net Sun Sep 16 11:11:04 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Sep 16 11:11:16 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second =?iso-8859-1?q?Life=09Grid=09Architecture_Working?= Group. In-Reply-To: <46ED6D1B.1080700@cox.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <1189959645.20962.49.camel@localhost> <46ED6D1B.1080700@cox.net> Message-ID: <200709162011.11763.dale@daleglass.net> On Sunday 16 September 2007 19:51:23 Lawson English wrote: > Callum Lerwick wrote: > > [...] > > > > Users would no longer have to compete for space. You would no longer > > be forced to live your second life next to an obnoxious neighbor. > > There would no longer be a market for land sales. The market would > > become the CPU cycles needed to simulate your dimension, as it should > > be. Suck it, Anshe. :) > > And... > > You've just explained why Linden Labs won't support such an architecture > within its own simulators, at least not in the near future: > > > you don't threaten the income of your largest single customer with your > far-off-plans for expansion. My impression is that doesn't like Anshe all that much. On one hand, she's a huge customer. One they can point at and say "See? You can get big bucks here". That's good to have. On the other hand, she's too big, and wields considerable power. She threatened to create her own alternative to L$ in one ocassion, IIRC. So while I don't think LL would go and screw over Anshe outright, they're probably not completely opposed to her losing a bit of influence either. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/ac63ca6a/attachment.pgp From david at fries.net Sun Sep 16 11:15:02 2007 From: david at fries.net (David Fries) Date: Sun Sep 16 11:15:22 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: References: <20070914123755.GA11645@spacedout.fries.net> <20070915162631.GB11645@spacedout.fries.net> Message-ID: <20070916181502.GH1843@spacedout.fries.net> On Sun, Sep 16, 2007 at 02:00:32PM +0100, Robin Cornelius wrote: > On 9/15/07, David Fries wrote: > Ah that explains it, looking at the code the 1.18.2.0 tree is a lot > cleaner in respect to what needs to be done and attached is a patch i > used to get it to build on an AMD64 debian testing. > > Its pretty much a swap a few #include "foo.h" to #include and > fiddle with the scons file slightly. Oh and debian has libapr in > "apr-1.0/" not "apr-1/" and openjpeg and libxml-rpc got dropped into > /usr/include and not /usr/include// so i patched the includes > as it was quick and easy. I looked into the apr-1.0 vs apr-1 and the apr source installs to apr-1 but the Debian package build process overrides that to set it to apr-1.0 on compile. I submitted a bug report noting it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442375 The libapr1-dev package description says that it conflicts with libapr1.0-dev, so I'm wondering if that override was specified when it was libapr1.0-dev and never changed to keep up with the version. The only solution for it to work for both the /usr/include/apr-1 and /usr/include/apr-1.0 case I see is to drop the subdirectory reference in the include directive and add `pkg-config --cflags apr-1` to the command line which will directly add the subdirectory. > But i have run in to a major issue. Although i can get in world with > my 64 bit build, i can't see anything, a few outlines, I can see the > avatar name/group tags floating around. UI controls all seem ok, mini > maps etc work. I assume a problem with the jpeg2000 lib stopping > textures being rendered so its all a grey goo. Bring up the texture decode debug information, control-shift-3, that might give a clue if a texture is getting stuck. Edit an object (doesn't have to be yours) and go to the texture tab, that will give that texture priority for decoding. But you say that the UI textures are fine? They are also compressed textures, so OpenJPEG must be working for them. That's just for information. Try clearing your cache (or move the directory out of the way) and see if things work. -- David Fries http://fries.net/~david/ (PGP encryption key available) From lenglish5 at cox.net Sun Sep 16 11:24:18 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 16 11:24:20 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <200709162011.11763.dale@daleglass.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <1189959645.20962.49.camel@localhost> <46ED6D1B.1080700@cox.net> <200709162011.11763.dale@daleglass.net> Message-ID: <46ED74D2.9050403@cox.net> Dale Glass wrote: > On Sunday 16 September 2007 19:51:23 Lawson English wrote: > >> Callum Lerwick wrote: >> >>> [...] >>> >>> Users would no longer have to compete for space. You would no longer >>> be forced to live your second life next to an obnoxious neighbor. >>> There would no longer be a market for land sales. The market would >>> become the CPU cycles needed to simulate your dimension, as it should >>> be. Suck it, Anshe. :) >>> >> And... >> >> You've just explained why Linden Labs won't support such an architecture >> within its own simulators, at least not in the near future: >> >> >> you don't threaten the income of your largest single customer with your >> far-off-plans for expansion. >> > My impression is that doesn't like Anshe all that much. > > On one hand, she's a huge customer. One they can point at and say "See? You > can get big bucks here". That's good to have. > > On the other hand, she's too big, and wields considerable power. She > threatened to create her own alternative to L$ in one ocassion, IIRC. > > So while I don't think LL would go and screw over Anshe outright, they're > probably not completely opposed to her losing a bit of influence either. > > I've seen enough of the politics between the big computer software makers: Microsoft, Apple, Adobe, etc., to realize that they play all sorts of interesting games at various levels. Entire product-lines within Apple get created in cooperation with Microsoft (TruetType) in order to put business pressure on Adobe to make PostScript less expensive. Other products, originally meant to threaten Adobe and Microsoft, (GX, OpenDoc), are thrown away in order to curry political favor with those some companies during Jobs' boardroom battles to take over Apple. Jobs denigrates the Newton and PDAs in general while secretly trying to buy the Palm Pilot from US Robotics for $1 billion. You see it in long-term patent-wars as well where companies procure obviously ludicrous patents in order to gain easier licensing terms for other, more valid patents--its easier to cut someone a better deal on licensing than to challenge patents in court and no-one wants to rock the boat by creating precedents that might screw up their OWN account of patent-currency anyway. No doubt, if LL's leadership has any savvy at all, there are similar maneuverings going on here as well, though not as obvious, at least to me. From tao.takashi at googlemail.com Sun Sep 16 11:37:34 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sun Sep 16 11:37:36 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <46ED74D2.9050403@cox.net> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <1189959645.20962.49.camel@localhost> <46ED6D1B.1080700@cox.net> <200709162011.11763.dale@daleglass.net> <46ED74D2.9050403@cox.net> Message-ID: <23bbb49e0709161137ud7f895xfb8b3a55028d381d@mail.gmail.com> Shouldn't we simply say that this architecture should support any form of regions? :-) Some people (me included) actually like to have some sort of continent be it implemented as you will. Some might want to do things like solar systems or completely different region shapes. Maybe it might not even be some 3d space but something completely different. I just would assume that Linden Lab will implement regions like we have them right now first as they want to port the existing grid to this new architecture. We just should make sure that the protocol does allow for more. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070916/0c288b6e/attachment.htm From robin.cornelius at gmail.com Sun Sep 16 11:43:29 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Sep 16 11:43:31 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: <20070916181502.GH1843@spacedout.fries.net> References: <20070914123755.GA11645@spacedout.fries.net> <20070915162631.GB11645@spacedout.fries.net> <20070916181502.GH1843@spacedout.fries.net> Message-ID: On 9/16/07, David Fries wrote: > > Its pretty much a swap a few #include "foo.h" to #include and > > fiddle with the scons file slightly. Oh and debian has libapr in > > "apr-1.0/" not "apr-1/" and openjpeg and libxml-rpc got dropped into > > /usr/include and not /usr/include// so i patched the includes > > as it was quick and easy. > > I looked into the apr-1.0 vs apr-1 and the apr source installs to > apr-1 but the Debian package build process overrides that to set it to > apr-1.0 on compile. I submitted a bug report noting it. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442375 Ah cool, that explains that one, I'm going back through the build process to see what the minimum number of changes necessary is to get a complete build. I think i am now down to some tweaking in the SConstruct file so perhapses the time has come to look at the preview release and see what has changed there as it may have sorted some of these issues out. > Bring up the texture decode debug information, control-shift-3, that > might give a clue if a texture is getting stuck. Edit an object > (doesn't have to be yours) and go to the texture tab, that will give > that texture priority for decoding. But you say that the UI textures > are fine? They are also compressed textures, so OpenJPEG must be > working for them. > > That's just for information. Try clearing your cache (or move the > directory out of the way) and see if things work. > I hosed the entire .secondlife directory, and it cleared the fault. I had not does this before as this is a new install of debian on a clean system and the first time I have been able to run secondlife on this system was with my 64bit build. But i assume one of the failed attempts to run a 32bit version or the rpm packaged 64bit version caused upset somewhere and left some crud! Many thanks Robin From bboomslang at googlemail.com Sun Sep 16 13:17:51 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sun Sep 16 13:17:53 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <46ED51AF.7070509@blueflash.cc> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> Message-ID: <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> Hey Nicholaz, yes, that's exactly what I did. llthread.cpp, changed to APR_THREAD_MUTEX_NESTED and all is golden. bye, Barney On 9/16/07, Nicholaz Beresford wrote: > > I just looked a bit deeper. I think the issue is to > replace all APR_THREAD_MUTEX_DEFAULT to > APR_THREAD_MUTEX_NESTED. > > Or of course undo my patch with the EasyCacheWriter. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Barney Boomslang wrote: > > Hey Mac-heads, > > > > please check the following jira bugs and vote if you think we > > Mac-heads should be able to do a full working build of the client, too > > ;) > > > > This one is critical: the cursors_mac directory is missing and > > viewer_manifest.py willingly ignores that, so we are missing several > > mouse cursors in the build (I wrote about that some time ago): > > > > http://jira.secondlife.com/browse/VWR-2482 > > > > The next one is about the giant executables the project file produces > > with Deployment or Universal builds: > > > > http://jira.secondlife.com/browse/VWR-2483 > > > > This one is the missing SecondLife icon for the application. This > > might be intentional of LL, but then there should be a word on it. > > > > http://jira.secondlife.com/browse/VWR-2484 > > > > Maybe an idea: put a readme in the source tree that actually states > > _why_ stuff is missing? And put comments into viewer_manifest.py about > > why parts of it are commented out, like the kakadu library - that one > > is a no-brainer, since we don't have redistribution rights for that. > > Oh, but you still deliver it (the library) with your libraries > > download ... > > > > bye, Barney > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Sun Sep 16 13:32:12 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 16 13:32:17 2007 Subject: [sldev] Re: [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <23bbb49e0709161137ud7f895xfb8b3a55028d381d@mail.gmail.com> References: <20070915190010.38A9F41B28F@stupor.lindenlab.com> <1189959645.20962.49.camel@localhost> <46ED6D1B.1080700@cox.net> <200709162011.11763.dale@daleglass.net> <46ED74D2.9050403@cox.net> <23bbb49e0709161137ud7f895xfb8b3a55028d381d@mail.gmail.com> Message-ID: <46ED92CC.4050805@cox.net> Tao Takashi wrote: > Shouldn't we simply say that this architecture should support any form > of regions? :-) > > Some people (me included) actually like to have some sort of continent > be it implemented as you will. Some might want to > do things like solar systems or completely different region shapes. > Maybe it might not even be some 3d space but something > completely different. > > I just would assume that Linden Lab will implement regions like we > have them right now first > as they want to port the existing grid to this new architecture. We > just should make sure that > the protocol does allow for more. > /me votes for that... From seg at haxxed.com Sun Sep 16 15:54:27 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 15:54:29 2007 Subject: [sldev] [VIEWER] 64 bit status and open source components In-Reply-To: <20070916181502.GH1843@spacedout.fries.net> References: <20070914123755.GA11645@spacedout.fries.net> <20070915162631.GB11645@spacedout.fries.net> <20070916181502.GH1843@spacedout.fries.net> Message-ID: <1189983267.20962.64.camel@localhost> On Sun, 2007-09-16 at 13:15 -0500, David Fries wrote: > The only solution for it to work for both the /usr/include/apr-1 and > /usr/include/apr-1.0 case I see is to drop the subdirectory reference > in the include directive and add `pkg-config --cflags apr-1` to the > command line which will directly add the subdirectory. The RC's use pkg-config as it should. > > But i have run in to a major issue. Although i can get in world with > > my 64 bit build, i can't see anything, a few outlines, I can see the > > avatar name/group tags floating around. UI controls all seem ok, mini > > maps etc work. I assume a problem with the jpeg2000 lib stopping > > textures being rendered so its all a grey goo. Hung texture decode is yet another manifestation of the yet to be found OpenJPEG lossless texture bug. You more often than not end up hanging while decoding your own avatar textures. You'll want the patch in VWR-1475: http://jira.secondlife.com/secure/attachment/11270/slviewer-1.18.0.6-openjpeg-use-lossy-encoding-20070716.patch > That's just for information. Try clearing your cache (or move the > directory out of the way) and see if things work. Won't help. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/2de45b47/attachment.pgp From trevor at gridbug.org Sun Sep 16 19:49:01 2007 From: trevor at gridbug.org (Trevor Powell) Date: Sun Sep 16 19:49:09 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> Message-ID: <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> I have a working OS X build of Nicholaz's 18g build.. I've worked through each of the issues below.. The problem with cursors_mac is just that the directory itself is missing; all the files that should be in it are dumped into the root of the mac resources directory, instead of into a 'cursors_mac' directory inside that directory. That one was easy to fix, locally. The giant executables seem to be caused by linking in the Mozilla library. Or at least, when I removed it from the linking process, it yielded no linking errors and the final executable came down from >1gig to the 70ish megs that you'd expect. I haven't yet looked at the post-voice source releases on the Mac (except to plunder some the pre-built png libraries that they forgot to include in the pre-voice source releases).. I'd release my builds, except that they suffer from a weird behaviour; textures seem to load far, far slower than they do in the official Linden version. Slow enough that it's not at all uncommon for me to hang around in a single area and still have blank grey textures on many things twenty minutes later. It's as though it wasn't retrying to grab the textures if a packet got lost, or something. Haven't had a chance to delve more deeply into it yet, though. And in all honesty, the solution may come by moving up to a post-voice source release; LL seem to have fixed a bunch of problems in the Mac source releases post-voice. Trevor > Hey Nicholaz, > > yes, that's exactly what I did. llthread.cpp, changed to > APR_THREAD_MUTEX_NESTED and all is golden. > > bye, Barney > > On 9/16/07, Nicholaz Beresford wrote: >> >> I just looked a bit deeper. I think the issue is to >> replace all APR_THREAD_MUTEX_DEFAULT to >> APR_THREAD_MUTEX_NESTED. >> >> Or of course undo my patch with the EasyCacheWriter. >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Barney Boomslang wrote: >> > Hey Mac-heads, >> > >> > please check the following jira bugs and vote if you think we >> > Mac-heads should be able to do a full working build of the client, too >> > ;) >> > >> > This one is critical: the cursors_mac directory is missing and >> > viewer_manifest.py willingly ignores that, so we are missing several >> > mouse cursors in the build (I wrote about that some time ago): >> > >> > http://jira.secondlife.com/browse/VWR-2482 >> > >> > The next one is about the giant executables the project file produces >> > with Deployment or Universal builds: >> > >> > http://jira.secondlife.com/browse/VWR-2483 >> > >> > This one is the missing SecondLife icon for the application. This >> > might be intentional of LL, but then there should be a word on it. >> > >> > http://jira.secondlife.com/browse/VWR-2484 >> > >> > Maybe an idea: put a readme in the source tree that actually states >> > _why_ stuff is missing? And put comments into viewer_manifest.py about >> > why parts of it are commented out, like the kakadu library - that one >> > is a no-brainer, since we don't have redistribution rights for that. >> > Oh, but you still deliver it (the library) with your libraries >> > download ... >> > >> > bye, Barney >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From seg at haxxed.com Sun Sep 16 20:16:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Sep 16 20:16:25 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> Message-ID: <1189998982.20962.81.camel@localhost> On Mon, 2007-09-17 at 12:49 +1000, Trevor Powell wrote: > I'd release my builds, except that they > suffer from a weird behaviour; textures seem to load far, far slower than > they do in the official Linden version. Slow enough that it's not at all > uncommon for me to hang around in a single area and still have blank grey > textures on many things twenty minutes later. *sigh* Sounds like you're using OpenJPEG and suffering from the lossless bug. You want this patch: http://jira.secondlife.com/browse/VWR-1475 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070916/e5f5b4fb/attachment.pgp From gigstaggart at gmail.com Sun Sep 16 22:15:49 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 16 22:16:24 2007 Subject: [sldev] How LL Branches Work Message-ID: <46EE0D85.8030606@gmail.com> I don't think I was the only one who was confused about this, I talked to Rob and made this picture and updated the page: https://wiki.secondlife.com/wiki/Source_branches From jhurliman at wsu.edu Sun Sep 16 22:17:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Sep 16 22:17:23 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <1189998982.20962.81.camel@localhost> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <1189998982.20962.81.camel@localhost> Message-ID: <46EE0DD7.2070908@wsu.edu> Callum Lerwick wrote: > On Mon, 2007-09-17 at 12:49 +1000, Trevor Powell wrote: > >> I'd release my builds, except that they >> suffer from a weird behaviour; textures seem to load far, far slower than >> they do in the official Linden version. Slow enough that it's not at all >> uncommon for me to hang around in a single area and still have blank grey >> textures on many things twenty minutes later. >> > > *sigh* Sounds like you're using OpenJPEG and suffering from the lossless > bug. You want this patch: > > http://jira.secondlife.com/browse/VWR-1475 > > ------------------------------------------------------------------------ Although that patch doesn't actually fix the bug, it just makes it less likely that you will encounter it since you would have to stumble across someone else's lossless images to trigger the bug. John From bboomslang at googlemail.com Sun Sep 16 23:25:56 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sun Sep 16 23:25:57 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> Message-ID: <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> Oh, I have working versions of both the non-voice and the voice NB builds. And no, mozilla is not the culprit, it's the way the executable is linked :) I have a rough writedown (mostly for myself, to remember for next build) of what I did here: http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt I have the nagging feeling I forgot one step, so it might need an adaption later when I find out what that was. If you run along those things and discover something missing, give me a shout. I'm currentlyl giving the voice variant a good usage to see what problems show up (non so far) and a friend runs the non-voice one and we look into that, too (a few little quirks so far). When all is fine, I will make some updaters with applescript that can turn an official RC app into a NB version - I think that's the best way to do the distribution on the Mac, as only the executable and the llcommon lib and a few helper files (the ..xml stuff for the voice version) need to be distributed and not all the special stuff like libllkdu or the icons or whatever. But for now I am just plain happy to enjoy a current viewer with less bugs and better useability than the official RC ;-P bye, Barney On 9/17/07, Trevor Powell wrote: > I have a working OS X build of Nicholaz's 18g build.. I've worked through > each of the issues below.. > > The problem with cursors_mac is just that the directory itself is missing; > all the files that should be in it are dumped into the root of the mac > resources directory, instead of into a 'cursors_mac' directory inside that > directory. That one was easy to fix, locally. > > The giant executables seem to be caused by linking in the Mozilla library. > Or at least, when I removed it from the linking process, it yielded no > linking errors and the final executable came down from >1gig to the 70ish > megs that you'd expect. > > > I haven't yet looked at the post-voice source releases on the Mac (except > to plunder some the pre-built png libraries that they forgot to include in > the pre-voice source releases).. I'd release my builds, except that they > suffer from a weird behaviour; textures seem to load far, far slower than > they do in the official Linden version. Slow enough that it's not at all > uncommon for me to hang around in a single area and still have blank grey > textures on many things twenty minutes later. It's as though it wasn't > retrying to grab the textures if a packet got lost, or something. Haven't > had a chance to delve more deeply into it yet, though. And in all > honesty, the solution may come by moving up to a post-voice source > release; LL seem to have fixed a bunch of problems in the Mac source > releases post-voice. > > > Trevor > > > Hey Nicholaz, > > > > yes, that's exactly what I did. llthread.cpp, changed to > > APR_THREAD_MUTEX_NESTED and all is golden. > > > > bye, Barney > > > > On 9/16/07, Nicholaz Beresford wrote: > >> > >> I just looked a bit deeper. I think the issue is to > >> replace all APR_THREAD_MUTEX_DEFAULT to > >> APR_THREAD_MUTEX_NESTED. > >> > >> Or of course undo my patch with the EasyCacheWriter. > >> > >> > >> Nick > >> > >> > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> > >> > >> Barney Boomslang wrote: > >> > Hey Mac-heads, > >> > > >> > please check the following jira bugs and vote if you think we > >> > Mac-heads should be able to do a full working build of the client, too > >> > ;) > >> > > >> > This one is critical: the cursors_mac directory is missing and > >> > viewer_manifest.py willingly ignores that, so we are missing several > >> > mouse cursors in the build (I wrote about that some time ago): > >> > > >> > http://jira.secondlife.com/browse/VWR-2482 > >> > > >> > The next one is about the giant executables the project file produces > >> > with Deployment or Universal builds: > >> > > >> > http://jira.secondlife.com/browse/VWR-2483 > >> > > >> > This one is the missing SecondLife icon for the application. This > >> > might be intentional of LL, but then there should be a word on it. > >> > > >> > http://jira.secondlife.com/browse/VWR-2484 > >> > > >> > Maybe an idea: put a readme in the source tree that actually states > >> > _why_ stuff is missing? And put comments into viewer_manifest.py about > >> > why parts of it are commented out, like the kakadu library - that one > >> > is a no-brainer, since we don't have redistribution rights for that. > >> > Oh, but you still deliver it (the library) with your libraries > >> > download ... > >> > > >> > bye, Barney > >> > _______________________________________________ > >> > Click here to unsubscribe or manage your list subscription: > >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > From tshephard at gmail.com Mon Sep 17 00:27:03 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Sep 17 00:27:05 2007 Subject: [sldev] [META] How LL can profit from open source Message-ID: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> 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. From mdepascale at dii.unisi.it Mon Sep 17 02:44:26 2007 From: mdepascale at dii.unisi.it (Maurizio de Pascale) Date: Mon Sep 17 02:44:29 2007 Subject: [sldev] adding support for a new input device to the SL viewer In-Reply-To: References: Message-ID: <46EE4C7A.5030409@dii.unisi.it> Hi Ettore, > I've been working on something like this on and off for a while (whenever I > have some free time) and currently I have a solution more or less working > for controlling the avatar, edit mode and flycam for Windows and OS X. Maybe > we can work together... > That would be a good idea. I'll be glad to study how you're approaching the problem and work together to have it done faster and better (hopefully ;) ) just let me know how you would like to proceed. > I think so - my approach was not to follow the mouse events flow because it > was just too crazy and platform specific. To get something moving (quick and > dirty style) I just added a scanDevice() call after scanJoystick, but that's > bad as well. The best approach I think depends on what kind of device you're > working on: if you're working with joysticks, 3D mice or other N degrees of > freedom devices I say LLViewerJoystick is a good class to expand. That's > what I'm doing right now. > > Hacking the event system with fake mouse events seem the way to Event Hell > IMO. This is what I did/am doing (I plan on posting some patches in a few > days): > > - As you know the viewer already uses DirectInput on windows for the flycam. > On OS X I'm using the HID manager, and I believe there is a library on Linux > to handle HID devices. > - I developed an open source library to have a cross-platform API to access > the device. The implementation is DI on Win and HID on OS X, any other > platforms can be added by just implementing a few functions. This makes > viewer code unaware of the underlying implementation. > - I am refactoring the joystick implementation to use the above library. > > Sorry if this is too vague - expect a patch soon. > > Ettore > I've looked into the LLViewerJoystick class. However at a first glance it looks like nothing more than another hack :( mostly forwarding messages to keyboard input handling. Looking forward to see your patch. thank you for your help, Maurizio de Pascale mdepascale@dii.unisi.it From tofu.linden at lindenlab.com Mon Sep 17 02:16:43 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Sep 17 02:55:30 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> Message-ID: <46EE45FB.4050906@lindenlab.com> Thanks again for looking into particle issues. I thought I should give an update: I've committed the VWR-2164 fix - the rest are more involved changes which will take longer to get through the review pipeline, but they'll get addressed before long. Thanks, -Tofu Dirk Moerenhout wrote: > I'm looking for people who want to go over my proposed particle > fixes/optimisations. There's a zip attached to VWR-418 on JIRA that > contains 4 patches. They are numbered and can be applied in that order > to 1.18.3.2. What it contains: > > dead code removal, most notably: > - removal of all isparticle() stuff as it doesn't do a thing > - removal of mextents and all the related calculations as the values > are overwritten whenever they are requested > > VWR-2164: > This fixes particle alpha transition. Specific bugs: > - particles can't currently fade in -> fixed > - particles don't fade out to the correct value if end value is not 0 -> fixed > > VWR-418: > This focuses on particle generation. This should fix most of the > issues where the particle system is overloaded. Note that the system > is adaptive. Depending on the amount of particles vs max particles a > reference variable is updated. This variable is in turn used to limit > particle generations. Some of the limits that'll be set: > - Particles that are too small to be useful are not generated at all > - Particles that are invisible when generated and require you to > travel towards them faster than a threshold are not generated > (threshold will depend on load) > - Particle sources that are very taxing get tougher restrictions (e.g. > a particle system which parameters would result in it having 2k > particles simultenously in transit will be aggressively cut down while > at the same time one generating only 20 is left alone). (limit will > depend on load) > There's also a bug fix for the fact that simulation may get to > generate particles twice. > > VWR-983: > This focuses on particle updates. This should fix the issues where > particles go out of sync and end up where they should not be according > to timing. This is done by keeping accurate timing for particles that > are invisible (and hence get updated only every 8 grames). And a bug > is fixed that caused particles not to be updated every time another > particle was moved to another group or deleted. > > Have fun :) > > I've other fixes and some performance stuff left but I think that the > above would be a nice start (it'll give quite a bit of visual impact > already). > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Mon Sep 17 03:13:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 17 03:13:55 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <46EE45FB.4050906@lindenlab.com> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> <46EE45FB.4050906@lindenlab.com> Message-ID: <46EE535C.4010709@blueflash.cc> Btw, the patch is running in my latest viewer (forgot to post that here with the release), so I think if there's anything critical, we'll find out pretty soon. Nick Tofu Linden wrote: > Thanks again for looking into particle issues. > I thought I should give an update: I've committed the VWR-2164 fix - > the rest are more involved changes which will take longer to get through > the review pipeline, but they'll get addressed before long. > Thanks, > -Tofu > > Dirk Moerenhout wrote: From nicholaz at blueflash.cc Mon Sep 17 03:34:57 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 17 03:35:03 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> Message-ID: <46EE5851.70805@blueflash.cc> Barney, maybe putting some of the infos on the wiki (or at least add a link to your page to the Mac build instructions) may be a good idea: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X%29 I'll be needing that (hopefully) pretty soon :-) Nick Barney Boomslang wrote: > Oh, I have working versions of both the non-voice and the voice NB > builds. And no, mozilla is not the culprit, it's the way the > executable is linked :) > > I have a rough writedown (mostly for myself, to remember for next > build) of what I did here: > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > > I have the nagging feeling I forgot one step, so it might need an > adaption later when I find out what that was. If you run along those > things and discover something missing, give me a shout. From bboomslang at googlemail.com Mon Sep 17 04:59:12 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Sep 17 04:59:15 2007 Subject: [sldev] Bugs in the Mac OS X Source tree In-Reply-To: <46EE5851.70805@blueflash.cc> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> <46EE5851.70805@blueflash.cc> Message-ID: <347b550f0709170459w5ead38c2u9c48643d04edb53e@mail.gmail.com> Hi Nicholaz, Well, I might do that in the future - for now it's more a (quick and dirty) checklist so I don't forget one of the steps when I have to do it again for the next versions. And of course I hope that some of the problems are taken care of by the lindens and won't be necessary with the next source releases ;) bye, Barney On 9/17/07, Nicholaz Beresford wrote: > > Barney, > > maybe putting some of the infos on the wiki (or at least add a link > to your page to the Mac build instructions) may be a good idea: > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X%29 > > > I'll be needing that (hopefully) pretty soon :-) > > > > Nick > > > Barney Boomslang wrote: > > Oh, I have working versions of both the non-voice and the voice NB > > builds. And no, mozilla is not the culprit, it's the way the > > executable is linked :) > > > > I have a rough writedown (mostly for myself, to remember for next > > build) of what I did here: > > > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > > > > I have the nagging feeling I forgot one step, so it might need an > > adaption later when I find out what that was. If you run along those > > things and discover something missing, give me a shout. > > From dale at daleglass.net Mon Sep 17 05:48:40 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 17 05:48:46 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> Message-ID: <20070917124839.GA3473@bruno.sbruno> On Mon, Sep 17, 2007 at 12:27:03AM -0700, Tim Shephard wrote: > Simply - buy out SLExchange. > > Get out of the hosting biz (a profound strategical error) and enter > into the marketplace biz. Great, and in the process alienate probably everybody who does business in SL now. People scream bloody murder every time LL does something that looks like it's benefitting some resident (like showing screenshots say) > 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. I think There does something of the sort? Just that is the reason I'm here and not There (horrible pun intended) I came to SL specifically with the aim of coding something, without even knowing what. It just had a cool feel to it: to have a 3D environment where to make things and have a huge potential userbase for them. There? Well, no way I'm going there for that. Only way I could have ended up developing in such an environment is if I first found it for another reason, decided to stay and then had an idea for something to code. And even then the requirement to clear it up with the company would be a major discouragement. > 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. That's terribly artificial. SL as it currently exists doesn't need such a thing, I'm perfectly capable of selling my stuff on my own. I could even sell plugins easily (if the license allowed it). Easy enough, make a script that contacts a server on payment and returns a newly generated download link. > 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. Right, because LL has shown so willing to moderate SL. No, from what I see, LL always had to be dragged kicking and screaming to intervene in how the world works. Now it's hard to contact a Linden at all, the world is supposed to be self-moderating. Which is something I like really, if only there were better tools to get rid of annoyances (I'm working on it), and LL made the sims stop crashing, it'd be great. Try to imagine yourself in LL's position. Would you want to be stuck between two people each arguing that it's the other one who copied their stuff? I wouldn't want to touch that with a 10 foot pole. > 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. Is this sarcasm or something? The GPL makes it practically impossible to sell software, excepting for support. Not that it forbids it of course, it just makes attempts to enforce payment futile. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070917/6afab767/attachment.pgp From soft at lindenlab.com Mon Sep 17 07:04:10 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Sep 17 07:04:12 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> Message-ID: <9e6e5c9e0709170704i3affaad5i5df7d47ceb0b50a5@mail.gmail.com> On 9/17/07, Tim Shephard wrote: > > 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. I can only speak for myself, not for all Lindens. But I'd never have applied for a job at the company you describe. I've gladly detached myself from other OSes and services where this kind of forced tie-in has been tried. From dzonatas at dzonux.net Mon Sep 17 07:25:02 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Sep 17 07:23:50 2007 Subject: [sldev] [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 In-Reply-To: <46EE535C.4010709@blueflash.cc> References: <7992d0d60709101408h5dcd1a58s58cd668bc736e1d@mail.gmail.com> <46EE45FB.4050906@lindenlab.com> <46EE535C.4010709@blueflash.cc> Message-ID: <46EE8E3E.4080802@dzonux.net> I haven't compared the changes of the latest patch, but in the current official version the particles have worked far better than since 1.14.x. Now if we can just get llTargetOmega() to work again so my spinning particles aren't broken anymore. http://jira.secondlife.com/browse/VWR-2498 Nicholaz Beresford wrote: > > Btw, the patch is running in my latest viewer (forgot to > post that here with the release), so I think if there's > anything critical, we'll find out pretty soon. > > > Nick > > > Tofu Linden wrote: >> Thanks again for looking into particle issues. >> I thought I should give an update: I've committed the VWR-2164 fix - >> the rest are more involved changes which will take longer to get through >> the review pipeline, but they'll get addressed before long. >> Thanks, >> -Tofu >> >> Dirk Moerenhout wrote: > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From secret.argent at gmail.com Mon Sep 17 07:35:47 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 17 07:35:59 2007 Subject: [sldev] [META] How LL can profit from open source (Tim Shephard) In-Reply-To: <20070917142353.C030441B1D6@stupor.lindenlab.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> Message-ID: <74C115EB-64C5-4161-8D64-EBA98DED5E5A@gmail.com> > 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. And spend all the profits on lawyers and DMCA takedown notices? From secret.argent at gmail.com Mon Sep 17 07:54:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 17 07:54:43 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <20070917142353.C030441B1D6@stupor.lindenlab.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> Message-ID: > Dirk Moerenhout wrote: >> VWR-418: >> This focuses on particle generation. This should fix most of the >> issues where the particle system is overloaded. Note that the system >> is adaptive. Depending on the amount of particles vs max particles a >> reference variable is updated. This variable is in turn used to limit >> particle generations. Some of the limits that'll be set: >> - Particles that are too small to be useful are not generated at all I didn't catch this before, or parsed it as "particles that are too small to be seen". Clouds of many small particles, particles that may individually be "too small to be useful", are common for things like smoke effects. You need to make sure that this case doesn't break them. I tried a number of variations of this kind of thing and it's hard to get right... I finally sent one to Nicolaz with a relatively simple algorithm that at least did no harm. >> VWR-983: >> This focuses on particle updates. This should fix the issues where >> particles go out of sync and end up where they should not be >> according >> to timing. This is done by keeping accurate timing for particles that >> are invisible (and hence get updated only every 8 grames). And a bug >> is fixed that caused particles not to be updated every time another >> particle was moved to another group or deleted. Does this fix the "flashing" bug where particles that have follow- source set are generated as if they didn't have follow-source set then *snap* to the source the first time they're updated? That one is really frustrating. This doesn't just effect particles that have mistakenly set burst radius and follow source together (that was where it was first discovered, and that case could (as Nicolaz suggested) be fixed by killing burst radius when follow source is set) unfortunately... it also makes particles from moving emitters seem to "shed" in a flickering cloud behind them. The underlying bug needs to be addressed. From secret.argent at gmail.com Mon Sep 17 07:54:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 17 07:55:09 2007 Subject: [sldev] [META] How LL can profit from open source (Tim Shephard) In-Reply-To: <20070917142353.C030441B1D6@stupor.lindenlab.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> Message-ID: > 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. And spend all the profits on lawyers and DMCA takedown notices? From kerdezixe at gmail.com Mon Sep 17 08:04:41 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Sep 17 08:04:45 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <9e6e5c9e0709170704i3affaad5i5df7d47ceb0b50a5@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <9e6e5c9e0709170704i3affaad5i5df7d47ceb0b50a5@mail.gmail.com> Message-ID: <8a1bfe660709170804i68092266o7e76f7c0852da04c@mail.gmail.com> Chapter 1 : > Enforce a license [...] Chapter 2 : Fail. -- kerunix Flan From blakar at gmail.com Mon Sep 17 08:31:36 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Sep 17 08:31:40 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: References: <20070917142353.C030441B1D6@stupor.lindenlab.com> Message-ID: <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> > I didn't catch this before, or parsed it as "particles that are too > small to be seen". More specifically it's "Particles that are so small they are not seen unless they are within 25cm of the camera position". I assume nobody is using those for smoke as it would require you to generate your smoke very close to the camera in order for it to be sized 1 pixel. As such for it to look even remotely like smoke you need a few thousand within 25cm of the camera which in turn would mean it's abusing the particle system. You could hence extend this limit beyond 25cm without harm but 25cm was enough to catch the bulk of the buggy scripts so that's why I opted for 25. Still I'm willing to look at any script one can come up with. > >> VWR-983: > >> This focuses on particle updates. This should fix the issues where > >> particles go out of sync and end up where they should not be > >> according > >> to timing. This is done by keeping accurate timing for particles that > >> are invisible (and hence get updated only every 8 grames). And a bug > >> is fixed that caused particles not to be updated every time another > >> particle was moved to another group or deleted. > > Does this fix the "flashing" bug where particles that have follow- > source set are generated as if they didn't have follow-source set > then *snap* to the source the first time they're updated? That one is > really frustrating. It might but I don't recall having a specific test object for this. Can you provide one? If it's not fixed I'll check what is causing it and fix it. Dirk aka Blakar Ogre From secret.argent at gmail.com Mon Sep 17 09:26:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 17 09:26:22 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> Message-ID: <187DCAD3-FF3D-440B-955F-5AF39B3C1490@gmail.com> On 17-Sep-2007, at 10:31, Dirk Moerenhout wrote: >> I didn't catch this before, or parsed it as "particles that are too >> small to be seen". > More specifically it's "Particles that are so small they are not seen > unless they are within 25cm of the camera position". Ah, so my original parse was correct. :) What I was doing was based on a minimum screen area per particle based on size and distance. Not an absolute size. I was tryingto make some existing distance-based culling work a bit better. This seems to be a completely different issue: I suspect that the particle systems you're culling are actually ones that were created by a common mistaken workaround for an update bug a while back that broke turning off particle systems with "llParticleSystem([])" in child prims. >> Does this fix the "flashing" bug where particles that have follow- >> source set are generated as if they didn't have follow-source set >> then *snap* to the source the first time they're updated? That one is >> really frustrating. > It might but I don't recall having a specific test object for this. > Can you provide one? If it's not fixed I'll check what is causing it > and fix it. I'll give you a copy of some particle wings that show the effect, in- world. They did NOT "shed feathers" during flying before the particle system optimizations that produced the flashing bug. From nicholaz at blueflash.cc Mon Sep 17 09:59:17 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 17 09:59:38 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> Message-ID: <46EEB265.30007@blueflash.cc> I had one effect today (didn't look into the code yet). A guy was standing in the sandbox on the Hippo sim, I was up there on my mountain. He was modifying an object and the pixies were flowing from his hand to the object. Zooming camera closer/further turned the pixies off before they were invisible by distance. Visually it was a whitish line a few pixels which then disappeard from one moment to the next, so culling may be a bit too agressive there. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dirk Moerenhout wrote: >> I didn't catch this before, or parsed it as "particles that are too >> small to be seen". > > More specifically it's "Particles that are so small they are not seen > unless they are within 25cm of the camera position". I assume nobody > is using those for smoke as it would require you to generate your > smoke very close to the camera in order for it to be sized 1 pixel. As > such for it to look even remotely like smoke you need a few thousand > within 25cm of the camera which in turn would mean it's abusing the > particle system. > > You could hence extend this limit beyond 25cm without harm but 25cm > was enough to catch the bulk of the buggy scripts so that's why I > opted for 25. > > Still I'm willing to look at any script one can come up with. > >>>> VWR-983: >>>> This focuses on particle updates. This should fix the issues where >>>> particles go out of sync and end up where they should not be >>>> according >>>> to timing. This is done by keeping accurate timing for particles that >>>> are invisible (and hence get updated only every 8 grames). And a bug >>>> is fixed that caused particles not to be updated every time another >>>> particle was moved to another group or deleted. >> Does this fix the "flashing" bug where particles that have follow- >> source set are generated as if they didn't have follow-source set >> then *snap* to the source the first time they're updated? That one is >> really frustrating. > > It might but I don't recall having a specific test object for this. > Can you provide one? If it's not fixed I'll check what is causing it > and fix it. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From blakar at gmail.com Mon Sep 17 10:10:48 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Sep 17 10:10:52 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <187DCAD3-FF3D-440B-955F-5AF39B3C1490@gmail.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> <187DCAD3-FF3D-440B-955F-5AF39B3C1490@gmail.com> Message-ID: <7992d0d60709171010tfba226cr2d7bbf82f7fbff63@mail.gmail.com> > I'll give you a copy of some particle wings that show the effect, in- > world. They did NOT "shed feathers" during flying before the particle > system optimizations that produced the flashing bug. Thanks for those! And for the really good news: this is indeed fixed by my VWR-983 patch. Dirk aka Blakar Ogre From blakar at gmail.com Mon Sep 17 10:18:23 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Sep 17 10:18:28 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <46EEB265.30007@blueflash.cc> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> <46EEB265.30007@blueflash.cc> Message-ID: <7992d0d60709171018g68a3d3a4v634811c9ed68d95c@mail.gmail.com> That's actually a different bug. I've it fixed locally but it's not in any production targeted patch yet. Note that this happens also in the LL versions. It's due to the culling in LLVOPartGroup::updateGeometry. Dirk aka Blakar Ogre On 9/17/07, Nicholaz Beresford wrote: > > I had one effect today (didn't look into the code yet). A guy was > standing in the sandbox on the Hippo sim, I was up there on my > mountain. He was modifying an object and the pixies were flowing > from his hand to the object. Zooming camera closer/further turned > the pixies off before they were invisible by distance. Visually > it was a whitish line a few pixels which then disappeard from one > moment to the next, so culling may be a bit too agressive there. > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Dirk Moerenhout wrote: > >> I didn't catch this before, or parsed it as "particles that are too > >> small to be seen". > > > > More specifically it's "Particles that are so small they are not seen > > unless they are within 25cm of the camera position". I assume nobody > > is using those for smoke as it would require you to generate your > > smoke very close to the camera in order for it to be sized 1 pixel. As > > such for it to look even remotely like smoke you need a few thousand > > within 25cm of the camera which in turn would mean it's abusing the > > particle system. > > > > You could hence extend this limit beyond 25cm without harm but 25cm > > was enough to catch the bulk of the buggy scripts so that's why I > > opted for 25. > > > > Still I'm willing to look at any script one can come up with. > > > >>>> VWR-983: > >>>> This focuses on particle updates. This should fix the issues where > >>>> particles go out of sync and end up where they should not be > >>>> according > >>>> to timing. This is done by keeping accurate timing for particles that > >>>> are invisible (and hence get updated only every 8 grames). And a bug > >>>> is fixed that caused particles not to be updated every time another > >>>> particle was moved to another group or deleted. > >> Does this fix the "flashing" bug where particles that have follow- > >> source set are generated as if they didn't have follow-source set > >> then *snap* to the source the first time they're updated? That one is > >> really frustrating. > > > > It might but I don't recall having a specific test object for this. > > Can you provide one? If it's not fixed I'll check what is causing it > > and fix it. > > > > Dirk aka Blakar Ogre > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Mon Sep 17 11:14:15 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 17 11:14:22 2007 Subject: [sldev] Re: [VWR] [PATCH] particles VWR-418 VWR-983 VWR-2164 (Tofu Linden) In-Reply-To: <7992d0d60709171010tfba226cr2d7bbf82f7fbff63@mail.gmail.com> References: <20070917142353.C030441B1D6@stupor.lindenlab.com> <7992d0d60709170831n30e74d21x83098d80f941d902@mail.gmail.com> <187DCAD3-FF3D-440B-955F-5AF39B3C1490@gmail.com> <7992d0d60709171010tfba226cr2d7bbf82f7fbff63@mail.gmail.com> Message-ID: <09B9C7B5-6607-47BD-8689-888C29B93759@gmail.com> On 17-Sep-2007, at 12:10, Dirk Moerenhout wrote: > Thanks for those! And for the really good news: this is indeed fixed > by my VWR-983 patch. Callooh, callay, oh frabjous day. One hopes LL will pick this up sooner than later. From bos at lindenlab.com Mon Sep 17 11:15:37 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Sep 17 11:15:40 2007 Subject: [sldev] Re: [VIEWER] 64 bit status and open source components In-Reply-To: <645E8FB2-BC96-443C-BB1E-4663815C470F@gmail.com> References: <20070914190010.B7DCB41B152@stupor.lindenlab.com> <645E8FB2-BC96-443C-BB1E-4663815C470F@gmail.com> Message-ID: <46EEC449.9080102@lindenlab.com> Argent Stonecutter wrote: > But Mesa is the CPU-side OpenGL implementation, right? Mesa is an open source OpenGL implementation that can run either entirely in software or, on some systems, use hardware acceleration. ATI and NVIDIA's proprietary OpenGL libraries are completely unrelated. References: <20070917171052.F2A0F41B202@stupor.lindenlab.com> Message-ID: <2D7342C0-E54C-4FD1-BC5F-EAF2B58E9524@gmail.com> I don't know how that message got posted twice. I only sent it once. I did have some difficulty getting to gmail when I was reading the list earlier, so possibly it got queued twice. From baba at libsecondlife.org Mon Sep 17 11:40:39 2007 From: baba at libsecondlife.org (Baba) Date: Mon Sep 17 11:41:12 2007 Subject: [sldev] Eventlet under windows? Message-ID: <46EECA27.1030606@libsecondlife.org> I've almost got Eventlet working on windows. I got greenlet compiled which required vs2003. The last issue is a dependency on fcntl in util.py fcntl seems to be unix only. Commenting it out gets the examples running but that's not the best of solutions. Any ideas? Baba From donovan at lindenlab.com Mon Sep 17 12:26:44 2007 From: donovan at lindenlab.com (Donovan Linden) Date: Mon Sep 17 12:27:00 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <46EECA27.1030606@libsecondlife.org> References: <46EECA27.1030606@libsecondlife.org> Message-ID: Now that I look at it closely, it appears the fcntl module is only used to set file descriptors non-blocking, which I think only happens in the case of unix pipes (not available on windows) and maybe stdin and stdout. Probably the right thing to do is at the top of the module: try: import fcntl HAS_FCNTL = True except ImportError: HAS_FCNTL = False And then at the bottom where it uses it, emit a warning (try the warnings module) if HAS_FCNTL is False. Then if anybody ever sees the warning, we can see what was being attempted and figure out how to implement it under windows. Thanks! :-) Donovan On Sep 17, 2007, at 11:40 AM, Baba wrote: > I've almost got Eventlet working on windows. I got greenlet > compiled which required vs2003. The last issue is a dependency on > fcntl in util.py > > fcntl seems to be unix only. Commenting it out gets the examples > running but that's not the best of solutions. Any ideas? > > Baba > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From rdw at lindenlab.com Mon Sep 17 12:30:03 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Sep 17 12:32:15 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <46EECA27.1030606@libsecondlife.org> References: <46EECA27.1030606@libsecondlife.org> Message-ID: <46EED5BB.8020809@lindenlab.com> Baba wrote: > I've almost got Eventlet working on windows. I got greenlet compiled > which required vs2003. The last issue is a dependency on fcntl in util.py Hey, thanks for giving it a try! Windows compatibility is totally one of Eventlet's major weaknesses. > fcntl seems to be unix only. Commenting it out gets the examples > running but that's not the best of solutions. Any ideas? I confess that I know very little about Windows, but a little googling turned up some discussions about this very topic, and the conclusion seemed to be to have conditional code that executes Windows-specific API calls. Thanks, Python, for making us platform-independent.....NOT. Seriously if you search for "fcntl windows" the first page of results is all Python-related, so this seems to be a common sticking point. I did find this little interesting snippet: The Unix fcntl() call has no direct equivalent under Winsock. Where necessary, similar functionality exists in Winsock's ioctlsocket() call. For example, the equivalent of using Unix's fcntl() to set a socket's O_NONBLOCK flag is setting the FIONBIO flag with Winsock's ioctlsocket(). Twisted seems to have solved the problem of making sockets nonblocking: http://itamarst.org/writings/win32sockets.html though this link doesn't go into the details. Maybe asyncore works on Windows and can be coopted for this purpose? -RYaN From tao.takashi at googlemail.com Mon Sep 17 13:15:42 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 17 13:15:44 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <46EED5BB.8020809@lindenlab.com> References: <46EECA27.1030606@libsecondlife.org> <46EED5BB.8020809@lindenlab.com> Message-ID: <23bbb49e0709171315q1db34809tf4f7dfe2fbba0f35@mail.gmail.com> 2007/9/17, Ryan Williams (Which) : > > Baba wrote: > > I've almost got Eventlet working on windows. I got greenlet compiled > > which required vs2003. The last issue is a dependency on fcntl in > util.py > > Hey, thanks for giving it a try! Windows compatibility is totally one > of Eventlet's major weaknesses. > > > fcntl seems to be unix only. Commenting it out gets the examples > > running but that's not the best of solutions. Any ideas? > > I confess that I know very little about Windows, but a little googling > turned up some discussions about this very topic, and the conclusion > seemed to be to have conditional code that executes Windows-specific API > calls. Thanks, Python, for making us platform-independent.....NOT. > Seriously if you search for "fcntl windows" the first page of results is > all Python-related, so this seems to be a common sticking point. > > I did find this little interesting snippet: > > The Unix fcntl() call has no direct equivalent under Winsock. Where > necessary, similar functionality exists in Winsock's ioctlsocket() call. > For example, the equivalent of using Unix's fcntl() to set a socket's > O_NONBLOCK flag is setting the FIONBIO flag with Winsock's ioctlsocket(). > > Twisted seems to have solved the problem of making sockets nonblocking: > http://itamarst.org/writings/win32sockets.html though this link > doesn't go into the details. Maybe asyncore works on Windows and can be coopted for this purpose? asyncore should run under Windows as it's used in Zope and this definitely runs under windows. And Itamar, who's page you link in that mail used to hang out on #zope on freenode.net and #twisted, so maybe it might also be useful to ask there (greetings from MrTopf :-) ). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070917/11632e3d/attachment.htm From tshephard at gmail.com Mon Sep 17 13:19:38 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Sep 17 13:19:39 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <9e6e5c9e0709170704i3affaad5i5df7d47ceb0b50a5@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <9e6e5c9e0709170704i3affaad5i5df7d47ceb0b50a5@mail.gmail.com> Message-ID: <3b19a500709171319u2881eebdkee30f62effe2efc0@mail.gmail.com> " can only speak for myself, not for all Lindens. But I'd never have > applied for a job at the company you describe. " Huh? LL has already stated they have a seperate license for commercial works. Hell, I've gotten emails from Linden employees telling me about it! What's the diff? No one is saying you can't give your GPL software away for free or whatever it is that you do with it. From monkowsk at watson.ibm.com Mon Sep 17 13:22:31 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Sep 17 13:22:35 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's Message-ID: <46EEE207.4080801@watson.ibm.com> I've read the transcript and looked at the slides of teh Architecture group, and I'd like to suggest an alternate partioning of the tasks. I'm not sure what the Hosts are in the diagrams, but my interpretation is that they are temporary instances, "virtual" virtual worlds. The information about an avatar is kept in the Stores, and when that avatar logs on, an instance of the avatar is created on an Avatar Host. The information about a region is kept in the Stores, and when someone visits it, an instance is created on a Region Host. It's not clear from the charts exactly what is in an Avatar Host, so let me suggest that first it should contain an instance of the avatar mesh. We don't want to live with just two meshes forever, and we don't want to have to store a universe of avatar meshes locally with the viewer. Second, it should contain instances of all of the avatar's attachments, including their positions relative to the avatar. And third, it should contain any objects temporarily rezzed by the avatar from his/her inventory. An avatar's inventory and all processing of the inventory would be handled by the Avatar Stores. A region host would contain instances of all objects owned by the region, but the ownership would be handled by the Region Stores. The diagrams don't consider multiple viewers attached to a Region Host, but let's consider how viewers get information about other avatars. In the current SL architecture, all the information about all of the avatars is on the sim (region host) and all connections are through the sim. When an avatar moves across regions, his information is handed off from sim to sim. And because of this, we are limited to about a hundred avatars per sim. So the new architecture has Avatar Hosts to keep track of the avatar information, and viewers get information from the Avatar Hosts. So if my avatar is in the Region and your avatar is in the Region, we both get information from the Region Host and we share information from our respective Avatar Hosts. And if we would like to be able to see across regions, we need to contact all of those other Avatar Hosts. That's a lot of very dispersed connections. Which brings me to my alternate partitioning of the tasks: The Avatar Hosts should be in the same domain as the Region Hosts. Getting information from the Avatar Stores to the Avatar Hosts doesn't have to be fast, but getting information from the Avatar Host to the Region Host should be fast. The Avatar Host would serve the appropriate LOD instances to the Region Hosts that need them. For highest LOD, they could communicate directly with the viewers. For lower LOD, the viewers could get the information through the Region Host. Region Hosts really only need to know enough about an avatar geometry to compute collisions. The rest of the physics could be done by the Avatar Hosts. The goal is to keep the amount of avatar information on the Region Host to a minimum so that we can dynamically repartition the virtual Region on servers as the load demands. A server could be running several Regions if they aren't doing much, or it could be running just a fraction of a Region if there are a lot of avatars doing a lot of things. Eliminate the population limit. "All the avatars that fits." For looking across regions, the avatars already have multiple LODs. For prims and object meshes (yes, we don't want to limit ourselves to prims) the Region Host could automatically generate low LOD meshes to represent the objects at a distance and pass them on to neighboring Regions. The viewer, also, could choose to use lower LODs for avatars and objects to improve performance. Kind of like progressive loading of images on the web. So if we allow thousands of avatars on a sim, how will they all be able to see the performer on stage? Well, since the Region Hosts are just instances, we can make multiple instances of the Region in the world that can only be entered by way of the instance that the performers are viewing at the time. For other instances, it would look like avatars appear and disappear at the region boundaries like a walking teleport. So you could have very large intimate gatherings and everybody gets a good seat. Right now we have huge central Stores, but we really know that objects belong either to an avatar or a region, so the Stores can be very small and very distributed with connectivity only to the relevant Avatar Hosts and Region Hosts. Transactions with the Stores would be through the Stores servers. There would be no "push" transactions to the Stores, they would all be "pull" transactions by those who are authenticated to the Stores servers. So the Stores could even be simple Apache web servers. The Stores could "push" to the Hosts or the Hosts could "pull" but nothing is permanent on the Hosts. So, in summary, if you din't get the clever biblical allusion of the title, the main idea is to keep all the information for rendering avatars on Avatar Hosts and for rendering Regions on Region Hosts, but keep both in the same domain. Mike From rdw at lindenlab.com Mon Sep 17 13:33:29 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Sep 17 13:35:33 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <23bbb49e0709171315q1db34809tf4f7dfe2fbba0f35@mail.gmail.com> References: <46EECA27.1030606@libsecondlife.org> <46EED5BB.8020809@lindenlab.com> <23bbb49e0709171315q1db34809tf4f7dfe2fbba0f35@mail.gmail.com> Message-ID: <46EEE499.8070502@lindenlab.com> > asyncore should run under Windows as it's used in Zope and this definitely > runs under windows. > And Itamar, who's page you link in that mail used to hang out on #zope on > freenode.net and #twisted, > so maybe it might also be useful to ask there (greetings from MrTopf :-) ). I think what Donovan said is the smartest thing to do. I was confusing sockets and file descriptors when I wrote my email. Apparently non-blocking sockets on Windows are a solved problem, but file descriptors are a different ball of wax. See this old-ass email on the topic, dunno if things have improved since then: http://mail.python.org/pipermail/python-list/2001-February/071201.html -RYaN From baba at libsecondlife.org Mon Sep 17 13:55:33 2007 From: baba at libsecondlife.org (Baba) Date: Mon Sep 17 13:56:05 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <46EECA27.1030606@libsecondlife.org> References: <46EECA27.1030606@libsecondlife.org> Message-ID: <46EEE9C5.5010700@libsecondlife.org> Some tests failing as well. I've been logging things on the SL wiki at: https://wiki.secondlife.com/wiki/User:Baba_Yamamoto/Eventlet Baba wrote: > I've almost got Eventlet working on windows. I got greenlet compiled > which required vs2003. The last issue is a dependency on fcntl in util.py > > fcntl seems to be unix only. Commenting it out gets the examples > running but that's not the best of solutions. Any ideas? > > Baba > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From donovan at lindenlab.com Mon Sep 17 15:18:23 2007 From: donovan at lindenlab.com (Donovan Linden) Date: Mon Sep 17 15:18:45 2007 Subject: [sldev] Eventlet under windows? In-Reply-To: <46EEE9C5.5010700@libsecondlife.org> References: <46EECA27.1030606@libsecondlife.org> <46EEE9C5.5010700@libsecondlife.org> Message-ID: <8DECB44F-D2C9-41C8-88EE-452630A6BB39@lindenlab.com> Thanks for the test output. test_004_close_keepalive is probably just a real race condition in the test... Not sure what can be done other than bump the timings so it's less likely to lose the race. test_005_run_apachebench probably shouldn't try to run on a system where it can't figure out how to run apachebench as a child process. The api tests are not actually failing, but just looks like noisy output. It would be nice to silence it, no idea what is causing it tho. Donovan On Sep 17, 2007, at 1:55 PM, Baba wrote: > Some tests failing as well. > I've been logging things on the SL wiki at: > https://wiki.secondlife.com/wiki/User:Baba_Yamamoto/Eventlet > > > Baba wrote: >> I've almost got Eventlet working on windows. I got greenlet >> compiled which required vs2003. The last issue is a dependency on >> fcntl in util.py >> >> fcntl seems to be unix only. Commenting it out gets the examples >> running but that's not the best of solutions. Any ideas? >> >> Baba >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From bbyer at mm.st Mon Sep 17 15:36:19 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Sep 17 15:36:06 2007 Subject: [sldev] [VWR] Bugs in the Mac OS X Source tree In-Reply-To: <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> Message-ID: <87457A8A-2280-4DD2-B115-CB09C3D3A161@mm.st> On Sep 16, 2007, at 11:25 PM, Barney Boomslang wrote: > Oh, I have working versions of both the non-voice and the voice NB > builds. And no, mozilla is not the culprit, it's the way the > executable is linked :) > > I have a rough writedown (mostly for myself, to remember for next > build) of what I did here: > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > open the macviewer.xcodeprj project file in XCode and edit the build options and set "only link essential symbols" in the linking options (otherwise you get giant executables) Errr... try strip(1)? -b From odysseus654 at gmail.com Mon Sep 17 16:30:45 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Mon Sep 17 16:30:51 2007 Subject: [sldev] [VWR] Bugs in the Mac OS X Source tree In-Reply-To: <87457A8A-2280-4DD2-B115-CB09C3D3A161@mm.st> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> <87457A8A-2280-4DD2-B115-CB09C3D3A161@mm.st> Message-ID: <1674f6c70709171630p1469c5c4u2b5f1cbe7b0db67@mail.gmail.com> If that's like the linux strip, doesn't that simply remove debug symbol information from the executable? The issue here seems to be that if there's only a single function (that doesn't reference any other functions) is included from an object or library, that all the code from that object or library is included. That's something that only the linker can really decide for sure, a post processor to strip out symbol information isn't going to understand that half the code in the executable will never be used. In VS.NET this option is known as /OPT:REF On 9/17/07, Ben Byer wrote: > > > On Sep 16, 2007, at 11:25 PM, Barney Boomslang wrote: > > > Oh, I have working versions of both the non-voice and the voice NB > > builds. And no, mozilla is not the culprit, it's the way the > > executable is linked :) > > > > I have a rough writedown (mostly for myself, to remember for next > > build) of what I did here: > > > > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > > > open the macviewer.xcodeprj project file in XCode and edit the > build options and set "only link essential symbols" in the linking > options (otherwise you get giant executables) > > Errr... try strip(1)? > -b > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070917/e54d01d7/attachment.htm From seg at haxxed.com Mon Sep 17 17:26:21 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 17 17:26:33 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46EEE207.4080801@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> Message-ID: <1190075181.23349.4.camel@localhost> On Mon, 2007-09-17 at 16:22 -0400, Mike Monkowski wrote: > It's not clear from the charts exactly what is in an Avatar Host, so let > me suggest that first it should contain an instance of the avatar mesh. > We don't want to live with just two meshes forever, and we don't want > to have to store a universe of avatar meshes locally with the viewer. Avatar meshes are an asset, thus belong in asset storage. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070917/e8d700fc/attachment.pgp From gigstaggart at gmail.com Mon Sep 17 14:54:07 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 17 17:48:33 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46EEE207.4080801@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> Message-ID: <46EEF77F.3040405@gmail.com> Mike Monkowski wrote: > I've read the transcript and looked at the slides of teh Architecture > group, and I'd like to suggest an alternate partioning of the tasks. > > I'm not sure what the Hosts are in the diagrams, but my interpretation > is that they are temporary instances, "virtual" virtual worlds. The > information about an avatar is kept in the Stores, and when that avatar > logs on, an instance of the avatar is created on an Avatar Host. The > information about a region is kept in the Stores, and when someone > visits it, an instance is created on a Region Host. > That's not necessary or even implied. It could be implemented that way, but it's likely irrelevant from the architectural standpoint, as long as the agent domain isn't making bad assumptions about a region being on a particular host. > It's not clear from the charts exactly what is in an Avatar Host, so let > me suggest that first it should contain an instance of the avatar mesh. > We don't want to live with just two meshes forever, and we don't want > to have to store a universe of avatar meshes locally with the viewer. > Second, it should contain instances of all of the avatar's attachments, > including their positions relative to the avatar. And third, it should > contain any objects temporarily rezzed by the avatar from his/her > inventory. We didn't discuss anything called an avatar host. I'll assume you mean a host inside of the agent domain. Again, these are implementation details it seems, probably irrelevant to arch. > > An avatar's inventory and all processing of the inventory would be > handled by the Avatar Stores. For the most part, assuming you mean "agent domain". The region would have to be handed inventory at some point (like when it was rezzed). > A region host would contain instances of all objects owned by the > region, but the ownership would be handled by the Region Stores. I'm not sure what you mean there. Regions don't own objects. > > The diagrams don't consider multiple viewers attached to a Region Host, > but let's consider how viewers get information about other avatars. In > the current SL architecture, all the information about all of the > avatars is on the sim (region host) and all connections are through the > sim. When an avatar moves across regions, his information is handed off > from sim to sim. And because of this, we are limited to about a hundred > avatars per sim. That's a non-sequitur. It's because of a lot of reasons, but the design you describe is really not one of them. > So the new architecture has Avatar Hosts to keep track of the avatar > information, and viewers get information from the Avatar Hosts. So if > my avatar is in the Region and your avatar is in the Region, we both get > information from the Region Host and we share information from our > respective Avatar Hosts. And if we would like to be able to see across > regions, we need to contact all of those other Avatar Hosts. That's a > lot of very dispersed connections. The viewers are also talking directly to region domain hosts. There's no reason the child agent paradigm we have now can't continue to work. I'm going to ignore the rest of your message, because I think your underlying assumptions and understandings were pretty flawed. Lets get those sorted out before we get too far ahead of things. -Jason From neuro at lindenlab.com Mon Sep 17 19:25:25 2007 From: neuro at lindenlab.com (William Anderson (neuro)) Date: Mon Sep 17 19:25:28 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> Message-ID: <46EF3715.6010600@lindenlab.com> First time posting to sldev, "hello everybody!" Tim Shephard wrote: > Simply - buy out SLExchange. > > Get out of the hosting biz (a profound strategical error) and enter > into the marketplace biz. Intersting, in what way is the hosting business a strategic error? > 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 Um, IP owners already sell their assets through "our" marketplace: that marketplace is called Second Life. What you're proposing sounds to me to be akin to Microsoft saying "hey, we're open sourcing IIS, but if you want to build websites to sell stuff using IIS, you have to go through us, and you can write and sell your own middleware to plug into IIS, but you have to give us a cut", i.e. a non starter. -- William Anderson - Operations, Linden Lab neuro@lindenlab.com From bboomslang at googlemail.com Mon Sep 17 23:21:31 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Sep 17 23:21:33 2007 Subject: [sldev] [VWR] Bugs in the Mac OS X Source tree In-Reply-To: <1674f6c70709171630p1469c5c4u2b5f1cbe7b0db67@mail.gmail.com> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> <87457A8A-2280-4DD2-B115-CB09C3D3A161@mm.st> <1674f6c70709171630p1469c5c4u2b5f1cbe7b0db67@mail.gmail.com> Message-ID: <347b550f0709172321g7cd6a596wa67a9d6e1cb7abb0@mail.gmail.com> Hey Erik, yep, something along that lines. Either a function or debugging stuff - I am not too sure about it being only code since it bloats the executable in a horrific way - I don't think anything has that much code ;) (and even if it is some data tables or things like that - we are talking about a tenfold size increase here!) But what definitely doesn't work is the often talked about strip - it is actually called in the project file by default. It's definitely this option that needs to be set to have decent executable sizes. bye, Barney On 9/18/07, Erik Anderson wrote: > If that's like the linux strip, doesn't that simply remove debug symbol > information from the executable? The issue here seems to be that if there's > only a single function (that doesn't reference any other functions) is > included from an object or library, that all the code from that object or > library is included. That's something that only the linker can really > decide for sure, a post processor to strip out symbol information isn't > going to understand that half the code in the executable will never be > used. In VS.NET this option is known as /OPT:REF > > > On 9/17/07, Ben Byer wrote: > > > > On Sep 16, 2007, at 11:25 PM, Barney Boomslang wrote: > > > > > Oh, I have working versions of both the non-voice and the voice NB > > > builds. And no, mozilla is not the culprit, it's the way the > > > executable is linked :) > > > > > > I have a rough writedown (mostly for myself, to remember for next > > > build) of what I did here: > > > > > > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > > > > > open the macviewer.xcodeprj project file in XCode and edit the > > build options and set "only link essential symbols" in the linking > > options (otherwise you get giant executables) > > > > Errr... try strip(1)? > > -b > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From robla at lindenlab.com Mon Sep 17 23:49:19 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Sep 17 23:49:26 2007 Subject: [sldev] Vivox SLVoice.exe documentation Message-ID: <46EF74EF.5070800@lindenlab.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070917/5407598c/signature-0001.pgp From jhurliman at wsu.edu Mon Sep 17 23:54:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Sep 17 23:54:49 2007 Subject: [sldev] Vivox SLVoice.exe documentation In-Reply-To: <46EF74EF.5070800@lindenlab.com> References: <46EF74EF.5070800@lindenlab.com> Message-ID: <46EF762A.5000706@wsu.edu> Rob Lanphier wrote: > Hi all, > > Attached is the documentation from Vivox for interacting with the > SLVoice.exe component of the Second Life viewer. This documentation > will be bundled with the library bundle of the viewer, but I'm including > this now for your convenience. > > Rob > > I haven't read anything past: "READ THE FOLLOWING CAREFULLY. BY USING ANY PORTION OF THIS SPECIFICATION, YOU AGREE TO BE BOUND BY THE FOLLOWING. IF YOU DO NOT AGREE TO BE SO BOUND, YOU MAY NOT USE THIS SPECIFICATION, OR ANY PORTION THEREOF, FOR ANY PURPOSE. This manual, including its content and any portion thereof (collectively, the ?Content?), is a work protected by copyright and is the sole and exclusive property of Vivox, Inc. (?Vivox?). Vivox licenses to you the right to use the Content solely in connection with your use of the Second Life viewer together with Vivox?s services. All other uses are prohibited and constitute an infringement of Vivox?s exclusive proprietary rights. Without limitation, you may not use any portion of the Content to clone any portion of the Vivox interface or to replicate Vivox code." But if anyone wants to document things on the wiki that would be very helpful. Thank you for getting this out to the community quickly Rob! John Hurliman From robla at lindenlab.com Tue Sep 18 00:00:51 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Sep 18 00:00:54 2007 Subject: [sldev] Topic for Thursday Open Source Meeting: Voice (guest: Joe Linden) Message-ID: <46EF77A3.8090306@lindenlab.com> Hi everyone, For this week's open source meeting (Thursday, 2pm), we have guest Joe Linden, who will be talking about voice in Second Life. Since this is about voice, we plan to use the voice feature, though we will also do our best to transcribe for those that want to attend but don't have voice available. Agenda is here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/d916a581/signature.pgp From tshephard at gmail.com Tue Sep 18 00:07:23 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Sep 18 00:07:25 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <46EF3715.6010600@lindenlab.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <46EF3715.6010600@lindenlab.com> Message-ID: <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> You're analogy is weak. It would be MS giving away Windows Vista for free with the caveat that any apps sold would be done via a Vista marketplace. Given the issues with adware/spyware/viruses in Windows - I don't think it would be a non starter at all. In fact, MS has already started in that direction with various security features that requires you to register your software with them in order not to flag security warnings on IE. As that gets more and more awkward to get around, more developers will be signing their software to avoid that error. Pretty soon you'll need MS permission to sell software for Vista, at that point they can lower the cost on Vista and get their money from developers. This model is already being used on SL. If you want to sell virtual goods, SL is the best platform to do it on. You have to rent land in order to do so. You *MUST* have an SL account in order to sell virtual goods, and you *MUST* comply with the SL TOS in order to sell virtual goods. .. in fact, you have to agree to a license saying that you give up all patent rights in order to sell virtual goods. This idea of a connector agreement is the non starter. People are going to start up their own grids and in fact, many people will have very little desire to connect to the SL grid because that means they'll have to comply with SL laws / policies. Who wants to do that? The only real revenue generator LL has is selling L$, but I'm not sure how long that'll hold out. On 9/17/07, William Anderson (neuro) wrote: > First time posting to sldev, "hello everybody!" > > Tim Shephard wrote: > > Simply - buy out SLExchange. > > > > Get out of the hosting biz (a profound strategical error) and enter > > into the marketplace biz. > > Intersting, in what way is the hosting business a strategic error? > > > 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 > > Um, IP owners already sell their assets through "our" marketplace: that > marketplace is called Second Life. What you're proposing sounds to me > to be akin to Microsoft saying "hey, we're open sourcing IIS, but if you > want to build websites to sell stuff using IIS, you have to go through > us, and you can write and sell your own middleware to plug into IIS, but > you have to give us a cut", i.e. a non starter. > > -- > William Anderson - Operations, Linden Lab > neuro@lindenlab.com > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From labrat.hb at gmail.com Tue Sep 18 00:47:38 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Sep 18 00:47:42 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <46EF3715.6010600@lindenlab.com> <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> Message-ID: On 9/18/07, Tim Shephard wrote: > > You're analogy is weak. > > The only real revenue generator LL has is selling L$, but I'm not sure > how long that'll hold out. Have you ever checked to see how much LL's makes from Tier payments? There are currently 9988 sims in SL, of those around 2900 are mainland sims, the other 7,088 are private islands. Considering that the Private Island Tier was raised to $295 at the end of 2006. At that time there were around 3000 private islands So that gives us 4,088 sims that are at the $295 a month tier. 2900 x $195 = $565,500.00 3000 x $195 = $585,000.00 4088 x $295 = $1,205,960.00 For a total of $2,356,460 in Tier Payments.... This is the MINIMUM amount as this presumes all sims are owned by one person. The smaller the parcel the higher the profit. A mainland Sim can bring as high as $640 a month in tier if the whole thing was 512 plots owned by different people. The average is probably somewhere around $300 a month for a mainland sim (which is right around the new price of private islands... how interesting) 2900 x $300 = $870,000.00 So between $2,356,460 and $2,660,960.00 ------- Now for selling Lindens they only make $599,586 US from selling lindens in July $65,503 dollars from people buying lindens ($0.30 per transaction) And roughly $254,000 US dollars from the 3.5% on all sales $919,089 total from the LindeX in July So LL's would need to make up roughly 1.8 Million dollars if they got out of the hosting business. And I seriously doubt they would come close to making that amount up by taking over SLX. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/6ab3d80c/attachment.htm From tao.takashi at googlemail.com Tue Sep 18 01:37:36 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 18 01:37:38 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46EEE207.4080801@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> Message-ID: <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> Hi! Good that somebody thinks about workitem 2 which is about alternative setups to the proposed architecture :-) I'm not sure what the Hosts are in the diagrams, but my interpretation > is that they are temporary instances, "virtual" virtual worlds. The > information about an avatar is kept in the Stores, and when that avatar > logs on, an instance of the avatar is created on an Avatar Host. The > information about a region is kept in the Stores, and when someone > visits it, an instance is created on a Region Host. As Gigs said, it's an Agent Host and according to Mark they are supposed to store an agent's session which is e.g. status of the agent, things about presence information and so on. It's not clear from the charts exactly what is in an Avatar Host, so let > me suggest that first it should contain an instance of the avatar mesh. I am not sure it will. I think the mesh and all the things an avatar is made up of will be transferred to the region for simulating it. Mark also said that the Region host will be basically the same what a simulator is right now. This would mean that the agent host probably does not have that much to do. It's mostly there to handle the login session of the user. In my understanding it might be responsible for changing profile, handling inventory transactions from and to regions and other agents etc. I think it is even open how these transactions to other agents may occur, whether it's through the region or directly from agent host to agent host or maybe via the viewer. An avatar's inventory and all processing of the inventory would be > handled by the Avatar Stores. Again, it's Agent Stores but from my understanding you are right, it stores e.g. profile information and assets for the avatar. A region host would contain instances of all objects owned by the > region, but the ownership would be handled by the Region Stores. I think this is right although maybe "owned" is the wrong word. It will contain the region's inventory, assets copied over from agent hosts e.g. when rezzing something in-world. The Owner of course is still the agent but I think you mean the right thing. > The diagrams don't consider multiple viewers attached to a Region Host, > but let's consider how viewers get information about other avatars. In > the current SL architecture, all the information about all of the > avatars is on the sim (region host) and all connections are through the > sim. When an avatar moves across regions, his information is handed off > from sim to sim. And because of this, we are limited to about a hundred > avatars per sim. > > So the new architecture has Avatar Hosts to keep track of the avatar > information, and viewers get information from the Avatar Hosts. So if > my avatar is in the Region and your avatar is in the Region, we both get > information from the Region Host and we share information from our > respective Avatar Hosts. And if we would like to be able to see across > regions, we need to contact all of those other Avatar Hosts. That's a > lot of very dispersed connections. I think it's mostly handled by the region host. The region host knows where each agent is and should also have the avatar information at hand. Whether the region host is actually 2 boxes, one for just the agent information and one for region stuff should not matter in the architecture. It even can be a cluster of 100 boxes. The only important thing here is the interface. I think one should think of all these more of black boxes. I also wonder if we shouldn't think about the whole domains more as black boxes. They just have different interfaces for either static information and dynamic information (services and hosts). Which brings me to my alternate partitioning of the tasks: The Avatar > Hosts should be in the same domain as the Region Hosts. As said, this will probably be one box or many depending on how you set this up. Actually you would have an additional host here, the avatar host, which is not the same as the agent host. But Linden Lab might correct us here what they think each component handles. Of course you are right that these things should be close together. > Right now we have huge central Stores, but we really know that objects > belong either to an avatar or a region, so the Stores can be very small > and very distributed with connectivity only to the relevant Avatar Hosts > and Region Hosts. Transactions with the Stores would be through the > Stores servers. There would be no "push" transactions to the Stores, > they would all be "pull" transactions by those who are authenticated to > the Stores servers. So the Stores could even be simple Apache web > servers. The Stores could "push" to the Hosts or the Hosts could "pull" > but nothing is permanent on the Hosts. Well, this is more implementation details but I think basically that's correct. The protocol will be REST mostly anyway. Whether it's push or pull needs to be seen, maybe the terms are also misleading, I guess it will get clearer once some sequence diagrams or transaction descriptions between region host and agent host are done. But there needs to be some means of course to transfer an asset from region to agent and the other way round (and from agent to agent). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/e25150d4/attachment-0001.htm From jhurliman at wsu.edu Tue Sep 18 01:58:20 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 18 01:58:32 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> References: <46EEE207.4080801@watson.ibm.com> <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> Message-ID: <46EF932C.7060503@wsu.edu> The diagrams and architecture discussion were very careful to use the word domain instead of host, since people can get confused and think the word host refers to a server. A domain could be running alongside several other domains on a single machine (even have multiple domains in a single process), or be spread across thousands of clusters around the world. The architecture only makes definitions of trust networks and protocols, so the implementation is left completely up to the providers. John Hurliman From nicholaz at blueflash.cc Tue Sep 18 02:28:34 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 18 02:28:57 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46E83F69.60409@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> <46E83168.2030708@lindenlab.com> <46E83F69.60409@blueflash.cc> Message-ID: <46EF9A42.5030106@blueflash.cc> Beta seems to be down every time I tried since last Friday. Any idea when it will come back? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From gigstaggart at gmail.com Tue Sep 18 02:29:04 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 18 02:29:10 2007 Subject: [sldev] [PATCH] Terraform with DYNAMIC TENSION to turn YOU into a BEAST OF A MAN Message-ID: <46EF9A60.3080707@gmail.com> I've finished the variable strength terraform patch. http://jira.secondlife.com/browse/VWR-2331 See attached screenshot too. I have to say, playing with it is very very cool. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: terraform-gui.png Type: image/png Size: 128212 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/1cebe910/terraform-gui-0001.png From gigstaggart at gmail.com Tue Sep 18 02:38:26 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 18 02:38:28 2007 Subject: [sldev] Vivox SLVoice.exe documentation In-Reply-To: <46EF762A.5000706@wsu.edu> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> Message-ID: <46EF9C92.3060506@gmail.com> John Hurliman wrote: > rights. Without limitation, you may not use any portion of the Content > to clone any portion of the Vivox > interface or to replicate Vivox code." It's pretty crappy that this was even released. Now Vivox can sue us if we replace the Vivox components, even if we never looked at that spec.:( We'd have been better off with no spec, I think. -Jason From nicholaz at blueflash.cc Tue Sep 18 02:49:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 18 02:49:37 2007 Subject: [sldev] [PATCH] Terraform with DYNAMIC TENSION to turn YOU into a BEAST OF A MAN In-Reply-To: <46EF9A60.3080707@gmail.com> References: <46EF9A60.3080707@gmail.com> Message-ID: <46EF9F1C.8090405@blueflash.cc> Btw, since you're at that area already .... what I'd find very helpful would be a way to switch between the functions (lower, raise, etc.) with keyboard. Being able to select the function with one hand while moving the mouse with the other would seem to ease up things a lot. (If there is already a way to do that, I didn't find it). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Jason Giglio wrote: > I've finished the variable strength terraform patch. > > http://jira.secondlife.com/browse/VWR-2331 > > See attached screenshot too. > > I have to say, playing with it is very very cool. > > -Jason > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Tue Sep 18 02:49:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 18 02:50:20 2007 Subject: [sldev] [PATCH] Terraform with DYNAMIC TENSION to turn YOU into a BEAST OF A MAN In-Reply-To: <46EF9A60.3080707@gmail.com> References: <46EF9A60.3080707@gmail.com> Message-ID: <46EF9F47.1010300@blueflash.cc> Hehe, or for that matter, now change the force with keyboard. Like F1 - F6 for the functions and 1-9 for the force. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Jason Giglio wrote: > I've finished the variable strength terraform patch. > > http://jira.secondlife.com/browse/VWR-2331 > > See attached screenshot too. > > I have to say, playing with it is very very cool. > > -Jason > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From bbyer at mm.st Tue Sep 18 03:28:53 2007 From: bbyer at mm.st (Ben Byer) Date: Tue Sep 18 03:30:01 2007 Subject: [sldev] [VWR] Bugs in the Mac OS X Source tree In-Reply-To: <1674f6c70709171630p1469c5c4u2b5f1cbe7b0db67@mail.gmail.com> References: <347b550f0709160309g679fed02x8859247c92f5ff74@mail.gmail.com> <46ED51AF.7070509@blueflash.cc> <347b550f0709161317j3e1aca1dl883668781f0f316e@mail.gmail.com> <42107.210.5.38.1.1189997341.squirrel@www.gridbug.org> <347b550f0709162325q2ddedaabide2d77574fc8e9a5@mail.gmail.com> <87457A8A-2280-4DD2-B115-CB09C3D3A161@mm.st> <1674f6c70709171630p1469c5c4u2b5f1cbe7b0db67@mail.gmail.com> Message-ID: My Bad. This is "dead code stripping". From OS X's ld(1): -dead_strip Remove functions and data that are unreachable by the entry point or exported symbols. (... I think...) On Sep 17, 2007, at 4:30 PM, Erik Anderson wrote: > If that's like the linux strip, doesn't that simply remove debug > symbol information from the executable? The issue here seems to be > that if there's only a single function (that doesn't reference any > other functions) is included from an object or library, that all the > code from that object or library is included. That's something that > only the linker can really decide for sure, a post processor to > strip out symbol information isn't going to understand that half the > code in the executable will never be used. In VS.NET this option is > known as /OPT:REF > > On 9/17/07, Ben Byer wrote: > > On Sep 16, 2007, at 11:25 PM, Barney Boomslang wrote: > > > Oh, I have working versions of both the non-voice and the voice NB > > builds. And no, mozilla is not the culprit, it's the way the > > executable is linked :) > > > > I have a rough writedown (mostly for myself, to remember for next > > build) of what I did here: > > > > http://radio-boomslang.shacknet.nu/~bb/archives/2007/09/16/index.html#e2007-09-16T19_05_06.txt > > > open the macviewer.xcodeprj project file in XCode and edit the > build options and set "only link essential symbols" in the linking > options (otherwise you get giant executables) > > Errr... try strip(1)? > -b > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/fc06f658/attachment.htm From dale at daleglass.net Tue Sep 18 03:30:20 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 03:30:26 2007 Subject: [sldev] Vivox SLVoice.exe documentation In-Reply-To: <46EF74EF.5070800@lindenlab.com> References: <46EF74EF.5070800@lindenlab.com> Message-ID: <20070918103020.GA5649@bruno.sbruno> On Mon, Sep 17, 2007 at 11:49:19PM -0700, Rob Lanphier wrote: > Hi all, > > Attached is the documentation from Vivox for interacting with the > SLVoice.exe component of the Second Life viewer. This documentation > will be bundled with the library bundle of the viewer, but I'm including > this now for your convenience. > > Rob Rob, documentation is a good thing to have, but under those terms (judging by John's post), I'm not going to touch that with a 10 foot pole. Please DO NOT include that in any package, I don't want to see that even by accident. I think you shouldn't have attached that at all, in fact. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/7661900c/attachment.pgp From kamilion at gmail.com Tue Sep 18 03:38:56 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Sep 18 03:39:00 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <46EF3715.6010600@lindenlab.com> <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> Message-ID: On 9/18/07, Tim Shephard wrote: > You have to rent land in order to do so. You *MUST* have an SL > account in order to sell virtual goods Not true, I'm still a free account with no land, and I sell most of my products through SLExchange, also free. I've got the server in one of the free SLExchange box places. All I have is an SL account. Alternatively, I could rent a parcel from another person for a couple L$. Most of the development I do in SL is script based, so I use LSLEditor [1] out-world to build 98% of what I need for a project. Don't even need a sandbox for most of the work. :) Currently, my only cost for all my SL development is paying $15 a month for a linux VPS to run apache with PHP and Ruby on Rails for llHTTPRequest to interact with. Sooo, at the moment, LL gets a big fat $0 a month from me. And I get quite a nice chunk of money back from it. :D [1]: http://www.lsleditor.org/ From dale at daleglass.net Tue Sep 18 03:44:51 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 03:44:56 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <46EF3715.6010600@lindenlab.com> <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> Message-ID: <20070918104451.GB5649@bruno.sbruno> On Tue, Sep 18, 2007 at 03:38:56AM -0700, Kamilion wrote: > Sooo, at the moment, LL gets a big fat $0 a month from me. And I get > quite a nice chunk of money back from it. :D That doesn't mean that they don't earn anything due to your activity though. They get money every time somebody buys L$ to pay you, as well as every time you exchange the L$ for cash if you do that. If you don't sell your L$ you probably use some of it to buy from somebody else, which in many cases will ultimately pay tier, get converted to USD, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/b078f369/attachment.pgp From jhurliman at wsu.edu Tue Sep 18 03:59:02 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 18 03:59:04 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EF9C92.3060506@gmail.com> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> Message-ID: <46EFAF76.3020203@wsu.edu> Jason Giglio wrote: > John Hurliman wrote: >> rights. Without limitation, you may not use any portion of the >> Content to clone any portion of the Vivox >> interface or to replicate Vivox code." > > It's pretty crappy that this was even released. Now Vivox can sue us > if we replace the Vivox components, even if we never looked at that > spec.:( > > We'd have been better off with no spec, I think. > > -Jason Speak for yourself, I never entered in to any agreement with Vivox that supersede my rights granted under the 1201(f) exemption of the DMCA. However, it might create problems documenting how the voice protocol works on the wiki if the redistribution language is too strict. On a side note I don't think there is a serious legal problem here. If a company found it more beneficial to sue developers rather then porting their own code it would speak volumes about their competency as software and service provider. John Hurliman From kamilion at gmail.com Tue Sep 18 04:00:20 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Sep 18 04:00:29 2007 Subject: [sldev] [META] How LL can profit from open source In-Reply-To: <20070918104451.GB5649@bruno.sbruno> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <46EF3715.6010600@lindenlab.com> <3b19a500709180007k5325d6ccw76f590f2c5606160@mail.gmail.com> <20070918104451.GB5649@bruno.sbruno> Message-ID: On 9/18/07, Dale Glass wrote: > On Tue, Sep 18, 2007 at 03:38:56AM -0700, Kamilion wrote: > > Sooo, at the moment, LL gets a big fat $0 a month from me. And I get > > quite a nice chunk of money back from it. :D > > That doesn't mean that they don't earn anything due to your activity > though. They get money every time somebody buys L$ to pay you, as well > as every time you exchange the L$ for cash if you do that. Other people buying L$ to pay me doesn't matter, because it's not 'from me' as I described. Plus SLExchange also allows people to pay with USD directly. > If you don't sell your L$ you probably use some of it to buy from > somebody else, which in many cases will ultimately pay tier, get > converted to USD, etc. Actually, I pull all of it out via paypal directly through SLExchange. AFAIK no SL transfers happen from this process, it's all completely within SLExchange's database. I don't make any purchases in SL other than the L$10 upload charge for assets. Everything rendered on my avatar or attached to it other than my free Mystitool radar, I uploaded myself. I havn't changed clothes in over a year now. (In SL, not in RL ;) So, for 3 years of nearly constantly being on SL, LL has managed to obtain, from me, a value not exceeding L$3000 for all the asset uploads. Ergo, over 3 years, a $10 outlay from me, has returned with enough income that I'm required by US law to file taxes on, a new laptop, a virtual private linux server running gentoo for over a year, and provided me with uncounted hours of communication with other people to the point where my long-standing IRC addiction is gone. (I've been an IRC user since 1993, with close to 24/7 connection. Now my IRC friends are lucky if they see me for over 5 minutes in 365 days ;) Kind of hard to be mad at a service that's saved me from poverty, even if it IS a little buggy. Long live LL, Free Seg! From dale at daleglass.net Tue Sep 18 04:06:51 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 04:06:56 2007 Subject: [sldev] Vivox SLVoice.exe documentation In-Reply-To: <20070918103020.GA5649@bruno.sbruno> References: <46EF74EF.5070800@lindenlab.com> <20070918103020.GA5649@bruno.sbruno> Message-ID: <20070918110651.GC5649@bruno.sbruno> On Tue, Sep 18, 2007 at 12:30:20PM +0200, Dale Glass wrote: > On Mon, Sep 17, 2007 at 11:49:19PM -0700, Rob Lanphier wrote: > > Hi all, > > > > Attached is the documentation from Vivox for interacting with the > > SLVoice.exe component of the Second Life viewer. This documentation > > will be bundled with the library bundle of the viewer, but I'm including > > this now for your convenience. > > > > Rob > > Rob, documentation is a good thing to have, but under those terms > (judging by John's post), I'm not going to touch that with a 10 foot > pole. > > Please DO NOT include that in any package, I don't want to see that even > by accident. I think you shouldn't have attached that at all, in fact. > In case anybody is interested: $ grep -l -E "^Attached is the documentation from Vivox" * 1190098235.30882_0.spaceymail-mx3:2,S $ grep -l -E "^Attached is the documentation from Vivox" * | xargs shred -fuz > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/b741eafc/attachment.pgp From dale at daleglass.net Tue Sep 18 04:17:59 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 04:18:04 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EFAF76.3020203@wsu.edu> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> Message-ID: <20070918111759.GD5649@bruno.sbruno> On Tue, Sep 18, 2007 at 03:59:02AM -0700, John Hurliman wrote: > Speak for yourself, I never entered in to any agreement with Vivox that > supersede my rights granted under the 1201(f) exemption of the DMCA. > However, it might create problems documenting how the voice protocol > works on the wiki if the redistribution language is too strict. I speak for myself, and I say that I am not going to use, or even touch any documentation under terms like that, even if they might not have an effect. If they don't, then they shouldn't be there in the first place. > > On a side note I don't think there is a serious legal problem here. If a > company found it more beneficial to sue developers rather then porting > their own code it would speak volumes about their competency as software > and service provider. That would still suck for the developer though. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/1ace41a8/attachment.pgp From jhurliman at wsu.edu Tue Sep 18 04:50:51 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 18 04:50:56 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <20070918111759.GD5649@bruno.sbruno> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> Message-ID: <46EFBB9B.6020302@wsu.edu> Dale Glass wrote: > On Tue, Sep 18, 2007 at 03:59:02AM -0700, John Hurliman wrote: > >> Speak for yourself, I never entered in to any agreement with Vivox that >> supersede my rights granted under the 1201(f) exemption of the DMCA. >> However, it might create problems documenting how the voice protocol >> works on the wiki if the redistribution language is too strict. >> > I speak for myself, and I say that I am not going to use, or even touch > any documentation under terms like that, even if they might not have an > effect. If they don't, then they shouldn't be there in the first place. > I might not have been clear enough. When I said I never entered in to any agreement with Vivox I was reiterating from my first e-mail that said "I haven't read anything past ...". I can't make use of that documentation myself since I'm supposed to be working on things like porting the voice daemon, but maybe someone could. John From dale at daleglass.net Tue Sep 18 05:33:23 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 05:33:28 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EFBB9B.6020302@wsu.edu> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> Message-ID: <20070918123220.GA12511@bruno.sbruno> On Tue, Sep 18, 2007 at 04:50:51AM -0700, John Hurliman wrote: > I might not have been clear enough. When I said I never entered in to > any agreement with Vivox I was reiterating from my first e-mail that > said "I haven't read anything past ...". I can't make use of that > documentation myself since I'm supposed to be working on things like > porting the voice daemon, but maybe someone could. Oh, sorry about that, misunderstood. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/9f162d52/attachment.pgp From secret.argent at gmail.com Tue Sep 18 08:10:31 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 08:10:42 2007 Subject: [sldev] Topic for Thursday Open Source Meeting: Voice In-Reply-To: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> Message-ID: <69AB0A3F-E810-4E7C-AB76-800E3FBFC133@gmail.com> > For this week's open source meeting (Thursday, 2pm), we have guest Joe > Linden, who will be talking about voice in Second Life. Since this is > about voice, we plan to use the voice feature, though we will also do > our best to transcribe for those that want to attend but don't have > voice available. I assume that this transcription will also be posted? From secret.argent at gmail.com Tue Sep 18 08:13:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 08:14:04 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> Message-ID: From: "Tao Takashi" > I am not sure it will. I think the mesh and all the things an > avatar is made up of will be transferred to the region for > simulating it. The region doesn't simulate an avatar. All it does is deliver the textures and appearance parameters to the client. The avatar mesh is in the client. From secret.argent at gmail.com Tue Sep 18 08:17:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 08:17:31 2007 Subject: [sldev] Re: Vivox SLVoice.exe documentation In-Reply-To: <20070918110030.469F641B1DB@stupor.lindenlab.com> References: <20070918110030.469F641B1DB@stupor.lindenlab.com> Message-ID: <81BC05F1-8E8E-452C-9C74-328D2118F4AA@gmail.com> From: Dale Glass > Rob, documentation is a good thing to have, but under those terms > (judging by John's post), I'm not going to touch that with a 10 foot > pole. > > Please DO NOT include that in any package, I don't want to see that > even > by accident. I think you shouldn't have attached that at all, in fact. I'm sure glad that it got left out of the digest then. :) From monkowsk at watson.ibm.com Tue Sep 18 08:26:33 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 08:26:54 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EFBB9B.6020302@wsu.edu> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> Message-ID: <46EFEE29.3000709@watson.ibm.com> John Hurliman wrote: > I can't make use of that > documentation myself since I'm supposed to be working on things like > porting the voice daemon, but maybe someone could. I've already put a lot of documentation out on the Wiki about Voice, and my interests are not in cloning it, so I don't think there's any problem for me to look at the SDK documentation and add to the Wiki. If doing so would compromise anyone else's position, let me know. Mike From tao.takashi at googlemail.com Tue Sep 18 08:28:20 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 18 08:28:23 2007 Subject: [sldev] [ARCH] Metaverse 1.0? Message-ID: <23bbb49e0709180828q6708ecbai711f9c33f434270a@mail.gmail.com> Hi! I just got a link from Dobre: http://www.lostinthemagicforest.com/blog/?p=43 So how does Metaverse 1.0 fit into that, does anybody know more about it, what is different, what is similar? Seems it has a far broader scope but I can imagine it also has a far longer timeframe. Unfortunately I cannot find more about this project online and he does not give a direct link. Does anybody know more? -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/a6add865/attachment.htm From dale at daleglass.net Tue Sep 18 09:12:07 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 09:12:21 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EFEE29.3000709@watson.ibm.com> References: <46EF74EF.5070800@lindenlab.com> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> Message-ID: <200709181812.14993.dale@daleglass.net> On Tuesday 18 September 2007 17:26:33 Mike Monkowski wrote: > John Hurliman wrote: > > I can't make use of that > > documentation myself since I'm supposed to be working on things like > > porting the voice daemon, but maybe someone could. > > I've already put a lot of documentation out on the Wiki about Voice, and > my interests are not in cloning it, so I don't think there's any > problem for me to look at the SDK documentation and add to the Wiki. > If doing so would compromise anyone else's position, let me know. I think you should mail legal@lindenlab.com (IIRC) and ask, just in case. If you agree to be bound by those conditions that's fine, but that shouldn't affect those of us that don't want to have anything to do with it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/34b88f15/attachment-0001.pgp From liana at lindenlab.com Tue Sep 18 09:17:47 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Tue Sep 18 09:17:45 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <200709181812.14993.dale@daleglass.net> References: <46EF74EF.5070800@lindenlab.com> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> <200709181812.14993.dale@daleglass.net> Message-ID: <46EFFA2B.5090607@lindenlab.com> The email address to use for licensing questions is licensing@lindenlab.com. :-) Dale Glass wrote: > On Tuesday 18 September 2007 17:26:33 Mike Monkowski wrote: > >> John Hurliman wrote: >> >>> I can't make use of that >>> documentation myself since I'm supposed to be working on things like >>> porting the voice daemon, but maybe someone could. >>> >> I've already put a lot of documentation out on the Wiki about Voice, and >> my interests are not in cloning it, so I don't think there's any >> problem for me to look at the SDK documentation and add to the Wiki. >> If doing so would compromise anyone else's position, let me know. >> > > I think you should mail legal@lindenlab.com (IIRC) and ask, just in case. > If you agree to be bound by those conditions that's fine, but that > shouldn't affect those of us that don't want to have anything to do with > it. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/7fece840/attachment.htm From lenglish5 at cox.net Tue Sep 18 09:18:21 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 09:18:22 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? Message-ID: <46EFFA4D.8030908@cox.net> http://www.gnucitizen.org/blog/ie-pwns-secondlife The comments appear to say that this is a firefox problem as well. Does this work on other browsers in other OS's? This is a "show stopper" if the article is correct. From odysseus654 at gmail.com Tue Sep 18 09:42:41 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Tue Sep 18 09:42:44 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <46EFFA4D.8030908@cox.net> References: <46EFFA4D.8030908@cox.net> Message-ID: <1674f6c70709180942vc0e2a10i3f2491024da8898d@mail.gmail.com> Looks like someone was a bit careless in the url method parser... On 9/18/07, Lawson English wrote: > > http://www.gnucitizen.org/blog/ie-pwns-secondlife > > The comments appear to say that this is a firefox problem as well. Does > this work on other browsers in other OS's? > > This is a "show stopper" if the article is correct. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/c6b670b3/attachment.htm From dale at daleglass.net Tue Sep 18 09:56:25 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 18 09:56:36 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <46EFFA4D.8030908@cox.net> References: <46EFFA4D.8030908@cox.net> Message-ID: <200709181856.29984.dale@daleglass.net> On Tuesday 18 September 2007 18:18:21 Lawson English wrote: > http://www.gnucitizen.org/blog/ie-pwns-secondlife > > The comments appear to say that this is a firefox problem as well. Does > this work on other browsers in other OS's? > > This is a "show stopper" if the article is correct. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SL should use CRAM-MD5 for login. Then the hashed password couldn't be reused. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/e97dce25/attachment.pgp From lenglish5 at cox.net Tue Sep 18 09:58:47 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 09:58:50 2007 Subject: [sldev] [VIEWER] Bug/inefficiency in mouse-handling in LLScrollLIstCtrl and other GUI classes? Message-ID: <46F003C7.908@cox.net> I've been trying to implement my baby hierarchy/outline list class and I found that "handleClick" to scroll list cells didn't pass the x,y,mask values to the cell. This is required in order to do things like drop-down folder arrow-icons, or edit-text-in-place cells, so I added the parameters in in the relevant places and dumped the x/y values to the debug console. The result suggests that handleClick is called over and over again on a single click, even though only one x/y value is passed down the line. This is inefficient, and probably reduces framerate, and possibly has other side-effects as well. The shortest click I could manage called handleClick 9 times. 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: handleClick: Text clicked and x is: 10 y is: 1 2007-09-18T16:45:37Z INFO: onCommitSelect: item is: test1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: handleClick: Text clicked and x is: 21 y is: 1 2007-09-18T16:45:51Z INFO: onCommitSelect: item is: test2 From odysseus654 at gmail.com Tue Sep 18 10:03:33 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Tue Sep 18 10:03:38 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <200709181856.29984.dale@daleglass.net> References: <46EFFA4D.8030908@cox.net> <200709181856.29984.dale@daleglass.net> Message-ID: <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> You know, if this is an actual exploit then this list may not be the appropriate place to continue discussions, I'm sorry that I contributed at this point. On 9/18/07, Dale Glass wrote: > > On Tuesday 18 September 2007 18:18:21 Lawson English wrote: > > This is a "show stopper" if the article is correct. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > SL should use CRAM-MD5 for login. Then the hashed password couldn't be > reused. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/b9993a36/attachment.htm From lenglish5 at cox.net Tue Sep 18 10:07:57 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 10:07:58 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> References: <46EFFA4D.8030908@cox.net> <200709181856.29984.dale@daleglass.net> <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> Message-ID: <46F005ED.7010803@cox.net> Erik Anderson wrote: > You know, if this is an actual exploit then this list may not be the > appropriate place to continue discussions, I'm sorry that I > contributed at this point. > The whole point of open source , vis a vis exploints is to get these things out in the open AND FIXED asap. Or such ha always been the claim of the open source community (or so I thought). Certainly, since it appeared on a public webpage, there's no hiding the vulnerability. > On 9/18/07, * Dale Glass* > wrote: > > On Tuesday 18 September 2007 18:18:21 Lawson English wrote: > > This is a "show stopper" if the article is correct. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > SL should use CRAM-MD5 for login. Then the hashed password > couldn't be > reused. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > From nicholaz at blueflash.cc Tue Sep 18 10:08:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 18 10:09:14 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> References: <46EFFA4D.8030908@cox.net> <200709181856.29984.dale@daleglass.net> <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> Message-ID: <46F00621.4060802@blueflash.cc> Erik Anderson wrote: > You know, if this is an actual exploit then this list may not be the > appropriate place to continue discussions, I'm sorry that I contributed > at this point. It's on the blogs already anyway. Saw it yesterday on SL Insider. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From lenglish5 at cox.net Tue Sep 18 10:14:34 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 10:14:36 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <46F00621.4060802@blueflash.cc> References: <46EFFA4D.8030908@cox.net> <200709181856.29984.dale@daleglass.net> <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> <46F00621.4060802@blueflash.cc> Message-ID: <46F0077A.5040901@cox.net> Nicholaz Beresford wrote: > > > Erik Anderson wrote: >> You know, if this is an actual exploit then this list may not be the >> appropriate place to continue discussions, I'm sorry that I >> contributed at this point. > > It's on the blogs already anyway. Saw it yesterday on SL Insider. > > I certainly didn't hear about it on a hacker's site. From monkowsk at watson.ibm.com Tue Sep 18 10:14:38 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 10:14:47 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> Message-ID: <46F0077E.60008@watson.ibm.com> Argent Stonecutter wrote: > From: "Tao Takashi" > >> I am not sure it will. I think the mesh and all the things an avatar >> is made up of will be transferred to the region for simulating it. > > > The region doesn't simulate an avatar. All it does is deliver the > textures and appearance parameters to the client. The avatar mesh is in > the client. It is now, but do you want to keep it that way? Mike From monkowsk at watson.ibm.com Tue Sep 18 10:21:29 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 10:21:41 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> References: <46EEE207.4080801@watson.ibm.com> <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> Message-ID: <46F00919.40704@watson.ibm.com> Tao Takashi wrote: > As Gigs said, it's an Agent Host and according to Mark they are supposed > to store an > agent's session which is e.g. status of the agent, things about presence > information and > so on. > > It's not clear from the charts exactly what is in an Avatar Host, so let > me suggest that first it should contain an instance of the avatar mesh. > > I am not sure it will. I think the mesh and all the things an avatar is > made up of will > be transferred to the region for simulating it. Mark also said that the > Region host will > be basically the same what a simulator is right now. I'm suggesting an alternate architecture with Avatar (not Agent) Hosts inside the Region Domain. Why keep transferring information from sim to sim if you don't have to? Mike From rdw at lindenlab.com Tue Sep 18 10:22:42 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Sep 18 10:22:45 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> Message-ID: <46F00962.9090909@lindenlab.com> Argent Stonecutter wrote: > From: "Tao Takashi" >> I am not sure it will. I think the mesh and all the things an avatar >> is made up of will be transferred to the region for simulating it. > > The region doesn't simulate an avatar. All it does is deliver the > textures and appearance parameters to the client. The avatar mesh is > in the client. It also calculates the collisions between avatars and the rest of the world, and runs the scripts in attachments, and makes the decision of when to deliver the representation to other agents, which is a non-trivial calculation. Maybe you meant something else, but the simulator definitely does more than just act as a bit pipe for avatars. -RYaN From secret.argent at gmail.com Tue Sep 18 10:41:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 10:41:59 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? (Lawson English) In-Reply-To: <20070918171438.4C83741B256@stupor.lindenlab.com> References: <20070918171438.4C83741B256@stupor.lindenlab.com> Message-ID: <0AC6D1D6-F25E-4050-BD0B-CEBE856C77F4@gmail.com> This exploit only works on Windows. On UNIX the calling application (shell, etc) splits the command line up into words, so the quoting exploit would not work unless the calling application is stupendously stupid and passes the input unfiltered to a shell (in which case there are many juicier exploits to be found). From monkowsk at watson.ibm.com Tue Sep 18 10:45:11 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 10:45:17 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> References: <46EEE207.4080801@watson.ibm.com> <23bbb49e0709180137s44eb6a69p2e87c099f1763043@mail.gmail.com> Message-ID: <46F00EA7.1000907@watson.ibm.com> Tao Takashi wrote: > A region host would contain instances of all objects owned by the > region, but the ownership would be handled by the Region Stores. > > > I think this is right although maybe "owned" is the wrong word. It will > contain the > region's inventory, assets copied over from agent hosts e.g. when rezzing > something in-world. The Owner of course is still the agent but I think you > mean the right thing. Yes, "owned" has a specific meaning in SL. I meant the kind of ownership that describes a C++ member variable within a class for example. It keeps track of it, defines its content, and delivers it to requestors. When rezzing an object, it wouldn't necessarily belong to the region. Only when it is left there permanently would it belong to the region. Otherwise it would belong to the avatar and vanish when the avatar logged off. Mike From lenglish5 at cox.net Tue Sep 18 10:45:31 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 10:45:33 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? (Lawson English) In-Reply-To: <0AC6D1D6-F25E-4050-BD0B-CEBE856C77F4@gmail.com> References: <20070918171438.4C83741B256@stupor.lindenlab.com> <0AC6D1D6-F25E-4050-BD0B-CEBE856C77F4@gmail.com> Message-ID: <46F00EBB.7090800@cox.net> Argent Stonecutter wrote: > This exploit only works on Windows. On UNIX the calling application > (shell, etc) splits the command line up into words, so the quoting > exploit would not work unless the calling application is stupendously > stupid and passes the input unfiltered to a shell (in which case there > are many juicier exploits to be found). > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Happy to learn this. From monkowsk at watson.ibm.com Tue Sep 18 10:47:56 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 10:48:13 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <1190075181.23349.4.camel@localhost> References: <46EEE207.4080801@watson.ibm.com> <1190075181.23349.4.camel@localhost> Message-ID: <46F00F4C.9080703@watson.ibm.com> Callum Lerwick wrote: > Avatar meshes are an asset, thus belong in asset storage. :) But when an avatar visits a region, everyone else in the region will need the mesh information. They should not have to go back to asset storage to get it. Mike From robla at lindenlab.com Tue Sep 18 10:54:30 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Sep 18 10:54:32 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <46EFFA4D.8030908@cox.net> References: <46EFFA4D.8030908@cox.net> Message-ID: <46F010D6.5030603@lindenlab.com> On 9/18/07 9:18 AM, Lawson English wrote: > http://www.gnucitizen.org/blog/ie-pwns-secondlife > > The comments appear to say that this is a firefox problem as well. > Does this work on other browsers in other OS's? > > This is a "show stopper" if the article is correct. We're aware of the issue, and we're working on a fix ASAP. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/a1ece581/signature.pgp From monkowsk at watson.ibm.com Tue Sep 18 11:01:29 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 11:01:47 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46EEF77F.3040405@gmail.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> Message-ID: <46F01279.9000706@watson.ibm.com> Jason Giglio wrote: > I'm going to ignore the rest of your message, because I think your > underlying assumptions and understandings were pretty flawed. Lets get > those sorted out before we get too far ahead of things. It's not a matter of sorting them out to get them right unless you're already sure that you have the "right" architecture. I may have misrepresented what was originally meant for the diagrams because I don't know what that was. But I wasn't trying to explain that. I was just using the existing diagrams for purposes of illustrating where I thought the information should reside and how it should be transferred to the viewer. Mike From secret.argent at gmail.com Tue Sep 18 11:05:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 11:05:41 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F00962.9090909@lindenlab.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> Message-ID: On 18-Sep-2007, at 12:22, Ryan Williams (Which) wrote: > Argent Stonecutter wrote: >> From: "Tao Takashi" >>> I am not sure it will. I think the mesh and all the things an >>> avatar is made up of will be transferred to the region for >>> simulating it. >> The region doesn't simulate an avatar. All it does is deliver the >> textures and appearance parameters to the client. The avatar mesh >> is in the client. > It also calculates the collisions between avatars and the rest of > the world, and runs the scripts in attachments, and makes the > decision of when to deliver the representation to other agents, > which is a non-trivial calculation. Maybe you meant something > else, but the simulator definitely does more than just act as a bit > pipe for avatars. What I mean is that as far as the sim is concerned, the avatar is a box. Apart from the overall size, the avatar shape takes no part in the physical simulation of the avatar, and the sim doesn't take the mesh and other visual characteristics of the actual avatar into account when dealing with it. Even scripted attachments don't involve the sim having to know anything about the mesh or avatar settings... all attachments are considered to be in the same place as far as the sim goes. I don't know if that place is the exact center of the bounding box, but it's not far off it, and the actual prims in the attachments are all phantom and don't interact in collisions either. I don't mean that the sim is a pipe, I mean that the sim is not where the actual simulation of the visible attributes of the avatar takes place. An avatar is not QUITE the same as a box prim in the same location (avatars can't fall over, for example, or rotate), but it's certainly not true that the mesh is ever transferred to the simulator, and most of the other characteristics of the avatar itself (other than attachments) don't need to be known by the sim as anything but a UUID (and I suppose an architecture where the client accessed assets like clothes, skins, and hair (as well as their associated textures) through another path would be quite possible). From monkowsk at watson.ibm.com Tue Sep 18 11:19:52 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 11:20:13 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46EEF77F.3040405@gmail.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> Message-ID: <46F016C8.6050403@watson.ibm.com> Jason Giglio wrote: >> The diagrams don't consider multiple viewers attached to a Region >> Host, but let's consider how viewers get information about other >> avatars. In the current SL architecture, all the information about >> all of the avatars is on the sim (region host) and all connections are >> through the sim. When an avatar moves across regions, his information >> is handed off from sim to sim. And because of this, we are limited to >> about a hundred avatars per sim. > > > That's a non-sequitur. It's because of a lot of reasons, but the design > you describe is really not one of them. If you know the reasons, it would be good to list them, because I think this is one of the limitations that should be eliminated. Mike From lenglish5 at cox.net Tue Sep 18 11:43:43 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 11:43:45 2007 Subject: [sldev] [VIEWER] Bug/inefficiency in mouse-handling in LLScrollLIstCtrl and other GUI classes? In-Reply-To: <46F003C7.908@cox.net> References: <46F003C7.908@cox.net> Message-ID: <46F01C5F.3040409@cox.net> Lawson English wrote: > I've been trying to implement my baby hierarchy/outline list class and > I found that "handleClick" to scroll list cells didn't pass the > x,y,mask values to the cell. This is required in order to do things > like drop-down folder arrow-icons, or edit-text-in-place cells, so I > added the parameters in in the relevant places and dumped the x/y > values to the debug console. > > The result suggests that handleClick is called over and over again on > a single click, even though only one x/y value is passed down the > line. This is inefficient, and probably reduces framerate, and > possibly has other side-effects as well. The shortest click I could > manage called handleClick 9 times. I am confused about this though. if handleClick is called multiple times, it should cause things like LLScrollListCheck::handleClick to be called multiple times which should set/reset checkboxes over and over. Testing... From makosoft at googlemail.com Tue Sep 18 11:55:24 2007 From: makosoft at googlemail.com (Aidan Thornton) Date: Tue Sep 18 11:55:25 2007 Subject: [sldev] MAJOR/CRITICAL exploit for webbrowsers and SL? In-Reply-To: <46F005ED.7010803@cox.net> References: <46EFFA4D.8030908@cox.net> <200709181856.29984.dale@daleglass.net> <1674f6c70709181003t7251d05cm5800465c353d8d13@mail.gmail.com> <46F005ED.7010803@cox.net> Message-ID: On 9/18/07, Lawson English wrote: > Erik Anderson wrote: > > You know, if this is an actual exploit then this list may not be the > > appropriate place to continue discussions, I'm sorry that I > > contributed at this point. > > > > The whole point of open source , vis a vis exploints is to get these > things out in the open AND FIXED asap. Or such ha always been the claim > of the open source community (or so I thought). > > Certainly, since it appeared on a public webpage, there's no hiding the > vulnerability. > The person who discovered the exploit also posted it on the full-disclosure mailing list 2 days or so ago, so I'd say the cat's well and truly out the bag. (It's a very well-known and fairly widely followed security mailing list, which means that lots of interesting individuals now know about it.) From tao.takashi at googlemail.com Tue Sep 18 12:11:52 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 18 12:11:54 2007 Subject: [sldev] [ARCH] Architecture Working Group in the wiki Message-ID: <23bbb49e0709181211u2e46b71bo9d3a35d2a431b70@mail.gmail.com> Hi! I just wanted to summarize a bit what I've done in the wiki for this project. So it all starts at https://wiki.secondlife.com/wiki/Architecture_Working_Group >From there I created pages which describe the proposed architecture as I understood it when Zero was talking about it. Feel free to correct me there or add more detail. Then I also added a Use Case page which already has some use cases and scenarios on it. Gigs also added some Strategic Goals which might help in finding the scope. My idea for now is though to think outside any scope for a while which is the reason for the blue sky scenarios there. As not everything fits into use case descriptions (after all they actually should only explain how the user directly interacts with the system and are maybe more useful for the viewer. But for now we migth see the components as the user) I also added a brainstorming section which is free form: https://wiki.secondlife.com/wiki/Brainstorming I would define the scope later then by collecting which features and requirements we want to model. Apparently these will be at least all the existing ones plus X. Then we could go in depth with the use cases and define protocols between the components. One first workitem might be to discuss other ways of decomposing based on the requirements we come up with. After we then decide to either stay with that setup or change it, it will be easier to define use cases as the components are fixed then. Anyway, feel free to edit and hope to meet some of you at Zero's office hour :-) Oh, and does this project need some (temporary) name actually? For me it's sometimes hard to say people what I am working on and I come up with something like "new SL architecture" etc. cheers, Tao PS: I am also thinking about doing some in-world meetings to maybe explain this thing to some more people. There seems to be interest. And I think it also needs to get publicized more. After all I think this project is rather drastic in the approach used and the thing being made and if it's really the start of e new internet then it should get more attention IMHO :-) -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/9544972a/attachment.htm From lenglish5 at cox.net Tue Sep 18 12:19:42 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 18 12:19:43 2007 Subject: [sldev] [VIEWER] Bug/inefficiency in mouse-handling in LLScrollLIstCtrl and other GUI classes? In-Reply-To: <46F01C5F.3040409@cox.net> References: <46F003C7.908@cox.net> <46F01C5F.3040409@cox.net> Message-ID: <46F024CE.9050707@cox.net> Lawson English wrote: > Lawson English wrote: >> I've been trying to implement my baby hierarchy/outline list class >> and I found that "handleClick" to scroll list cells didn't pass the >> x,y,mask values to the cell. This is required in order to do things >> like drop-down folder arrow-icons, or edit-text-in-place cells, so I >> added the parameters in in the relevant places and dumped the x/y >> values to the debug console. >> >> The result suggests that handleClick is called over and over again on >> a single click, even though only one x/y value is passed down the >> line. This is inefficient, and probably reduces framerate, and >> possibly has other side-effects as well. The shortest click I could >> manage called handleClick 9 times. > > I am confused about this though. if handleClick is called multiple > times, it should cause things like LLScrollListCheck::handleClick > > > to be called multiple times which should set/reset checkboxes over and > over. > > Testing... > _______________________________________________ LLScrollListCheck doesn't receive multiple handleClicks. Nor does my code IF it is does something else involving mouse handling that takes any significant time after the first click is received. The multiple-call seems to occur only if a do-nothing handleClick function receives the message with no intervening code of any significance. My intuition suggests that this is a sign of a hidden inefficiency, but it DOES APPEAR to allow one to work with the code without fear of getting multiple clicks. Depending on latency to prevent multiple calls is a bad way to code. There may be other issues that prevent the multiple handleClick calls, but latency appears to be a factor. L. From phoenix at secondlife.com Tue Sep 18 12:36:34 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Sep 18 12:36:43 2007 Subject: [sldev] URL handler vulnerability patch Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/66703019/PGP.pgp From josh at lindenlab.com Tue Sep 18 13:13:36 2007 From: josh at lindenlab.com (Joshua Bell) Date: Tue Sep 18 13:11:39 2007 Subject: [sldev] [ATTN-LINDEN] What's the future of the beta grid? In-Reply-To: <46EF9A42.5030106@blueflash.cc> References: <46E8113D.4070406@blueflash.cc> <46E83168.2030708@lindenlab.com> <46E83F69.60409@blueflash.cc> <46EF9A42.5030106@blueflash.cc> Message-ID: <46F03170.7020605@lindenlab.com> Nicholaz Beresford wrote: > > Beta seems to be down every time I tried since last > Friday. Any idea when it will come back? Ugh, sorry about that. We were planning to re-open it on Friday, but hit a snag with the deployed code. Updated ETA is Thursday. (Note: it's a different code branch than what's going out tomorrow.) From gigstaggart at gmail.com Tue Sep 18 13:19:17 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 18 13:19:19 2007 Subject: [sldev] [PATCH] Terraform with DYNAMIC TENSION to turn YOU into a BEAST OF A MAN In-Reply-To: <46EF9F47.1010300@blueflash.cc> References: <46EF9A60.3080707@gmail.com> <46EF9F47.1010300@blueflash.cc> Message-ID: <46F032C5.9050602@gmail.com> It's a good idea, but I think my patch already has some pretty large UI hurdles to get through, might want to save that for patchv2. F1-F6 would conflict with gestures I think, the number keys might be safe though. Nicholaz Beresford wrote: > > Hehe, or for that matter, now change the force > with keyboard. > > Like F1 - F6 for the functions and 1-9 for the > force. > > > Nick > > From gigstaggart at gmail.com Tue Sep 18 13:31:10 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 18 13:31:12 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F016C8.6050403@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F016C8.6050403@watson.ibm.com> Message-ID: <46F0358E.4000202@gmail.com> Mike Monkowski wrote: > If you know the reasons, it would be good to list them, because I think > this is one of the limitations that should be eliminated. Sure. Scene polygon count, script load, physics load, and network load. -Jason From monkowsk at watson.ibm.com Tue Sep 18 14:04:48 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 14:04:55 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F0358E.4000202@gmail.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com> Message-ID: <46F03D70.2090405@watson.ibm.com> Jason Giglio wrote: > Mike Monkowski wrote: > > If you know the reasons, it would be good to list them, because I think > > this is one of the limitations that should be eliminated. > > Sure. Scene polygon count, script load, physics load, and network load. For the scene polygon count, I assume you mean the added polygons for the avatars. This could be handled with lower LOD for more distant avatars. Script load and physics load (except for collision detection) shouldn't depend on the number of avatars, just the number of objects. By network load do you mean sim-to-sim or viewer-to-sim? If the latter, then it would mean in the new architecture we shouldn't have communication directly with the Region Hosts if we want to allow more avatars per sim. Yes? Mike From gigstaggart at gmail.com Tue Sep 18 14:11:50 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 18 14:11:52 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F03D70.2090405@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com> <46F03D70.2090405@watson.ibm.com> Message-ID: <46F03F16.7040308@gmail.com> Mike Monkowski wrote: > Jason Giglio wrote: >> Mike Monkowski wrote: >> > If you know the reasons, it would be good to list them, because I >> think >> > this is one of the limitations that should be eliminated. >> >> Sure. Scene polygon count, script load, physics load, and network load. > > For the scene polygon count, I assume you mean the added polygons for > the avatars. This could be handled with lower LOD for more distant > avatars. Yep, to an extent. > > Script load and physics load (except for collision detection) shouldn't > depend on the number of avatars, just the number of objects. > Except for collision detection!? Agents wear a load of scripts, usually much more than there are scripts in fixed objects in a sim. I've seen agents taking up 5+ms of script time. > By network load do you mean sim-to-sim or viewer-to-sim? If the latter, > then it would mean in the new architecture we shouldn't have > communication directly with the Region Hosts if we want to allow more > avatars per sim. Yes? sim-to-viewer mainly. And it's things like objectupdates that really the sim needs to handle. If you offload it you just move the load to the interdomain link, bogging it down. There's no silver bullet here to get more agents on a sim. -Jason From robla at lindenlab.com Tue Sep 18 14:18:03 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Sep 18 14:18:09 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <200709181812.14993.dale@daleglass.net> References: <46EF74EF.5070800@lindenlab.com> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> <200709181812.14993.dale@daleglass.net> Message-ID: <46F0408B.7000903@lindenlab.com> In general, comments and questions about Vivox's licensing terms should be directed to sl-feedback@vivox.com . Rob On 9/18/07 9:12 AM, Dale Glass wrote: > On Tuesday 18 September 2007 17:26:33 Mike Monkowski wrote: > >> John Hurliman wrote: >> >>> I can't make use of that >>> documentation myself since I'm supposed to be working on things like >>> porting the voice daemon, but maybe someone could. >>> >> I've already put a lot of documentation out on the Wiki about Voice, and >> my interests are not in cloning it, so I don't think there's any >> problem for me to look at the SDK documentation and add to the Wiki. >> If doing so would compromise anyone else's position, let me know. >> > > I think you should mail legal@lindenlab.com (IIRC) and ask, just in case. > If you agree to be bound by those conditions that's fine, but that > shouldn't affect those of us that don't want to have anything to do with > it. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070918/298497f7/signature.pgp From secret.argent at gmail.com Tue Sep 18 14:18:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 14:18:57 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <20070918180545.665D141B2AE@stupor.lindenlab.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> Message-ID: <70870729-8E0E-4E14-938F-08351E122795@gmail.com> From: Mike Monkowski >> The region doesn't simulate an avatar. All it does is deliver the >> textures and appearance parameters to the client. The avatar mesh >> is in >> the client. > It is now, but do you want to keep it that way? In the matter of what I *want*, why, I want the mesh to be another asset that can be edited by the user and uploaded, along with the skeleton. I want to be able to trigger animations selectively, overriding the priority, timing, and bones of the anim, or applying constraints on the joints beyond the ones built in. I want, dare I say it, rag doll animation. But none of that is really an issue here. In fact all of what I *want* could be implemented in the current architecture, and I doubt that any architecture that had a significant impact for the worse would pass muster, because any architecture that had constraints that prevented the creation of new network packets (say, ones carrying the overrides I suggested, as well as the UUID of the animation) or asset types would almost certainly carry grave restrictions elsewhere. I really don't think that the architecture needs to be particularly concerned with specific new types of assets, but rather that it should be able to handle new types of assets efficiently in the general case. > Why keep transferring information from sim to sim if you don't have > to? Locality of reference. If all the data associated with a request is cached on the same server, then it can be streamed to the client over the same TCP connection. In addition... in the general case the network connections between the sims is far faster than the network connections between the client and the various hosts, it makes sense to cache that information in the sim. Don't forget, 90% of programming is an exercise in caching. > When rezzing an object, it wouldn't necessarily belong to the region. > Only when it is left there permanently would it belong to the region. > Otherwise it would belong to the avatar and vanish when the avatar > logged off. I'm not sure that it makes a lot of sense for the avatar logging off should change the responsibility (perhaps a better word than ownership, given the conflict here) for a rezzed object. Why wouldn't you want the sim to take ownership of the avatar immediately? > But when an avatar visits a region, everyone else in the region will > need the mesh information. They should not have to go back to asset > storage to get it. Which answers "Why keep transferring information from sim to sim if you don't have to?", no? From Kindragon at comcast.net Tue Sep 18 14:31:45 2007 From: Kindragon at comcast.net (Obsidian Kindragon) Date: Tue Sep 18 14:31:33 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F03F16.7040308@gmail.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com> <46F03D70.2090405@watson.ibm.com> <46F03F16.7040308@gmail.com> Message-ID: <46F043C1.5010603@comcast.net> > Agents wear a load of scripts, usually much more than there are > scripts in fixed objects in a sim. I've seen agents taking up 5+ms of > script time. > > -Jason Tell me about it. I've caught avatars using 1000+ scripts and they didn't even realize it. I think a hard part is that the average scripter and user does not know how much script time their individual scripted objects are using. If there was an easier way for a scripter to know how many ms their script is using, I'm sure you'd find a number of scripters making less laggy scripts and using it as a selling point. - Obsidian Kindragon (AKA Obsidian Stormwind) From secret.argent at gmail.com Tue Sep 18 14:32:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 14:32:45 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <20070918211156.7BC3541B2F7@stupor.lindenlab.com> References: <20070918211156.7BC3541B2F7@stupor.lindenlab.com> Message-ID: <02735E97-2D9C-4988-8E12-99B517C269DD@gmail.com> From: Mike Monkowski > For the scene polygon count, I assume you mean the added polygons for > the avatars. This could be handled with lower LOD for more distant > avatars. This has already been fiddled with and the results were horrible. > Script load and physics load (except for collision detection) > shouldn't > depend on the number of avatars, just the number of objects. The number of physical objects. Avatars require more work from the physics engine than just about any common physical objects, except perhaps for dynamic physical machines like physical windchimes... and back when the avatar limit was a hard "40" you could bring a sim to its knees with more than a handful of physical windchimes. These kinds of toys are less common now that joints don't work, and sims are faster, but 100 physical and dynamically controlled objects (avatars or not) in a sim is still a pretty substantial load. From nik at terminaldischarge.net Tue Sep 18 14:35:53 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Sep 18 14:34:33 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F03D70.2090405@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com><46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com> <46F03D70.2090405@watson.ibm.com> Message-ID: <843EE08573AE46CC818248BE23E3683E@printingsolutions.co.uk> ----- Original Message ----- From: "Mike Monkowski" To: "Jason Giglio" Cc: Sent: Tuesday, September 18, 2007 10:04 PM Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are Caesar's > Jason Giglio wrote: >> Mike Monkowski wrote: >> > If you know the reasons, it would be good to list them, because I >> think >> > this is one of the limitations that should be eliminated. >> >> Sure. Scene polygon count, script load, physics load, and network load. > > For the scene polygon count, I assume you mean the added polygons for the > avatars. This could be handled with lower LOD for more distant avatars. > I assumed scene polygon count is all polygons on the region, The polygons for the avatar, polygons for all objects and prims, etc etc. > Script load and physics load (except for collision detection) shouldn't > depend on the number of avatars, just the number of objects. > Well, physics does depend on avatars too, for collisions against avatars. Scripts is just load depending on the amount of scripts running on the sim > By network load do you mean sim-to-sim or viewer-to-sim? If the latter, > then it would mean in the new architecture we shouldn't have communication > directly with the Region Hosts if we want to allow more avatars per sim. > Yes? I would of thought the network load is quite high all round, with communicating with adjacent sims as well as all viewers, but yes perhaps a suitable archiecture would be to have one sim, and then relay servers a bit like shoutcast does with relay servers? to lessen the load, of course the communication between relay and sim (Region host, sorry) would be two way to update information on the sim (created objects, object updates from clients, avatar positions etc) But would that actually help? (sorry I'm just jibbering on randomly) > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev Nik From nik at terminaldischarge.net Tue Sep 18 14:42:08 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Sep 18 14:40:52 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <843EE08573AE46CC818248BE23E3683E@printingsolutions.co.uk> References: <46EEE207.4080801@watson.ibm.com><46EEF77F.3040405@gmail.com><46F016C8.6050403@watson.ibm.com><46F0358E.4000202@gmail.com> <46F03D70.2090405@watson.ibm.com> <843EE08573AE46CC818248BE23E3683E@printingsolutions.co.uk> Message-ID: <763FDF9D8304433A8574FB831B28E12B@printingsolutions.co.uk> Ignore me, I hadn't realized this had been replied to already. ----- Original Message ----- From: "Nik Radford" To: "Mike Monkowski" Cc: Sent: Tuesday, September 18, 2007 10:35 PM Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are Caesar's > > ----- Original Message ----- > From: "Mike Monkowski" > To: "Jason Giglio" > Cc: > Sent: Tuesday, September 18, 2007 10:04 PM > Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are > Caesar's > > >> Jason Giglio wrote: >>> Mike Monkowski wrote: >>> > If you know the reasons, it would be good to list them, because I >>> think >>> > this is one of the limitations that should be eliminated. >>> >>> Sure. Scene polygon count, script load, physics load, and network load. >> >> For the scene polygon count, I assume you mean the added polygons for the >> avatars. This could be handled with lower LOD for more distant avatars. >> > I assumed scene polygon count is all polygons on the region, The polygons > for the avatar, polygons for all objects and prims, etc etc. > >> Script load and physics load (except for collision detection) shouldn't >> depend on the number of avatars, just the number of objects. >> > Well, physics does depend on avatars too, for collisions against avatars. > Scripts is just load depending on the amount of scripts running on the sim > >> By network load do you mean sim-to-sim or viewer-to-sim? If the latter, >> then it would mean in the new architecture we shouldn't have >> communication directly with the Region Hosts if we want to allow more >> avatars per sim. Yes? > I would of thought the network load is quite high all round, with > communicating with adjacent sims as well as all > viewers, but yes perhaps a suitable archiecture would be to have one sim, > and then relay servers a bit like shoutcast does with relay servers? to > lessen the load, of course the communication between relay and sim (Region > host, sorry) would be two way to update information on the sim (created > objects, object updates from clients, avatar positions etc) But would that > actually help? (sorry I'm just jibbering on randomly) > >> >> Mike >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > Nik > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From monkowsk at watson.ibm.com Tue Sep 18 14:50:17 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 14:50:21 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F03F16.7040308@gmail.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com> <46F03D70.2090405@watson.ibm.com> <46F03F16.7040308@gmail.com> Message-ID: <46F04819.7070300@watson.ibm.com> Jason Giglio wrote: > Agents wear a load of scripts, usually much more than there are scripts > in fixed objects in a sim. I've seen agents taking up 5+ms of script time. That's a good reason for having Avatar Hosts. I understand though that performance is expected to improve dramatically when scripting goes to Mono. Don't know when that's planned though. >> By network load do you mean sim-to-sim or viewer-to-sim? If the >> latter, then it would mean in the new architecture we shouldn't have >> communication directly with the Region Hosts if we want to allow more >> avatars per sim. Yes? > > > sim-to-viewer mainly. And it's things like objectupdates that really > the sim needs to handle. If you offload it you just move the load to > the interdomain link, bogging it down. > > There's no silver bullet here to get more agents on a sim. I'm not sure where an interdomain link would be or what it would do, but I'm guessing that your're saying that it's not really the number of avatars but the number of changes in the scene, and more avatars tends to mean more changes. Maybe it's a matter of proximity dependent object update rate. Silver bullet? No. I never said it would be easy, but the population limit is one of those limitations that's worth solving. Mike From nik at terminaldischarge.net Tue Sep 18 14:55:48 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Sep 18 14:54:26 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F04819.7070300@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com><46F016C8.6050403@watson.ibm.com> <46F0358E.4000202@gmail.com><46F03D70.2090405@watson.ibm.com> <46F03F16.7040308@gmail.com> <46F04819.7070300@watson.ibm.com> Message-ID: <2FC3FE0290124B4FBA0AF577962EA55A@printingsolutions.co.uk> ----- Original Message ----- From: "Mike Monkowski" To: "Jason Giglio" Cc: Sent: Tuesday, September 18, 2007 10:50 PM Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are Caesar's > Jason Giglio wrote: >> Agents wear a load of scripts, usually much more than there are scripts >> in fixed objects in a sim. I've seen agents taking up 5+ms of script >> time. > > That's a good reason for having Avatar Hosts. I understand though that > performance is expected to improve dramatically when scripting goes to > Mono. Don't know when that's planned though. > >>> By network load do you mean sim-to-sim or viewer-to-sim? If the latter, >>> then it would mean in the new architecture we shouldn't have >>> communication directly with the Region Hosts if we want to allow more >>> avatars per sim. Yes? >> >> >> sim-to-viewer mainly. And it's things like objectupdates that really the >> sim needs to handle. If you offload it you just move the load to the >> interdomain link, bogging it down. >> >> There's no silver bullet here to get more agents on a sim. > > I'm not sure where an interdomain link would be or what it would do, but > I'm guessing that your're saying that it's not really the number of > avatars but the number of changes in the scene, and more avatars tends to > mean more changes. Maybe it's a matter of proximity dependent object > update rate. Well as far as I know, a viewer is only sent object updates from the region host for the objects it is near. However, the region host itself has to update all objects all the time in memory in order to keep things consistant. > > Silver bullet? No. I never said it would be easy, but the population > limit is one of those limitations that's worth solving. > > Mike > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Tue Sep 18 14:56:57 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 18 14:57:03 2007 Subject: [sldev] [VIEWER] Distant avatar billboarding (was: Re: [ARCH] Render unto Caesar...) In-Reply-To: <02735E97-2D9C-4988-8E12-99B517C269DD@gmail.com> References: <20070918211156.7BC3541B2F7@stupor.lindenlab.com> <02735E97-2D9C-4988-8E12-99B517C269DD@gmail.com> Message-ID: <46F049A9.3040601@wsu.edu> Argent Stonecutter wrote: > From: Mike Monkowski >> For the scene polygon count, I assume you mean the added polygons for >> the avatars. This could be handled with lower LOD for more distant >> avatars. > > This has already been fiddled with and the results were horrible. That's a pretty quick dismissal of a very broad optimization technique, especially since it is going to be introduced again shortly. John Hurliman From monkowsk at watson.ibm.com Tue Sep 18 15:29:37 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 15:29:41 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <70870729-8E0E-4E14-938F-08351E122795@gmail.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> Message-ID: <46F05151.8050700@watson.ibm.com> Argent Stonecutter wrote: > I really don't think that the architecture needs to be particularly > concerned with specific new types of assets, but rather that it should > be able to handle new types of assets efficiently in the general case. But you need to know how much data is been transferred and how much computation is needed in order to scale efficiently. >> But when an avatar visits a region, everyone else in the region will >> need the mesh information. They should not have to go back to asset >> storage to get it. > > Which answers "Why keep transferring information from sim to sim if you > don't have to?", no? The question is whether it is better to keep the avatar information on specialized servers in the same domain as the region servers or whether the region server should kepp all of the information. I'm trying to address the population limit on a sim. I don't know the best solution, but I know the current implementation doesn't work. Any ideas? Mike From tao.takashi at googlemail.com Tue Sep 18 15:45:48 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 18 15:45:50 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F05151.8050700@watson.ibm.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> Message-ID: <23bbb49e0709181545x349d9980m27892589760b6b02@mail.gmail.com> Hi! I wanted to suggest to step a little back and see at the thing we want to implement. I think the main distinction Linden Lab does here is the agent and region domain. Mainly two black boxes to each other. Does it matter then where that avatar host is and if one is needed at all? Do I understand it right that your (Mike) suggestion is to have a separate box handle avatars? Maybe a little diagram might help :) If it's part of the region domain then the main question is whether it affects any possible interface or not.. There surely needs to be some sort of interfaces to load the avatar's appearance from probably the agent domain but I wonder if really more is needed. (box == whatever you can imagine here, cluster, single host, whatever) I also think the agent hosts were merely thought as some interface to a session object which can - take and give out inventory - handle profile and status updates and so on but not for having anything to do with rendering or simulating the actual virtual world. As for the population limit we maybe need some input from Linden Lab what the bottleneck here is. We once discussed it in an Zero office hour and the main thing there was some database bottleneck IIRC. But actually I did not really understand the problem in detail there. Of course that's for the sim only. Polygon count etc. might affect the client additionally. (Torley did note down something on her wiki user page though about impostering agents which are farer away. Whatever the plan there is ;-) To quote her: "There's some neat tech coming out, like "avatar imposters" to improve your framerate in big crowds by using less resources to draw further-away avatars. That means they will walk kind of jerkily and look like old-skool video game sprites, but the performance tradeoff may be very well worth it. This, of course, will be an OPTION so if you have a beefy rig and want to turn those imposters off, that's your prerogative." But I wonder if that really is something the architecture can change. Of course we should keep connections and possibly data streams to as minimal (or adjustable) as possible. -- Tao 2007/9/19, Mike Monkowski : > > Argent Stonecutter wrote: > > I really don't think that the architecture needs to be particularly > > concerned with specific new types of assets, but rather that it should > > be able to handle new types of assets efficiently in the general case. > > But you need to know how much data is been transferred and how much > computation is needed in order to scale efficiently. > > >> But when an avatar visits a region, everyone else in the region will > >> need the mesh information. They should not have to go back to asset > >> storage to get it. > > > > Which answers "Why keep transferring information from sim to sim if you > > don't have to?", no? > > The question is whether it is better to keep the avatar information on > specialized servers in the same domain as the region servers or whether > the region server should kepp all of the information. > > I'm trying to address the population limit on a sim. I don't know the > best solution, but I know the current implementation doesn't work. Any > ideas? > > Mike > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/8f8a064c/attachment.htm From monkowsk at watson.ibm.com Tue Sep 18 16:15:46 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 16:15:50 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <23bbb49e0709181545x349d9980m27892589760b6b02@mail.gmail.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> <23bbb49e0709181545x349d9980m27892589760b6b02@mail.gmail.com> Message-ID: <46F05C22.6020700@watson.ibm.com> Tao Takashi wrote: > I wanted to suggest to step a little back and see at the thing we want > to implement. > I think the main distinction Linden Lab does here is the agent and > region domain. > Mainly two black boxes to each other. Does it matter then where that > avatar host is > and if one is needed at all? > Do I understand it right that your (Mike) suggestion is to have a > separate box handle > avatars? Yes, that was the suggestion. > If it's part of the region domain then the main question is whether it > affects > any possible interface or not. It affects the information flow and the computational load. > I also think the agent hosts were merely thought as some interface to a > session object which can > - take and give out inventory > - handle profile and status updates > and so on but not for having anything to do with rendering or simulating > the actual virtual world. Yes, I misunderstood before, but I now I understand. > As for the population limit we maybe need some input from Linden Lab > what the bottleneck here is. > We once discussed it in an Zero office hour and the main thing there was > some database bottleneck Yes, the central database is very inefficient. If avatar information were distributed in Agent Stores and region information in Region Stores as the new architecture proposes, then database access would be distributed. No bottlenecks. > "There's some neat tech coming out, like "avatar imposters" to improve > your framerate in big crowds by using less resources to draw > further-away avatars. That means they will walk kind of jerkily and look > like old-skool video game sprites, but the performance tradeoff may be > very well worth it. This, of course, will be an OPTION so if you have a > beefy rig and want to turn those imposters off, that's your prerogative." > > But I wonder if that really is something the architecture can change. Of > course we should keep > connections and possibly data streams to as minimal (or adjustable) as > possible. Well, it's not something the architecture can change, but it should be taken into account when estimating communications loads. The key issue of all the new architecture is scaling. Mike From secret.argent at gmail.com Tue Sep 18 16:22:46 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 16:22:52 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <20070918215429.7EB4A41B2F6@stupor.lindenlab.com> References: <20070918215429.7EB4A41B2F6@stupor.lindenlab.com> Message-ID: From: Mike Monkowski >> Agents wear a load of scripts, usually much more than there are >> scripts >> in fixed objects in a sim. I've seen agents taking up 5+ms of >> script time. > > That's a good reason for having Avatar Hosts. I understand though > that > performance is expected to improve dramatically when scripting goes to > Mono. Don't know when that's planned though. How would "avatar hosts" reduce the load of scripts running in the sim? It doesn't MATTER where the scripts are stored, they still need to execute in the sim's context. From monkowsk at watson.ibm.com Tue Sep 18 16:27:29 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 18 16:27:32 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: References: <20070918215429.7EB4A41B2F6@stupor.lindenlab.com> Message-ID: <46F05EE1.9040601@watson.ibm.com> Argent Stonecutter wrote: > From: Mike Monkowski > >>> Agents wear a load of scripts, usually much more than there are scripts >>> in fixed objects in a sim. I've seen agents taking up 5+ms of >>> script time. >> >> >> That's a good reason for having Avatar Hosts. I understand though that >> performance is expected to improve dramatically when scripting goes to >> Mono. Don't know when that's planned though. > > > How would "avatar hosts" reduce the load of scripts running in the sim? > > It doesn't MATTER where the scripts are stored, they still need to > execute in the sim's context. By Avatar Hosts, I meant something different from Agent Hosts. The Avatar Hosts would perform the "sim" functions for avatars and attachments. Mike From secret.argent at gmail.com Tue Sep 18 16:32:44 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 16:32:56 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F05151.8050700@watson.ibm.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> Message-ID: On 18-Sep-2007, at 17:29, Mike Monkowski wrote: > Argent Stonecutter wrote: >> I really don't think that the architecture needs to be >> particularly concerned with specific new types of assets, but >> rather that it should be able to handle new types of assets >> efficiently in the general case. > But you need to know how much data is been transferred and how much > computation is needed in order to scale efficiently. How much data is there in an as-yet-undesigned avatar mesh asset? You don't know. "Premature optimization is the root of all evil." - Donald Knuth. > The question is whether it is better to keep the avatar information > on specialized servers in the same domain as the region servers or > whether the region server should kepp all of the information. The region server keeps as much information about the avatar as is needed to perform the operations on the avatar that the region server needs. That's true whether it's called a "region server" or a "sim". That's true regardless of the architecture. You can't put information that the region server needs on a different server, because you will increase network traffic and STILL need to keep a copy of whatever it needs on the region server. You can change the amount of information the region server caches, but that doesn't have a significant impact on the server architecture... it's all highly tunable. > I'm trying to address the population limit on a sim. I don't know > the best solution, but I know the current implementation doesn't > work. Any ideas? Multithreaded server using more than one core? From secret.argent at gmail.com Tue Sep 18 17:12:07 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 17:12:12 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F05EE1.9040601@watson.ibm.com> References: <20070918215429.7EB4A41B2F6@stupor.lindenlab.com> <46F05EE1.9040601@watson.ibm.com> Message-ID: On 18-Sep-2007, at 18:27, Mike Monkowski wrote: > By Avatar Hosts, I meant something different from Agent Hosts. The > Avatar Hosts would perform the "sim" functions for avatars and > attachments. How do you imagine it could possibly do that, without being the sim? If two avatars collide, the "sim function" for that collision is the collision itself. If a script in an attachment performs a sensor scan for nearby high-velocity objects, and rezzes a shield prim to ward them off, then where could it perform that task but the sim? Everything that could be performed on an avatar's behalf outside the sim has ALREADY been handed off to the client. From secret.argent at gmail.com Tue Sep 18 17:27:27 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 18 17:27:31 2007 Subject: [sldev] Re: [VIEWER] Reducing the LoD is not the same as billboarding. In-Reply-To: <20070918233255.3C96A41B2EC@stupor.lindenlab.com> References: <20070918233255.3C96A41B2EC@stupor.lindenlab.com> Message-ID: From: John Hurliman > Argent Stonecutter wrote: >> From: Mike Monkowski >>> For the scene polygon count, I assume you mean the added polygons >>> for >>> the avatars. This could be handled with lower LOD for more distant >>> avatars. >> This has already been fiddled with and the results were horrible. > That's a pretty quick dismissal of a very broad optimization > technique, > especially since it is going to be introduced again shortly. Reducing the LoD for avatars at a lower distance than is already done is not "avatar billboarding". Billboarding in general is a tremendously useful technique, and really needs to be performed on a wider scale than simply avatars (for example I've suggested that the already existing world map images could be used to replace the view of the regions at high altitudes, letting them act as billboards for the sims and giving a useful view of the world for flying vehicles). It's a completely different approach from reducing the level of detail of the mesh. To illustrate, consider https://jira.secondlife.com/browse/VWR-1623. In the first three images in that example the level of detail of the mesh is being reduced, from a multi-sided prism to a 4-sided prism to a 2-sided prism (or plane), without changing the number of elements. The fourth image shows a billboarded tree. The second reduction in mesh detail produces a result MUCH worse than a billboard, and yet costs more to render. I'd like to see snapshots of whole sims be used as billboards. You could do this progressively and get the equivalent of kilometers worth of draw distance at a lower cost than 256 meters now. From dzonatas at dzonux.net Tue Sep 18 17:43:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Sep 18 17:42:10 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F05151.8050700@watson.ibm.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> Message-ID: <46F070AF.5020906@dzonux.net> Mike Monkowski wrote: > I'm trying to address the population limit on a sim. I don't know the > best solution, but I know the current implementation doesn't work. > Any ideas? > It appears an idea for non-copy assets is partially done for scalability in mind. My suggestion would be to let copyable assets to decentralize themselves away from the current central server. That way bandwidth can be reshaped and localized to where the assets are effective. You can see some of this already happen with the drawn-up cache servers, which shows it is possible. The questions then becomes how would a viewer or region know where to find the assets once decentralized. Perhaps, a scheme like http redirects could help. The idea here is to reshape asset bandwidth so that population data does not have to be squeezed. I spoke and now I shut up again. -- Power to Change the Void From rdw at lindenlab.com Tue Sep 18 20:12:08 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Sep 18 20:12:26 2007 Subject: [sldev] [ANN] certified http development Message-ID: <46F09388.50404@lindenlab.com> You may have noticed that Certified HTTP was listed as one of the components of SL Grid 2008. Well, we're starting to build it. :-) I encourage everyone interested to take a look at the documents and code, flesh them out, poke holes in the logic, etc. This thing is going to be awesome and totally sweet, and I'm looking forward to working on it with you all. There are some design documents: http://wiki.secondlife.com/wiki/Certified_HTTP http://wiki.secondlife.com/wiki/Certified_HTTP_API You can check out the public repository here: http://svn.secondlife.com/svn/certified_http/trunk/ ...complete with a whole two commits. The eventual goal is to perform multi-host transactions through an escrow application (needs a better name). Sketchy design page here: http://wiki.secondlife.com/wiki/Certified_HTTP_Escrow We'll shift focus to the escrow application when Certified HTTP is complete. The design document at this point is mostly to give a use case for Certified HTTP. I'll do office hours on Thursday at 11am to talk about this stuff. Feel free to stop by! -RYaN From nlv19372 at natlab.research.philips.com Wed Sep 19 00:57:44 2007 From: nlv19372 at natlab.research.philips.com (Patrick Ozer) Date: Wed Sep 19 00:52:42 2007 Subject: [sldev] VWR-586 still in source? Message-ID: <46F0D678.2060307@natlab.research.philips.com> Hi All, I am new in the mailing list, so a short intro. My name is Patrick Ozer, I am a graduate student (MSc Artificial Intelligence)from the Netherlands and doing my internship at Philips Research. I am involved in a project about SL for Philips Research, Philips Design and McKinsey & Co. I compiled the source code (from 1.18.0.6 to 1.18.2.0) and got SL running and succesfully added my changes to the source, which were needed for my project. (all under Windows!) But after a while of usage the viewer crashes. I checked my code and the flaw isn't in there. To be sure I redid compilation with the source only and the problem still occurred. After compiling in ReleaseNoOpt and debugging, it looks like it is the VWR-586 bug, which was solved I thought?? Another piece of info. After making an installer out of it it still crashes (duh). But after trying it on my PC at home, or my laptop is worked just as the original SL viewer. After checking on other PC's, the viewer only crashed on some systems all with a 'Buffer Overrun detected' notification. Most of the time after a while, and after the first or a couple of crashes, short after each other. I think there is a problem with OpenGL, but I am no expert. In the call stack, before the usual stack with the VWR-586 bug the nvoglnt.dll is listed a couple of times. The PC has a NVIDIA Quadro FX graphics card. This one caused problems earlier I thought. Can anyone help me with this, or has someone had the same problem? thanks in advance, Patrick -- Patrick Ozer Artificial Intelligence MSc: Cognitive Engineering Radboud Universiteit Nijmegen Philips Research Connected Consumer Solutions WB 5.069 0031 40 27 49558 e-mail: nlv19372@natlab.research.philips.com From tao.takashi at googlemail.com Wed Sep 19 01:44:14 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 01:44:16 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F09388.50404@lindenlab.com> References: <46F09388.50404@lindenlab.com> Message-ID: <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> Hi! 2007/9/19, Ryan Williams (Which) : > > You may have noticed that Certified HTTP was listed as one of the > components of SL Grid 2008. Well, we're starting to build it. :-) Hey, a start! :-) I encourage everyone interested to take a look at the documents and > code, flesh them out, poke holes in the logic, etc. This thing is going > to be awesome and totally sweet, and I'm looking forward to working on > it with you all. You really should make this an open source developmen and inform the Python community :-) I quickly looked at the code and wondered, if maybe the ZODB might be of help for the persistance part. Not sure if it adds to much overhead though. But it would be a finished object storage with transactions and also the possibility to work distributed (e.g. one storage and many clients). Somebody in the Zope community is also implementing some RAID-like solution for it. (the ZODB is part of Zope but can also be used and is available standalone). http://wiki.zope.org/ZODB/FrontPage Oh, and you maybe want to start directly with an egg-like structure for the project so you can easily create an egg out of it and e.g. upload it to the cheeseshop. And I hope to see Linden Lab at the next EuroPython :-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/80f3f08b/attachment.htm From dmahalko at gmail.com Wed Sep 19 02:03:33 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Sep 19 02:03:36 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? Message-ID: It's now been about nine months since Andrew Linden or anyone else has said anything official about the physics engine upgrade project. Joints disappeared, and that was the end of it. I keep hearing rumors that LL has Havok 4 implemented on a closed beta grid, but there is nothing to back that up anywhere. What's the latest info on the physics upgrade project? Is there any continuing work to resolve the severe sim-crashing bugs in the old Havok-I engine? And finally, if anything is happening with a new engine on a beta grid, is there some way for physics explorers like me to get involved and help to stress-test it before it goes live? :-) I submit my latest Havok-stressing project "Paddle-Whack" in Chilbo (205,30,93) and my physics/art museum in Chilbo (137,47,98) as my resume. Last Thursday while intensely trying to do my Paddle-Whack physics testing, I was crashing Chilbo about every ten minutes due to the Havok engine collision bugs, until eventually the world map was showing Chiblo to be red/Offline/invalid for half an hour. I've documented one of these crashes on Google Video, showing a sim crash within one MINUTE of starting up the physics experiment. Google Video: Second Life Physics Engine - Tumbler Crash http://video.google.com/videoplay?docid=1028823598159492193 I'm not intentionally trying to crash the sim, but I don't see how to move forward without risking occasional crashes. Because the physics engine is in the unlreleased server-side code, debugging is apparantly out of our control. All I can do is try to learn how to step gingerly around the major problems. This Paddle-Whack project is so unstable that it apparantly cannot be allowed to run unattended, because it may be causing the sim to crash every 10 - 30 minutes all night long. Instead I've added a user-triggerable control panel that loads a number of marbles and knocks them around for just a few minutes to try and reduce the crash frequency. My partial hope here is that perhaps my continued physics experiments are helping Andrew Linden and his team to narrow down the source of the engine crashes. This depends on whether the Havok-1 engine is still even being debugged, or if it is considered "stable" and not being updated any further, with the only fixes being like the anti-crash script-stopper mechanism to mop up the mess after a buggy engine crash. I don't know if its worth reporting these physics crashes to the JIRA since they seem almost totally random, and the sim gives me no debugging messages when it crashes. It just dies and the connection immediately drops -- which you may happen to experience for yourself, if you try the 5-ball setting with Paddle-Whack.. -Scalar Tardis, aka Dale Mahalko From tao.takashi at googlemail.com Wed Sep 19 02:50:42 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 02:50:44 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: Message-ID: <23bbb49e0709190250k42cac746m5e491ccab45bfd5@mail.gmail.com> Hi! 2007/9/19, Dale Mahalko : > > It's now been about nine months since Andrew Linden or anyone else has > said anything official about the physics engine upgrade project. > Joints disappeared, and that was the end of it. I keep hearing rumors > that LL has Havok 4 implemented on a closed beta grid, but there is > nothing to back that up anywhere. There is a blog post about it: http://blog.secondlife.com/2007/08/24/linden-labs-effort-to-improve-grid-stability/ (somewhere hidden in the middle) where Ian says: "We've been talking about upgrading the Havokphysics engine included in the sim software for years, and haven't managed to deliver. However, this project is making real progress now and will be ready for a beta test soon." (there is more detail in the post) "Soon" is of course relative but let's hope it's not months :-) Is there any continuing work to resolve the severe sim-crashing bugs > in the old Havok-I engine? The hope is apparently that there are fewer sim crashes with Havok 4 caused by Physics. I don't know if its worth reporting these physics crashes to the JIRA > since they seem almost totally random, and the sim gives me no > debugging messages when it crashes. It just dies and the connection > immediately drops -- which you may happen to experience for yourself, > if you try the 5-ball setting with Paddle-Whack.. Probably it is because if you give time and date they might at least have a look at logfiles and whatnot. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/70490f4e/attachment-0001.htm From tao.takashi at googlemail.com Wed Sep 19 06:49:45 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 06:49:48 2007 Subject: [sldev] [ARCH] Slashdot and Metaplace Message-ID: <23bbb49e0709190649x76fb4c5l40c8ca3aef25a377@mail.gmail.com> Hi! I just wanted to throw 2 links into the round. First of all I thought that the architecture group is not getting enough attention from any blogs and thus I submitted that story to slashdot and it even got taken and is on the frontpage now. http://games.slashdot.org/games/07/09/19/126250.shtml So far I don't see not that many bad comments, actually it seems pretty ok. Of course some are proposing different things like Croquet etc. but most of them do not know yet the actual proposed architecture and the complete problem Then there is news about metaplace out now, the product Raph Koster's company has been working on for the last year or so: http://taotakashi.wordpress.com/2007/09/19/raph-koster-finally-reveils-what-areae-is-all-about-metaplacecom/ So it declares to be a standard for virtual worlds, too. And it might gain some momentum as Raph Koster is a well known guy. But not much information is out yet and it needs to be seen how this whole project will look like. You can find it at http://metaplace.com. But it seems to get slowly crowded in the we-define-a-virtual-worlds-standard field, 3 projects announced within 1 week. well, I thought I share these links with you :-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/454cc062/attachment.htm From nicholaz at blueflash.cc Wed Sep 19 07:34:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Sep 19 07:34:43 2007 Subject: [sldev] [VIEWER][CRASH][PATCH][JIRA] Possible crash on startup Message-ID: <46F13363.7060901@blueflash.cc> This could use a few eyeballs, or homebrewers might be interested in doing some testing (I just have a crash dump, no solid repro yet) https://jira.secondlife.com/browse/VWR-2524 -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From labrat.hb at gmail.com Wed Sep 19 07:45:17 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Sep 19 07:45:20 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <23bbb49e0709190250k42cac746m5e491ccab45bfd5@mail.gmail.com> References: <23bbb49e0709190250k42cac746m5e491ccab45bfd5@mail.gmail.com> Message-ID: This was from Meta Lindens office hours on Friday of last week (Sept 14) Meta Linden: In fact het-grid *is* helping- already. We are rolling the new physics engine onto some sims on the main grid *today*. I can't confirm this as Meta no longer posts logs of his office hours, and the blog I did pull it from isn't on the top of my "Contains factual information" list On 9/19/07, Tao Takashi wrote: > > Hi! > > > 2007/9/19, Dale Mahalko : > > > > It's now been about nine months since Andrew Linden or anyone else has > > said anything official about the physics engine upgrade project. > > Joints disappeared, and that was the end of it. I keep hearing rumors > > that LL has Havok 4 implemented on a closed beta grid, but there is > > nothing to back that up anywhere. > > > > There is a blog post about it: > > http://blog.secondlife.com/2007/08/24/linden-labs-effort-to-improve-grid-stability/ > > > (somewhere hidden in the middle) where Ian says: > > "We've been talking about upgrading the Havokphysics engine included in the sim software for years, and haven't managed > to deliver. However, this project is making real progress now and will be > ready for a beta test soon." (there is more detail in the post) > > "Soon" is of course relative but let's hope it's not months :-) > > > > Is there any continuing work to resolve the severe sim-crashing bugs > > in the old Havok-I engine? > > > The hope is apparently that there are fewer sim crashes with Havok 4 > caused by Physics. > > > > I don't know if its worth reporting these physics crashes to the JIRA > > since they seem almost totally random, and the sim gives me no > > debugging messages when it crashes. It just dies and the connection > > immediately drops -- which you may happen to experience for yourself, > > if you try the 5-ball setting with Paddle-Whack.. > > > > Probably it is because if you give time and date they might at least have > a look at logfiles and whatnot. > > -- Tao > > > > -- > taotakashi@gmail.com > http://taotakashi.wordpress.com > http://worldofsl.com > > RL: Christian Scholz, cs@comlounge.net > http://mrtopf.de > > http://comlounge.net > http://comlounge.tv > http://mrtopf.tv > http://dev.comlounge.net > IRC: MrTopf/Tao_T > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/b1373b2c/attachment.htm From monkowsk at watson.ibm.com Wed Sep 19 07:51:36 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Sep 19 07:52:16 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F070AF.5020906@dzonux.net> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> <46F070AF.5020906@dzonux.net> Message-ID: <46F13778.90402@watson.ibm.com> Dzonatas wrote: > The questions then becomes how would a viewer or region know where to > find the assets once decentralized. Perhaps, a scheme like http > redirects could help. OK, maybe I misunderstood (again), but I thought that was the purpose of the Region Stores. Everything that is permanent in a sim would be kept there. Everything that comes with avatars would come with references from the Agent Hosts. > I spoke and now I shut up again. Me too (at least on this topic). Thank you all for your forbearance. Mike From tao.takashi at googlemail.com Wed Sep 19 07:57:33 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 07:57:40 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar... In-Reply-To: <46F13778.90402@watson.ibm.com> References: <20070918180545.665D141B2AE@stupor.lindenlab.com> <70870729-8E0E-4E14-938F-08351E122795@gmail.com> <46F05151.8050700@watson.ibm.com> <46F070AF.5020906@dzonux.net> <46F13778.90402@watson.ibm.com> Message-ID: <23bbb49e0709190757t5ad2791y18e0fc42543ff1a4@mail.gmail.com> > OK, maybe I misunderstood (again), but I thought that was the purpose of > the Region Stores. Everything that is permanent in a sim would be kept > there. Everything that comes with avatars would come with references > from the Agent Hosts. I think you are right about the region stores.. Not sure about the references from agent stores, I think if you rez an object in-world it will be copied to the region store of course with owner information etc. It was one work item I think to discuss what an object actual is and what is referential (or can be) and what is the actual object (e.g. textures on faces are right now referenced, what will happen to them? Maybe there needs to be a means of making them more a part of the object and copy them over as well, etc.). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/5a84fa5d/attachment.htm From seg at haxxed.com Wed Sep 19 08:38:17 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Sep 19 08:38:27 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: Message-ID: <1190216297.8146.4.camel@localhost> I'm wondering how ODE compares to Havok. It would certainly beat the hell out of Havok 1. ODE is apparently good enough for BloodRayne 2. And I wasn't aware Stair/Truck dismount were using ODE. :) http://www.ode.org/users.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070919/3b58bd5f/attachment.pgp From labrat.hb at gmail.com Wed Sep 19 08:41:21 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Sep 19 08:41:24 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <1190216297.8146.4.camel@localhost> References: <1190216297.8146.4.camel@localhost> Message-ID: OpenSim is using ODE so they might be good to ask how it's working. On 9/19/07, Callum Lerwick wrote: > > I'm wondering how ODE compares to Havok. It would certainly beat the > hell out of Havok 1. ODE is apparently good enough for BloodRayne 2. And > I wasn't aware Stair/Truck dismount were using ODE. :) > > http://www.ode.org/users.html > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/18fa1ef3/attachment-0001.htm From nik at terminaldischarge.net Wed Sep 19 09:01:55 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Wed Sep 19 09:01:57 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: <1190216297.8146.4.camel@localhost> Message-ID: <51427.86.10.79.229.1190217715.squirrel@webmail.terminaldischarge.net> Actually the OpenSim you see in the list, isn't the same OpenSim that your thinking of. Nik > OpenSim is using ODE so they might be good to ask how it's working. > > On 9/19/07, Callum Lerwick wrote: >> >> I'm wondering how ODE compares to Havok. It would certainly beat the >> hell out of Havok 1. ODE is apparently good enough for BloodRayne 2. And >> I wasn't aware Stair/Truck dismount were using ODE. :) >> >> http://www.ode.org/users.html >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From labrat.hb at gmail.com Wed Sep 19 09:28:20 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Sep 19 09:28:24 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <51427.86.10.79.229.1190217715.squirrel@webmail.terminaldischarge.net> References: <1190216297.8146.4.camel@localhost> <51427.86.10.79.229.1190217715.squirrel@webmail.terminaldischarge.net> Message-ID: http://opensimulator.org/wiki/Main_Page <--- That's the one I'm thinking of On 9/19/07, nik@terminaldischarge.net wrote: > > Actually the OpenSim you see in the list, isn't the same OpenSim that your > thinking of. > > Nik > > > OpenSim is using ODE so they might be good to ask how it's working. > > > > On 9/19/07, Callum Lerwick wrote: > >> > >> I'm wondering how ODE compares to Havok. It would certainly beat the > >> hell out of Havok 1. ODE is apparently good enough for BloodRayne 2. > And > >> I wasn't aware Stair/Truck dismount were using ODE. :) > >> > >> http://www.ode.org/users.html > >> > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > >> > >> > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/aff36d8b/attachment.htm From donovan at lindenlab.com Wed Sep 19 09:19:02 2007 From: donovan at lindenlab.com (Donovan Linden) Date: Wed Sep 19 09:43:32 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> Message-ID: <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> I like the ZODB a lot, and there is also Divmod Axiom, which is glyph's 3rd or 4th object database for Python, and I think this one is pretty solid. It's based on embedding SQLite. However, the information here which requires persistence is so simple that a real object database would be way overkill. I think (rdw correct me if I am wrong) the current plan is just to use mysql to store whatever needs to be stored for a Long Time. However, this may be overkill in my mind as well. I think the simplest possible solution is just to have the HTTP server write requests as it reads them to a logfile along with the responses after they are written. (It probably couldn't store the body, because that could be of arbitrary size.) If the server crashes, it will read in the logfile, build the appropriate "I've already done that" structures based on what it sees, and then delete the logfile, creating a new one to record all the traffic it successfully handles. But I haven't been the one who has been thinking through the implementation details, so this might not work. Donovan On Sep 19, 2007, at 1:44 AM, Tao Takashi wrote: > Hi! > > > 2007/9/19, Ryan Williams (Which) : > You may have noticed that Certified HTTP was listed as one of the > components of SL Grid 2008. Well, we're starting to build it. :-) > > > Hey, a start! :-) > > I encourage everyone interested to take a look at the documents and > code, flesh them out, poke holes in the logic, etc. This thing is > going > to be awesome and totally sweet, and I'm looking forward to working on > it with you all. > > > You really should make this an open source developmen and inform > the Python community :-) > > I quickly looked at the code and wondered, if maybe the ZODB might > be of help > for the persistance part. Not sure if it adds to much overhead though. > But it would be a finished object storage with transactions and > also the > possibility to work distributed (e.g. one storage and many clients). > Somebody in the Zope community is also implementing some RAID-like > solution > for it. > (the ZODB is part of Zope but can also be used and is available > standalone). > > http://wiki.zope.org/ZODB/FrontPage > > Oh, and you maybe want to start directly with an egg-like structure > for the project > so you can easily create an egg out of it and e.g. upload it to the > cheeseshop. > > And I hope to see Linden Lab at the next EuroPython :-) > > -- Tao > > > -- > taotakashi@gmail.com > http://taotakashi.wordpress.com > http://worldofsl.com > > RL: Christian Scholz, cs@comlounge.net > http://mrtopf.de > > http://comlounge.net > http://comlounge.tv > http://mrtopf.tv > http://dev.comlounge.net > IRC: MrTopf/Tao_T > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/ed360783/attachment.htm From rdw at lindenlab.com Wed Sep 19 09:45:48 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Sep 19 10:28:03 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> Message-ID: <46F1523C.4060206@lindenlab.com> Tao Takashi wrote: > > You really should make this an open source developmen and inform the > Python community :-) > It's already as open source as I can make it, what you see is what we have, and I'll keep committing as I keep writing code and figuring out the documentation. Is there something else I can do? If anyone with a contributor agreement wants to hack on the code, that can be arranged too. I should poke on some of the Python mailing lists (that's where the community is, right?). I'll see if I can find the right place. Not everyone is interested in distributed agreement. :-) > I quickly looked at the code and wondered, if maybe the ZODB might be > of help > for the persistance part. Not sure if it adds to much overhead though. > But it would be a finished object storage with transactions and also the > possibility to work distributed (e.g. one storage and many clients). > Somebody in the Zope community is also implementing some RAID-like > solution > for it. > (the ZODB is part of Zope but can also be used and is available > standalone). > > http://wiki.zope.org/ZODB/FrontPage > An ORM would definitely be nicer than ham-handed use of pickle. I wonder if ZODB offers enough control over when the object gets written to disk, though. Definitely certified http should support different backends in any case. > Oh, and you maybe want to start directly with an egg-like structure > for the project > so you can easily create an egg out of it and e.g. upload it to the > cheeseshop. > Yeah, totally. Is there a good HOWTO on that? We should do that for eventlet and mulib too, because that would be rad. > And I hope to see Linden Lab at the next EuroPython :-) > Me too! -RYaN From phoenix at secondlife.com Wed Sep 19 10:56:59 2007 From: phoenix at secondlife.com (Phoenix) Date: Wed Sep 19 11:27:26 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> Message-ID: In order for reliable message delivery to work, you have to have an ACID data store. It could be a file system (with much programmer care), or it could be any of a number of ACID relational/object databases. We have the most operational experience with MySQL, so our initial implementation will almost certainly be backed by it. I think once we have a solid interface for persistence needs, it should not be too difficult to port to another store. On 2007-09-19, at 09:19, Donovan Linden wrote: > I like the ZODB a lot, and there is also Divmod Axiom, which is > glyph's 3rd or 4th object database for Python, and I think this one > is pretty solid. It's based on embedding SQLite. However, the > information here which requires persistence is so simple that a > real object database would be way overkill. > > I think (rdw correct me if I am wrong) the current plan is just to > use mysql to store whatever needs to be stored for a Long Time. > However, this may be overkill in my mind as well. > > I think the simplest possible solution is just to have the HTTP > server write requests as it reads them to a logfile along with the > responses after they are written. (It probably couldn't store the > body, because that could be of arbitrary size.) If the server > crashes, it will read in the logfile, build the appropriate "I've > already done that" structures based on what it sees, and then > delete the logfile, creating a new one to record all the traffic it > successfully handles. But I haven't been the one who has been > thinking through the implementation details, so this might not work. > > Donovan > > On Sep 19, 2007, at 1:44 AM, Tao Takashi wrote: > >> Hi! >> >> >> 2007/9/19, Ryan Williams (Which) : You may have >> noticed that Certified HTTP was listed as one of the >> components of SL Grid 2008. Well, we're starting to build it. :-) >> >> >> Hey, a start! :-) >> >> I encourage everyone interested to take a look at the documents and >> code, flesh them out, poke holes in the logic, etc. This thing is >> going >> to be awesome and totally sweet, and I'm looking forward to >> working on >> it with you all. >> >> >> You really should make this an open source developmen and inform >> the Python community :-) >> >> I quickly looked at the code and wondered, if maybe the ZODB might >> be of help >> for the persistance part. Not sure if it adds to much overhead >> though. >> But it would be a finished object storage with transactions and >> also the >> possibility to work distributed (e.g. one storage and many clients). >> Somebody in the Zope community is also implementing some RAID-like >> solution >> for it. >> (the ZODB is part of Zope but can also be used and is available >> standalone). >> >> http://wiki.zope.org/ZODB/FrontPage >> >> Oh, and you maybe want to start directly with an egg-like >> structure for the project >> so you can easily create an egg out of it and e.g. upload it to >> the cheeseshop. >> >> And I hope to see Linden Lab at the next EuroPython :-) >> >> -- Tao >> >> >> -- >> taotakashi@gmail.com >> http://taotakashi.wordpress.com >> http://worldofsl.com >> >> RL: Christian Scholz, cs@comlounge.net >> http://mrtopf.de >> >> http://comlounge.net >> http://comlounge.tv >> http://mrtopf.tv >> http://dev.comlounge.net >> IRC: MrTopf/Tao_T >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tao.takashi at googlemail.com Wed Sep 19 11:37:44 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 11:37:49 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1523C.4060206@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <46F1523C.4060206@lindenlab.com> Message-ID: <23bbb49e0709191137j63603363wca6f009d1a59f3f4@mail.gmail.com> Hi1 > You really should make this an open source developmen and inform the > > Python community :-) > > > It's already as open source as I can make it, what you see is what we > have, and I'll keep committing as I keep writing code and figuring out > the documentation. Is there something else I can do? If anyone with a > contributor agreement wants to hack on the code, that can be arranged too. > > I should poke on some of the Python mailing lists (that's where the > community is, right?). I'll see if I can find the right place. Not > everyone is interested in distributed agreement. :-) Well, in general I guess you can announce it at least. Of course with contributor agreements it's harder to find people than without. It might also depend on how many people's problem it might solve (not really sure in this case). And maybe we need to make more of the Python people in Second Life actually. There should be some around and I am not sure if they do meetings or whatever but it would be definitely nice (but I am not in that group because of that group limit..) > I quickly looked at the code and wondered, if maybe the ZODB might be > > of help > > for the persistance part. Not sure if it adds to much overhead though. > > But it would be a finished object storage with transactions and also the > > possibility to work distributed (e.g. one storage and many clients). > > Somebody in the Zope community is also implementing some RAID-like > > solution > > for it. > > (the ZODB is part of Zope but can also be used and is available > > standalone). > > > > http://wiki.zope.org/ZODB/FrontPage > > > > An ORM would definitely be nicer than ham-handed use of pickle. I > wonder if ZODB offers enough control over when the object gets written > to disk, though. Definitely certified http should support different > backends in any case. What control would you need? I am not really an expert of ZODB internals as I mainly use it in a Zope context where it's more or less packaged in. But I know at least one guy who is quite an expert (the one hacking on the RAID solution for it). As for ACID it should support that at least with the most recent version. http://www.zope.org/Wikis/ZODB/guide/node3.html also states this. Different backends might be definitely nice. Did you look at e.g. Zope 3 interfaces? It might be one solution to have a delegation architecture. You simply define an interfaces and on runtime you ask for an object implementing that interface. In this case it could be whatever backend might implement IPersistentStore (actually in Zope 3 terms these would be probably more utilities but these are also simply class with an interface which are registered). > Oh, and you maybe want to start directly with an egg-like structure > > for the project > > so you can easily create an egg out of it and e.g. upload it to the > > cheeseshop. > > > Yeah, totally. Is there a good HOWTO on that? We should do that for > eventlet and mulib too, because that would be rad. You might want to start here: http://peak.telecommunity.com/DevCenter/PythonEggs Honestly I haven't really started a project using eggs myself as I mostly was working on projects in egg form already. But once I did it I might write a eventually good HOWTO :-) > And I hope to see Linden Lab at the next EuroPython :-) > > > Me too! See you in Vilnius then ;-) (well and tomorrow at your office hour maybe.. Where will it be?) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/56eab61c/attachment-0001.htm From ettore_pasquini at 3dconnexion.com Wed Sep 19 11:55:37 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Wed Sep 19 11:55:49 2007 Subject: [sldev] [VWR] [PATCH] Flycam support for Mac OS X Message-ID: My first patch, finally. I implemented flycam support on Mac OS X. Main things worth noting: - I refactored the current implementation in two ways: (1) abstracting out OS-specific device initialization into a separate, minimal, reusable "libndofdev" library; (2) cleaning up the LLWindow hierarchy with joystick related junk and putting that in the more proper LLViewerJoystick class. (Why having a joystick class when all the main joystick functions are inside a window hierarchy?) - I used Apple's HID Utilities sample code because it's free and it works. - Linux is to do, but I will do it when I get some free time. I know it's a fairly big chunk of stuff, but there was no "small" way around it. Any problems you notice, please let me know. More details here: http://jira.secondlife.com/browse/VWR-2516 Ettore From bos at lindenlab.com Wed Sep 19 11:59:42 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Sep 19 12:04:29 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1523C.4060206@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <46F1523C.4060206@lindenlab.com> Message-ID: <46F1719E.1090704@lindenlab.com> Ryan Williams (Which) wrote: > An ORM would definitely be nicer than ham-handed use of pickle. Meh. If you ever come across a Python ORM that isn't in some way awful, let me know :-( >> Oh, and you maybe want to start directly with an egg-like structure >> for the project >> so you can easily create an egg out of it and e.g. upload it to the >> cheeseshop. >> > Yeah, totally. Is there a good HOWTO on that? Beware of eggs. They put everything on the front of sys.path no matter what value PYTHONPATH has, so they completely bollix up the frequent case of having a stable version of a package installed system-wide, and an unstable one in development in one's SVN tree. A terrible design choice. Message-ID: On 9/13/07 3:53 PM, "Callum Lerwick" wrote: > On Thu, 2007-09-13 at 14:06 -0700, Ettore Pasquini wrote: >> - I developed an open source library to have a cross-platform API to access >> the device. The implementation is DI on Win and HID on OS X, any other >> platforms can be added by just implementing a few functions. This makes >> viewer code unaware of the underlying implementation. >> - I am refactoring the joystick implementation to use the above library. > > Is there a reason you can't just use SDL's joystick layer rather than > reinventing more wheels? Actually there is. Currently the flycam on Windows works nicely with a few calls to DirectInput: I didn't want to radically change already working code. I wanted to minimize any possible breakage. Ettore From rdw at lindenlab.com Wed Sep 19 12:52:50 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Sep 19 12:53:20 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1719E.1090704@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <46F1523C.4060206@lindenlab.com> <46F1719E.1090704@lindenlab.com> Message-ID: <46F17E12.1050506@lindenlab.com> Bryan O'Sullivan wrote: > Ryan Williams (Which) wrote: > >> An ORM would definitely be nicer than ham-handed use of pickle. > > Meh. If you ever come across a Python ORM that isn't in some way > awful, let me know :-( > >>> Oh, and you maybe want to start directly with an egg-like structure >>> for the project >>> so you can easily create an egg out of it and e.g. upload it to the >>> cheeseshop. >>> >> Yeah, totally. Is there a good HOWTO on that? > > Beware of eggs. They put everything on the front of sys.path no > matter what value PYTHONPATH has, so they completely bollix up the > frequent case of having a stable version of a package installed > system-wide, and an unstable one in development in one's SVN tree. A > terrible design choice. > So, is the moral: if you make an egg, don't install it on the machine you're developing it on? Is there a better packaging system, or some workaround? Surely there's some way to develop nice python packages. -RYaN From bos at lindenlab.com Wed Sep 19 13:03:27 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Sep 19 13:08:17 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F17E12.1050506@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <46F1523C.4060206@lindenlab.com> <46F1719E.1090704@lindenlab.com> <46F17E12.1050506@lindenlab.com> Message-ID: <46F1808F.6040300@lindenlab.com> Ryan Williams wrote: > So, is the moral: if you make an egg, don't install it on the machine > you're developing it on? Yes. Also, don't try to install multiple versions of an egg-based package at once. > Is there a better packaging system, or some workaround? Surely there's > some way to develop nice python packages. There aren't any elegant workarounds that I know of. References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> Message-ID: <46F1842B.2050201@lindenlab.com> Donovan Linden wrote: > I like the ZODB a lot, and there is also Divmod Axiom, which is > glyph's 3rd or 4th object database for Python, and I think this one is > pretty solid. It's based on embedding SQLite. However, the information > here which requires persistence is so simple that a real object > database would be way overkill. > That's a good point. Also, the data is completely opaque to the chttp layer, with limited exceptions. I think that a single method is actually enough to interact with the persistent store, no matter how it's implemented under the hood. We shall see! No need to discuss underlying technology libraries for your chickens before they're hatched, I guess. > I think (rdw correct me if I am wrong) the current plan is just to use > mysql to store whatever needs to be stored for a Long Time. However, > this may be overkill in my mind as well. > We're thinking that we'll be doing *everything* in MySQL, because then we can wrap an entire do-something-non-idempotent-and-send-a-response into one database transaction and hope that those guys implemented ACID right. :-) We'll also have to store the Long Time data somewhere, MySQL is as good a place as any. Doesn't have to be, though. > I think the simplest possible solution is just to have the HTTP server > write requests as it reads them to a logfile along with the responses > after they are written. (It probably couldn't store the body, because > that could be of arbitrary size.) If the server crashes, it will read > in the logfile, build the appropriate "I've already done that" > structures based on what it sees, and then delete the logfile, > creating a new one to record all the traffic it successfully handles. > But I haven't been the one who has been thinking through the > implementation details, so this might not work. I think this is necessary but not sufficient. I dunno if this is "feature creep", but if you want to perform non-idempotent operations to generate a response, you want said operations to not be run multiple times even in the case where you've only done half of them and haven't written the response to the log before you crash. Not having this guarantee basically means that the exactly-once messaging guarantee is worthless, because you can call the handler function an arbitrary number of times in the worst case, and that's not really distinguishable from receiving the message multiple times. -RYaN From odysseus654 at gmail.com Wed Sep 19 14:05:50 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Sep 19 14:05:53 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1842B.2050201@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <46F1842B.2050201@lindenlab.com> Message-ID: <1674f6c70709191405g20200ce7he6aa19193531086e@mail.gmail.com> On 9/19/07, Ryan Williams wrote: > > > I think the simplest possible solution is just to have the HTTP server > > write requests as it reads them to a logfile along with the responses > > after they are written. (It probably couldn't store the body, because > > that could be of arbitrary size.) If the server crashes, it will read > > in the logfile, build the appropriate "I've already done that" > > structures based on what it sees, and then delete the logfile, > > creating a new one to record all the traffic it successfully handles. > > But I haven't been the one who has been thinking through the > > implementation details, so this might not work. I think this is necessary but not sufficient. I dunno if this is > "feature creep", but if you want to perform non-idempotent operations to > generate a response, you want said operations to not be run multiple > times even in the case where you've only done half of them and haven't > written the response to the log before you crash. Not having this > guarantee basically means that the exactly-once messaging guarantee is > worthless, because you can call the handler function an arbitrary number > of times in the worst case, and that's not really distinguishable from > receiving the message multiple times. > If you're gonna be using a transaction log to handle your requests, you need to make sure that it's written out and flushed to disk before sending the response, not afterwards. I know that the local DHCP server I have on my linux box here uses this kind of approach, so this type of solution is not unheard of (every so often it copies out all active entries into a new log file). Transaction log management does start sounding like something that a database excels at though... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/2d8c0de4/attachment.htm From robin.cornelius at gmail.com Wed Sep 19 13:09:38 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Sep 19 14:09:45 2007 Subject: [sldev] [VIEWER] problems with AMD64 build Message-ID: <46F18202.1080600@gmail.com> Hi Everyone i am seeing the following issues with my standalone 64bit build. This is constant across 1.18.2.0 to 1.18.3.4 Build ----- Firstly i need to apply the attached patch to build :- On my system (debian) expat.h is not in /usr/include/expat but in /usr/include The viewer_manifest.py wants to include its own libxmlrpc-epi and not use the system one And the files that reference gstreamer do not build unless gstreamer is in the pkg-config list. Are these problems with the build or problems with my system setup? After that build is ok, viewer cannot start however as the required ttf fonts are missing. If i copy the fonts directory from a linden build, the viewer will start. Again is there a font missing i can install, or is the fonts directory required and should be included in the standalone build. The fail is quite ungraceful with an exception. The cursors are also missing but not fatal. Again should these be included in a standalone build? or have i missed the point of standalone and should be building STANDALONE=no (as this dosn't work) And other resource files seem missing and YES i did copy the artwork zip file into my build tree! So is this an issue when building standalone builds?? GL Issues --------- For some reason my GL does not support the same features as when I am on the same PC but running 32bit (nvidia drivers). First of all my card was being detected as a nvidia generic (therefor class 0), its a 7100 so i added in a line for it NVIDIA GeForce 7100 .*NVIDIA.*GeForce 71.* 3 But i still can't select bump mapped/shiny or ripple Also the builds spam the debug logs with:- WARNING: isFeatureAvailable: Feature UseOcclusion not on feature list! many times a second, so much so makes the viewer very very slow. Any ideas what I have done wrong this time! Many thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-build.patch Type: text/x-patch Size: 1630 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070919/1f7213b2/slviewer-build.bin From rdw at lindenlab.com Wed Sep 19 14:28:34 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Sep 19 14:28:56 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <1674f6c70709191405g20200ce7he6aa19193531086e@mail.gmail.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <46F1842B.2050201@lindenlab.com> <1674f6c70709191405g20200ce7he6aa19193531086e@mail.gmail.com> Message-ID: <46F19482.20409@lindenlab.com> Erik Anderson wrote: > > > On 9/19/07, *Ryan Williams* > wrote: > > > I think the simplest possible solution is just to have the HTTP > server > > write requests as it reads them to a logfile along with the > responses > > after they are written. (It probably couldn't store the body, > because > > that could be of arbitrary size.) If the server crashes, it will > read > > in the logfile, build the appropriate "I've already done that" > > structures based on what it sees, and then delete the logfile, > > creating a new one to record all the traffic it successfully > handles. > > But I haven't been the one who has been thinking through the > > implementation details, so this might not work. > > > I think this is necessary but not sufficient. I dunno if this is > "feature creep", but if you want to perform non-idempotent > operations to > generate a response, you want said operations to not be run multiple > times even in the case where you've only done half of them and haven't > written the response to the log before you crash. Not having this > guarantee basically means that the exactly-once messaging guarantee is > worthless, because you can call the handler function an arbitrary > number > of times in the worst case, and that's not really distinguishable > from > receiving the message multiple times. > > > If you're gonna be using a transaction log to handle your requests, > you need to make sure that it's written out and flushed to disk before > sending the response, not afterwards. I know that the local DHCP > server I have on my linux box here uses this kind of approach, so this > type of solution is not unheard of (every so often it copies out all > active entries into a new log file). Transaction log management does > start sounding like something that a database excels at though... Exactly. :-) -RYaN From nik at terminaldischarge.net Wed Sep 19 14:56:54 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Sep 19 14:55:33 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: References: <46F09388.50404@lindenlab.com><23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com><1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> Message-ID: <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> ----- Original Message ----- From: "Phoenix" To: "Donovan Linden" Cc: ; "Ryan Williams (Which)" Sent: Wednesday, September 19, 2007 6:56 PM Subject: Re: [sldev] [ANN] certified http development > In order for reliable message delivery to work, you have to have an ACID > data store. It could be a file system (with much programmer care), or it > could be any of a number of ACID relational/object databases. > > We have the most operational experience with MySQL, so our initial > implementation will almost certainly be backed by it. I think once we > have a solid interface for persistence needs, it should not be too > difficult to port to another store. > As long as you wrap the data access up in a nice class, I don't know if python supports interfaces or abstract classes, but it may be a good idea to create a data access interface, which other coders can inherit from and implement they're own back-end code for data storage. > > On 2007-09-19, at 09:19, Donovan Linden wrote: >> I like the ZODB a lot, and there is also Divmod Axiom, which is glyph's >> 3rd or 4th object database for Python, and I think this one is pretty >> solid. It's based on embedding SQLite. However, the information here >> which requires persistence is so simple that a real object database >> would be way overkill. >> >> I think (rdw correct me if I am wrong) the current plan is just to use >> mysql to store whatever needs to be stored for a Long Time. However, >> this may be overkill in my mind as well. >> >> I think the simplest possible solution is just to have the HTTP server >> write requests as it reads them to a logfile along with the responses >> after they are written. (It probably couldn't store the body, because >> that could be of arbitrary size.) If the server crashes, it will read in >> the logfile, build the appropriate "I've already done that" structures >> based on what it sees, and then delete the logfile, creating a new one >> to record all the traffic it successfully handles. But I haven't been >> the one who has been thinking through the implementation details, so >> this might not work. >> >> Donovan >> >> On Sep 19, 2007, at 1:44 AM, Tao Takashi wrote: >> >>> Hi! >>> >>> >>> 2007/9/19, Ryan Williams (Which) : You may have >>> noticed that Certified HTTP was listed as one of the >>> components of SL Grid 2008. Well, we're starting to build it. :-) >>> >>> >>> Hey, a start! :-) >>> >>> I encourage everyone interested to take a look at the documents and >>> code, flesh them out, poke holes in the logic, etc. This thing is >>> going >>> to be awesome and totally sweet, and I'm looking forward to working on >>> it with you all. >>> >>> >>> You really should make this an open source developmen and inform the >>> Python community :-) >>> >>> I quickly looked at the code and wondered, if maybe the ZODB might be >>> of help >>> for the persistance part. Not sure if it adds to much overhead though. >>> But it would be a finished object storage with transactions and also >>> the >>> possibility to work distributed (e.g. one storage and many clients). >>> Somebody in the Zope community is also implementing some RAID-like >>> solution >>> for it. >>> (the ZODB is part of Zope but can also be used and is available >>> standalone). >>> >>> http://wiki.zope.org/ZODB/FrontPage >>> >>> Oh, and you maybe want to start directly with an egg-like structure for >>> the project >>> so you can easily create an egg out of it and e.g. upload it to the >>> cheeseshop. >>> >>> And I hope to see Linden Lab at the next EuroPython :-) >>> >>> -- Tao >>> >>> >>> -- >>> taotakashi@gmail.com >>> http://taotakashi.wordpress.com >>> http://worldofsl.com >>> >>> RL: Christian Scholz, cs@comlounge.net >>> http://mrtopf.de >>> >>> http://comlounge.net >>> http://comlounge.tv >>> http://mrtopf.tv >>> http://dev.comlounge.net >>> IRC: MrTopf/Tao_T >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tao.takashi at googlemail.com Wed Sep 19 15:14:11 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Sep 19 15:14:12 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> Message-ID: <23bbb49e0709191514j49b2c826vca56363bcfc76f3d@mail.gmail.com> Hi! As long as you wrap the data access up in a nice class, I don't know if > python supports interfaces or abstract classes, but it may be a good idea > to > create a data access interface, which other coders can inherit from and > implement they're own back-end code for data storage. In Python 2.x there are not interfaces in the language directly but there are implementations like one from the Zope project (also usable standalone). In Python 3 there will be then Abstract Base Classes. But that's still a bit ahead I think (although the Alpha has just been released IIRC). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070920/1e3a0d9b/attachment.htm From nik at terminaldischarge.net Wed Sep 19 15:55:07 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Sep 19 15:53:40 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <23bbb49e0709191514j49b2c826vca56363bcfc76f3d@mail.gmail.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> <23bbb49e0709191514j49b2c826vca56363bcfc76f3d@mail.gmail.com> Message-ID: <184D89F431B245809D2CE8210EE5E719@printingsolutions.co.uk> Its a shame, at least its something being worked to ^_^ ----- Original Message ----- From: Tao Takashi To: Nik Radford Cc: Phoenix ; Donovan Linden ; sldev@lists.secondlife.com ; Ryan Williams (Which) Sent: Wednesday, September 19, 2007 11:14 PM Subject: Re: [sldev] [ANN] certified http development Hi! As long as you wrap the data access up in a nice class, I don't know if python supports interfaces or abstract classes, but it may be a good idea to create a data access interface, which other coders can inherit from and implement they're own back-end code for data storage. In Python 2.x there are not interfaces in the language directly but there are implementations like one from the Zope project (also usable standalone). In Python 3 there will be then Abstract Base Classes. But that's still a bit ahead I think (although the Alpha has just been released IIRC). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/a226af60/attachment.htm From rdw at lindenlab.com Wed Sep 19 16:10:57 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Sep 19 16:11:18 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <184D89F431B245809D2CE8210EE5E719@printingsolutions.co.uk> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> <23bbb49e0709191514j49b2c826vca56363bcfc76f3d@mail.gmail.com> <184D89F431B245809D2CE8210EE5E719@printingsolutions.co.uk> Message-ID: <46F1AC81.4020608@lindenlab.com> Duck typing is probably close enough, actually. I mean, you don't need to inherit from an abstract base class to implement a simple API. The way I'm doing this is right now (though this could probably use some improvement) is the Context object has a member that implements a 'store' method and an 'objects' method, and that's the entire API. There's an implementation that uses files, but it should be straightforward to implement it using MySQL or whatever you like. -RYaN Nik Radford wrote: > Its a shame, at least its something being worked to ^_^ > > ----- Original Message ----- > > *From:* Tao Takashi > *To:* Nik Radford > *Cc:* Phoenix ; Donovan Linden > ; sldev@lists.secondlife.com > ; Ryan Williams (Which) > > *Sent:* Wednesday, September 19, 2007 11:14 PM > *Subject:* Re: [sldev] [ANN] certified http development > > Hi! > > As long as you wrap the data access up in a nice class, I > don't know if > python supports interfaces or abstract classes, but it may be > a good idea to > create a data access interface, which other coders can inherit > from and > implement they're own back-end code for data storage. > > > > In Python 2.x there are not interfaces in the language directly > but there are implementations > like one from the Zope project (also usable standalone). In Python > 3 there will be then > Abstract Base Classes. But that's still a bit ahead I think > (although the Alpha has > just been released IIRC). > > -- Tao > > > -- > taotakashi@gmail.com > http://taotakashi.wordpress.com > http://worldofsl.com > > RL: Christian Scholz, cs@comlounge.net > http://mrtopf.de > > http://comlounge.net > http://comlounge.tv > http://mrtopf.tv > http://dev.comlounge.net > IRC: MrTopf/Tao_T > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nik at terminaldischarge.net Wed Sep 19 16:19:37 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Sep 19 16:18:11 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1AC81.4020608@lindenlab.com> References: <46F09388.50404@lindenlab.com> <23bbb49e0709190144h6b841f51y733eeac320cd771e@mail.gmail.com> <1148DC91-E5DA-4688-B60F-E500B9CBF102@lindenlab.com> <4F002EE47A2949C6884224C266DE88DF@printingsolutions.co.uk> <23bbb49e0709191514j49b2c826vca56363bcfc76f3d@mail.gmail.com> <184D89F431B245809D2CE8210EE5E719@printingsolutions.co.uk> <46F1AC81.4020608@lindenlab.com> Message-ID: <93C56A26495647708D1DBDCEE9978352@printingsolutions.co.uk> Fair enough :) ----- Original Message ----- From: "Ryan Williams" To: "Nik Radford" Cc: "Tao Takashi" ; Sent: Thursday, September 20, 2007 12:10 AM Subject: Re: [sldev] [ANN] certified http development > Duck typing is probably close enough, actually. I mean, you don't need to > inherit from an abstract base class to implement a simple API. The way > I'm doing this is right now (though this could probably use some > improvement) is the Context object has a member that implements a 'store' > method and an 'objects' method, and that's the entire API. There's an > implementation that uses files, but it should be straightforward to > implement it using MySQL or whatever you like. > > -RYaN > > Nik Radford wrote: >> Its a shame, at least its something being worked to ^_^ >> >> ----- Original Message ----- >> >> *From:* Tao Takashi >> *To:* Nik Radford >> *Cc:* Phoenix ; Donovan Linden >> ; sldev@lists.secondlife.com >> ; Ryan Williams (Which) >> >> *Sent:* Wednesday, September 19, 2007 11:14 PM >> *Subject:* Re: [sldev] [ANN] certified http development >> >> Hi! >> >> As long as you wrap the data access up in a nice class, I >> don't know if >> python supports interfaces or abstract classes, but it may be >> a good idea to >> create a data access interface, which other coders can inherit >> from and >> implement they're own back-end code for data storage. >> >> >> >> In Python 2.x there are not interfaces in the language directly >> but there are implementations >> like one from the Zope project (also usable standalone). In Python >> 3 there will be then >> Abstract Base Classes. But that's still a bit ahead I think >> (although the Alpha has >> just been released IIRC). >> >> -- Tao >> >> >> -- >> taotakashi@gmail.com >> http://taotakashi.wordpress.com >> http://worldofsl.com >> >> RL: Christian Scholz, cs@comlounge.net >> http://mrtopf.de >> >> http://comlounge.net >> http://comlounge.tv >> http://mrtopf.tv >> http://dev.comlounge.net >> IRC: MrTopf/Tao_T >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > From secret.argent at gmail.com Wed Sep 19 16:27:45 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 19 16:27:48 2007 Subject: [sldev] "Intel reaps Havok for $110M" In-Reply-To: <20070919212857.222D041B367@stupor.lindenlab.com> References: <20070919212857.222D041B367@stupor.lindenlab.com> Message-ID: <9C4E28BF-B8BC-4B89-8922-2E4F89873CC7@gmail.com> http://news.zdnet.com/2100-9595_22-6208614.html?tag=nl.e550 From secret.argent at gmail.com Wed Sep 19 16:32:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 19 16:32:55 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <20070919212857.222D041B367@stupor.lindenlab.com> References: <20070919212857.222D041B367@stupor.lindenlab.com> Message-ID: From: Ryan Williams > We're thinking that we'll be doing *everything* in MySQL, because then > we can wrap an entire do-something-non-idempotent-and-send-a-response > into one database transaction and hope that those guys implemented > ACID > right. :-) Was that a joke about MySQL? I'm not laughing. But that does bring up a question... did you guys ever consider PostgreSQL? From soft at lindenlab.com Wed Sep 19 16:39:06 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Sep 19 16:39:08 2007 Subject: [sldev] [Ann] SLDev-Traffic #27 Message-ID: <9e6e5c9e0709191639l775ad532rb598bf1241b2f6ae@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_27 SLDev-Traffic number 27 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From dmahalko at gmail.com Wed Sep 19 17:38:20 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Sep 19 17:38:22 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: <1190216297.8146.4.camel@localhost> Message-ID: Before making any claim that another physics engine is better, you need to load up the engine with the same amount of collision-volume data as a maxed-out LL sim to do a really fair comparison. Any engine will look pretty if it only has to deal with a small number of objects, as with Truck Dismount, which has fewer objects to spread the calculations. Get the engine up to SL's triangle counts and the holes will start to appear. A static prim with physics turned off is treated as a collision volume for anything else moving around. In Sandbox Island, that is up to 15,000 collision volumes for the engine to deal with -- and potentially even more collision volumes can be in the sim if temp-on-rez is thrown into the picture. (Imagine 5,000 objects that each rez up a 10-prim temp-on-rez linked object.) Since SL does things differently than a proper 3D mesh-editor and doesn't go by triangles/meshes but an ephemeral "prim" quantity, you have to include objects that approximate the same mesh counts as the various SL prims. A cut, hollowed, adv-cut, revolved torus probably has around 500 triangles. Multiply that by your test-sim's prims, and that adds up to over 7,500,000 triangles across all collision volumes, to be processed every 0.022 sec (at 45 FPS sim-physics). A test like this will probably bring the Open Simulator to to its knees, begging for mercy. ;-) From rdw at lindenlab.com Wed Sep 19 19:25:01 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Sep 19 19:25:21 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: References: <20070919212857.222D041B367@stupor.lindenlab.com> Message-ID: <46F1D9FD.3040708@lindenlab.com> Argent Stonecutter wrote: > From: Ryan Williams >> We're thinking that we'll be doing *everything* in MySQL, because then >> we can wrap an entire do-something-non-idempotent-and-send-a-response >> into one database transaction and hope that those guys implemented ACID >> right. :-) > > Was that a joke about MySQL? I'm not laughing. > Ha ha, well, it's better than hoping that *we* implemented ACID right. :-) Gotta start with something solid. > But that does bring up a question... did you guys ever consider > PostgreSQL? I think chttp would do quite well with a Postgres backend. No reason not to. As for our choice of software to run on our servers, I've seen that question a lot, and I don't really have an answer since the decision to use MySQL was made long before I started here. -RYaN From bbyer at mm.st Wed Sep 19 22:47:03 2007 From: bbyer at mm.st (Ben Byer) Date: Wed Sep 19 22:47:13 2007 Subject: [sldev] [VWR] Crashes in C++ STL functions Message-ID: <68434DD1-2B71-400A-8E75-900EBBFB72FA@mm.st> Okay, so, STL stuff is a weak point for me, and several of the most common crashes I'm seeing in the database available to me are found in STL code. For example: https://jira.secondlife.com/browse/VWR-2462 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x3ed6e6e8 Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00d16724 std::_Rb_tree, std::less, std::allocator >::lower_bound(LLImageGL* const&) + 20 1 com.secondlife.indra.viewer 0x008887d8 LLImageGL::~LLImageGL [in- charge deleting]() + 556 2 com.secondlife.indra.viewer 0x00319fb4 LLBumpImageList::updateImages() + 180 3 com.secondlife.indra.viewer 0x004d6ec0 idle() + 6380 4 com.secondlife.indra.viewer 0x004dba1c main_loop() + 1008 5 com.secondlife.indra.viewer 0x004e54b8 main + 22104 6 com.secondlife.indra.viewer 0x000026dc _start + 760 7 com.secondlife.indra.viewer 0x000023e0 start + 48 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x5cc0daad Thread 0 Crashed: 0 com.secondlife.indra.viewer 0x00d722e1 std::_Rb_tree, std::less, std::allocator >::upper_bound(LLImageGL* const&) + 35 1 com.secondlife.indra.viewer 0x00d7254f std::_Rb_tree, std::less, std::allocator >::erase(LLImageGL* const&) + 27 2 com.secondlife.indra.viewer 0x00911974 LLImageGL::~LLImageGL [in- charge deleting]() + 220 3 com.secondlife.indra.viewer 0x005adc60 LLDynamicTexture::~LLDynamicTexture [not-in-charge]() + 490 4 com.secondlife.indra.viewer 0x004906c9 LLTexLayerSetBuffer::~LLTexLayerSetBuffer [in-charge deleting]() + 117 5 com.secondlife.indra.viewer 0x00495a49 LLTexLayerSet::~LLTexLayerSet [in-charge]() + 69 6 com.secondlife.indra.viewer 0x000aec7c LLVOAvatar::~LLVOAvatar [in- charge deleting]() + 872 7 com.secondlife.indra.viewer 0x004f7e37 LLObjectSelection::~LLObjectSelection [in-charge deleting]() + 609 8 com.secondlife.indra.viewer 0x00013e16 __tcf_420 + 112 9 com.secondlife.indra.viewer 0x00002bed cxa_atexit_wrapper + 115 10 libSystem.B.dylib 0x900103e1 __cxa_finalize + 226 11 libSystem.B.dylib 0x900102e8 exit + 24 12 com.secondlife.indra.viewer 0x000027da _start + 224 13 com.secondlife.indra.viewer 0x000026f9 start + 41 https://jira.secondlife.com/browse/VWR-2463 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xc0323f3d Thread 0 Crashed: 0 libSystem.B.dylib 0x90003a28 szone_malloc + 240 1 libSystem.B.dylib 0x90003600 malloc + 632 2 libstdc++.6.dylib 0x94c94350 operator new(unsigned long) + 116 3 com.secondlife.indra.viewer 0x00c76b64 std::_Rb_tree, std::less, std::allocator >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, LLViewerImage* const&) + 44 4 com.secondlife.indra.viewer 0x00c76cac std::_Rb_tree, std::less, std::allocator >::insert_unique(LLViewerImage* const&) + 220 5 com.secondlife.indra.viewer 0x00282d04 LLViewerImageList::updateImagesFetchTextures(float) + 316 6 com.secondlife.indra.viewer 0x0028ab80 LLViewerImageList::updateImages(float) + 380 7 com.secondlife.indra.viewer 0x004d6ed4 idle() + 6400 8 com.secondlife.indra.viewer 0x004dba1c main_loop() + 1008 9 com.secondlife.indra.viewer 0x004e54b8 main + 22104 10 com.secondlife.indra.viewer 0x000026dc _start + 760 11 com.secondlife.indra.viewer 0x000023e0 start + 48 ... etc. I'd be happy to dig into these crashes more, but I don't really even know where to begin -- I don't know where to find the code that implements the crashing functions. Help! -b From dale at daleglass.net Thu Sep 20 01:42:35 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 01:42:46 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: Message-ID: <200709201042.40855.dale@daleglass.net> On Thursday 20 September 2007 02:38:20 Dale Mahalko wrote: > Since SL does things differently than a proper 3D mesh-editor and > doesn't go by triangles/meshes but an ephemeral "prim" quantity, you > have to include objects that approximate the same mesh counts as the > various SL prims. A cut, hollowed, adv-cut, revolved torus probably > has around 500 triangles. > > Multiply that by your test-sim's prims, and that adds up to over > 7,500,000 triangles across all collision volumes, to be processed > every 0.022 sec (at 45 FPS sim-physics). Why would it test for collisions on triangles? Prims are ideal for collision testing. Testing for collisions against a mesh which happens to be a sphere would take a lot of processing time, while checking against a sphere prim would be near instant in comparison since as you KNOW it's a sphere you can do the check against an imaginary perfect sphere. In fact, I thought this was a major reason to use the prims concept: If you specify the shape and its characteristics instead of a mesh you can generate as few or many triangles as you want (scaling with available processing power) and calculate collisions much more efficiently. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/15d8e912/attachment.pgp From dale at daleglass.net Thu Sep 20 01:48:16 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 01:48:27 2007 Subject: [sldev] [VWR] Crashes in C++ STL functions In-Reply-To: <68434DD1-2B71-400A-8E75-900EBBFB72FA@mm.st> References: <68434DD1-2B71-400A-8E75-900EBBFB72FA@mm.st> Message-ID: <200709201048.21890.dale@daleglass.net> On Thursday 20 September 2007 07:47:03 Ben Byer wrote: > ... etc. I'd be happy to dig into these crashes more, but I don't > really even know where to begin -- I don't know where to find the code > that implements the crashing functions. Help! > -b Crashes in the STL are like crashes in malloc: A real bug in the STL or malloc would be a very rare thing. The most likely reason for a crash there is that the code calling the STL function or malloc screwed something up, and then the function you called choked on it. At first glance, I see there in the stack: LLImageGL::~LLImageGL. This means something went wrong in the destructor. You could start by checking what that destructor does and what could go wrong in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/b84b89dd/attachment.pgp From nik at terminaldischarge.net Thu Sep 20 01:49:25 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Thu Sep 20 01:49:26 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <200709201042.40855.dale@daleglass.net> References: <200709201042.40855.dale@daleglass.net> Message-ID: <49500.86.10.79.229.1190278165.squirrel@webmail.terminaldischarge.net> Hey > On Thursday 20 September 2007 02:38:20 Dale Mahalko wrote: >> Since SL does things differently than a proper 3D mesh-editor and >> doesn't go by triangles/meshes but an ephemeral "prim" quantity, you >> have to include objects that approximate the same mesh counts as the >> various SL prims. A cut, hollowed, adv-cut, revolved torus probably >> has around 500 triangles. >> >> Multiply that by your test-sim's prims, and that adds up to over >> 7,500,000 triangles across all collision volumes, to be processed >> every 0.022 sec (at 45 FPS sim-physics). > > Why would it test for collisions on triangles? > > Prims are ideal for collision testing. Testing for collisions against a > mesh which happens to be a sphere would take a lot of processing time, > while checking against a sphere prim would be near instant in comparison > since as you KNOW it's a sphere you can do the check against an imaginary > perfect sphere. > > In fact, I thought this was a major reason to use the prims concept: If > you > specify the shape and its characteristics instead of a mesh you can > generate as few or many triangles as you want (scaling with available > processing power) and calculate collisions much more efficiently. What happens if the sphere a dimple or has been turned into a torus? What happens if the sphere is cut? The reason for prims, was so they could send shapes that, even after some fiddling, might have complex meshs, as just a few parameters across the network. Rather than 100's of vertices, they send 20ish parameters. Lowering network bandwidth usuage and allowing the streaming of objects you see. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Nik. From blakar at gmail.com Thu Sep 20 01:59:00 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Sep 20 01:59:03 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <49500.86.10.79.229.1190278165.squirrel@webmail.terminaldischarge.net> References: <200709201042.40855.dale@daleglass.net> <49500.86.10.79.229.1190278165.squirrel@webmail.terminaldischarge.net> Message-ID: <7992d0d60709200159tf3dbda3p1c6847d2be65b379@mail.gmail.com> > > In fact, I thought this was a major reason to use the prims concept: If > > you > > specify the shape and its characteristics instead of a mesh you can > > generate as few or many triangles as you want (scaling with available > > processing power) and calculate collisions much more efficiently. > > What happens if the sphere a dimple or has been turned into a torus? > What happens if the sphere is cut? > The reason for prims, was so they could send shapes that, even after some > fiddling, might have complex meshs, as just a few parameters across the > network. Rather than 100's of vertices, they send 20ish parameters. > Lowering network bandwidth usuage and allowing the streaming of objects > you see. The physical simulation and the graphical representation do not match at all times. If the math for the physical representation is too complex it'll revert to using a shape that approximates what we see. Similarly the visible representation may be less correct than the physical one. Spheres are a good example. In any case meshes are not useful at all for the physics engine. Meshes are solely a way to represent the objects graphically. This is exactly why sculpted prims have dodgy physics. There's no way to represent it mathematically so the physical object is not at all alike the visible object. Dirk aka Blakar Ogre From nik at terminaldischarge.net Thu Sep 20 02:03:51 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Thu Sep 20 02:04:11 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709200159tf3dbda3p1c6847d2be65b379@mail.gmail.com> References: <200709201042.40855.dale@daleglass.net> <49500.86.10.79.229.1190278165.squirrel@webmail.terminaldischarge.net> <7992d0d60709200159tf3dbda3p1c6847d2be65b379@mail.gmail.com> Message-ID: <49582.86.10.79.229.1190279031.squirrel@webmail.terminaldischarge.net> >> > In fact, I thought this was a major reason to use the prims concept: >> If >> > you >> > specify the shape and its characteristics instead of a mesh you can >> > generate as few or many triangles as you want (scaling with available >> > processing power) and calculate collisions much more efficiently. >> >> What happens if the sphere a dimple or has been turned into a torus? >> What happens if the sphere is cut? >> The reason for prims, was so they could send shapes that, even after >> some >> fiddling, might have complex meshs, as just a few parameters across the >> network. Rather than 100's of vertices, they send 20ish parameters. >> Lowering network bandwidth usuage and allowing the streaming of objects >> you see. > > The physical simulation and the graphical representation do not match > at all times. If the math for the physical representation is too > complex it'll revert to using a shape that approximates what we see. > Similarly the visible representation may be less correct than the > physical one. Spheres are a good example. > > In any case meshes are not useful at all for the physics engine. > Meshes are solely a way to represent the objects graphically. This is > exactly why sculpted prims have dodgy physics. There's no way to > represent it mathematically so the physical object is not at all alike > the visible object. > > Dirk aka Blakar Ogre > *chuckles* I'll just shut my mouth now shall I? :P Thanks for that :) Nik From kerdezixe at gmail.com Thu Sep 20 03:17:49 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Sep 20 03:17:52 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709200159tf3dbda3p1c6847d2be65b379@mail.gmail.com> References: <200709201042.40855.dale@daleglass.net> <49500.86.10.79.229.1190278165.squirrel@webmail.terminaldischarge.net> <7992d0d60709200159tf3dbda3p1c6847d2be65b379@mail.gmail.com> Message-ID: <8a1bfe660709200317n19a8d63n4a512f34956c3f66@mail.gmail.com> On 9/20/07, Dirk Moerenhout wrote: > > The physical simulation and the graphical representation do not match > at all times. If the math for the physical representation is too > complex it'll revert to using a shape that approximates what we see. > Similarly the visible representation may be less correct than the > physical one. Spheres are a good example. > > In any case meshes are not useful at all for the physics engine. > Meshes are solely a way to represent the objects graphically. This is > exactly why sculpted prims have dodgy physics. There's no way to > represent it mathematically so the physical object is not at all alike > the visible object. I seen (and used) racetrack in SL using 2x10x10 hollowed cylinder for the track, Like a very flattened halfpipe. How is it handled physically, if not triangle per triangle ? -- kerunix Flan From gigstaggart at gmail.com Thu Sep 20 04:09:17 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Sep 20 04:09:20 2007 Subject: [sldev] [PATCH] Presence notifications in IM windows Message-ID: <46F254DD.9010308@gmail.com> http://jira.secondlife.com/browse/VWR-1484 From tao.takashi at googlemail.com Thu Sep 20 04:12:53 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Thu Sep 20 04:12:56 2007 Subject: [sldev] [PATCH] Presence notifications in IM windows In-Reply-To: <46F254DD.9010308@gmail.com> References: <46F254DD.9010308@gmail.com> Message-ID: <23bbb49e0709200412i2df73d5etb423020ffcd38c0e@mail.gmail.com> 2007/9/20, Jason Giglio : > > http://jira.secondlife.com/browse/VWR-1484 Gigs++ :-) -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070920/a972cf53/attachment.htm From dale at daleglass.net Thu Sep 20 04:20:48 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 04:20:54 2007 Subject: [sldev] LLUUIDHashMap vs hash_map Message-ID: <20070920112048.GA6313@bruno.sbruno> I'm looking at implementing a cache storing data by LLUUID and found the LLUUIDHashMap. I see it seems to be used only in LLMotionRegistry. Should I use it? How about making a hash function for LLUUID and using that instead? I presume that simply using the first/last sizeof(size_t)*8 bits of the LLUUID would work fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/d648beac/attachment.pgp From mdepascale at dii.unisi.it Thu Sep 20 05:27:15 2007 From: mdepascale at dii.unisi.it (Maurizio de Pascale) Date: Thu Sep 20 05:27:35 2007 Subject: [sldev] Getting position and mesh data for objects Message-ID: <46F26723.10708@dii.unisi.it> Hi, I'm interested into getting access to position and mesh data for objects close to the agent. I've found the getPositionGlobal() and getPositionAgent() methods on the gAgent and gObjectList.getObject(i) globals. Is this the correct way to get position for agent and objects, right? Yet I'm having no success to find mesh data :( I've noticed the getNumVertices() and getNumIndices() methods, but can't find a way to get to the actual vertices and triangles. can anyone point me to the right direction? Thank you, Maurizio de Pascale mdepascale@dii.unisi.it From dale at daleglass.net Thu Sep 20 05:52:36 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 05:52:42 2007 Subject: [sldev] LLUUIDHashMap vs hash_map In-Reply-To: <20070920112048.GA6313@bruno.sbruno> References: <20070920112048.GA6313@bruno.sbruno> Message-ID: <20070920125236.GB6313@bruno.sbruno> On Thu, Sep 20, 2007 at 01:20:48PM +0200, Dale Glass wrote: > I'm looking at implementing a cache storing data by LLUUID and found the > LLUUIDHashMap. I see it seems to be used only in LLMotionRegistry. > > Should I use it? How about making a hash function for LLUUID and using > that instead? I presume that simply using the first/last > sizeof(size_t)*8 bits of the LLUUID would work fine. Been looking a bit more at the source of LLUUIDHashMap, it's weird. It's hardcoded to 256 buckets, not even as a constant but as a magic number in the source (ick!) It uses an U8 for the hash key, so it can't go higher anyway. LLUUIDHashNode stores a number of elements that varies depending on the argument to the template (why?) So I'm thinking a hash_map could be better for my purposes, as I might want more than 256 elements (cache will probably be quite big). For the hash function I'm considering this: size_t operator()(const LLUUID&x) { return (size_t)x.getCRC32(); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/6caf97a3/attachment.pgp From doug at lindenlab.com Thu Sep 20 07:31:29 2007 From: doug at lindenlab.com (Douglas Soo) Date: Thu Sep 20 07:33:31 2007 Subject: [sldev] LLUUIDHashMap vs hash_map In-Reply-To: <20070920125236.GB6313@bruno.sbruno> References: <20070920112048.GA6313@bruno.sbruno> <20070920125236.GB6313@bruno.sbruno> Message-ID: <5952CC72E8BC270C1EB31BDC@[192.168.254.9]> The LLUUIDHashMap is an EXTREMELY specialized hash map that was primarily designed for extremely fast lookup and iteration over a map of objects keyed by UUIDs - specifically for the simulator, which spends a lot of its time iterating over lists of this type (looking up and iterating through objects and scripts on the simulator). Unless you are iterating or looking through objects EXTREMELY often (enough to show up as more than a couple percent of time in a time-based profile), I would stay far away from it. It doesn't use any of the standard STL semantics for iteration, and is assuredly not thread-safe, or anything else that you'd really like. In fact, unless there are performance or memory utilization reasons, I would convert the existing code away from using it. Also, hash_map isn't part of the official STL standard, so even though it's in common usage, I would stay away from it for portability reasons. So, I would stick with a standard map unless you really need to iterate or look things up extremely frequently (> 10000 times/frame). More about LLUUIDHashMap (for the interested): The biggest performance bottleneck (by far) on most modern hardware is memory access - so all of the weird implementation of the LLUUIDHashMap is an attempt by me to reduce the number of times you have to do pointer dereferences, and reduce the resulting cache misses. It's also pretty much entirely optimized to work with the number of objects/scripts that you typically see on a region, so it's tuned to work well for on the order of 10s of thousands of elements - it will typically reduce the number of pointer dereferences to only 2 or 3 to get an item in the hash. It also takes advantage of the essentially randomized bits in the UUID to reduce the amount of work being done to hash the elements. It's an interesting exercise in profiling to optimize something like this - this is where timing-based profilers make a HUGE difference. There was extensive profiling done against this implementation to optimize it. When running synthetic benchmarks against std::map, it was substantially (at least 50%?) faster for both random lookups and iteration. It was also being timed against our legacy containers (LLSkipMap), which were even slower at the time (and buggier). We didn't look at hash_map for the aforementioned compatibility reasons. That being said, this was written to improve the performance of some very specific inner loops on the simulator code. If I remember correctly, we probably got around a 10% improvement in overall simulator performance by switching to this from the previous implementation. - Doug --On Thursday, September 20, 2007 2:52 PM +0200 Dale Glass wrote: > On Thu, Sep 20, 2007 at 01:20:48PM +0200, Dale Glass wrote: >> I'm looking at implementing a cache storing data by LLUUID and found the >> LLUUIDHashMap. I see it seems to be used only in LLMotionRegistry. >> >> Should I use it? How about making a hash function for LLUUID and using >> that instead? I presume that simply using the first/last >> sizeof(size_t)*8 bits of the LLUUID would work fine. > > Been looking a bit more at the source of LLUUIDHashMap, it's weird. > > It's hardcoded to 256 buckets, not even as a constant but as a magic > number in the source (ick!) > > It uses an U8 for the hash key, so it can't go higher anyway. > > LLUUIDHashNode stores a number of elements that varies depending on the > argument to the template (why?) > > > So I'm thinking a hash_map could be better for my purposes, as I might > want more than 256 elements (cache will probably be quite big). > > For the hash function I'm considering this: > > size_t operator()(const LLUUID&x) > { > return (size_t)x.getCRC32(); > } > > -- Douglas Soo Studio Director Linden Lab From dale at daleglass.net Thu Sep 20 08:28:40 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 08:28:53 2007 Subject: [sldev] Re: LLUUIDHashMap vs hash_map In-Reply-To: <5952CC72E8BC270C1EB31BDC@[192.168.254.9]> References: <20070920112048.GA6313@bruno.sbruno> <20070920125236.GB6313@bruno.sbruno> <5952CC72E8BC270C1EB31BDC@[192.168.254.9]> Message-ID: <200709201728.45371.dale@daleglass.net> On Thursday 20 September 2007 16:31:29 Douglas Soo wrote: > Unless you are iterating or looking through objects EXTREMELY often > (enough to show up as more than a couple percent of time in a time-based > profile), I would stay far away from it. It doesn't use any of the > standard STL semantics for iteration, and is assuredly not thread-safe, > or anything else that you'd really like. In fact, unless there are > performance or memory utilization reasons, I would convert the existing > code away from using it. > > Also, hash_map isn't part of the official STL standard, so even though > it's in common usage, I would stay away from it for portability reasons. > So, I would stick with a standard map unless you really need to iterate > or look things up extremely frequently (> 10000 times/frame). I'm looking at implementing a cache of object owners, to implement several features on top of that. Current uses: Muting everything owned by an avatar when the avatar is muted. Keeping the info for my particle sources list (grid sends owner data for those IIRC) Visible object search by owner, to allow people to find things like griefer cubes without having to have the corresponding land privileges. All that shouldn't be anywhere near your 10000 times/frame figure, so I'll go with the map, then. I know hash_map isn't standard, but I thought to use it because I thought it was used in the source, although turns out I didn't look well enough. It's #included in llstringtable.h and llhash.h but doesn't seem to be actually used anywhere. I'll put a patch on jira to remove those then. > > More about LLUUIDHashMap (for the interested): > [snip] Thanks a lot, that was very interesting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/367d17a3/attachment-0001.pgp From secret.argent at gmail.com Thu Sep 20 08:44:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 20 08:44:56 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <20070920085908.155BC41AEAF@stupor.lindenlab.com> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> Message-ID: <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> From: "Dirk Moerenhout" > Meshes are solely a way to represent the objects graphically. This is > exactly why sculpted prims have dodgy physics. There's no way to > represent it mathematically so the physical object is not at all alike > the visible object. Sculpted prims have dodgy physics because the sim is not using the sculpt texture to calculate their shape yet. Whether the mesh is hard to simulate or not isn't relevant... the mesh isn't actually being used at all by the sim. From comments Qarl has made they are intending to use the actual mesh at some point, but right now all sculpted prims are treated as spheres by the sim. From odysseus654 at gmail.com Thu Sep 20 09:07:49 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Thu Sep 20 09:07:52 2007 Subject: [sldev] [VWR] Crashes in C++ STL functions In-Reply-To: <200709201048.21890.dale@daleglass.net> References: <68434DD1-2B71-400A-8E75-900EBBFB72FA@mm.st> <200709201048.21890.dale@daleglass.net> Message-ID: <1674f6c70709200907r2ac05fc5qa57f4b7a43faf39@mail.gmail.com> To add to this, I ran into an STL crashing bug in a destructor recently and figured out that the destructor was getting called twice. An STL collection should never contain NULL references inside of itself... On 9/20/07, Dale Glass wrote: > > On Thursday 20 September 2007 07:47:03 Ben Byer wrote: > > ... etc. I'd be happy to dig into these crashes more, but I don't > > really even know where to begin -- I don't know where to find the code > > that implements the crashing functions. Help! > > -b > Crashes in the STL are like crashes in malloc: A real bug in the STL or > malloc would be a very rare thing. The most likely reason for a crash > there is that the code calling the STL function or malloc screwed > something up, and then the function you called choked on it. > > At first glance, I see there in the stack: LLImageGL::~LLImageGL. This > means something went wrong in the destructor. You could start by checking > what that destructor does and what could go wrong in it. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070920/af70ddec/attachment.htm From blakar at gmail.com Thu Sep 20 10:22:41 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Sep 20 10:22:44 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> Message-ID: <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> On 9/20/07, Argent Stonecutter wrote: > From: "Dirk Moerenhout" > > Meshes are solely a way to represent the objects graphically. This is > > exactly why sculpted prims have dodgy physics. There's no way to > > represent it mathematically so the physical object is not at all alike > > the visible object. > > Sculpted prims have dodgy physics because the sim is not using the > sculpt texture to calculate their shape yet. Whether the mesh is hard > to simulate or not isn't relevant... the mesh isn't actually being > used at all by the sim. From comments Qarl has made they are > intending to use the actual mesh at some point, but right now all > sculpted prims are treated as spheres by the sim. You have rather strange logic and I guess you didn't get what I was implying. I know it's a sphere so let me put it this way: They are using a sphere to represent it because it's too complicated to simulate the mesh. If you truly believe the mesh complexity does not matter then I'd really want to know what you consider the reason to opt for a sphere. As for using the detailed mesh I wouldn't take bets on it if I were you. You can use it if you downsample it but that it'll remain a rough representation. Best bet is to calculate Bezier curves that match the shape best. But still the most important part is: you need a mathematical representation, not a triangulated result. Dirk aka Blakar Ogre From nik at terminaldischarge.net Thu Sep 20 10:42:29 2007 From: nik at terminaldischarge.net (Nik Radford) Date: Thu Sep 20 10:40:55 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com><0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> Message-ID: <52ED71DBFF914B53AEE3AE99D45A3267@printingsolutions.co.uk> ----- Original Message ----- From: "Dirk Moerenhout" To: "Argent Stonecutter" Cc: Sent: Thursday, September 20, 2007 6:22 PM Subject: Re: [sldev] [ATTN-LL] Physics engine status update? > On 9/20/07, Argent Stonecutter wrote: >> From: "Dirk Moerenhout" >> > Meshes are solely a way to represent the objects graphically. This is >> > exactly why sculpted prims have dodgy physics. There's no way to >> > represent it mathematically so the physical object is not at all alike >> > the visible object. >> >> Sculpted prims have dodgy physics because the sim is not using the >> sculpt texture to calculate their shape yet. Whether the mesh is hard >> to simulate or not isn't relevant... the mesh isn't actually being >> used at all by the sim. From comments Qarl has made they are >> intending to use the actual mesh at some point, but right now all >> sculpted prims are treated as spheres by the sim. > > You have rather strange logic and I guess you didn't get what I was > implying. I know it's a sphere so let me put it this way: > They are using a sphere to represent it because it's too complicated > to simulate the mesh. > > If you truly believe the mesh complexity does not matter then I'd > really want to know what you consider the reason to opt for a sphere. > > As for using the detailed mesh I wouldn't take bets on it if I were > you. You can use it if you downsample it but that it'll remain a rough > representation. Best bet is to calculate Bezier curves that match the > shape best. But still the most important part is: you need a > mathematical representation, not a triangulated result. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev Triangles are often used when needing exact collision. Maths can be used on two meshes of triangles to determine collisions. It can all be mathimatically represented. The triangles are the data, and mathimatical function are applied to that data. Just like maths is used to display the triangles, maths can be used on the triangles in any number of ways. Simple bounding boxes and spheres are the simplist of collisions because the representation of them is a considerable less effort to calculate for than meshs. But meshs can be, and are used in collision detection, the can be used as to calculate the theoretical centre of mass for an object, assuming each part of its volume has an equal mass. Think games like half-life, where a wall has been modeled in the world to have a odd shaped hole blown through it. Though the players collision is treated as a bounding box, the wall is not. Collision on BSP's pretty quick to determine due to the nature of being able to singlw out the vertexs, vertices and triangles involved in an extreamly quick fashion, but its still done on triangles. If a physics engine wants to accuratly simulate collisions on an object it will do it, on triangle basis. Perhaps originally using bounding spheres and bounding boxes, to narrow down the triangles it should check, but it will still check them. By the way, I'm not aiming this at anyone. And I apologize if I've appeared to ramble From secret.argent at gmail.com Thu Sep 20 10:43:54 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 20 10:44:14 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> Message-ID: <9589910B-87F5-4311-9B3B-032D934BDD3E@gmail.com> On 20-Sep-2007, at 12:22, Dirk Moerenhout wrote: > If you truly believe the mesh complexity does not matter then I'd > really want to know what you consider the reason to opt for a sphere. I didn't claim mesh complexity doesn't matter. I'm not arguing against your post, even. I'm just correcting a technical point. The problems with sculpties originate in the fact that the implementation is not nearly complete. It's not just the physics: the implementation is missing promised functionality in the LSL interface (you can't even query sculpt parameters yet... thy come back as a donut), in the user interface (you can't set some of the sculpt parameters in the editor at all), and in the features (like flexibility and animation). This isn't something I'm making up, this is all from Qarl Linden. Sculpties are a "work in progress" far more than most things in Second Life. He has said that they will eventually have an actual approximation of the shape of sculpties in the sim, what it's currently got is a stopgap. From lenglish5 at cox.net Thu Sep 20 10:44:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 10:44:51 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> Message-ID: <46F2B191.2090302@cox.net> Dirk Moerenhout wrote: > On 9/20/07, Argent Stonecutter wrote: > >> From: "Dirk Moerenhout" >> >>> Meshes are solely a way to represent the objects graphically. This is >>> exactly why sculpted prims have dodgy physics. There's no way to >>> represent it mathematically so the physical object is not at all alike >>> the visible object. >>> >> Sculpted prims have dodgy physics because the sim is not using the >> sculpt texture to calculate their shape yet. Whether the mesh is hard >> to simulate or not isn't relevant... the mesh isn't actually being >> used at all by the sim. From comments Qarl has made they are >> intending to use the actual mesh at some point, but right now all >> sculpted prims are treated as spheres by the sim. >> > > You have rather strange logic and I guess you didn't get what I was > implying. I know it's a sphere so let me put it this way: > They are using a sphere to represent it because it's too complicated > to simulate the mesh. > > If you truly believe the mesh complexity does not matter then I'd > really want to know what you consider the reason to opt for a sphere. > > As for using the detailed mesh I wouldn't take bets on it if I were > you. You can use it if you downsample it but that it'll remain a rough > representation. Best bet is to calculate Bezier curves that match the > shape best. But still the most important part is: you need a > mathematical representation, not a triangulated result. > > > At this point, you are correct. However, with later versions of Havok, especially 4+, things are allegedly more efficient than what SL currently uses, and you can use simpler representations of the mesh if need be, for speed. http://www.havok.com/misc/physicsEfficiency-2007.pdf The REAL question is: will LL go with Havok 5, which is now out? http://www.havok.com/content/view/538/53/ From bos at lindenlab.com Thu Sep 20 10:57:13 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Sep 20 10:57:16 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <46F2B191.2090302@cox.net> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> <46F2B191.2090302@cox.net> Message-ID: <46F2B479.3000900@lindenlab.com> Lawson English wrote: > The REAL question is: will LL go with Havok 5, which is now out? > > http://www.havok.com/content/view/538/53/ Definitely not any time in the nearish future. Havok 4 is close to release, and I'm sure we'll have plenty of fun stabilising it without worrying about a version bump. References: <20070919154125.427F141B30D@stupor.lindenlab.com> Message-ID: <3ABF4BC2-A401-4E4D-BE23-80ED49115F10@gmail.com> Going back to the original quote... > Meta Linden: In fact het-grid *is* helping- already. We are rolling > the new > physics engine onto some sims on the main grid *today*. Which sims? :) From Kindragon at comcast.net Thu Sep 20 13:11:22 2007 From: Kindragon at comcast.net (Obsidian Kindragon) Date: Thu Sep 20 13:11:09 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <3ABF4BC2-A401-4E4D-BE23-80ED49115F10@gmail.com> References: <20070919154125.427F141B30D@stupor.lindenlab.com> <3ABF4BC2-A401-4E4D-BE23-80ED49115F10@gmail.com> Message-ID: <46F2D3EA.4070409@comcast.net> Argent Stonecutter wrote: > Going back to the original quote... >> Meta Linden: In fact het-grid *is* helping- already. We are rolling >> the new >> physics engine onto some sims on the main grid *today*. > > Which sims? :) Yeah! What SIMs? I want to test out my new rocket lau... errr, "swingset". - Obsidian Stormwind From lee at lindenlab.com Thu Sep 20 13:16:01 2007 From: lee at lindenlab.com (Lee Linden) Date: Thu Sep 20 13:18:04 2007 Subject: [sldev] Source release for RC 1.18.3.5 Message-ID: <46F2D501.9060707@lindenlab.com> Release Candidate 1.18.3.5 source release is now available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.3.5 Checksums: 4579b573fe50f5248558b907804bd2d2 slviewer-darwin-libs-RC-1.18.3.5.tar.gz dabe7b697061d37e00f27abfb74b7ad3 slviewer-linux-libs-RC-1.18.3.5.tar.gz d1eb0b1e76c52c57182dc42b8a0c4333 slviewer-src-RC-1.18.3.5.tar.gz a5e99446ddf1265ef3470634292c42bf slviewer-artwork-RC-1.18.3.5.zip 86c66390a27cd29e07cc4f6b3b1427bb slviewer-src-RC-1.18.3.5.zip 47d6b7944afa3ccae1384bc531edfefb slviewer-win32-libs-RC-1.18.3.5.zip SVN checkout: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-3-Viewer/ From rdw at lindenlab.com Thu Sep 20 13:45:13 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Sep 20 13:45:14 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <46F2D3EA.4070409@comcast.net> References: <20070919154125.427F141B30D@stupor.lindenlab.com> <3ABF4BC2-A401-4E4D-BE23-80ED49115F10@gmail.com> <46F2D3EA.4070409@comcast.net> Message-ID: <46F2DBD9.7070104@lindenlab.com> Obsidian Kindragon wrote: > Argent Stonecutter wrote: >> Going back to the original quote... >>> Meta Linden: In fact het-grid *is* helping- already. We are rolling >>> the new >>> physics engine onto some sims on the main grid *today*. I'm pretty sure that this is not true. There are several showstopper bugs on Havok. Possibly the plan that day was to do what Meta said, but it was interrupted by the discovery of said bugs. -RYaN From blakar at gmail.com Thu Sep 20 13:45:55 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Sep 20 13:45:58 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <46F2B191.2090302@cox.net> References: <20070920085908.155BC41AEAF@stupor.lindenlab.com> <0846255B-09EA-48A4-A980-D4DE7DCBEE46@gmail.com> <7992d0d60709201022h29664c0etefc7089c1d26e99d@mail.gmail.com> <46F2B191.2090302@cox.net> Message-ID: <7992d0d60709201345o44c31e30vbc2bfcad52148544@mail.gmail.com> > At this point, you are correct. However, with later versions of Havok, > especially 4+, things are allegedly more efficient than what SL > currently uses, and you can use simpler representations of the mesh if > need be, for speed. > > http://www.havok.com/misc/physicsEfficiency-2007.pdf That PDF is good, thanks! What I was mostly aiming for but can't obviously explain as eloquently as somebody actually working a lot on the subject is "Choice of complexity Part 2: Sharing data or not?" In SL I see little reason to share data. It's good to share if you have it but we're discussing physics on the server side and off course there's no dual data as the sim has no reason to triangulate all the prims as it's not representing them graphically. For sculpted prims we'll have to find some sort of solution obviously. An interpolated mesh could be a consideration although I fear it would do it little justice in several cases because the interpolation meshes aren't always great (as we can see with LOD on sculpted prims). It might be a good sideproject though. Someone can try to come up with a system that converts sculpted prims in convex objects. Ideally as few objects as possible. Dirk aka Blakar Ogre From robla at lindenlab.com Thu Sep 20 13:47:51 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 20 13:47:57 2007 Subject: [sldev] New version of Vivox-SLVoice documentation uploaded to JIRA Message-ID: <46F2DC77.6010700@lindenlab.com> Hi folks, Rather than distributing on this list, I've uploaded new documentation to this jira task: https://jira.secondlife.com/browse/VWR-2029 The main difference is a less restrictive copyright notice, quoted here: > By releasing the specification to the SLVoice interfaces, we hope to > take another step to help you better > utilize the voice and communications services Vivox provides. We look > forward to working with and > getting feedback from the Second Life Community regarding ways in > which Vivox can enrich and expand > communications in Second Life in a scalable, high-quality manner. > > This manual, including its content and any portion thereof > (collectively, the ?Content?), is a work protected > by copyright and is the sole and exclusive property of Vivox, Inc. > (?Vivox?). > The Content is provided ``as is?? and without any expressed or implied > warranties. In no event will Vivox > be liable for any direct, indirect, incidental, special, exemplary, or > consequential damages, however > caused and on any theory of liability, whether in contract, strict > liability, or tort (including negligence or > otherwise) arising in any way out of the use of the Content, even if > advised of the possibility of such > damages. > > You can provide feedback regarding issues or suggestions related to > this document its use by sending > email to sl-feedback@vivox.com, Sorry for sending the doc as an attachment last time.....it didn't occur to me to attach in JIRA, and I didn't want to put it on the wiki for fear that people would assume the notice there applied. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/7d640431/signature.pgp From blakar at gmail.com Thu Sep 20 14:09:40 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Sep 20 14:09:43 2007 Subject: [sldev] Re: LLUUIDHashMap vs hash_map In-Reply-To: <200709201728.45371.dale@daleglass.net> References: <20070920112048.GA6313@bruno.sbruno> <20070920125236.GB6313@bruno.sbruno> <5952CC72E8BC270C1EB31BDC@192.168.254.9> <200709201728.45371.dale@daleglass.net> Message-ID: <7992d0d60709201409y10b491f0k746db88ba579153a@mail.gmail.com> Be careful: The includes are part of llcommon which is also used to build the simulators. As you can see in Douglas' mail it was written for the simulator. As such it should not be removed even though the client is not using it. On 9/20/07, Dale Glass wrote: > It's #included in llstringtable.h and llhash.h but doesn't seem to be > actually used anywhere. I'll put a patch on jira to remove those then. On 9/20/07, Douglas Soo wrote: > The LLUUIDHashMap is an EXTREMELY specialized hash map that was primarily > designed for extremely fast lookup and iteration over a map of objects > keyed by UUIDs - specifically for the simulator, Dirk aka Blakar Ogre From jhurliman at wsu.edu Thu Sep 20 14:44:41 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Sep 20 14:46:01 2007 Subject: [sldev] New version of Vivox-SLVoice documentation uploaded to JIRA In-Reply-To: <46F2DC77.6010700@lindenlab.com> References: <46F2DC77.6010700@lindenlab.com> Message-ID: <46F2E9C9.8030804@wsu.edu> Rob Lanphier wrote: > Hi folks, > > Rather than distributing on this list, I've uploaded new documentation > to this jira task: > https://jira.secondlife.com/browse/VWR-2029 > > The main difference is a less restrictive copyright notice, quoted here: > >> By releasing the specification to the SLVoice interfaces, we hope to >> take another step to help you better >> utilize the voice and communications services Vivox provides. We look >> forward to working with and >> getting feedback from the Second Life Community regarding ways in >> which Vivox can enrich and expand >> communications in Second Life in a scalable, high-quality manner. >> >> This manual, including its content and any portion thereof >> (collectively, the ?Content?), is a work protected >> by copyright and is the sole and exclusive property of Vivox, Inc. >> (?Vivox?). >> The Content is provided ``as is?? and without any expressed or implied >> warranties. In no event will Vivox >> be liable for any direct, indirect, incidental, special, exemplary, or >> consequential damages, however >> caused and on any theory of liability, whether in contract, strict >> liability, or tort (including negligence or >> otherwise) arising in any way out of the use of the Content, even if >> advised of the possibility of such >> damages. >> >> You can provide feedback regarding issues or suggestions related to >> this document its use by sending >> email to sl-feedback@vivox.com, >> > > Sorry for sending the doc as an attachment last time.....it didn't occur > to me to attach in JIRA, and I didn't want to put it on the wiki for > fear that people would assume the notice there applied. > > Rob > Wow, many thanks! So I guess this error I've been getting (20202) is "missing credentials". I must be sending a malformed login or something, I'll take a look in to it and start up on the voice development again soon. John Hurliman From robla at lindenlab.com Thu Sep 20 15:28:35 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 20 15:28:45 2007 Subject: [sldev] jira.secondlife.com downtime tomorrow, 9am PDT Message-ID: <46F2F413.7050208@lindenlab.com> Hi all, jira.secondlife.com will be down starting tomorrow at 9am for approximately 30 minutes while we futz with it. With any luck, we'll have a partial solution for WEB-58 (Fix this JIRA's email capability), though it probably won't be turned on immediately after the fix. If you've never logged into jira.secondlife.com, now is a good time to do it, because what we'll be doing is taking a snapshot of everyone who had logged into jira at some point, and populating those email addresses. Everyone who logs in for the first time after that snapshot will need to wait until a following snapshot at a time TBD, or until we get the permasolution in place. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/7f9ba8d7/signature.pgp From anthony at lindenlab.com Thu Sep 20 15:51:45 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Sep 20 15:51:48 2007 Subject: [sldev] Source release for release branch 2007-Sep-20 In-Reply-To: <46EB1A45.3070206@lindenlab.com> References: <46E08CB4.4070909@lindenlab.com> <46EB1A45.3070206@lindenlab.com> Message-ID: <46F2F981.7000402@lindenlab.com> Hey Everyone, Here's the next installment of the release branch's dated snapshot. Release branch source available here: https://wiki.secondlife.com/wiki/Source_downloads#2007-Sep-20 Checksums: eff62e42af3e7320ee8691e1693e3ad9 slviewer-darwin-libs-20070920a.tar.gz 1b4a2f7e54ffc372df857bb400a24514 slviewer-linux-libs-20070920a.tar.gz 2adec2cd5193d0a45138795b4e87ad00 slviewer-src-20070920a.tar.gz 00663e3f4993f6aa040f32dbee6d2042 slviewer-artwork-20070920a.zip 175567a678eb48e25000d2393d5980f8 slviewer-src-20070920a.zip 97484c3db7da71cec9fa785e18665bc8 slviewer-win32-libs-20070920a.zip SVN checkout: Robla will send email when this is available. Enjoy. -Anthony From lenglish5 at cox.net Thu Sep 20 16:13:09 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 16:13:12 2007 Subject: [sldev] Source release for release branch 2007-Sep-20 In-Reply-To: <46F2F981.7000402@lindenlab.com> References: <46E08CB4.4070909@lindenlab.com> <46EB1A45.3070206@lindenlab.com> <46F2F981.7000402@lindenlab.com> Message-ID: <46F2FE85.5060304@cox.net> Anthony Foster wrote: > Hey Everyone, > > Here's the next installment of the release branch's dated snapshot. > > Release branch source available here: > https://wiki.secondlife.com/wiki/Source_downloads#2007-Sep-20 > > Checksums: > > eff62e42af3e7320ee8691e1693e3ad9 slviewer-darwin-libs-20070920a.tar.gz > 1b4a2f7e54ffc372df857bb400a24514 slviewer-linux-libs-20070920a.tar.gz > 2adec2cd5193d0a45138795b4e87ad00 slviewer-src-20070920a.tar.gz > 00663e3f4993f6aa040f32dbee6d2042 slviewer-artwork-20070920a.zip > 175567a678eb48e25000d2393d5980f8 slviewer-src-20070920a.zip > 97484c3db7da71cec9fa785e18665bc8 slviewer-win32-libs-20070920a.zip I'm still continuing my experimentation/development-of-patches on the source for 1.18.3(4). Is this the best way to go? My understanding is that these interim source releases are not necessarily meant for using/development? Thanks. L. From secret.argent at gmail.com Thu Sep 20 16:36:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 20 16:36:24 2007 Subject: [sldev] Source release for RC 1.18.3.5 (Lee Linden) In-Reply-To: <20070920225155.95F9B41B002@stupor.lindenlab.com> References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: Wow. That hasn't even shown up on http://secondlife.com/community/ downloads-optional.php yet! From labrat.hb at gmail.com Thu Sep 20 16:52:05 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Sep 20 16:52:08 2007 Subject: [sldev] Source release for RC 1.18.3.5 (Lee Linden) In-Reply-To: References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: http://s3.amazonaws.com/release-candidate-secondlife-com/Second%20Life%201-18-3-5%20Release%20Candidate%20Setup.exe Someone forgot to update the links / make a blog post. On 9/20/07, Argent Stonecutter wrote: > > Wow. That hasn't even shown up on http://secondlife.com/community/ > downloads-optional.php yet! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070920/ac664e5f/attachment.htm From nicholaz at blueflash.cc Thu Sep 20 16:55:01 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Sep 20 16:55:25 2007 Subject: [sldev] Source release for release branch 2007-Sep-20 In-Reply-To: <46F2FE85.5060304@cox.net> References: <46E08CB4.4070909@lindenlab.com> <46EB1A45.3070206@lindenlab.com> <46F2F981.7000402@lindenlab.com> <46F2FE85.5060304@cox.net> Message-ID: <46F30855.5020403@blueflash.cc> I have a viewer build released based on 3(4). Checked the source changes for 3(5) today, it's just two screen pages (mainly the security fix). I'm attaching the diff if anyone wants to look or apply. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- diff -urN -X srcdiff.ind --strip-trailing-cr sl1_18_3_4\linden-orig\indra/llcommon/llversionviewer.h sl1_18_3_5\linden-orig\indra/llcommon/llversionviewer.h --- sl1_18_3_4\linden-orig\indra/llcommon/llversionviewer.h 2007-09-14 13:56:54.000000000 +0200 +++ sl1_18_3_5\linden-orig\indra/llcommon/llversionviewer.h 2007-09-20 12:36:46.000000000 +0200 @@ -32,7 +32,7 @@ const S32 LL_VERSION_MAJOR = 1; const S32 LL_VERSION_MINOR = 18; const S32 LL_VERSION_PATCH = 3; -const S32 LL_VERSION_BUILD = 4; +const S32 LL_VERSION_BUILD = 5; const char * const LL_CHANNEL = "Second Life Release"; diff -urN -X srcdiff.ind --strip-trailing-cr sl1_18_3_4\linden-orig\indra/newview/Info-SecondLife.plist sl1_18_3_5\linden-orig\indra/newview/Info-SecondLife.plist --- sl1_18_3_4\linden-orig\indra/newview/Info-SecondLife.plist 2007-09-14 13:56:56.000000000 +0200 +++ sl1_18_3_5\linden-orig\indra/newview/Info-SecondLife.plist 2007-09-20 12:36:50.000000000 +0200 @@ -32,7 +32,7 @@ CFBundleVersion - 1.18.3.4 + 1.18.3.5 CSResourcesFileMapped diff -urN -X srcdiff.ind --strip-trailing-cr sl1_18_3_4\linden-orig\indra/newview/llstartup.cpp sl1_18_3_5\linden-orig\indra/newview/llstartup.cpp --- sl1_18_3_4\linden-orig\indra/newview/llstartup.cpp 2007-09-14 13:56:58.000000000 +0200 +++ sl1_18_3_5\linden-orig\indra/newview/llstartup.cpp 2007-09-20 12:36:50.000000000 +0200 @@ -568,7 +568,10 @@ #endif // LL_LINUX std::ostringstream codec; - codec << "[Second Life " << LL_VERSION_MAJOR << "." << LL_VERSION_MINOR << "." << LL_VERSION_PATCH << "." << LL_VERSION_BUILD << "]"; + codec << "[Second Life "; + codec << "(" << gChannelName << ")"; + codec << " - " << LL_VERSION_MAJOR << "." << LL_VERSION_MINOR << "." << LL_VERSION_PATCH << "." << LL_VERSION_BUILD; + codec << "]"; LLMozLib::getInstance()->setBrowserAgentId( codec.str() ); #endif @@ -2633,7 +2636,7 @@ #if !LL_RELEASE_FOR_DOWNLOAD if (option == 2) { - LLStartUp::setStartupState( STATE_WORLD_INIT ); + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); return; } #endif @@ -2649,7 +2652,7 @@ } else { - LLStartUp::setStartupState( STATE_WORLD_INIT ); + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); } return; } diff -urN -X srcdiff.ind --strip-trailing-cr sl1_18_3_4\linden-orig\indra/newview/res/newViewRes.rc sl1_18_3_5\linden-orig\indra/newview/res/newViewRes.rc --- sl1_18_3_4\linden-orig\indra/newview/res/newViewRes.rc 2007-09-14 13:56:58.000000000 +0200 +++ sl1_18_3_5\linden-orig\indra/newview/res/newViewRes.rc 2007-09-20 12:36:50.000000000 +0200 @@ -227,8 +227,8 @@ // VS_VERSION_INFO VERSIONINFO - FILEVERSION 1,18,3,4 - PRODUCTVERSION 1,18,3,4 + FILEVERSION 1,18,3,5 + PRODUCTVERSION 1,18,3,5 FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L @@ -245,12 +245,12 @@ BEGIN VALUE "CompanyName", "Linden Lab" VALUE "FileDescription", "Second Life" - VALUE "FileVersion", "1.18.3.4" + VALUE "FileVersion", "1.18.3.5" VALUE "InternalName", "Second Life" VALUE "LegalCopyright", "Copyright ? 2001-2007, Linden Research, Inc." VALUE "OriginalFilename", "SecondLife.exe" VALUE "ProductName", "Second Life" - VALUE "ProductVersion", "1.18.3.4" + VALUE "ProductVersion", "1.18.3.5" END END BLOCK "VarFileInfo" diff -urN -X srcdiff.ind --strip-trailing-cr sl1_18_3_4\linden-orig\indra/newview/viewer.cpp sl1_18_3_5\linden-orig\indra/newview/viewer.cpp --- sl1_18_3_4\linden-orig\indra/newview/viewer.cpp 2007-09-14 13:56:58.000000000 +0200 +++ sl1_18_3_5\linden-orig\indra/newview/viewer.cpp 2007-09-20 12:36:50.000000000 +0200 @@ -946,10 +946,6 @@ // May need to know this early also gDisableVoice = TRUE; } - else if (!strcmp(argv[j], "-url") && (++j < argc)) - { - LLURLSimString::setString(argv[j]); - } } if (!strcmp(gUserServerName, gUserServerDomainName[USERSERVER_AGNI].mName)) @@ -5344,18 +5340,13 @@ // Sometimes IP addresses passed in on the command line have leading // or trailing white space. Use LLString to clean that up. LLString ip_string; - S32 j; - // agent_sim_host holds the settings for connecting to the first simulator. - for (j = 1; j < argc; j++) + for (j = 1; j < argc; j++) { gArgs += argv[j]; gArgs += " "; - } - for (j = 1; j < argc; j++) - { LLString argument = argv[j]; if ((!strcmp(argv[j], "-port")) && (++j < argc)) { @@ -5613,11 +5604,23 @@ // so this allows us to parse the URL straight off the command line without a "-url" paramater else if (!argument.compare(0, std::string( "secondlife://" ).length(), std::string("secondlife://"))) { + // *NOTE: After setting the url, bail. What can happen is + // that someone can use IE (or potentially other browsers) + // and do the rough equivalent of command injection and + // steal passwords. Phoenix. SL-55321 LLURLSimString::setString(argv[j]); + gArgs += argv[j]; + return 0; } else if (!strcmp(argv[j], "-url") && (++j < argc)) { + // *NOTE: After setting the url, bail. What can happen is + // that someone can use IE (or potentially other browsers) + // and do the rough equivalent of command injection and + // steal passwords. Phoenix. SL-55321 LLURLSimString::setString(argv[j]); + gArgs += argv[j]; + return 0; } else if (!strcmp(argv[j], "-ignorepixeldepth")) { From robla at lindenlab.com Thu Sep 20 17:55:05 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 20 17:55:08 2007 Subject: [sldev] Transcript and audio of OSS meeting @ Hippotropolis (guest: Joe Linden) posted Message-ID: <46F31669.8000503@lindenlab.com> Hi everyone, The real-time transcript and the audio of the Open Source Meeting at Hippotropolis are here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-09-20 Thanks everyone who joined, and thanks Joe for speaking and taking questions. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070920/8be83116/signature.pgp From dale at daleglass.net Thu Sep 20 18:00:20 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 18:00:37 2007 Subject: [sldev] Request For Comments: Patch to allow registering multiple message system handlers Message-ID: <200709210300.28037.dale@daleglass.net> This adds new functions: LLMessageSystem::addHandlerFunc: Adds a handler to the list of handlers LLMessageSystem::delHandlerFunc: Removes a previously added handler LLMessageSystem::setHandlerFunc is kept with its original functionality, removes all the registered functions, then adds the specified one. Intended usage: LLFoo::LLFoo() { LLMessageSystem *msg = gMessageSystem; msg->addHandlerFunc("FooMsg", fooHandler, NULL); } LLFoo::~LLFoo() { LLMessageSystem *msg = gMessageSystem; if ( msg ) { msg->delHandlerFunc("FooMsg", fooHandler); } } Users of this should check the existing handler before adding another and make sure that it won't get confused if it receives replies to requests made by some other part of the code. This was made because my additions want to do the same things as existing parts of the code. For example the avatar list wants to parse the AvatarPropertiesReply message, which is also used by the profile screen. It also makes patches somewhat cleaner, as by moving the required stuff to the new class' constructor it removes another potential source of a merge conflict. IMO, the source should have more of this: Ideally I shouldn't have to be appending to files with long lists of various things that get initialized or registered. Ideally, a new screen should only need that the object gets constructed, and everything else should happen from the file that implements the new feature. Soft commented that perhaps handlers should have a return value that indicates whether to continue executing the rest of the handlers. So far I've chosen not to do that because my code is written to be independent of anything else related going on, so if the profile screen happens to decide that it doesn't like what it got that doesn't mean my code wouldn't want it either. Also changing the return type of all those functions would result in a huge patch. But this seems like something worth discussing: Do we need a system where the order in which handlers will be run can be defined, and where one of them can decide to stop the ones after it from running? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070921/993d82cf/attachment.pgp From dale at daleglass.net Thu Sep 20 18:08:43 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Sep 20 18:08:55 2007 Subject: [sldev] Request For Comments: Patch to allow registering multiple message system handlers In-Reply-To: <200709210300.28037.dale@daleglass.net> References: <200709210300.28037.dale@daleglass.net> Message-ID: <200709210308.49830.dale@daleglass.net> On Friday 21 September 2007 03:00:20 Dale Glass wrote: > This adds new functions: Err, forgot to add, patch attached here: https://jira.secondlife.com/browse/VWR-2546 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070921/f13b1c6a/attachment.pgp From lenglish5 at cox.net Thu Sep 20 18:49:52 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 18:49:53 2007 Subject: [sldev] [viewer] adding a simple outline list class, aka "stuck between a rock and a hard place..." Message-ID: <46F32340.9020607@cox.net> OK, this "simple" project is getting beyond ludicrous. I've analyzed things enough to understand what I need to do (I think): First, I have to refactor the header and .cpp files for LLScrollListCtrl so that the various classes are arranged in such a way that I can add a new cell type for LLScrollListCtrl to use. The problem is that not only are LLScrollListCell and its sub-classes declared in the LLSrollListCtr.h file, but those classes are also at least partially defined there as well, immediately followed by the declaration and partial definition of LLScrollListItem and the declaration and partial definition of LLScrollListCtrl itself. In order to add my LLScrollListOutlinerCell class, I have to separate all those definitions and declarations into the relevant .h and .cpp files, and then test to make sure I didn't goof. THEN I can start coding. The problem is, however, that each possible LLScrollListCell subclass is tested for within the LLScrollLIstCtrl and/or LLScrollListItem class methods, and the approrpriate calls are made from there. No LLScrollListCellFactory class exists, so I gotta change methods in each of those. Due to the interesting nature of the XML factory class, I can't derive a new LLScrollListCtrl subclass without losing the ability to use the xml factory, so I have to add new capabilities there as well. Keep in mind that this isn't a REAL hierarchy class, but only something that adds a conditional arrow icon that can't be clocked on separately from the name of the category. The show stopper for me is comletely refactoring the existing class files just to add something new in the first place. My NEW strategy is to just use the existing LLScrollList classes, with a minor modification to the LLScrollListText cell-subclass : LLScrollListText::handleClick which evokes a callback to my floater. I'll just RECREATE the entire hierarchy list with each possible selection within the floater, and use old school text-based indentation and + - signs to indicate the state of the hierarchy of categories. Wonky logic, but straightfoward compared to the alternative. And the scripters I've asked say they would prefer to see the old-school text hierarchy, however, ugly, rather than not see the floater exist at all. This GUI framework is a total mess, BTW. It only took me two weeks of hair-pulling to arrive at this conclusion. :-/ Double BTW, the mouse handling of the GUI, at least on the Mac, appears to be shot. As I pointed out earlier, handleMouseDown evokes LLScrollListCtrl::itemSelect anywhere from 5-15 times on a single mouse click with identical coordinates. There are various bits of information about the mouse coordinates created at the event handler level which appear to be ignored, at least on the Mac, because the first level LLViewerWindow::handleMouseDown gets called a 5-15 or more times from that single click, even though the mouse coordinates apparently never change, even at the lowest level of the Mac OS X event handler. #0 0x006bbf88 in LLScrollListText::handleClick at llscrolllistctrl.cpp:313 #1 0x006c3068 in LLScrollListCtrl::selectItemAt at llscrolllistctrl.cpp:1701 #2 0x006c3328 in LLScrollListCtrl::handleMouseDown at llscrolllistctrl.cpp:1735 #3 0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273 #4 0x006570d8 in LLView::handleMouseDown at llview.cpp:1089 #5 0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273 #6 0x006570d8 in LLView::handleMouseDown at llview.cpp:1089 #7 0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273 #8 0x006570d8 in LLView::handleMouseDown at llview.cpp:1089 #9 0x000ddb18 in LLViewerWindow::handleMouseDown at llviewerwindow.cpp:666 #10 0x00a578d0 in LLWindowMacOSX::eventHandler at llwindowmacosx.cpp:2210 L. From secret.argent at gmail.com Thu Sep 20 19:09:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 20 19:09:11 2007 Subject: [sldev] [SECURITY] Release Notes for Second Life 1.18.3(5) September 20, 2007 In-Reply-To: <20070920225155.95F9B41B002@stupor.lindenlab.com> References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: > Release Notes for Second Life 1.18.3(5) September 20, 2007 > ===================================== > Bug fixes: > * Fixed login failure when declining optional updates > * Fixed VWR-2487: Covenant Details between live version and release > candidate version > * Fixed VWR-2484: Icons missing from Mac OS X build > * Fixed VWR-2482: build tree misses the cursors_mac directory > * Fixed VWR-2378: Failure to enable the "Update" button in the > profile/classifieds tab, after a "Set Location" update. I was expecting to also see something like: > Changes: > * Fix URL handler exploit described here: http:// > blog.secondlife.com/2007/09/18/second-life-url-handler-exploit/ Did this not apply to the RC, was this fixed without an entry in the release notes, or is the RC still vulnerable? From lenglish5 at cox.net Thu Sep 20 19:17:48 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 19:17:49 2007 Subject: [sldev] [SECURITY] Release Notes for Second Life 1.18.3(5) September 20, 2007 In-Reply-To: References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: <46F329CC.2050400@cox.net> Argent Stonecutter wrote: >> Release Notes for Second Life 1.18.3(5) September 20, 2007 >> ===================================== >> Bug fixes: >> * Fixed login failure when declining optional updates >> * Fixed VWR-2487: Covenant Details between live version and release >> candidate version >> * Fixed VWR-2484: Icons missing from Mac OS X build >> * Fixed VWR-2482: build tree misses the cursors_mac directory >> * Fixed VWR-2378: Failure to enable the "Update" button in the >> profile/classifieds tab, after a "Set Location" update. > > I was expecting to also see something like: >> Changes: >> * Fix URL handler exploit described here: >> http://blog.secondlife.com/2007/09/18/second-life-url-handler-exploit/ > > Did this not apply to the RC, was this fixed without an entry in the > release notes, or is the RC still vulnerable? > I'm guessing still vulnerable since it wasn't mentioned, or... they forgot to mention. From lenglish5 at cox.net Thu Sep 20 20:14:22 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 20:14:24 2007 Subject: [sldev] Source release for RC 1.18.3.5 (Lee Linden) In-Reply-To: References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: <46F3370E.9050004@cox.net> Harold Brown wrote: > http://s3.amazonaws.com/release-candidate-secondlife-com/Second%20Life%201-18-3-5%20Release%20Candidate%20Setup.exe > > > Someone forgot to update the links / make a blog post. Heh. Somehow I doubt the .exe is going to run on my mac. Couldn't figure out how to find the Mac OS X version From lenglish5 at cox.net Thu Sep 20 20:17:33 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 20:17:35 2007 Subject: [sldev] [ANN] certified http development In-Reply-To: <46F1D9FD.3040708@lindenlab.com> References: <20070919212857.222D041B367@stupor.lindenlab.com> <46F1D9FD.3040708@lindenlab.com> Message-ID: <46F337CD.7060409@cox.net> Ryan Williams wrote: > Argent Stonecutter wrote: >> From: Ryan Williams >>> We're thinking that we'll be doing *everything* in MySQL, because then >>> we can wrap an entire do-something-non-idempotent-and-send-a-response >>> into one database transaction and hope that those guys implemented ACID >>> right. :-) >> >> Was that a joke about MySQL? I'm not laughing. >> > Ha ha, well, it's better than hoping that *we* implemented ACID > right. :-) Gotta start with something solid. > >> But that does bring up a question... did you guys ever consider >> PostgreSQL? > I think chttp would do quite well with a Postgres backend. No reason > not to. > > As for our choice of software to run on our servers, I've seen that > question a lot, and I don't really have an answer since the decision > to use MySQL was made long before I started here. What do you mean, its not your fault? Of course its you're fault. You're the person we're talking to and everyone knows that that is the person responsible for everything. From labrat.hb at gmail.com Thu Sep 20 20:34:35 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Sep 20 20:34:38 2007 Subject: [sldev] Source release for RC 1.18.3.5 (Lee Linden) In-Reply-To: <46F3370E.9050004@cox.net> References: <20070920225155.95F9B41B002@stupor.lindenlab.com> <46F3370E.9050004@cox.net> Message-ID: Mac: http://s3.amazonaws.com/release-candidate-secondlife-com/SecondLife_1_18_3_5_RELEASECANDIDATE.dmg Linux: http://s3.amazonaws.com/release-candidate-secondlife-com/SecondLife_i686_1_18_3_5_RELEASECANDIDATE.tar.bz2 On 9/20/07, Lawson English wrote: > > Harold Brown wrote: > > > http://s3.amazonaws.com/release-candidate-secondlife-com/Second%20Life%201-18-3-5%20Release%20Candidate%20Setup.exe > > < > http://s3.amazonaws.com/release-candidate-secondlife-com/Second%20Life%201-18-3-5%20Release%20Candidate%20Setup.exe > > > > > > Someone forgot to update the links / make a blog post. > > Heh. Somehow I doubt the .exe is going to run on my mac. Couldn't figure > out how to find the Mac OS X version > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070920/67199b80/attachment.htm From lenglish5 at cox.net Thu Sep 20 20:47:57 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 20 20:47:59 2007 Subject: [sldev] Source release for RC 1.18.3.5 (Lee Linden) In-Reply-To: References: <20070920225155.95F9B41B002@stupor.lindenlab.com> <46F3370E.9050004@cox.net> Message-ID: <46F33EED.2090407@cox.net> Harold Brown wrote: > Mac: > http://s3.amazonaws.com/release-candidate-secondlife-com/SecondLife_1_18_3_5_RELEASECANDIDATE.dmg > > Linux: > http://s3.amazonaws.com/release-candidate-secondlife-com/SecondLife_i686_1_18_3_5_RELEASECANDIDATE.tar.bz2 > Great, thanks. L From jhurliman at wsu.edu Thu Sep 20 21:48:10 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Sep 20 21:48:16 2007 Subject: [sldev] My progress, post architecture working group Message-ID: <46F34D0A.1070606@wsu.edu> Here's my followup to the architecture working group. I think others have done a great job of summarizing what was discussed and dissecting meaning so I'll just post about what I'm doing. As much as I want to write a Java implementation of all these ideas, C# is the easiest path for me to take right now. I created a new branch of libsecondlife that separates the LLSD and CAPS systems in to separate namespaces, and I have read through the certified HTTP spec. The hope is to get a lot of independent building blocks, and when serious proposals for prototypes come up plug them all together to quickly get a prototype in code. When this code is ready to be merged back to the trunk, the LLSD system will be capable of parsing and serializing to all three formats (xml, binary, and notation) and the CAPS system will support all of the client and server operations that I'm currently aware of. Not sure exactly how the cHTTP system will fit in as far as code libraries and namespaces and all the gritty details go, but it's not important now. This work will be auxiliary to my main focus on Second Life bots and voice clients, but every once in a while it's good to work on something different. John Hurliman From dale at daleglass.net Fri Sep 21 01:31:15 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Sep 21 01:31:27 2007 Subject: [sldev] Re: Request For Comments: Patch to allow registering multiple message system handlers In-Reply-To: <2c99c46e0709201805w7eb7993enbe6ac6edb8319ee2@mail.gmail.com> References: <200709210300.28037.dale@daleglass.net> <2c99c46e0709201804k28255a0er8eae37b1027e4323@mail.gmail.com> <2c99c46e0709201805w7eb7993enbe6ac6edb8319ee2@mail.gmail.com> Message-ID: <200709211031.22805.dale@daleglass.net> On Friday 21 September 2007 03:05:31 Michael Miller wrote: > *D'oh* I didn't read the whole message. You're asking for comments on > the design of the handler, not any code, right? No, everything really. Looking for feedback, like "good idea", "bad idea", "code should be improved", etc. In my first post I left out the link, the code is attached to https://jira.secondlife.com/browse/VWR-2546 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070921/cbf45271/attachment.pgp From nicholaz at blueflash.cc Fri Sep 21 02:20:06 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Sep 21 02:20:30 2007 Subject: [sldev] [SECURITY] Release Notes for Second Life 1.18.3(5) September 20, 2007 In-Reply-To: References: <20070920225155.95F9B41B002@stupor.lindenlab.com> Message-ID: <46F38CC6.4030503@blueflash.cc> Argent Stonecutter wrote: > Did this not apply to the RC, was this fixed without an entry in the > release notes, or is the RC still vulnerable? It's fixed ... it's the practically the only noticeable change in the source code for this release at all (besides version numbering). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From webmaster at ligosworld.com Fri Sep 21 06:26:49 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Fri Sep 21 06:27:19 2007 Subject: [sldev] Object and Texture Cache Message-ID: <46F3C699.3050008@ligosworld.com> Hi, is anyone able to explain me Object and Texturecache, especially how I can read it out. I need Object vertices, faces and textures for testing. Regards Andi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070921/2906fd52/attachment-0001.htm From blakar at gmail.com Fri Sep 21 06:34:55 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Sep 21 06:35:01 2007 Subject: [sldev] Object and Texture Cache In-Reply-To: <46F3C699.3050008@ligosworld.com> References: <46F3C699.3050008@ligosworld.com> Message-ID: <7992d0d60709210634j648feb08pa812afb139334479@mail.gmail.com> Textures are stored and can be retrieved but I fear that you have a misconception related to vertices that will stop you from reaching your goals. Vertices, faces ... are created based on the prim parameters. They are not stored as vertices. It's probably better if you give some idea of what you want to achieve first. Dirk aka Blakar Ogre On 9/21/07, Andreas Lichtenberger wrote: > > Hi, > is anyone able to explain me Object and Texturecache, especially how I can > read it out. > I need Object vertices, faces and textures for testing. > > Regards > Andi > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From webmaster at ligosworld.com Fri Sep 21 07:00:52 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Fri Sep 21 07:00:59 2007 Subject: [sldev] Object and Texture Cache In-Reply-To: <7992d0d60709210634j648feb08pa812afb139334479@mail.gmail.com> References: <46F3C699.3050008@ligosworld.com> <7992d0d60709210634j648feb08pa812afb139334479@mail.gmail.com> Message-ID: <46F3CE94.3080002@ligosworld.com> We want to render a SL scene in a own rendering engine. At the moment just a static scene. Without agentmovement and without connection to the sim. So I need the data which goes through the sl rendering pipeline. My idea was to fill the clean cache, just starting second life, let the scene load and close it again. Then to read out the cache and store the rendering data. At the moment I?m able to read out the .slc files. So I have LLVOCacheEntries. What is written in the mBuffer U8[size] Array? Can I use this information to restore the object data? Is there an other way to bring the objects data in a format like the data in the llm files of the character? It would be a great start, to know how Vertices, Faces and so on are created based on the prim parameters and where the primparameters are stored, if they are stored. Can you tell me what is written in the data.db2.x... file of the cache directory? Just sounds? I tried to restor the j2c textures of the cache. But I did something wrong. I think, I have some misunderstandings, how long the header of these files are and how the headers are stored. Best regards, Andi Dirk Moerenhout schrieb: > Textures are stored and can be retrieved but I fear that you have a > misconception related to vertices that will stop you from reaching > your goals. > > Vertices, faces ... are created based on the prim parameters. They are > not stored as vertices. It's probably better if you give some idea of > what you want to achieve first. > > Dirk aka Blakar Ogre > > On 9/21/07, Andreas Lichtenberger wrote: > >> Hi, >> is anyone able to explain me Object and Texturecache, especially how I can >> read it out. >> I need Object vertices, faces and textures for testing. >> >> Regards >> Andi >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070921/dabb0ef4/attachment.htm From robla at lindenlab.com Fri Sep 21 09:58:23 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 21 09:58:26 2007 Subject: [sldev] POSTPONED: jira.secondlife.com downtime tonight, 11pm PDT In-Reply-To: <46F2F413.7050208@lindenlab.com> References: <46F2F413.7050208@lindenlab.com> Message-ID: <46F3F82F.907@lindenlab.com> Downtime has been postponed to 11pm tonight. On 9/20/07 3:28 PM, Rob Lanphier wrote: > Hi all, > > jira.secondlife.com will be down starting tomorrow at 9am for > approximately 30 minutes while we futz with it. With any luck, we'll > have a partial solution for WEB-58 (Fix this JIRA's email capability), > though it probably won't be turned on immediately after the fix. If > you've never logged into jira.secondlife.com, now is a good time to do > it, because what we'll be doing is taking a snapshot of everyone who had > logged into jira at some point, and populating those email addresses. > Everyone who logs in for the first time after that snapshot will need to > wait until a following snapshot at a time TBD, or until we get the > permasolution in place. > > Rob > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070921/7022dfee/signature.pgp From joel at lindenlab.com Fri Sep 21 13:51:12 2007 From: joel at lindenlab.com (Sidewinder Linden) Date: Fri Sep 21 13:51:37 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <46F2D3EA.4070409@comcast.net> References: <20070919154125.427F141B30D@stupor.lindenlab.com> <3ABF4BC2-A401-4E4D-BE23-80ED49115F10@gmail.com> <46F2D3EA.4070409@comcast.net> Message-ID: <46F42EC0.3020800@lindenlab.com> Argent Stonecutter wrote: >> Going back to the original quote... >>> Meta Linden: In fact het-grid *is* helping- already. We are rolling >>> the new >>> physics engine onto some sims on the main grid *today*. > That comment qualifies as an "oops"... Havok4 has not been rolled onto the main grid, and it was not planned to be on the main grid at this point. We do not want to roll an update of this significance without serious beta testing and resolution of issues that surface from a public beta preview. Het-Grid is being used in internal testing, and will be used for the public preview and final rollout of Havok4, so that we can run Havok1 and Havok4 simulators in parallel throughout the process. We are working through some known issues and will announce a public beta as soon as possible. To answer Lawson's question about Havok5... Yes we have known about the Havok5 release for a while, and after discussions with the Havok folks decided that it was far better to release the Havok4 version and to get that version solid before taking the next jump. Regards, Sidewinder Linden Havok4 Program Manager From ingmar at RiversRunRed.com Fri Sep 21 13:53:23 2007 From: ingmar at RiversRunRed.com (Ingmar Hupp) Date: Fri Sep 21 13:53:30 2007 Subject: [sldev] Object and Texture Cache In-Reply-To: <46F3CE94.3080002@ligosworld.com> References: <46F3C699.3050008@ligosworld.com> <7992d0d60709210634j648feb08pa812afb139334479@mail.gmail.com> <46F3CE94.3080002@ligosworld.com> Message-ID: <816D1D27-8DA5-4DB9-B562-D9E12F139C91@RiversRunRed.com> You're probably better off grabbing the actual 3D data via http:// ogle.eyebeamresearch.org/ than getting the prim parameters, because then you'd still have to implement the rendering for those. Ingmar On 21 Sep 2007, at 15:00, Andreas Lichtenberger wrote: > We want to render a SL scene in a own rendering engine. At the > moment just a static scene. Without agentmovement and without > connection to the sim. > So I need the data which goes through the sl rendering pipeline. My > idea was to fill the clean cache, just starting second life, let > the scene load and close it again. > Then to read out the cache and store the rendering data. > At the moment I?m able to read out the .slc files. So I have > LLVOCacheEntries. What is written in the mBuffer U8[size] Array? > Can I use this information to restore > the object data? > Is there an other way to bring the objects data in a format like > the data in the llm files of the character? > It would be a great start, to know how Vertices, Faces and so on > are created based on the prim parameters and where the > primparameters are stored, if they are stored. > Can you tell me what is written in the data.db2.x... file of the > cache directory? Just sounds? > I tried to restor the j2c textures of the cache. But I did > something wrong. I think, I have some misunderstandings, how long > the header of these files are and how the headers are stored. > Best regards, > Andi > > > > Dirk Moerenhout schrieb: >> Textures are stored and can be retrieved but I fear that you have a >> misconception related to vertices that will stop you from reaching >> your goals. >> >> Vertices, faces ... are created based on the prim parameters. They >> are >> not stored as vertices. It's probably better if you give some idea of >> what you want to achieve first. >> >> Dirk aka Blakar Ogre >> >> On 9/21/07, Andreas Lichtenberger wrote: >> >>> Hi, >>> is anyone able to explain me Object and Texturecache, especially >>> how I can >>> read it out. >>> I need Object vertices, faces and textures for testing. >>> >>> Regards >>> Andi >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Ingmar "Ezhar Fairlight" Hupp | Head of Technology | Rivers Run Red http://spacethinkdream.com | http://riversrunred.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070921/c06d2fa7/attachment.htm From benglenn at lindenlab.com Fri Sep 21 14:14:35 2007 From: benglenn at lindenlab.com (Ben Glenn) Date: Fri Sep 21 14:14:48 2007 Subject: [sldev] No UI triage this week Message-ID: <006f01c7fc94$69bea690$3d3bf3b0$@com> Torley and I are both on vacation next week so there will be no UI triage on 9/25. Next UI triage is 10/2. Please spread the word. Thanks, Ben Ben Glenn User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070921/05301c23/attachment.htm From agrimes at speakeasy.net Fri Sep 21 15:45:41 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Fri Sep 21 15:45:28 2007 Subject: [sldev] The "Fix SL challenge" Message-ID: <46F44995.2000407@speakeasy.net> About Twenty years ago there was a game that I used to play on my 286-10 called "Stunt Driver" it let you build your own race tracks by dropping tiles onto a grid and then gave you a full 3D vector graphics simulation that actually worked quite well within its limitations. A few days ago I came across this obnoxious truck with a large 'FIX SL'. Banner on it. I came across a road today so I pulled it out and tried to drive it. It was barely controllable. So Here's the challenge, get yourself a Fix SL truck, put it on the road at one end of one of the larger continents and drive it to the other end of the road. That's all. Just drive the thing across the sim. If you get that to work well enough, then there wouldn't be any reason for these trucks. Float the Linden!! (crash the dollar!) -- Buy Ron Paul's Money! =) http://www.libertydollar.org/ld/ronpauldollar Soundest investment on the planet! From labrat.hb at gmail.com Fri Sep 21 15:56:53 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Sep 21 15:56:55 2007 Subject: [sldev] The "Fix SL challenge" In-Reply-To: <46F44995.2000407@speakeasy.net> References: <46F44995.2000407@speakeasy.net> Message-ID: And what if the reason the truck doesn't make it from one end to the other is because the truck is just scripted in a fucked up way? Problems with a vehicle does not indicate a problem with SL other then with that particular vehicle implementation. So yes I'm sure someone could fix SL so that those "Fix SL" trucks run like butter on a hot griddle from one side of the SL Grid to the other.... but what is that fix going to do to every other vehicle in SL? Yes SL has issues.. and they are being addressed. But just like the story of the blind men asked to describe an elephant... not everyone sees the same issues with SL. My wife crashes 5-12 times a day... I may crash once... Friends complain about rez issues... I TP someplace and everything rezzes quickly... SL does work well "within its limitations" but it is also not constrained by those limitations other then falling over when they are exceeded. On 9/21/07, Alan Grimes wrote: > > About Twenty years ago there was a game that I used to play on my 286-10 > called "Stunt Driver" it let you build your own race tracks by dropping > tiles onto a grid and then gave you a full 3D vector graphics simulation > that actually worked quite well within its limitations. > > A few days ago I came across this obnoxious truck with a large 'FIX SL'. > Banner on it. I came across a road today so I pulled it out and tried to > drive it. It was barely controllable. So Here's the challenge, get > yourself a Fix SL truck, put it on the road at one end of one of the > larger continents and drive it to the other end of the road. That's all. > Just drive the thing across the sim. If you get that to work well > enough, then there wouldn't be any reason for these trucks. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070921/18317cb3/attachment-0001.htm From secret.argent at gmail.com Fri Sep 21 16:20:15 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 21 16:20:41 2007 Subject: [sldev] The "Fix SL challenge" In-Reply-To: <20070921225659.C246D41AF82@stupor.lindenlab.com> References: <20070921225659.C246D41AF82@stupor.lindenlab.com> Message-ID: <0B818357-94CC-4BB7-A2BE-74B4CE0AB0C2@gmail.com> > A few days ago I came across this obnoxious truck with a large 'FIX > SL'. > Banner on it. I came across a road today so I pulled it out and > tried to > drive it. It was barely controllable. I've got vehicles that are barely controllable, and I've vehicles that drive or fly well. I've *flown* across the continent on my Mehve at around 5m level, following the roads, and that's with a vehicle that's using "aircraft" controls. As in, if you let yourself hit anything you're stopped. Now I've got a fair bit of practice with that, but I've also worked pretty hard on making it controllable. If you've got a parcel handy to a road on the mainland, I'll stick a demo Mehve rezzer on it and you can try it yourself. The biggest problem is outflying the sim handoff or running into ban lines. From dzonatas at dzonux.net Fri Sep 21 17:29:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Sep 21 17:27:50 2007 Subject: [sldev] [ARCH] Prokofy Neva's "Open Architecture and the Rest of Us" (today) Message-ID: <46F461DD.5030705@dzonux.net> As seen on the forums: http://forums.secondlife.com/showthread.php?t=212067 --- TONIGHT 6:00 PM SLT Sutherland Dam Did you see the Lindens' post about their concept of open architecture, and the small group discussion they had with programmers? http://blog.secondlife.com/2007/09/19/slgarchwg1/ Well, this is not just a technical matter but involves eventual changes to the world as we know it that will have a profound impact on many people, especially those in business on the grid. While saying this project is just about the technical architecture, they are discussing -- and therefore making decisions about economic, political, and social matters -- and many people are not even aware they're up to this. Here are some of the topics already laid out in the wiki: http://wiki.secondlife.com/wiki/Brainstorming o currency -- whether to close the LindEx and end the micropayment system in favour of Paypal or currencies hosts will devise o land -- how/whether it devalues in a host-your-own environment o regions -- deciding whether to allow in agents based on age, RL identity, financial o hook-ups -- will everybody pay to hook up to SL Central? How much? Or will many not bother and want to hook up only to each other? o content -- the harsh reality is that Open Architecture is Copybot, Institutionalized, and everything that is seen in the viewer as it is open-sourced is available to any licensed user. Right now, the discussion is a lot like having the anarchists decide what to do about globalization. It's time to get started some kind of process that is like world economic forum that tries to understand the impact of these changes and proposes ways to prevent, mitigate, or adapt to them reasonably, without the extreme solutions often provided by tekkies that they then present as fait accomplis. All welcome, but griefers summarily ejected. -- Power to Change the Void From dmahalko at gmail.com Fri Sep 21 17:28:27 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Sep 21 17:28:30 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: <200709201042.40855.dale@daleglass.net> References: <200709201042.40855.dale@daleglass.net> Message-ID: On 9/20/07, Dale Glass wrote: > Why would it test for collisions on triangles? > > Prims are ideal for collision testing. Testing for collisions against a > mesh which happens to be a sphere would take a lot of processing time, > while checking against a sphere prim would be near instant in comparison > since as you KNOW it's a sphere you can do the check against an imaginary > perfect sphere. > SL goes by triangles, and you can test this for yourself. Make a 10m x 10m x 10m sphere, hollow to 95% (lower mass) and then roll it around on a very slight incline, such as 3 - 5 degrees. It will roll a little ways and then come to a stop on one of the "flat spots" on the sphere. This usually drives people like me nuts since I'm trying to build marble rollercoasters and marble time clocks and other stuff where things are often precisely balanced and adjusted. A rough marble with flat spots that stops halfway down the slope screws things up. You can actually make a sphere "more round" than normal by doing a little trick I discovered. The sphere seems to use an odd number of triangles around its circumference, so if you overlay multiple offset spheres on top of each other and link them, they will form a far more perfect sphere that rolls much more smoothly. - Create a sphere, align it on x.000 y.000 z.000 (for easier alignment) and the euler rotation at 0,0,0. - copy it and set the copy nearby. - duplicate the copy an Rotate it to 90,0,0 on the main sphere - duplicate the copy an Rotate it to 180,0,0 on the main sphere - duplicate the copy an Rotate it to 270,0,0 on the main sphere - duplicate the copy an Rotate it to 0,90,0 on the main sphere - duplicate the copy an Rotate it to 0,180,0 on the main sphere This forms a cross of six overlapping spheres pointing to -X +X -Y +Y -Z +Z Select all, Link them and set aside another copy - duplicate the crossed-copy and rotate it to 45,0,0 on the main six - duplicate the crossed-copy and rotate it to 45,45,0 on the main six - duplicate the crossed-copy and rotate it to 45,90,0 on the main six - duplicate the crossed-copy and rotate it to 45,135,0 on the main six Now you have 24 overlapping spheres covering the six cardinal directions plus all points halfway between. Link them all together. Roll this ulra-sphere around and you will discover it rolls far more smoothly than any sphere you've ever seen before, because it has been forced to have a far higher than normal triangle count, making the collision volume extremely high detail. Even a large sphere with huge triangles will roll around quite smoothly, and you'll notice it has almost a perfectly round appearance. However, since it now has about 300 * 24 triangles the physics processing load is going to be much higher, and two such ultra-spheres generally only work against other simple 1-surface flat and round prims. Two ultra-spheres colliding can lead to Deep Think or object freezing since the load on the engine is so much higher than normal. Here I am experimenting with ultra-spheres in my oversize pinball machine project last year (bigger physics objects usually seem to work better): http://img151.imageshack.us/my.php?image=pinballflipperll2.png http://img152.imageshack.us/my.php?image=pinballballhoppersa2.png http://img174.imageshack.us/my.php?image=pinballballlauncherig0.png http://img151.imageshack.us/my.php?image=pinballpopbumpersgy2.png -Scalar Tardis / Dale Mahalko From kerdezixe at gmail.com Fri Sep 21 20:39:05 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Sep 21 20:39:07 2007 Subject: [sldev] [ARCH] Prokofy Neva's "Open Architecture and the Rest of Us" (today) In-Reply-To: <46F461DD.5030705@dzonux.net> References: <46F461DD.5030705@dzonux.net> Message-ID: <8a1bfe660709212039r311f7756v8762b7560650f823@mail.gmail.com> I assisted to some prokofy's "office hour takeover". Totally ignoring the topic of the office hour to whine about their very own concern. i heard question like "How the new physic engine while improve our IP privacy ?" (because we were talking about havok4) ... you see what i mean ...what can you possibily answer to _that_ ? and the time you type the answer prokofy already asked 2 others question totally unrelated to the 1st one. Additionally, prokofy is highly offensive : We're tekkies so we don't understand human (we propbably aren't human anyway ?) and always provide extreme anti-social solutions. and about that "the anarchists decide what to do about globalization" : being myself kinda anarchist it could make me laugh very hardly if it wasn't prokofy's words (it's certainly taken as an offence in the context of prokofy's post). Hurting people's feeling, spreading FUD, ... very selffish and hatefull. sad ... -- kerunix Flan From robin.cornelius at gmail.com Sat Sep 22 01:20:17 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 22 01:20:25 2007 Subject: [sldev] [VWR] OpenJPEG backtraces Message-ID: <46F4D041.3060502@gmail.com> Hi Eveyone, Is this useful to anyone, backtraces from openjpeg when running sl 1.18.3.5 on native compiled AMD64? If anyone wants more information or detailed gdb poking of any variables please let me know. I can crash it fairly regularly! (I do have the OpenJPEGEncodeLossless patch applied to my SL code as well) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41804950 (LWP 21675)] 0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) at libopenjpeg/dwt.c:166 (gdb) bt #0 0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) at libopenjpeg/dwt.c:166 #1 0x0000000001dcdfaf in dwt_decode_tile (tilec=0x845ede0, stop=0, dwt_1D=0x1dccf0c ) at libopenjpeg/dwt.c:641 #2 0x0000000001dcdb63 in dwt_decode_real (tilec=0x845ede0, stop=0) at libopenjpeg/dwt.c:541 #3 0x0000000001dc9d5b in tcd_decode_tile (tcd=0x9d29a70, src=0xea41180 "?\026\207\016\216:?P\215??\b\v\033?\204??d??\236\205|\b?\017?<\235yF?#D?Z\b?&\213???\\\236?4?~?\214?\037\233???\005B???;\216\237????2?\aI???J>?\025$\202?_?&?J\t0????N??U?? \025\032?'?W\005;??\2315\033H1\217??YhY3???<\235n?6?T?\036\037\n\200\200?\022?\016\200??????\225?=??\200??DY?\a\227?\203?h?f\223>?^?]?d\220Y??\201?n~m\210\231???\216?\223\035??\001F"..., len=89166, tileno=0) at libopenjpeg/tcd.c:1307 #4 0x0000000001db962e in j2k_read_eoc (j2k=0x6096a60) at libopenjpeg/j2k.c:1483 #5 0x0000000001db9bd8 in j2k_decode (j2k=0x6096a60, cio=0xab86d20) at libopenjpeg/j2k.c:1778 #6 0x0000000001db59cb in opj_decode (dinfo=0x9fb3e80, cio=0xab86d20) at libopenjpeg/openjpeg.c:154 #7 0x0000000001ab0a63 in LLImageJ2COJ::decodeImpl (this=0x90e8980, base=@0x9683f40, raw_image=@0x9048700, decode_time=0.100000001, first_channel=0, max_channel_count=4) at /tmp/root/usr/src/1.18.3.5/linden/indra/x86_64-linux-client-debug/llimagej2coj/llimagej2coj.cpp:131 (gdb) list dwt.c:166 161 static void dwt_interleave_h(dwt_t* h, int *a) { 162 int *ai = a; 163 int *bi = h->mem + h->cas; 164 int i = h->sn; 165 while( i-- ) { 166 *bi = *(ai++); 167 bi += 2; 168 } 169 ai = a + h->sn; 170 bi = h->mem + 1 - h->cas; (gdb) print i $1 = 31 (gdb) print bi $2 = (int *) 0xb0037c80 (gdb) print ai $3 = (int *) 0xff6a0f0 (gdb) print h->sn $4 = 32 Anyway i've started trying to follow it back up the call stack but i don't know openjpeg at all so this may take me ages or i might not get there. But if someone has a clue what to look for please give me a hint. Regards Robin From robin.cornelius at gmail.com Sat Sep 22 02:34:26 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 22 02:34:34 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F4D041.3060502@gmail.com> References: <46F4D041.3060502@gmail.com> Message-ID: <46F4E1A2.4070701@gmail.com> Robin Cornelius wrote: > > (gdb) bt > #0 0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) > at libopenjpeg/dwt.c:166 > #1 0x0000000001dcdfaf in dwt_decode_tile (tilec=0x845ede0, stop=0, Looking at frame #1 i've found the problem in dwt.c line 623 we have pointer truncation h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; I've checked the contents of h and m using the gdb console and with the (unsigned) cast you get a bogus memory location and with a (unsigned long) cast you get the intended memory location 64bit systems only I'm not sure what the correct portable correct version is to make a patch thats good for 32 and 64 systems. Robin From mdepascale at dii.unisi.it Sat Sep 22 02:49:28 2007 From: mdepascale at dii.unisi.it (Maurizio de Pascale) Date: Sat Sep 22 02:49:51 2007 Subject: [sldev] Object and Texture Cache In-Reply-To: <816D1D27-8DA5-4DB9-B562-D9E12F139C91@RiversRunRed.com> References: <46F3C699.3050008@ligosworld.com> <7992d0d60709210634j648feb08pa812afb139334479@mail.gmail.com> <46F3CE94.3080002@ligosworld.com> <816D1D27-8DA5-4DB9-B562-D9E12F139C91@RiversRunRed.com> Message-ID: <46F4E528.2000001@dii.unisi.it> Hi, the viewer engine is drawing things, and to do that it has obviously to build up vertices and indices at some point, to feed them down to the opengl since it is not using a software renderer. Probably this data is stored somewhere in memory since it will be too costly to build them on the fly at each rendering cycle. I think that the LLDrawable class (the mDrawable field of viewer objects) could be a good point to begin searching for (at least is what I'm doing right now) but if some good guy on this list could shed light on the subject I will be eternally grateful... :) thank you in advance, Maurizio de Pascale mdepascale@dii.unisi.it Ingmar Hupp wrote: > You're probably better off grabbing the actual 3D data > via http://ogle.eyebeamresearch.org/ than getting the prim parameters, > because then you'd still have to implement the rendering for those. > > > Ingmar > > On 21 Sep 2007, at 15:00, Andreas Lichtenberger wrote: > >> We want to render a SL scene in a own rendering engine. At the moment >> just a static scene. Without agentmovement and without connection to >> the sim. >> So I need the data which goes through the sl rendering pipeline. My >> idea was to fill the clean cache, just starting second life, let the >> scene load and close it again. >> Then to read out the cache and store the rendering data. >> At the moment I?m able to read out the .slc files. So I have >> LLVOCacheEntries. What is written in the mBuffer U8[size] Array? Can >> I use this information to restore >> the object data? >> Is there an other way to bring the objects data in a format like the >> data in the llm files of the character? >> It would be a great start, to know how Vertices, Faces and so on are >> created based on the prim parameters and where the primparameters are >> stored, if they are stored. >> Can you tell me what is written in the data.db2.x... file of the >> cache directory? Just sounds? >> I tried to restor the j2c textures of the cache. But I did something >> wrong. I think, I have some misunderstandings, how long the header of >> these files are and how the headers are stored. >> Best regards, >> Andi >> >> >> >> Dirk Moerenhout schrieb: >>> Textures are stored and can be retrieved but I fear that you have a >>> misconception related to vertices that will stop you from reaching >>> your goals. >>> >>> Vertices, faces ... are created based on the prim parameters. They are >>> not stored as vertices. It's probably better if you give some idea of >>> what you want to achieve first. >>> >>> Dirk aka Blakar Ogre >>> >>> On 9/21/07, Andreas Lichtenberger wrote: >>> >>>> Hi, >>>> is anyone able to explain me Object and Texturecache, especially how I can >>>> read it out. >>>> I need Object vertices, faces and textures for testing. >>>> >>>> Regards >>>> Andi >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>>> >>> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- > Ingmar "Ezhar Fairlight" Hupp | Head of Technology | *Rivers Run Red* > http://spacethinkdream.com | http://riversrunred.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Sat Sep 22 05:24:05 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Sep 22 05:24:08 2007 Subject: [sldev] [ATTN-LL] Physics engine status update? In-Reply-To: References: <200709201042.40855.dale@daleglass.net> Message-ID: <7992d0d60709220524i474f730bg1172aeeebcdc3bbf@mail.gmail.com> I never tested how SL (or rather the old Havok I guess) does it but I can't imagine it's, currently, the fastest way to do it. Nor as you noticed yourself is it really usable. If you build up the sphere with too few triangles you may end up getting something that is (or maybe rather was) mathematically faster as you can simplify the triangle math more easily. Still with todays FPU power it'd be better to just calculate how a real sphere would roll over that plane. This is what Nick Gray from Havok says about it in the PDF that was in this thread earlier on: "But we need one more piece of info to help us guide our choices for efficiency, and it's that convex objects are easier to perform collisions with than non-convex objects. So triangles, spheres, capsules, cylinders, boxes, cones or convex polyhedra are 'simple'. Arbitrary meshes (triangle soups), or even just triangle representations of the above convex shapes are 'complex'. And the rule-of-thumb is that collisions between complex geometries are very costly to do in real-time." Dirk aka Blakar Ogre From secret.argent at gmail.com Sat Sep 22 06:25:40 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 06:25:55 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <20070922122412.4777841AFE3@stupor.lindenlab.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> Message-ID: <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> > h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; Ick. Try this: h.mem = v.mem = (int*)( (char *)m + 16 - ( (char *)m % 16 ) ) ; There's possibly a derived type that is more "ANSI", but this is valid portable C. In addition, I'm not sure that this code is doing the right thing. It seems to be an attempt to round a pointer up to the next 16 byte boundary, but where the pointer is already pointing to a 16 byte boundary is it really supposed to increment it to the next boundary? If this is just making sure there's room for some specifically aligned objects below the pointer it will introduce unnecessary 16 byte gaps in the result. May I suggest (int *)( ((char *) m + 0x10) & ~0x0F ) to round up to the next 16-byte boundary even if you're on a 16-byte boundary, or (int *)( ((char *) m + 0x0F) & ~0x0F ) to just round up to the next 16-byte boundary. Finally, the original code is amusing because the "unsigned" type was introduced to C because people were having to cast ints to pointers to get unsigned arithmetic. Since this is arithmetic on pointers to begin with... :) From dzonatas at dzonux.net Sat Sep 22 07:38:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 07:37:22 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> Message-ID: <46F528FB.4000806@dzonux.net> Argent Stonecutter wrote: > Finally, the original code is amusing because the "unsigned" type was > introduced to C because people were having to cast ints to pointers to > get unsigned arithmetic. Since this is arithmetic on pointers to begin > with... :) > _______________________________________________ > Some compilers don't allow that to happen, so you cast them to unsigned. 16 byte boundaries are needed for SSE. The instructions just before it add the pad, which is just once and a little bit for the entire image. The alignment in that part is not mandatory but helps avoid non 16 byte aligned pointers later on. -- Power to Change the Void From nicholaz at blueflash.cc Sat Sep 22 07:43:33 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 22 07:44:01 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F4E1A2.4070701@gmail.com> References: <46F4D041.3060502@gmail.com> <46F4E1A2.4070701@gmail.com> Message-ID: <46F52A15.9070609@blueflash.cc> Argent Stonecutter wrote: >> h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; > > h.mem = v.mem = (int*)( (char *)m + 16 - ( (char *)m % 16 ) ) ; the modulo operator can't be applied to a pointer type (same goes for "ptr & x"), only legal arithmetic for potiner is addition and subtract. > I'm not sure what the correct portable correct version is to make a > patch thats good for 32 and 64 systems. I'd say do it as (unsigned long). ULONG should have a size large enough on both versions to hold the numeric equivalent of a pointer. If you want to be sure add an assertion, like assert(sizeof(unsigned long)>=sizeof(int*)); My variant would be. h.mem = v.mem = (int*)( ((unsigned long)m + 16) & ~0xF ) ; As a side note, depending on the source, they probably want to do a +15 instead of +16 to not skip to the next segment if the pointer is already 16-aligned, but that depends on what's about to happen there exactly. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Robin Cornelius wrote: > Robin Cornelius wrote: >> >> (gdb) bt >> #0 0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) >> at libopenjpeg/dwt.c:166 >> #1 0x0000000001dcdfaf in dwt_decode_tile (tilec=0x845ede0, stop=0, > > Looking at frame #1 i've found the problem > > in dwt.c line 623 we have pointer truncation > > h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; > > I've checked the contents of h and m using the gdb console and with the > (unsigned) cast you get a bogus memory location and with a (unsigned > long) cast you get the intended memory location > > 64bit systems only > > I'm not sure what the correct portable correct version is to make a > patch thats good for 32 and 64 systems. > > Robin > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Sat Sep 22 07:50:48 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 07:49:20 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F4E1A2.4070701@gmail.com> References: <46F4D041.3060502@gmail.com> <46F4E1A2.4070701@gmail.com> Message-ID: <46F52BC8.4060609@dzonux.net> Robin Cornelius wrote: > h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; > > I've checked the contents of h and m using the gdb console and with > the (unsigned) cast you get a bogus memory location and with a > (unsigned long) cast you get the intended memory location > > 64bit systems only > > I'm not sure what the correct portable correct version is to make a > patch thats good for 32 and 64 systems. > > This sucks because it means there are cases were "unsigned" doesn't follow the standard, which "unsigned" (without "int" or "long") should be automatically 32 or 64 bit based on the the machine. Fudge... Toss it... We'll have to use _mm_alloc() or like where it is defined correctly in the headers. I think Callum already changed it to use such in a patch. -- Power to Change the Void From robin.cornelius at gmail.com Sat Sep 22 07:51:34 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 22 07:51:46 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F528FB.4000806@dzonux.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> Message-ID: <46F52BF6.9080601@gmail.com> Dzonatas wrote: > Argent Stonecutter wrote: >> Finally, the original code is amusing because the "unsigned" type was >> introduced to C because people were having to cast ints to pointers to >> get unsigned arithmetic. Since this is arithmetic on pointers to begin >> with... :) >> _______________________________________________ >> > > Some compilers don't allow that to happen, so you cast them to unsigned. > > 16 byte boundaries are needed for SSE. The instructions just before it > add the pad, which is just once and a little bit for the entire image. > The alignment in that part is not mandatory but helps avoid non 16 byte > aligned pointers later on. > > Oh guys as a follow up i think this is this bug http://jira.secondlife.com/browse/VWR-1864 I was certainly seeing the crash in dwt_decode_tile() before i had a openjpeg with full debug (cause there are some inline functions there that the full trace shows). Regards Robin From lenglish5 at cox.net Sat Sep 22 08:24:51 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 22 08:24:54 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> Message-ID: <46F533C3.1060200@cox.net> Argent Stonecutter wrote: >> h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; > > Ick. > > Try this: > > h.mem = v.mem = (int*)( (char *)m + 16 - ( (char *)m % 16 ) ) ; > > There's possibly a derived type that is more "ANSI", but this is valid > portable C. > > In addition, I'm not sure that this code is doing the right thing. It > seems to be an attempt to round a pointer up to the next 16 byte > boundary, but where the pointer is already pointing to a 16 byte > boundary is it really supposed to increment it to the next boundary? > If this is just making sure there's room for some specifically aligned > objects below the pointer it will introduce unnecessary 16 byte gaps > in the result. > > May I suggest (int *)( ((char *) m + 0x10) & ~0x0F ) to round up to > the next 16-byte boundary even if you're on a 16-byte boundary, or > (int *)( ((char *) m + 0x0F) & ~0x0F ) to just round up to the next > 16-byte boundary. > > Finally, the original code is amusing because the "unsigned" type was > introduced to C because people were having to cast ints to pointers to > get unsigned arithmetic. Since this is arithmetic on pointers to begin > with... :) > _______________________________________________ /me suddenly recalls why he despises intel. No other architecture has to worry about this crap. From secret.argent at gmail.com Sat Sep 22 08:48:25 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 08:48:35 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F528FB.4000806@dzonux.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> Message-ID: <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> On 22-Sep-2007, at 09:38, Dzonatas wrote: > 16 byte boundaries are needed for SSE. The instructions just before > it add the pad, which is just once and a little bit for the entire > image. The alignment in that part is not mandatory but helps avoid > non 16 byte aligned pointers later on. Then there's another bug, because if it's already aligned the original code will add an unnecessary 16 byte gap. Eg: Let's say m is 0xA0000000. m + 16 is 0xA0000010. m % 16 is 0. So the result of aligning it is 0xA0000010, not 0xA0000000. Adding 0x0F and masking with ~0x0F always does the right thing. On the other hand... > Some compilers don't allow that to happen, so you cast them to > unsigned. Some compilers don't allow what to happen? Adding an integer to a pointer ALWAYS works, even on word-addressed machines and machines with non-power-of-two word size. I could see pointer masking being a problem, though I'd like to know of any compilers on machines newer than a DECsystem-20 where this would be a problem. Anyway, I think the maximally portable code is this: (int *)( (char *)m + ( 16 - ((unsigned)m % 16) ) % 16 ) You could explicitly mask here but any compiler that doesn't produce the same code for (uns % 16) and (uns & 0xF) has problems. Now...does this work? Well, m cast to unsigned might truncate, but since it's immediately truncated again to 4 bits that doesn't matter. Then the second mask takes care of the case of m already being aligned. Then you're adding a pointer to an integer, which is portable. If this is only done once it's not worth saving the extra mask. From secret.argent at gmail.com Sat Sep 22 08:52:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 08:52:45 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F533C3.1060200@cox.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F533C3.1060200@cox.net> Message-ID: <6BACFBFB-3BD1-4896-AB5D-9BF1262FF280@gmail.com> On 22-Sep-2007, at 10:24, Lawson English wrote: > /me suddenly recalls why he despises intel. No other architecture > has to worry about this crap. Um, this has nothing to do with intel. Any byte addressed machine EVER needs this kind of code if you're laying out mixed data types into a block of memory. 68000, Power, Alpha, Sparc, what computer are YOU thinking of that doesn't have alignment requirements? If you're thinking about the pointer size, well, that's still not an intel issue. From nicholaz at blueflash.cc Sat Sep 22 09:27:47 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 22 09:28:11 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> Message-ID: <46F54283.1010907@blueflash.cc> > I could see pointer masking being a problem, though I'd like to know of > any compilers on machines newer than a DECsystem-20 where this would be > a problem. MSVC doesn't allow modulo or bit-ops on pointers. Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From secret.argent at gmail.com Sat Sep 22 10:00:59 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 10:01:09 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F54283.1010907@blueflash.cc> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> Message-ID: <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> On 22-Sep-2007, at 11:27, Nicholaz Beresford wrote: > > I could see pointer masking being a problem, though I'd like to > know of > > any compilers on machines newer than a DECsystem-20 where this > would be > > a problem. > MSVC doesn't allow modulo or bit-ops on pointers. *static* Whiskey Tango Foxtrot, Captain? Could you repeat that, I'm not sure I copied correctly. That's... special. WTF not? MOST of the masking and shifting I've done on pointers, EVER, has been on Microsoft operating systems, to deal with the "special" requirements of 286 enchanted bowel movement mode. From robin.cornelius at gmail.com Sat Sep 22 10:01:15 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 22 10:01:23 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> Message-ID: <46F54A5B.8010202@gmail.com> Argent Stonecutter wrote: > > Anyway, I think the maximally portable code is this: > > (int *)( (char *)m + ( 16 - ((unsigned)m % 16) ) % 16 ) > > You could explicitly mask here but any compiler that doesn't produce the > same code for (uns % 16) and (uns & 0xF) has problems. > Well gcc had a warn (but i think you expected this as you had a known truncation that is not important) libopenjpeg/dwt.c: In function 'dwt_decode_tile': libopenjpeg/dwt.c:623: warning: cast from pointer to integer of different siz But it seems ok running, so far. All in all this seems to have fixed the worst 64 bit bug now so a 64 bit build with 100% open source libs is quite quite usable. We should really push this upstream to openjpeg source. Should i do this or will Callum Lerwick "OpenJPEG Czar of the Second Life Open Source Enforcement Agency" take this one? Robin From dzonatas at dzonux.net Sat Sep 22 10:09:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 10:07:53 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F54A5B.8010202@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54A5B.8010202@gmail.com> Message-ID: <46F54C41.3020706@dzonux.net> Robin Cornelius wrote: > We should really push this upstream to openjpeg source. Should i do > this or will Callum Lerwick "OpenJPEG Czar of the Second Life Open > Source Enforcement Agency" take this one? > > Toss it... It's in a patch on this list, already. Changes the whole alloc to use _mm_alloc(), instead... http://www.haxxed.com/code/openjpeg-1.2-aligned-malloc.patch That link didn't work for me today, however. -- Power to Change the Void From secret.argent at gmail.com Sat Sep 22 10:16:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 10:16:32 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <20070922170112.3555141B049@stupor.lindenlab.com> References: <20070922170112.3555141B049@stupor.lindenlab.com> Message-ID: <1A903849-EE0B-480C-95AD-074E9DDC7784@gmail.com> Dzonatas writes: > This sucks because it means there are cases were "unsigned" doesn't > follow the standard, which "unsigned" (without "int" or "long") should > be automatically 32 or 64 bit based on the the machine. Fudge... > Toss it... According to the standard, unsigned means "unsigned int". If sizeof (int) is less than sizeof (void *) then so is sizeof (unsigned). While I agree that ILP64 is more logical than LP64, both models must be accommodated. I would prefer L128IP64. (I was pissed when I found that the VAX was ILP32 instead of L64IP32, back in the early '80s... I mean we hadn't invented those terms yet, but it was daft not having a C type for a register pair like on the PDP-11) From robin.cornelius at gmail.com Sat Sep 22 10:18:48 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 22 10:18:56 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F54C41.3020706@dzonux.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54A5B.8010202@gmail.com> <46F54C41.3020706@dzonux.net> Message-ID: <46F54E78.20406@gmail.com> Dzonatas wrote: > Robin Cornelius wrote: >> We should really push this upstream to openjpeg source. Should i do >> this or will Callum Lerwick "OpenJPEG Czar of the Second Life Open >> Source Enforcement Agency" take this one? >> >> > > Toss it... > > It's in a patch on this list, already. Changes the whole alloc to use > _mm_alloc(), instead... > > http://www.haxxed.com/code/openjpeg-1.2-aligned-malloc.patch > > > That link didn't work for me today, however. Ah sorry, missed the point about your earlier toss it comment. Ok when haxxed.com comes back up I will give that patch a shot. I will also make a note in JIRA in one of the openjpeg issues about this patch, I had missed the previous patch on the list (although its in my inbox somewhere i am sure). Thanks Robin From dzonatas at dzonux.net Sat Sep 22 10:33:45 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 10:32:15 2007 Subject: [sldev] [VWR] Real-time Raytracing, now proof-of-concept on 8+ core. Message-ID: <46F551F9.8010006@dzonux.net> Good time to read the article, as it is not being slashdotted anymore. "Rendering Games with Raytracing Will Revolutionize Graphics" http://www.pcper.com/article.php?aid=455&type=expert&pid=1 -- Power to Change the Void From robla at lindenlab.com Sat Sep 22 11:27:26 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Sep 22 11:27:45 2007 Subject: [sldev] [WEB] Email from JIRA working (fix for WEB-58) Message-ID: <46F55E8E.4040209@lindenlab.com> Hi everyone, Email from JIRA now works (finally). This means that you will automatically receive email updates whenever an issue you filed is updated, or when an issue assigned to you is updated. This fixes WEB-58: https://jira.secondlife.com/browse/WEB-58 Additionally, you may now watch issues that you didn't file by adding yourself to the watch list (select the "Watch it" link in the lower left) There is one substantial caveat. This was the result of a manual one-time push of email addresses which required downtime to accomplish (ugh). We don't yet have automatic synchronization in place, so people who have never logged into JIRA won't be able to get emails until we sync databases again. Part of the reason for the delay in enabling this feature in the first place is that we were holding out for the automatic solution, and only recently broke down and accepted the manual solution as a temporary workaround. So, we'll need your help working with new JIRA users who will understandably be frustrated with the lack of this capability. Next week, we'll get an estimate for when automatic synchronization will be in place, whether or not subsequent manual syncs will be necessary, and how frequently we'll be doing those. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070922/26dde9c0/signature.pgp From 1337mail at gmail.com Sat Sep 22 12:20:16 2007 From: 1337mail at gmail.com (Michael Miller) Date: Sat Sep 22 12:20:18 2007 Subject: [sldev] Dead code stripping causes the libjpeg to not work Message-ID: <2c99c46e0709221220k4b61889am5fcd205b6f3aa580@mail.gmail.com> The default settings cause the build to create a huge, bloated executable. Thus, I turned on dead code stripping in XCode(Mac OSX 10.4.10). However, the compiler(Development configuration) spits out 134 errors when compiling llviewerprecompiledheaders.h. The errors solely deal with libjpeg. I've included the (very long) error list below. Is this a fault of libjpeg? Anything that can be done to fix it? -- Mike Errors: ../../libraries/include/jpeglib/jpeglib.h:73: error: expected `)' before ';' token ../../libraries/include/jpeglib/jpeglib.h:73: error: storage class specifiers invalid in parameter declarations ../../libraries/include/jpeglib/jpeglib.h:73: error: multiple storage classes in declaration of 'parameter' ../../libraries/include/jpeglib/jpeglib.h:75: error: expected initializer before '*' token ../../libraries/include/jpeglib/jpeglib.h:88: error: 'UINT16' does not name a type ../../libraries/include/jpeglib/jpeglib.h:94: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:102: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:104: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:110: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:139: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:140: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:154: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:155: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:160: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:197: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:200: error: ISO C++ forbids declaration of 'JOCTET' with no type ../../libraries/include/jpeglib/jpeglib.h:200: error: expected ';' before '*' token ../../libraries/include/jpeglib/jpeglib.h:254: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:269: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:279: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:280: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:309: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:310: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:311: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:320: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:321: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:322: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:323: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:337: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:338: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:339: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:344: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:345: error: 'UINT16' does not name a type ../../libraries/include/jpeglib/jpeglib.h:346: error: 'UINT16' does not name a type ../../libraries/include/jpeglib/jpeglib.h:347: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:354: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:363: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:367: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:382: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:383: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:412: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:420: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:421: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:436: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:437: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:440: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:441: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:443: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:446: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:449: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:450: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:451: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:459: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:460: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:479: error: 'JSAMPARRAY' does not name a type ../../libraries/include/jpeglib/jpeglib.h:489: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:495: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:502: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:538: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:539: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:541: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:542: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:543: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:550: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:552: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:553: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:554: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:555: error: 'UINT16' does not name a type ../../libraries/include/jpeglib/jpeglib.h:556: error: 'UINT16' does not name a type ../../libraries/include/jpeglib/jpeglib.h:557: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:558: error: 'UINT8' does not name a type ../../libraries/include/jpeglib/jpeglib.h:560: error: 'boolean' does not name a type ../../libraries/include/jpeglib/jpeglib.h:580: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:589: error: ISO C++ forbids declaration of 'JSAMPLE' with no type ../../libraries/include/jpeglib/jpeglib.h:589: error: expected ';' before '*' token ../../libraries/include/jpeglib/jpeglib.h:600: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:601: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:714: error: ISO C++ forbids declaration of 'JOCTET' with no type ../../libraries/include/jpeglib/jpeglib.h:714: error: expected ';' before '*' token ../../libraries/include/jpeglib/jpeglib.h:718: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:718: error: ISO C++ forbids declaration of 'boolean' with no type ../../libraries/include/jpeglib/jpeglib.h:718: error: 'boolean' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:726: error: ISO C++ forbids declaration of 'JOCTET' with no type ../../libraries/include/jpeglib/jpeglib.h:726: error: expected ';' before '*' token ../../libraries/include/jpeglib/jpeglib.h:730: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:730: error: ISO C++ forbids declaration of 'boolean' with no type ../../libraries/include/jpeglib/jpeglib.h:730: error: 'boolean' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:732: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:732: error: ISO C++ forbids declaration of 'boolean' with no type ../../libraries/include/jpeglib/jpeglib.h:732: error: 'boolean' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:732: error: 'int jpeg_source_mgr::boolean(int*)' and 'int jpeg_source_mgr::boolean(int*)' cannot be overloaded ../../libraries/include/jpeglib/jpeglib.h:762: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:762: error: ISO C++ forbids declaration of 'JSAMPARRAY' with no type ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JSAMPARRAY' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:765: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:765: error: ISO C++ forbids declaration of 'JBLOCKARRAY' with no type ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JBLOCKARRAY' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:768: error: 'boolean' has not been declared ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:774: error: 'boolean' has not been declared ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:781: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:781: error: 'boolean' has not been declared ../../libraries/include/jpeglib/jpeglib.h:781: error: ISO C++ forbids declaration of 'JSAMPARRAY' with no type ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JSAMPARRAY' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:781: error: 'int jpeg_memory_mgr::JSAMPARRAY(int*)' and 'int jpeg_memory_mgr::JSAMPARRAY(int*)' cannot be overloaded ../../libraries/include/jpeglib/jpeglib.h:786: error: expected identifier before '*' token ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JDIMENSION' has not been declared ../../libraries/include/jpeglib/jpeglib.h:786: error: 'boolean' has not been declared ../../libraries/include/jpeglib/jpeglib.h:786: error: ISO C++ forbids declaration of 'JBLOCKARRAY' with no type ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JBLOCKARRAY' declared as function returning a function ../../libraries/include/jpeglib/jpeglib.h:786: error: 'int jpeg_memory_mgr::JBLOCKARRAY(int*)' and 'int jpeg_memory_mgr::JBLOCKARRAY(int*)' cannot be overloaded ../../libraries/include/jpeglib/jpeglib.h:809: error: ISO C++ forbids declaration of 'boolean' with no type ../../libraries/include/jpeglib/jpeglib.h:809: error: typedef 'boolean' is initialized (use __typeof__ instead) ../../libraries/include/jpeglib/jpeglib.h:809: error: 'jpeg_marker_parser_method' was not declared in this scope ../../libraries/include/jpeglib/jpeglib.h:809: error: expected ',' or ';' before '(' token ../../libraries/include/jpeglib/jpeglib.h:938: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:944: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:950: error: expected ',' or '...' before '*' token ../../libraries/include/jpeglib/jpeglib.h:950: error: ISO C++ forbids declaration of 'JOCTET' with no type ../../libraries/include/jpeglib/jpeglib.h:976: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:982: error: 'JDIMENSION' does not name a type ../../libraries/include/jpeglib/jpeglib.h:1011: error: 'jpeg_marker_parser_method' has not been declared From 1337mail at gmail.com Sat Sep 22 12:40:07 2007 From: 1337mail at gmail.com (Michael Miller) Date: Sat Sep 22 12:40:10 2007 Subject: [sldev] Re: Dead code stripping causes the libjpeg to not work In-Reply-To: <2c99c46e0709221220k4b61889am5fcd205b6f3aa580@mail.gmail.com> References: <2c99c46e0709221220k4b61889am5fcd205b6f3aa580@mail.gmail.com> Message-ID: <2c99c46e0709221240q7de33cal2663709a022341b8@mail.gmail.com> I found the solution. "Don't dead-strip inits and terms" needs to be checked as well. -- Mike On 9/22/07, Michael Miller <1337mail@gmail.com> wrote: > The default settings cause the build to create a huge, bloated > executable. Thus, I turned on dead code stripping in XCode(Mac OSX > 10.4.10). However, the compiler(Development configuration) spits out > 134 errors when compiling llviewerprecompiledheaders.h. The errors > solely deal with libjpeg. I've included the (very long) error list > below. Is this a fault of libjpeg? Anything that can be done to fix > it? > > -- Mike > > Errors: > > ../../libraries/include/jpeglib/jpeglib.h:73: error: expected `)' > before ';' token > ../../libraries/include/jpeglib/jpeglib.h:73: error: storage class > specifiers invalid in parameter declarations > ../../libraries/include/jpeglib/jpeglib.h:73: error: multiple storage > classes in declaration of 'parameter' > ../../libraries/include/jpeglib/jpeglib.h:75: error: expected > initializer before '*' token > ../../libraries/include/jpeglib/jpeglib.h:88: error: 'UINT16' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:94: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:102: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:104: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:110: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:139: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:140: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:154: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:155: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:160: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:197: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:200: error: ISO C++ forbids > declaration of 'JOCTET' with no type > ../../libraries/include/jpeglib/jpeglib.h:200: error: expected ';' > before '*' token > ../../libraries/include/jpeglib/jpeglib.h:254: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:269: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:279: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:280: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:309: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:310: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:311: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:320: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:321: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:322: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:323: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:337: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:338: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:339: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:344: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:345: error: 'UINT16' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:346: error: 'UINT16' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:347: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:354: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:363: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:367: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:382: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:383: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:412: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:420: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:421: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:436: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:437: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:440: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:441: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:443: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:446: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:449: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:450: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:451: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:459: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:460: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:479: error: 'JSAMPARRAY' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:489: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:495: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:502: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:538: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:539: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:541: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:542: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:543: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:550: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:552: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:553: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:554: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:555: error: 'UINT16' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:556: error: 'UINT16' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:557: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:558: error: 'UINT8' does not > name a type > ../../libraries/include/jpeglib/jpeglib.h:560: error: 'boolean' does > not name a type > ../../libraries/include/jpeglib/jpeglib.h:580: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:589: error: ISO C++ forbids > declaration of 'JSAMPLE' with no type > ../../libraries/include/jpeglib/jpeglib.h:589: error: expected ';' > before '*' token > ../../libraries/include/jpeglib/jpeglib.h:600: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:601: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:714: error: ISO C++ forbids > declaration of 'JOCTET' with no type > ../../libraries/include/jpeglib/jpeglib.h:714: error: expected ';' > before '*' token > ../../libraries/include/jpeglib/jpeglib.h:718: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:718: error: ISO C++ forbids > declaration of 'boolean' with no type > ../../libraries/include/jpeglib/jpeglib.h:718: error: 'boolean' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:726: error: ISO C++ forbids > declaration of 'JOCTET' with no type > ../../libraries/include/jpeglib/jpeglib.h:726: error: expected ';' > before '*' token > ../../libraries/include/jpeglib/jpeglib.h:730: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:730: error: ISO C++ forbids > declaration of 'boolean' with no type > ../../libraries/include/jpeglib/jpeglib.h:730: error: 'boolean' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:732: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:732: error: ISO C++ forbids > declaration of 'boolean' with no type > ../../libraries/include/jpeglib/jpeglib.h:732: error: 'boolean' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:732: error: 'int > jpeg_source_mgr::boolean(int*)' and 'int > jpeg_source_mgr::boolean(int*)' cannot be overloaded > ../../libraries/include/jpeglib/jpeglib.h:762: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:762: error: ISO C++ forbids > declaration of 'JSAMPARRAY' with no type > ../../libraries/include/jpeglib/jpeglib.h:762: error: 'JSAMPARRAY' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:765: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:765: error: ISO C++ forbids > declaration of 'JBLOCKARRAY' with no type > ../../libraries/include/jpeglib/jpeglib.h:765: error: 'JBLOCKARRAY' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:768: error: 'boolean' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:768: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:774: error: 'boolean' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:774: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:781: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:781: error: 'boolean' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:781: error: ISO C++ forbids > declaration of 'JSAMPARRAY' with no type > ../../libraries/include/jpeglib/jpeglib.h:781: error: 'JSAMPARRAY' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:781: error: 'int > jpeg_memory_mgr::JSAMPARRAY(int*)' and 'int > jpeg_memory_mgr::JSAMPARRAY(int*)' cannot be overloaded > ../../libraries/include/jpeglib/jpeglib.h:786: error: expected > identifier before '*' token > ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JDIMENSION' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:786: error: 'boolean' has > not been declared > ../../libraries/include/jpeglib/jpeglib.h:786: error: ISO C++ forbids > declaration of 'JBLOCKARRAY' with no type > ../../libraries/include/jpeglib/jpeglib.h:786: error: 'JBLOCKARRAY' > declared as function returning a function > ../../libraries/include/jpeglib/jpeglib.h:786: error: 'int > jpeg_memory_mgr::JBLOCKARRAY(int*)' and 'int > jpeg_memory_mgr::JBLOCKARRAY(int*)' cannot be overloaded > ../../libraries/include/jpeglib/jpeglib.h:809: error: ISO C++ forbids > declaration of 'boolean' with no type > ../../libraries/include/jpeglib/jpeglib.h:809: error: typedef > 'boolean' is initialized (use __typeof__ instead) > ../../libraries/include/jpeglib/jpeglib.h:809: error: > 'jpeg_marker_parser_method' was not declared in this scope > ../../libraries/include/jpeglib/jpeglib.h:809: error: expected ',' or > ';' before '(' token > ../../libraries/include/jpeglib/jpeglib.h:938: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:944: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:950: error: expected ',' or > '...' before '*' token > ../../libraries/include/jpeglib/jpeglib.h:950: error: ISO C++ forbids > declaration of 'JOCTET' with no type > ../../libraries/include/jpeglib/jpeglib.h:976: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:982: error: 'JDIMENSION' > does not name a type > ../../libraries/include/jpeglib/jpeglib.h:1011: error: > 'jpeg_marker_parser_method' has not been declared > From secret.argent at gmail.com Sat Sep 22 13:07:05 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 13:07:17 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <20070922190010.97A8A41B099@stupor.lindenlab.com> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> Message-ID: Dzonatas notes: > "Rendering Games with Raytracing Will Revolutionize Graphics" > > http://www.pcper.com/article.php?aid=455&type=expert&pid=1 Old news. Philipp Slusallek has been pushing this for years. He had an FPGA hardware raytracer that was doing 7M rays/sec on a 66 MHz FPGA with 6M gates in 2005. Got a lot of pushback from nVidia and ATI over this, which is a pity, but I just got mail from him that both ATI and nVidia are adding RT acceleration to future GPUs... though nothing as aggressive as his SaarCOR prototype. An 8800 runs at, what, 400 MHZ and has 600M transistors. Given how parallelizable raytracing is a dedicated raytracer with a similar budget should blow past the magic billion rays a second without difficulty... and be a lot cheaper and use less power than an 8 core CPU. http://graphics.cs.uni-sb.de/~slusallek/ From webmaster at ligosworld.com Sat Sep 22 13:13:48 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Sat Sep 22 13:14:06 2007 Subject: [sldev] Object and Texture Cache References: 816D1D27-8DA5-4DB9-B562-D9E12F139C91@RiversRunRed.com Message-ID: <46F5777C.5050705@ligosworld.com> Hi, I searched for the right point, where indizes and vertices are build for nearly three days, and did not found the wright way to get them. So it would be very helpfull if sombody can tell where they are stored for opengl. Thanks Andi From 1337mail at gmail.com Sat Sep 22 13:45:45 2007 From: 1337mail at gmail.com (Michael Miller) Date: Sat Sep 22 13:45:49 2007 Subject: [sldev] 1.18.2.1 source code Message-ID: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> I fired up SL today(using my home-compiled 1.18.2 source). First, I noticed a message on the right side of the login screen: "Optional Update." Then, I logged in. I got a message saying that I needed to upgrade to 1.18.2.1. Unfortunately, I don't see any source code listed for 1.18.2.1 on https://wiki.secondlife.com/wiki/Source_archive. Was 1.18.2.1 intended to be optional? Is there any source code available for 1.18.2.1? From lenglish5 at cox.net Sat Sep 22 14:37:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 22 14:37:20 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: References: <20070922190010.97A8A41B099@stupor.lindenlab.com> Message-ID: <46F58B0B.6040105@cox.net> Argent Stonecutter wrote: > Dzonatas notes: >> "Rendering Games with Raytracing Will Revolutionize Graphics" >> >> http://www.pcper.com/article.php?aid=455&type=expert&pid=1 > > Old news. Philipp Slusallek has been pushing this for years. He had an > FPGA hardware raytracer that was doing 7M rays/sec on a 66 MHz FPGA > with 6M gates in 2005. Got a lot of pushback from nVidia and ATI over > this, which is a pity, but I just got mail from him that both ATI and > nVidia are adding RT acceleration to future GPUs... though nothing as > aggressive as his SaarCOR prototype. > > An 8800 runs at, what, 400 MHZ and has 600M transistors. Given how > parallelizable raytracing is a dedicated raytracer with a similar > budget should blow past the magic billion rays a second without > difficulty... and be a lot cheaper and use less power than an 8 core CPU. > > http://graphics.cs.uni-sb.de/~slusallek/ > How compatible would the already-built SL content be for a ray-traced based viewer? Would everything have to be pre-converted, converted-on-the-fly, or do existing ray-tracing algorithms handle OpenGL geometry already? L. From nicholaz at blueflash.cc Sat Sep 22 14:46:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Sep 22 14:46:55 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> Message-ID: <46F58D35.3070305@blueflash.cc> Argent Stonecutter wrote: >> MSVC doesn't allow modulo or bit-ops on pointers. > > *static* Whiskey Tango Foxtrot, Captain? Could you repeat that, I'm not > sure I copied correctly. > > That's... special. WTF not? MOST of the masking and shifting I've done > on pointers, EVER, has been on Microsoft operating systems, to deal with > the "special" requirements of 286 enchanted bowel movement mode. Well Captain, have a look at the ANSI standard. Over and out. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From adam at gwala.net Sat Sep 22 15:04:37 2007 From: adam at gwala.net (Adam Frisby) Date: Sat Sep 22 15:04:52 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F58D35.3070305@blueflash.cc> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> Message-ID: <46F59175.20206@gwala.net> That and doing arithmetic on pointers makes a hell of a lot of assumptions about the memory space and can lead to all sorts of fun debugging it later. Adam Nicholaz Beresford wrote: > > Argent Stonecutter wrote: > >>> MSVC doesn't allow modulo or bit-ops on pointers. >> >> >> *static* Whiskey Tango Foxtrot, Captain? Could you repeat that, I'm >> not sure I copied correctly. >> >> That's... special. WTF not? MOST of the masking and shifting I've done >> on pointers, EVER, has been on Microsoft operating systems, to deal >> with the "special" requirements of 286 enchanted bowel movement mode. > > > Well Captain, have a look at the ANSI standard. Over and out. > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sllists at boroon.dasgupta.ch Sat Sep 22 15:21:04 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Sep 22 15:21:31 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F58B0B.6040105@cox.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> Message-ID: <46F59550.2060201@boroon.dasgupta.ch> Lawson English schrieb: > How compatible would the already-built SL content be for a ray-traced > based viewer? The 'content' being based on prims that can probably easily be described by parametric surfaces, it would be very compatible, I'd say. > Would everything have to be pre-converted, At the moment everything has to be converted to triangles. With ray tracing you'd actually save that pre-conversion step. > converted-on-the-fly, This could be done for the ground, for sculpties and other yet-to-come free-form or free-form-like surfaces. The already mentioned Phillipp Slusallek et al. describe this here: Carsten Benthin, Ingo Wald, and Philipp Slusallek, Interactive Ray Tracing of Free-Form Surfaces , Proceedings of Afrigraph 2004, Stellenbosch (Cape Town), South Africa, November 3-5, 2004 (from http://graphics.cs.uni-sb.de/~slusallek/publications.html) > or do existing ray-tracing algorithms handle OpenGL geometry already? OpenGL geometry is based on triangles (if we only consider surfaces, not lines and points which are also supported). There are triangle based ray-tracing algorithms and in fact the very first *real time* ray-tracers operated on triangles only. But in almost all cases where you've got some simpler geometric description of an object than its mash you'd want to use that simpler description directly for rendering to achieve higher image quality while having to cache (or even generate) less data. Problem is, those 'simpler descriptions' (parametric equations, mostly) might be more expensive to intersect with a ray than plain triangles, but for "good" shapes like spheres and cubes it shouldn't make a too big difference. I'm really looking forward to have hardware accelerated ray-tracing support on mass market computers. Might take quite some time till that'll happen, though. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070923/da57f44f/attachment.htm From dzonatas at dzonux.net Sat Sep 22 15:33:30 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 15:32:03 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F59550.2060201@boroon.dasgupta.ch> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> Message-ID: <46F5983A.1090305@dzonux.net> Boroondas Gupte wrote: > I'm really looking forward to have hardware accelerated ray-tracing > support on mass market computers. Might take quite some time till > that'll happen, though. > ...within one year on the octacores. It can be done on the quadcores, as they have shown, but that assumes most of the processing power is dedicated to RTRT. Also, the demos show more advanced lighting, shadows, and refractions than what SL would need at this time if we switched right over. Given sound, voice, and network and the rest, next years octacores makes a good starting platform to process it all. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070922/f756bd20/attachment.htm From secret.argent at gmail.com Sat Sep 22 15:51:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 15:51:33 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F58B0B.6040105@cox.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> Message-ID: <306BB372-5A9F-4AEC-B829-522B2E911531@gmail.com> On 22-Sep-2007, at 16:37, Lawson English wrote: > How compatible would the already-built SL content be for a ray- > traced based viewer? Would everything have to be pre-converted, > converted-on-the-fly, or do existing ray-tracing algorithms handle > OpenGL geometry already? There's nothing I can think of in any of the content created in SL that depends on OpenGL or even rasterization except perhaps some details of particle systems. The viewer would need to be significantly changed, but the servers and in-world content are unlikely to be effected. From secret.argent at gmail.com Sat Sep 22 16:25:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 22 16:25:27 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F58D35.3070305@blueflash.cc> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> Message-ID: <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> On 22-Sep-2007, at 16:46, Nicholaz Beresford wrote: > Well Captain, have a look at the ANSI standard. Over and out. No compiler in the world implements ANSI C without extensions. A compiler should emit a diagnostic when it encounters one, but that is not the same thing as refusing to permit it. In c89/c90 there is no way of portably defining an integer type that can contain any pointer, since long long wasn't standardized until c99. Therefore the only way to portably express aligning a pointer was to do it without a cast, and c89/c90 compilers HAD to permit that in practice. The c99 standard hasn't been out long enough to justify writing code that's not portable to c89/c90, so the appropriate behavior for a compiler is to emit a diagnostic, not forbid the operation. I suspect this is another of those "it's really a C++ compiler" issues with Microsoft C. On 22-Sep-2007, at 17:04, Adam Frisby wrote: > That and doing arithmetic on pointers makes a hell of a lot of > assumptions about the memory space and can lead to all sorts of fun > debugging it later. Not relevant in this case. The arithmetic operation needs to be performed, the only issue is what the syntax of that operation should be. From blakar at gmail.com Sat Sep 22 16:49:17 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Sep 22 16:49:21 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F5983A.1090305@dzonux.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> Message-ID: <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> > ...within one year on the octacores. Which 0.1% of the SL population will own. It's nice, it's the future but if we're today not even ready to start using SSE as a minimum then why dream of what you can do with a CPU that's not even on the market yet? Dirk aka Blakar Ogre From mdepascale at dii.unisi.it Sat Sep 22 16:58:32 2007 From: mdepascale at dii.unisi.it (Maurizio de Pascale) Date: Sat Sep 22 16:58:47 2007 Subject: [sldev] Object and Texture Cache In-Reply-To: <46F5777C.5050705@ligosworld.com> References: 816D1D27-8DA5-4DB9-B562-D9E12F139C91@RiversRunRed.com <46F5777C.5050705@ligosworld.com> Message-ID: <46F5AC28.9000204@dii.unisi.it> Hi, So far I've "reached" the LLVertexBuffer (object->mDrawable->getFace(0)->getVertexBuffer() even if this doesn't look to me the cleanest way to get there...) which actually seems to contain both vertex and index data. please let me know if you find a better solution to access rendering data. cheers, Maurizio de Pascale mdepascale@dii.unisi.it Andreas Lichtenberger wrote: > Hi, > I searched for the right point, where indizes and vertices are build > for nearly three days, and did not found the wright way to get them. > So it would be very helpfull if sombody can tell where they are stored > for opengl. > > Thanks > Andi > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dzonatas at dzonux.net Sat Sep 22 20:11:54 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Sep 22 20:10:23 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> Message-ID: <46F5D97A.6090300@dzonux.net> Dirk Moerenhout wrote: >> ...within one year on the octacores. >> > > Which 0.1% of the SL population will own. > I think they said the same about the latest ATI and nVidia cards. > It's nice, it's the future but if we're today not even ready to start > using SSE as a minimum then why dream of what you can do with a CPU > that's not even on the market yet? > The problem is not just SSE but cache pollution even without SSE. More cores would allow a program to assign specific tasks to a core and optimize for that cache. ATI has also presented new instruction to help monitor and control the cache. Modern OSs still don't even thread correctly under multicores, as they have no way to know what a program will do with the cache. The new Linux scheduler tries (CFS) to address some of it, but even that dev team has noted it still needs work. SL just easily exploits the problem the OS schedulers have had. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070922/703077e6/attachment.htm From Anders at Arnholm.se Sun Sep 23 00:07:25 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Sun Sep 23 00:08:53 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> Message-ID: <1190531245.7423.17.camel@kitiara> On Sat, 2007-09-22 at 18:25 -0500, Argent Stonecutter wrote: > On 22-Sep-2007, at 16:46, Nicholaz Beresford wrote: > > Well Captain, have a look at the ANSI standard. Over and out. > > No compiler in the world implements ANSI C without extensions. A > compiler should emit a diagnostic when it encounters one, but that is > not the same thing as refusing to permit it. No good programmer in the world breaks ANSI C, with out really good reasoning behind it. The original expression made the hair in my neck rise, I have been tracking down and destroying that kind of code now in six months to make the transitions of code from RH8 (i386) to RHEL5 (x86_64). It was about the typical code with assumptions of memory that don't work. > In c89/c90 there is no way of portably defining an integer type that > can contain any pointer, since long long wasn't standardized until > c99. Therefore the only way to portably express aligning a pointer long long isn't really that type, ptrdiff_t is a much better choose. / Balp, Fist port to this list. (And I had issues with OpenJPEG in opensim on my x86_84 host...) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gigstaggart at gmail.com Sun Sep 23 01:30:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 01:30:23 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F5D97A.6090300@dzonux.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> <46F5D97A.6090300@dzonux.net> Message-ID: <46F6241D.1090208@gmail.com> Dzonatas wrote: >> It's nice, it's the future but if we're today not even ready to start >> using SSE as a minimum then why dream of what you can do with a CPU >> that's not even on the market yet? >> > The problem is not just SSE but cache pollution even without SSE. More > cores would allow a program to assign specific tasks to a core and > optimize for that cache. You are missing the point. SL is designed for the lowest common denominator. These octo-core chips might come out next year, but SL is supporting CPUs from 5 years ago. So like, bring this up again in 6 years. -Jason From gigstaggart at gmail.com Sun Sep 23 01:31:24 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 01:31:26 2007 Subject: [sldev] [PATCH] VWR-442 Message-ID: <46F6245C.5070705@gmail.com> http://jira.secondlife.com/browse/VWR-442 Adds warning when inviting new group owners. The action is not reversible and had no warning previously. -Jason From dzonatas at dzonux.net Sun Sep 23 04:53:46 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Sep 23 04:52:15 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F6241D.1090208@gmail.com> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> <46F5D97A.6090300@dzonux.net> <46F6241D.1090208@gmail.com> Message-ID: <46F653CA.3050307@dzonux.net> Jason Giglio wrote: > Dzonatas wrote: >>> It's nice, it's the future but if we're today not even ready to start >>> using SSE as a minimum then why dream of what you can do with a CPU >>> that's not even on the market yet? >>> >> The problem is not just SSE but cache pollution even without SSE. >> More cores would allow a program to assign specific tasks to a core >> and optimize for that cache. > > You are missing the point. SL is designed for the lowest common > denominator. These octo-core chips might come out next year, but SL > is supporting CPUs from 5 years ago. So like, bring this up again in > 6 years. > I understood that point, but SSE and # of CPUs are unrelated. The attempt to argue against # of CPUs (as being the future instead of sooner) with an argument about the state of SSE is not fair. That's like saying why even bother mentioning the latest GPU when you know it won't plug into the motherboards that are of the least common denominator. The point, as with the proof-of-concept, that seemed to be missed here is that one can use general RT algorithms on the multicore CPUs than build specialized code to support different vendor's GPUs. RTRT has been around for awhile, but to do it under general RT algorithms on hardware that is on the market now is the proof that no special hardware is needed anymore just to do it in practical sense. That's all for this -- Power to Change the Void From dzonatas at dzonux.net Sun Sep 23 05:53:04 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Sep 23 05:51:33 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <1190531245.7423.17.camel@kitiara> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> <1190531245.7423.17.camel@kitiara> Message-ID: <46F661B0.6000802@dzonux.net> Anders Arnholm wrote: > No good programmer in the world breaks ANSI C, with out really good > reasoning behind it. The original expression made the hair in my neck > rise, I have been tracking down and destroying that kind of code now in > six months to make the transitions of code from RH8 (i386) to RHEL5 > (x86_64). It was about the typical code with assumptions of memory that > don't work. > Memory range is fine, as the malloc() before that statement padded it fine. It's just a compiler nuance that can't be portably used anymore. The "long" keyword would be a hack to fix it (as Nicholas suggested), but that doesn't actually correct the intention. The "unsigned" keyword (by it self) worked fine through 32 bit, 16 bit, and 8 bit. Now with 64 bit, it will depend on the compiler options if "long" is needed or not. That would be the more of the event of C++ than the changes from "RH8 to RHEL5," as C++ creates the distinct type on "long." Instead of worrying about compiler options/mode or the best expression, we can just result back to _mm_alloc() for now as defined in the xmm headers (and correctly for each compiler that supplies such headers). That is something we intended to do, but it would be nice to have something more portable than _mm_alloc(). The Mac has those headers, so it'll work for AltiVec, also. The most portable expression (that gives no compiler warnings) becomes mandatory if we use other vector processors besides SSE and AltiVec. Also note, OpenJPEG was being compiled under C, but SL is set to compile it under C++. This nuance is one of the reasons why people have screamed to implement into the standard the "align" (or "alignof") keyword on the "new" operator, such as: mem = new align[16] char[1024]; -- Power to Change the Void From dale at daleglass.net Sun Sep 23 06:02:31 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Sep 23 06:02:44 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F661B0.6000802@dzonux.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <1190531245.7423.17.camel@kitiara> <46F661B0.6000802@dzonux.net> Message-ID: <200709231502.38993.dale@daleglass.net> On Sunday 23 September 2007 14:53:04 Dzonatas wrote: > This nuance is one of the reasons why people have screamed to implement > into the standard the "align" (or "alignof") keyword on the "new" > operator, such as: > > mem = new align[16] char[1024]; Isn't malloc/new supposed to align already on the largest boundary needed by the architecture? Meaning, if the largest alignment needed is 32 bits, then everything returned by malloc should be 32 bits aligned. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070923/b0a4a4a9/attachment-0001.pgp From secret.argent at gmail.com Sun Sep 23 06:36:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 23 06:36:18 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <1190531245.7423.17.camel@kitiara> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> <1190531245.7423.17.camel@kitiara> Message-ID: <0673EFA6-5BDF-4B2A-96C8-062214CFAF5E@gmail.com> On 23-Sep-2007, at 02:07, Anders Arnholm wrote: > No good programmer in the world breaks ANSI C, with out really good > reasoning behind it. That's why you need a diagnostic. That's not the same as forcing a cast that makes the code less portable. > long long isn't really that type, ptrdiff_t is a much better choose. 1. ptrdiff_t is a derived type. 2. ptrdiff_t is not guaranteed to be large enough to hold a pointer, only to hold the difference between two pointers to the same object. In a segmented architecture that's not necessarily large enough to hold a pointer, and the same is true for size_t. From mattk at electricsheepcompany.com Sun Sep 23 07:42:03 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Sun Sep 23 07:41:51 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> Message-ID: <46F67B3B.6020002@electricsheepcompany.com> Hey Michael, The 1.18.2.1 source didn't seem to make it onto the Wiki, but it was committed to the Subversion repository, in Branch-1.18.2-Viewer. Here's a snippet from the commit e-mail that went out, minus the diffs: Author: rob.linden Date: 2007-09-19 19:56:54 -0500 (Wed, 19 Sep 2007) New Revision: 103 Modified: branches/Branch_1-18-2-Viewer/indra/llcommon/llversion.h branches/Branch_1-18-2-Viewer/indra/newview/English.lproj/InfoPlist.strings branches/Branch_1-18-2-Viewer/indra/newview/Info-SecondLife.plist branches/Branch_1-18-2-Viewer/indra/newview/llstartup.cpp branches/Branch_1-18-2-Viewer/indra/newview/releasenotes.txt branches/Branch_1-18-2-Viewer/indra/newview/res/newViewRes.rc branches/Branch_1-18-2-Viewer/indra/newview/viewer.cpp Trac: http://svn.secondlife.com/trac/linden/changeset/103 Log: 1.18.2.1 security update http://blog.secondlife.com/2007/09/19/more-on-11821/ Last Changed Rev: 70095 Last Changed Date: 2007-09-19 12:36:26 -0700 (Wed, 19 Sep 2007) -Matt Michael Miller wrote: > I fired up SL today(using my home-compiled 1.18.2 source). First, I > noticed a message on the right side of the login screen: "Optional > Update." Then, I logged in. I got a message saying that I needed to > upgrade to 1.18.2.1. Unfortunately, I don't see any source code listed > for 1.18.2.1 on https://wiki.secondlife.com/wiki/Source_archive. Was > 1.18.2.1 intended to be optional? Is there any source code available > for 1.18.2.1? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From Anders at Arnholm.se Sun Sep 23 08:19:41 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Sun Sep 23 08:21:24 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <0673EFA6-5BDF-4B2A-96C8-062214CFAF5E@gmail.com> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> <3E857306-1057-4107-80C7-1E1F493E6069@gmail.com> <46F58D35.3070305@blueflash.cc> <26E47DF3-5266-44A3-BC68-4A89A3FC4EC9@gmail.com> <1190531245.7423.17.camel@kitiara> <0673EFA6-5BDF-4B2A-96C8-062214CFAF5E@gmail.com> Message-ID: <1190560781.7105.5.camel@kitiara> On Sun, 2007-09-23 at 08:36 -0500, Argent Stonecutter wrote: > 1. ptrdiff_t is a derived type. And how often in real programing is this a problem? > 2. ptrdiff_t is not guaranteed to be large enough to hold a pointer, > only to hold the difference between two pointers to the same object. > In a segmented architecture that's not necessarily large enough to > hold a pointer, and the same is true for size_t. Yes, but pointers, are held by the pointer variable there is no other portable solution. long long is not guaranteed either to be able to hold pointer. But it think this comes a away from the original problem. -- Anders Arnholm -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tao.takashi at googlemail.com Sun Sep 23 10:24:08 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sun Sep 23 10:24:10 2007 Subject: [sldev] informal SL architecture meetup in half an hour Message-ID: <23bbb49e0709231024m60037bb4ve6325eb724b59e29@mail.gmail.com> Just FYI: I am trying to explain the SL architecture working group to some interested people in about 30 minutes. It won't be too technical but I want to give them a little bit of insight of what this project is all about. Find more here: http://taotakashi.wordpress.com/2007/09/22/second-life-grid-architecture-meetup-tomorrow/ Feel free to come and help spread the word :-) (and now I should hurry and upload my slides etc. :-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070923/a5e6fd4a/attachment.htm From webmaster at ligosworld.com Sun Sep 23 13:31:07 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Sun Sep 23 13:31:17 2007 Subject: [sldev] Object and Texture Cache References: 46F5777C.5050705@ligosworld.com Message-ID: <46F6CD0B.2020506@ligosworld.com> I was at this point with the mDrawable as well a few days ago. But I didn't could find the point where the vertexbuffer gets filled. I had not really time on the weekend, but I will work on it tomorrow. Let's see what we will find. I would still be glad about some more help! Regards, Andi From gigstaggart at gmail.com Sun Sep 23 14:40:20 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 14:40:22 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F653CA.3050307@dzonux.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> <46F5D97A.6090300@dzonux.net> <46F6241D.1090208@gmail.com> <46F653CA.3050307@dzonux.net> Message-ID: <46F6DD44.9010104@gmail.com> Dzonatas wrote: > I understood that point, but SSE and # of CPUs are unrelated. The > attempt to argue against # of CPUs (as being the future instead of > sooner) with an argument about the state of SSE is not fair. You know, actually for the architecture interop it would be very nice to have an alternative client for testing. If you and a group of people want to get together and make a raytracing client for high-core CPUs, go for it, seriously! -Jason From gigstaggart at gmail.com Sun Sep 23 14:42:48 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 14:42:51 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> Message-ID: <46F6DDD8.60808@gmail.com> You can use the RCs instead. All of them (I think) still function currently (they have high enough message_template version) but only .5 has the exploit fix. -Jason From labrat.hb at gmail.com Sun Sep 23 15:12:50 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Sep 23 15:12:53 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F6DDD8.60808@gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> Message-ID: They forced the update on the RC's also... have to use .5 On 9/23/07, Jason Giglio wrote: > > You can use the RCs instead. All of them (I think) still function > currently (they have high enough message_template version) but only .5 > has the exploit fix. > > -Jason > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070923/a9b37476/attachment.htm From lenglish5 at cox.net Sun Sep 23 16:46:20 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 23 16:47:03 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F6DD44.9010104@gmail.com> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> <46F5D97A.6090300@dzonux.net> <46F6241D.1090208@gmail.com> <46F653CA.3050307@dzonux.net> <46F6DD44.9010104@gmail.com> Message-ID: <46F6FACC.5000302@cox.net> Jason Giglio wrote: > Dzonatas wrote: >> I understood that point, but SSE and # of CPUs are unrelated. The >> attempt to argue against # of CPUs (as being the future instead of >> sooner) with an argument about the state of SSE is not fair. > > You know, actually for the architecture interop it would be very nice > to have an alternative client for testing. > > If you and a group of people want to get together and make a > raytracing client for high-core CPUs, go for it, seriously! > > -Jason My own belief is that the GUI needs fixing before anything more interesting can reliably be done. Wish that Steve would release his ideas and let me and others critique. Things are terribly messy right now, and until that is sorted out, making a new graphics engine will likely have hidden gotchas due to the hight interprenetration of the GUI code with the graphics and other code How do you handle redrawing of the GUI windows in a ray-tracing engine, for example? What about those cute animated folder arrows in the inventory panel window? I don't understand how they're done currently under OpenGL, and I suspect trying to switch graphics engines without knowing that will result in even MORE kludges in order to restore broken GUI functionality, What about mouse coordinates? Etc? L. From dzonatas at dzonux.net Sun Sep 23 18:01:26 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Sep 23 17:59:53 2007 Subject: [sldev] Re: [VWR] Real-time Raytracing In-Reply-To: <46F6FACC.5000302@cox.net> References: <20070922190010.97A8A41B099@stupor.lindenlab.com> <46F58B0B.6040105@cox.net> <46F59550.2060201@boroon.dasgupta.ch> <46F5983A.1090305@dzonux.net> <7992d0d60709221649g55c0185anb1f482abded9c1ba@mail.gmail.com> <46F5D97A.6090300@dzonux.net> <46F6241D.1090208@gmail.com> <46F653CA.3050307@dzonux.net> <46F6DD44.9010104@gmail.com> <46F6FACC.5000302@cox.net> Message-ID: <46F70C66.1050402@dzonux.net> Lawson English wrote: > My own belief is that the GUI needs fixing before anything more > interesting can reliably be done. > > Wish that Steve would release his ideas and let me and others > critique. Things are terribly messy right now, and until that is > sorted out, making a new graphics engine will likely have hidden > gotchas due to the hight interprenetration of the GUI code with the > graphics and other code > > > How do you handle redrawing of the GUI windows in a ray-tracing > engine, for example? What about those cute animated folder arrows in > the inventory panel window? I don't understand how they're done > currently under OpenGL, and I suspect trying to switch graphics > engines without knowing that will result in even MORE kludges in order > to restore broken GUI functionality, What about mouse coordinates? Etc? > > Very good points. My plate has more than a few important things to chew on, and it's not easy to switch between each one. I've had to pick just one to focus on that'll return an income. I believe the wiki pages on UI would be a good place to note the points you made! =) -- Power to Change the Void From 1337mail at gmail.com Sun Sep 23 18:55:22 2007 From: 1337mail at gmail.com (Michael Miller) Date: Sun Sep 23 18:55:24 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> Message-ID: <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> How soon(approximately, of course) until the RCs become stable? On 9/23/07, Harold Brown wrote: > They forced the update on the RC's also... have to use .5 > > > On 9/23/07, Jason Giglio wrote: > > > > You can use the RCs instead. All of them (I think) still function > > currently (they have high enough message_template version) but only .5 > > has the exploit fix. > > > > -Jason > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > From gigstaggart at gmail.com Sun Sep 23 19:11:59 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 19:12:02 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> Message-ID: <46F71CEF.1000203@gmail.com> Michael Miller wrote: > How soon(approximately, of course) until the RCs become stable? > The RCs are stable. The idea is to find out if there are any regressions, if not, then the RC becomes the release, without further change. -Jason From gigstaggart at gmail.com Sun Sep 23 19:57:32 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 19:57:34 2007 Subject: [sldev] What color should I paint the bike shed? Message-ID: <46F7279C.9000208@gmail.com> http://jira.secondlife.com/browse/VWR-2491 VWR-2491 has been kinda bumping around a while, I'd really like to get some consensus before writing the patch. My proposal is to simply get rid of BMP snapshots and make PNG the default format for saving snapshots. So far I've gotten about 50/50 feedback saying "go for it" and "keep BMP as an option". Due to SL's cross platform nature, keeping BMP will likely require new UI on the snapshot floater. That's not a huge deal, but I'm not sure it's necessary since I still haven't heard any compelling arguments for keeping BMP other than "it's already in there". Does anyone have any compelling reason to keep BMP as an option, including new UI to select the format to save as? -Jason From tateru.nino at gmail.com Sun Sep 23 20:07:41 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Sep 23 20:07:46 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F7279C.9000208@gmail.com> References: <46F7279C.9000208@gmail.com> Message-ID: <46F729FD.8020205@gmail.com> Jason Giglio wrote: > http://jira.secondlife.com/browse/VWR-2491 > > VWR-2491 has been kinda bumping around a while, I'd really like to get > some consensus before writing the patch. > > My proposal is to simply get rid of BMP snapshots and make PNG the > default format for saving snapshots. > > So far I've gotten about 50/50 feedback saying "go for it" and "keep > BMP as an option". > > Due to SL's cross platform nature, keeping BMP will likely require new > UI on the snapshot floater. That's not a huge deal, but I'm not > sure it's necessary since I still haven't heard any compelling > arguments for keeping BMP other than "it's already in there". > > Does anyone have any compelling reason to keep BMP as an option, > including new UI to select the format to save as? I've got very little in the way of qualms about giving BMP the boot - except one. Writing the snapshot involves (correct me if I'm wrong) two basic phases. Encoding the image, and writing it to disk. During the encoding stage, the viewer essentially becomes non-responsive to the network (okay, this can happen during the write-to-disk phase as well, and BMP's are pathetically overweight). All that time taken multiplies the odds that the circuit to the primary simulator will break. That said, if this reduces the overall time that the viewer spends in fairyland while packets pile up on the floor, then hooray! -- Tateru Nino http://dwellonit.blogspot.com/ From gigstaggart at gmail.com Sun Sep 23 21:40:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 23 21:40:23 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <050f01c7fe59$5eaa9310$a4689943@gwsystems2.com> References: <050f01c7fe59$5eaa9310$a4689943@gwsystems2.com> Message-ID: <46F73FB5.9070304@gmail.com> Gary Wardell wrote: > Hi, > > Speaking for myself: > > I'm not particularly tied to bmp, other than I've gotten very good at using MS Paint. > > If there is another simple to use program that works with PNGs I'm fine with that. > > In general, if I take a snapshot I'd want to do something with it, so whatever the format is, it needs to be usable with some > readably available tool. Given that, MS Paint is on every windows system, and bmp, gif, and jpg are about all it can work with. MS Paint supports PNG in Windows 2000+ :P (copying to list because you probably just forgot to reply to all) -Jason From lenglish5 at cox.net Sun Sep 23 22:06:34 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 23 22:06:35 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F729FD.8020205@gmail.com> References: <46F7279C.9000208@gmail.com> <46F729FD.8020205@gmail.com> Message-ID: <46F745DA.1030308@cox.net> Tateru Nino wrote: > Jason Giglio wrote: > >> http://jira.secondlife.com/browse/VWR-2491 >> >> VWR-2491 has been kinda bumping around a while, I'd really like to get >> some consensus before writing the patch. >> >> My proposal is to simply get rid of BMP snapshots and make PNG the >> default format for saving snapshots. >> >> So far I've gotten about 50/50 feedback saying "go for it" and "keep >> BMP as an option". >> >> Due to SL's cross platform nature, keeping BMP will likely require new >> UI on the snapshot floater. That's not a huge deal, but I'm not >> sure it's necessary since I still haven't heard any compelling >> arguments for keeping BMP other than "it's already in there". >> >> Does anyone have any compelling reason to keep BMP as an option, >> including new UI to select the format to save as? >> > I've got very little in the way of qualms about giving BMP the boot - > except one. > Writing the snapshot involves (correct me if I'm wrong) two basic > phases. Encoding the image, and writing it to disk. > During the encoding stage, the viewer essentially becomes non-responsive > to the network (okay, this can happen during the write-to-disk phase as > well, and BMP's are pathetically overweight). All that time taken > multiplies the odds that the circuit to the primary simulator will break. > > That said, if this reduces the overall time that the viewer spends in > fairyland while packets pile up on the floor, then hooray! > > Why should this be the case? Asynchronous file i/o has been around a long time on home computers. I patched the MacOS's version in the mid-80's because SCSI-I wasn't properly defined back then and Apple's non-standard implementation depended on timing loops (which our Mac+ 68020 accelerator card broke) to fake it, but that was 20+ years ago. Surely Second Life can save a file to disk without blocking? And why should encoding block either? That's just lame. L. From sl at phoca.com Sun Sep 23 22:14:45 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Sun Sep 23 22:14:56 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F745DA.1030308@cox.net> References: <46F7279C.9000208@gmail.com> <46F729FD.8020205@gmail.com> <46F745DA.1030308@cox.net> Message-ID: There are a couple of places that SL is strangely non-async :( Uploading files also halts the viewer and causes some funny artifacts when is starts up again. WHY? Start a new thread for the file dialog... One of those things that /should/ be fixed but is unromantic and not really "problematic" and so will stay that way forever I would guess ;) Farallon ----- Original Message ----- From: "Lawson English" Cc: Sent: Sunday, September 23, 2007 10:06 PM Subject: Re: [sldev] What color should I paint the bike shed? > Tateru Nino wrote: >> Jason Giglio wrote: >> >>> http://jira.secondlife.com/browse/VWR-2491 >>> >>> VWR-2491 has been kinda bumping around a while, I'd really like to get >>> some consensus before writing the patch. >>> >>> My proposal is to simply get rid of BMP snapshots and make PNG the >>> default format for saving snapshots. >>> >>> So far I've gotten about 50/50 feedback saying "go for it" and "keep >>> BMP as an option". >>> >>> Due to SL's cross platform nature, keeping BMP will likely require new >>> UI on the snapshot floater. That's not a huge deal, but I'm not >>> sure it's necessary since I still haven't heard any compelling >>> arguments for keeping BMP other than "it's already in there". >>> >>> Does anyone have any compelling reason to keep BMP as an option, >>> including new UI to select the format to save as? >>> >> I've got very little in the way of qualms about giving BMP the boot - >> except one. >> Writing the snapshot involves (correct me if I'm wrong) two basic >> phases. Encoding the image, and writing it to disk. >> During the encoding stage, the viewer essentially becomes non-responsive >> to the network (okay, this can happen during the write-to-disk phase as >> well, and BMP's are pathetically overweight). All that time taken >> multiplies the odds that the circuit to the primary simulator will break. >> >> That said, if this reduces the overall time that the viewer spends in >> fairyland while packets pile up on the floor, then hooray! >> >> > > Why should this be the case? Asynchronous file i/o has been around a long > time on home computers. I patched the MacOS's version in the mid-80's > because SCSI-I wasn't properly defined back then and Apple's non-standard > implementation depended on timing loops (which our Mac+ 68020 accelerator > card broke) to fake it, but that was 20+ years ago. Surely Second Life can > save a file to disk without blocking? And why should encoding block > either? That's just lame. > > > L. > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Sun Sep 23 22:25:45 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 23 22:25:49 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <20070924044026.E6C8541B118@stupor.lindenlab.com> References: <20070924044026.E6C8541B118@stupor.lindenlab.com> Message-ID: From: Jason Giglio > Does anyone have any compelling reason to keep BMP as an option, > including new UI to select the format to save as? Windows users can edit BMPs (crop them, etc) with Windows Paint. They can't do that for other formats. Uploaded PNG and TGS come in as alpha textures, and even if they're 100% opaque for all pixels you get alpha rendering issues. So being able to save in a format that most users can just edit and upload is valuable. The second issue can be fixed with a smarter uploader (at least one with the ability to specify whether alpha is maintained). The first, not without help from Microsoft. :) From jhurliman at wsu.edu Sun Sep 23 22:39:19 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Sep 23 22:40:23 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: References: <46F7279C.9000208@gmail.com> <46F729FD.8020205@gmail.com> <46F745DA.1030308@cox.net> Message-ID: <46F74D87.1030700@wsu.edu> This is historical. The old upload system had no way of handling multiple simultaneous uploads. We hacked support for it in to libsl but it is really ugly, and if you start two uploads at the same time there is a race condition in the protocol. When the old system is completely deprecated out in favor of the new CAPS uploading this could be changed. John Hurliman SL - Farallon Greyskin wrote: > There are a couple of places that SL is strangely non-async :( > Uploading files also halts the viewer and causes some funny artifacts > when is starts up again. WHY? Start a new thread for the file dialog... > > One of those things that /should/ be fixed but is unromantic and not > really "problematic" and so will stay that way forever I would guess ;) > > Farallon > > ----- Original Message ----- From: "Lawson English" > Cc: > Sent: Sunday, September 23, 2007 10:06 PM > Subject: Re: [sldev] What color should I paint the bike shed? > > >> Tateru Nino wrote: >>> Jason Giglio wrote: >>> >>>> http://jira.secondlife.com/browse/VWR-2491 >>>> >>>> VWR-2491 has been kinda bumping around a while, I'd really like to get >>>> some consensus before writing the patch. >>>> >>>> My proposal is to simply get rid of BMP snapshots and make PNG the >>>> default format for saving snapshots. >>>> >>>> So far I've gotten about 50/50 feedback saying "go for it" and "keep >>>> BMP as an option". >>>> >>>> Due to SL's cross platform nature, keeping BMP will likely require new >>>> UI on the snapshot floater. That's not a huge deal, but I'm not >>>> sure it's necessary since I still haven't heard any compelling >>>> arguments for keeping BMP other than "it's already in there". >>>> >>>> Does anyone have any compelling reason to keep BMP as an option, >>>> including new UI to select the format to save as? >>>> >>> I've got very little in the way of qualms about giving BMP the boot - >>> except one. >>> Writing the snapshot involves (correct me if I'm wrong) two basic >>> phases. Encoding the image, and writing it to disk. >>> During the encoding stage, the viewer essentially becomes >>> non-responsive >>> to the network (okay, this can happen during the write-to-disk phase as >>> well, and BMP's are pathetically overweight). All that time taken >>> multiplies the odds that the circuit to the primary simulator will >>> break. >>> >>> That said, if this reduces the overall time that the viewer spends in >>> fairyland while packets pile up on the floor, then hooray! >>> >>> >> >> Why should this be the case? Asynchronous file i/o has been around a >> long time on home computers. I patched the MacOS's version in the >> mid-80's because SCSI-I wasn't properly defined back then and Apple's >> non-standard implementation depended on timing loops (which our Mac+ >> 68020 accelerator card broke) to fake it, but that was 20+ years ago. >> Surely Second Life can save a file to disk without blocking? And why >> should encoding block either? That's just lame. >> >> >> L. >> >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gwardell at gwsystems.co.il Sun Sep 23 22:42:44 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sun Sep 23 22:42:49 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F73FB5.9070304@gmail.com> Message-ID: <052801c7fe6d$bbb01d00$a4689943@gwsystems2.com> Hi, Not in my version of MS Paint. Win2K SP4 Besides, I said I'd go with another commonly available tool that was easy to install and use. --------------------------- Paint --------------------------- \\webserver\Chart-tmp\rad01BD4.tmp.png Paint cannot read this file. This is not a valid bitmap file, or its format is not currently supported. --------------------------- > -----Original Message----- > From: Jason Giglio [mailto:gigstaggart@gmail.com] > Sent: Mon, September 24, 2007 12:40 AM > To: Gary Wardell; sldev@lists.secondlife.com >> Second Life Developer > Mailing List > Subject: Re: [sldev] What color should I paint the bike shed? > > > Gary Wardell wrote: > > Hi, > > > > Speaking for myself: > > > > I'm not particularly tied to bmp, other than I've gotten > very good at using MS Paint. > > > > If there is another simple to use program that works with > PNGs I'm fine with that. > > > > In general, if I take a snapshot I'd want to do something > with it, so whatever the format is, it needs to be usable with some > > readably available tool. Given that, MS Paint is on every > windows system, and bmp, gif, and jpg are about all it can work with. > > MS Paint supports PNG in Windows 2000+ > > :P > > (copying to list because you probably just forgot to reply to all) > > -Jason > > From gigstaggart at gmail.com Mon Sep 24 00:33:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 24 00:33:23 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <052801c7fe6d$bbb01d00$a4689943@gwsystems2.com> References: <052801c7fe6d$bbb01d00$a4689943@gwsystems2.com> Message-ID: <46F76841.3030707@gmail.com> Gary Wardell wrote: > Hi, > > Not in my version of MS Paint. > Win2K SP4 > > Besides, I said I'd go with another commonly available tool that was easy to install and use. Oh, sorry, it's Win XP Paint and later. -Jason From gigstaggart at gmail.com Mon Sep 24 00:35:42 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 24 00:35:43 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: References: <20070924044026.E6C8541B118@stupor.lindenlab.com> Message-ID: <46F768CE.90908@gmail.com> Argent Stonecutter wrote: > From: Jason Giglio >> Does anyone have any compelling reason to keep BMP as an option, >> including new UI to select the format to save as? > > Windows users can edit BMPs (crop them, etc) with Windows Paint. They > can't do that for other formats. > Uploaded PNG and TGS come in as alpha textures, and even if they're 100% > opaque for all pixels you get alpha rendering issues. > So being able to save in a format that most users can just edit and > upload is valuable. > > The second issue can be fixed with a smarter uploader (at least one with > the ability to specify whether alpha is maintained). > The first, not without help from Microsoft. :) > Well as I pointed out elsewhere, MS Paint in Win XP+ apparently does support PNG. As for your other issue, that is somewhat valid, but you are right, really that's a bug in the upload that should be fixed. Hmm. Thanks. -Jason From hud at zurich.ibm.com Mon Sep 24 01:01:25 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 01:04:55 2007 Subject: [sldev] Permissions In-Reply-To: <1189622927.18800.10.camel@localhost> References: <46E806E7.1010104@corp.telexs.nl> <50603.86.10.79.229.1189611769.squirrel@webmail.terminaldischarge.net> <00e001c7f557$2be5aa60$6500a8c0@MUDDY> <1189622927.18800.10.camel@localhost> Message-ID: <46F76ED5.1090408@zurich.ibm.com> Callum Lerwick wrote: > On Wed, 2007-09-12 at 11:08 -0500, Black Hat Design wrote: > >> Maybe.. Just Maybe, it is so you cannot take a copiable item, keep a copy >> for yourself and then sell the other one! >> > > Yes, if there was no "no transfer", people selling stuff would have to > set it "no copy". Which, if its modifyable, means you can't make a > backup before you mod it. > > "no transfer" is the lesser evil IMHO. But still evil. > > People selling stuff mod/no-copy should be dragged out in the street and > shot. > and useless anyhow as the client will have access to the prims and textures anyhow. the only thing that this might protect is a script inside a prim... ...which becomes an interesting concept once we have a virtual universe (i.e., interconnected grids, each operated by different providers) -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/eeb42ea5/attachment.htm From hud at zurich.ibm.com Mon Sep 24 02:07:00 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 02:07:15 2007 Subject: [sldev] Permissions In-Reply-To: References: <46E806E7.1010104@corp.telexs.nl> Message-ID: <46F77E34.9010305@zurich.ibm.com> SL - Farallon Greyskin wrote: > [...] > > If there are any changes to the permission system (other than fixes > for current brokenness like mod/copy objects going no mod when they > are taken from world when they contain a no mod script) it would be > nice to be able to do things like set an object for sale /permanently/ > rather than just for one generation, and possibly allow a temp > transfer so that everything could be set to "gift" and then the owner > could give it away and people could regift etc until someone "claimed" > it... > > Farallon i think that the whole permissions systems is an "honor" system at best. why? well, the client --- or better: a client --- will always get the prim coordinates as well as the texture references from the grid. with open source clients you cannot count on nor can you guarantee that they will NOT act as a "copy bot" --- with the exception of scripts, but with open grids/open sims that will change as well. as the "DRM" debacle of the last years has shown, "DRM" never really works in the end --- and it always drags with it more problems (useability, maintainability, etc), that become a pain to interact with. just my humble opinion, though. feel free to disagree :-) cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From tao.takashi at googlemail.com Mon Sep 24 02:21:12 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 02:21:18 2007 Subject: [sldev] Permissions In-Reply-To: <46F77E34.9010305@zurich.ibm.com> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> Message-ID: <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> i think that the whole permissions systems is an "honor" system at best. > why? well, the client --- or better: a client --- will always get the > prim coordinates as well as the texture references from the grid. with > open source clients you cannot count on nor can you guarantee that they > will NOT act as a "copy bot" --- with the exception of scripts, but with > open grids/open sims that will change as well. > > as the "DRM" debacle of the last years has shown, "DRM" never really > works in the end --- and it always drags with it more problems > (useability, maintainability, etc), that become a pain to interact with. Regarding an open grid: Wouldn't it still be more practical for somebody to copy via a client hack than via a server hack if it's not about scripts? Should be easier than trying to get people on your sim to copy it. Of course scripts are an issue but for the LL grid it will certainly come down to be a trust issue. Linden Lab needs will most probably have a TOS in place for connecting to their grid. But as was obvious in the meeting yesterday, the copy problem seems to be one of the main issues, at least for some. I haven't yet talked to content creators how big they see that issue (and it might also need some explanation and beside that an open grid of course offers a bigger market and other opportunities than just problems). But in any case Linden Lab should address this issue and maybe reveal a bit on how they think it might work regarding connection of foreign servers. For me it would also be interesting to know how much of the content in world is actually bought content and how much is just made for fun (e.g. on the web we have right now a big community of people creating stuff just for fun and I am interested to know how much this is the case for the SL community). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/c26cf345/attachment.htm From dale at daleglass.net Mon Sep 24 02:25:40 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 24 02:25:58 2007 Subject: [sldev] Permissions In-Reply-To: <46F77E34.9010305@zurich.ibm.com> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> Message-ID: <200709241125.46563.dale@daleglass.net> On Monday 24 September 2007 11:07:00 dirk husemann wrote: > i think that the whole permissions systems is an "honor" system at best. > why? well, the client --- or better: a client --- will always get the > prim coordinates as well as the texture references from the grid. with > open source clients you cannot count on nor can you guarantee that they > will NOT act as a "copy bot" --- with the exception of scripts, but with > open grids/open sims that will change as well. They don't have to. Simply add a new flag: "Bind to domain". When set on an item, the originating server refuses to hand it out to one owned by somebody else. So an asset with my scripts would be simply forced to remain on the LL grid. If the script remains there, and the LL grid doesn't out the source to it, then it still remains safe. > as the "DRM" debacle of the last years has shown, "DRM" never really > works in the end --- and it always drags with it more problems > (useability, maintainability, etc), that become a pain to interact with. Not my personal opinion, but content providers argue that even if a perfect solution isn't possible, permissions should still exist, if only as a way of indicating the will of the author. There is a certain sense in forcing people to bypass the system, even if it's very weak. If you bypassed it, you can't really argue you didn't know what the creator wanted. Really, IMO, the permissions system should continue to exist. If you don't want to restrict your own stuff, then don't, and just release all your stuff as full perms. But there are a lot of people who will be really annoyed should it vanish completely. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/c62e047f/attachment.pgp From dale at daleglass.net Mon Sep 24 02:42:44 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 24 02:43:13 2007 Subject: [sldev] Permissions In-Reply-To: <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> Message-ID: <200709241142.58284.dale@daleglass.net> On Monday 24 September 2007 11:21:12 Tao Takashi wrote: > Regarding an open grid: Wouldn't it still be more practical for somebody > to copy via a client hack than via a server hack if it's not about > scripts? Should be easier than trying to get people on your sim to copy > it. Probably, yeah. Have in mind though that content creators are artists and not necessarily very technically knowledgeable, so some of them will worry about things that seem quite clear to us. > > Of course scripts are an issue but for the LL grid it will certainly > come down to be a trust issue. Linden Lab needs will most probably have > a TOS in place for connecting to their grid. > > But as was obvious in the meeting yesterday, the copy problem seems to > be one of the main issues, at least for some. I haven't yet talked to > content creators how big they see that issue (and it might also need > some explanation and beside that an open grid of course offers a bigger > market and other opportunities than just problems). Well, I was involved in one talk of the sort, and at least from the conversation I had, I'd say they're VERY worried. In fact, they tried very hard to try to convince me of their position, hoping that I hold enough influence here (hah) to convince people here not to create a grid design that'd drive them out of business. Note here that I'm not saying what I am simply because I've been asked to, I really think having an economy is a good thing for SL, and IMO the current permissions system is quite reasonable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/52fb2fab/attachment.pgp From hud at zurich.ibm.com Mon Sep 24 02:46:06 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 02:46:35 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> Message-ID: <46F7875E.4040200@zurich.ibm.com> Matthew Dowd wrote: > > I'm still playing catch up so this may have already been mentioned, > but I think it would also be worth considering how the Region > simulator (or rather components) maps to actual servers, and (as I > think has been suggested) start considering computer grid computing > based architectures (http://en.wikipedia.org/wiki/Grid_computing) to > handle the region scalability problem (e.g. regions with >100 users). > > So for instance, initially a region sim with only a few users may be > running on a compute node (which might be a cluster) alongside other > regions. > > As the region gets busier it might move itself to a more powerful node > or a node running fewer regions (or perhaps a dedicated node). > > At some point it might start splitting tasks - so the physic engine > gets moved to one node, and the script engine to another. > > As the load really increases it may even split sub tasks - e.g. > splitting the script engine between two nodes (of course, this may > introduce communication latencies). > > I've worked with grid computing enough to know that the above is not > trivial, and is much easier to express than actually do, but I think > it worth considering this in the architecture discussions - at the > very least the architecture should support the above even if not > initially implement it. good points, really. my thinking is that the current segmentation should only be a model to use when defining the *network protocols* --- and we should try and come up with other models to work against as well! if we manage to describe the grid in terms of protocols without imposing a fixed way of segmenting it into services (or only a small amount of it), we should then be able to implement all kinds of grid service provider systems. what are your thoughts? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/512fdcee/attachment.htm From hud at zurich.ibm.com Mon Sep 24 02:47:11 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 02:47:15 2007 Subject: [sldev] [ARCH] Raw notes from the Second Life Grid Architecture Working Group. In-Reply-To: <23bbb49e0709160417n4268f5edle9bfb52e4ce621a8@mail.gmail.com> References: <46E9D388.3030204@lindenlab.com> <23bbb49e0709140815r57b9e966nee630dbab6b90d62@mail.gmail.com> <46EAE987.9080009@lindenlab.com> <4D602B6B-FC49-42D6-85EB-E35FA7E6338A@lindenlab.com> <23bbb49e0709160417n4268f5edle9bfb52e4ce621a8@mail.gmail.com> Message-ID: <46F7879F.4030304@zurich.ibm.com> Tao Takashi wrote: > Hi! > > > I'm still playing catch up so this may have already been > mentioned, but I think it would also be worth considering how the > Region simulator (or rather components) maps to actual servers, > and (as I think has been suggested) start considering computer > grid computing based architectures ( > http://en.wikipedia.org/wiki/Grid_computing) to handle the region > scalability problem (e.g. regions with >100 users). > > > > The region hosts you see in the diagram can probably be anything, a > single host, a cluster, whatever.. For a start there will probably be > the simulators we know but later on people could experiment with more > complex setups (and I guess at least folks like Intel, IBM or Sun will > definitely want to use their technology which might support this). > > As I see it those boxes are just there for showing where interfaces > need to be defined. and as zha pointed out, we should think about different boxes, different ways of drawing those boundaries as well. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/324ffc55/attachment-0001.htm From hud at zurich.ibm.com Mon Sep 24 03:16:21 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 03:16:26 2007 Subject: [sldev] Vivox SLVoice.exe documentation In-Reply-To: <20070918103020.GA5649@bruno.sbruno> References: <46EF74EF.5070800@lindenlab.com> <20070918103020.GA5649@bruno.sbruno> Message-ID: <46F78E75.7060109@zurich.ibm.com> Dale Glass wrote: > On Mon, Sep 17, 2007 at 11:49:19PM -0700, Rob Lanphier wrote: > >> Hi all, >> >> Attached is the documentation from Vivox for interacting with the >> SLVoice.exe component of the Second Life viewer. This documentation >> will be bundled with the library bundle of the viewer, but I'm including >> this now for your convenience. >> >> Rob >> > > Rob, documentation is a good thing to have, but under those terms > (judging by John's post), I'm not going to touch that with a 10 foot > pole. > > Please DO NOT include that in any package, I don't want to see that even > by accident. I think you shouldn't have attached that at all, in fact. > i agree... those are almost "confidential disclosure agreement" terms --- some of us can get into trouble for receiving stuff like that without having gone through "legal"... please, don't do this again...and, please, get us a description of the interfaces that is open! cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/0e2ebc1f/attachment.htm From hud at zurich.ibm.com Mon Sep 24 03:18:33 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 03:18:57 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> Message-ID: <46F78EF9.4000903@zurich.ibm.com> Argent Stonecutter wrote: > From: "Tao Takashi" >> I am not sure it will. I think the mesh and all the things an avatar >> is made up of will be transferred to the region for simulating it. > > The region doesn't simulate an avatar. All it does is deliver the > textures and appearance parameters to the client. The avatar mesh is > in the client. hmm...but where are collisions detected? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 03:20:25 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 03:21:30 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46EFEE29.3000709@watson.ibm.com> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> Message-ID: <46F78F69.60109@zurich.ibm.com> Mike Monkowski wrote: > John Hurliman wrote: >> I can't make use of that documentation myself since I'm supposed to >> be working on things like porting the voice daemon, but maybe someone >> could. > > I've already put a lot of documentation out on the Wiki about Voice, > and my interests are not in cloning it, so I don't think there's any > problem for me to look at the SDK documentation and add to the Wiki. > If doing so would compromise anyone else's position, let me know. the question is: can any of the OS devs make use of that documentation to implement a clone given the pedigree? is that information "tainted" in any way? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From nicholaz at blueflash.cc Mon Sep 24 03:22:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 03:22:27 2007 Subject: [sldev] Permissions In-Reply-To: <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> Message-ID: <46F78FDA.2090309@blueflash.cc> Tao Takashi wrote: > But as was obvious in the meeting yesterday, the copy problem seems to > be one of the main issues, at least for some. I haven't yet talked to > content creators how big they see that issue (and it might also need > some explanation and beside that an open grid of course offers a bigger > market and other opportunities than just problems). I'm sure it would be close to impossible for LL to do away with permissions as they are now. If ever, I'd see this as a separate metasphere being based on full-perm content, which would draw an entirely different type of users/content creators and create a different atmosphere. I remember an interview with Daniel Linden where he said that this was how SL was envisioned but that it really got kick-started when they entered real commerce. That was sure good for LL because people are willing to pay tier when they have the impression that they can earn the money back, but independent of that I'm getting increasingly annoyed by the whole atmosphere created through content commerce and would probably do a lot more content in an open-content themed world. The thing I would want to see from Linden Labs is for once that they get their permissions at least working as they are supposed to. I had at least three items in the last couple of weeks where permissions I had were lost. Another thing I'd like to see is a GPL style permission, that is creating a full perm object that remains full perm and can't be merged/linked/embedded into an less perm object. I'd have a few ideas how this could lead into sort of parallel universe, at lest in terms of content. Nick From nik at terminaldischarge.net Mon Sep 24 03:35:32 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Mon Sep 24 03:35:33 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <46F78F69.60109@zurich.ibm.com> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> <46F78F69.60109@zurich.ibm.com> Message-ID: <50321.86.10.79.229.1190630132.squirrel@webmail.terminaldischarge.net> > Mike Monkowski wrote: >> John Hurliman wrote: >>> I can't make use of that documentation myself since I'm supposed to >>> be working on things like porting the voice daemon, but maybe someone >>> could. >> >> I've already put a lot of documentation out on the Wiki about Voice, >> and my interests are not in cloning it, so I don't think there's any >> problem for me to look at the SDK documentation and add to the Wiki. >> If doing so would compromise anyone else's position, let me know. > the question is: can any of the OS devs make use of that documentation > to implement a clone given the pedigree? is that information "tainted" > in any way? > > cheers, > dirk Which ever linden posted it (sorry my memory isn't so good) has re-posted the documentation in jira, but this time with alot less restrictive license. Basically, "use as you will, but vivox will not accept resonsibilty if anything goes wrong." terms. > > -- > dr dirk husemann, pervasive computing, ibm zurich research lab > --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nik at terminaldischarge.net Mon Sep 24 03:37:08 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Mon Sep 24 03:37:09 2007 Subject: [sldev] Permissions In-Reply-To: <46F78FDA.2090309@blueflash.cc> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> <46F78FDA.2090309@blueflash.cc> Message-ID: <50327.86.10.79.229.1190630228.squirrel@webmail.terminaldischarge.net> > > Tao Takashi wrote: >> But as was obvious in the meeting yesterday, the copy problem seems to >> be one of the main issues, at least for some. I haven't yet talked to >> content creators how big they see that issue (and it might also need >> some explanation and beside that an open grid of course offers a bigger >> market and other opportunities than just problems). > > I'm sure it would be close to impossible for LL to do away with > permissions as they are now. > > If ever, I'd see this as a separate metasphere being based on > full-perm content, which would draw an entirely different type > of users/content creators and create a different atmosphere. > > I remember an interview with Daniel Linden where he said that this > was how SL was envisioned but that it really got kick-started > when they entered real commerce. That was sure good for LL because > people are willing to pay tier when they have the impression that > they can earn the money back, but independent of that I'm getting > increasingly annoyed by the whole atmosphere created through > content commerce and would probably do a lot more content in an > open-content themed world. > > > The thing I would want to see from Linden Labs is for once that > they get their permissions at least working as they are supposed > to. I had at least three items in the last couple of weeks where > permissions I had were lost. > > Another thing I'd like to see is a GPL style permission, that is > creating a full perm object that remains full perm and can't be > merged/linked/embedded into an less perm object. I'd have a few > ideas how this could lead into sort of parallel universe, at lest > in terms of content. > > > > Nick You know, I like that idea. Nik > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tao.takashi at googlemail.com Mon Sep 24 03:43:57 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 03:43:59 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <50321.86.10.79.229.1190630132.squirrel@webmail.terminaldischarge.net> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> <46F78F69.60109@zurich.ibm.com> <50321.86.10.79.229.1190630132.squirrel@webmail.terminaldischarge.net> Message-ID: <23bbb49e0709240343h5f31fb2eqa84c68f228153c63@mail.gmail.com> > Which ever linden posted it (sorry my memory isn't so good) has re-posted > the documentation in jira, but this time with alot less restrictive > license. Basically, "use as you will, but vivox will not accept > resonsibilty if anything goes wrong." terms. And Joe explained at the Open Source meetup that these are the results of Linden Lab talking to Vivox in getting them more into Open Source. Joe said that Linden Lab is committed to Open Source and they also try to make voice part of that. It's just a process to sort out problems Vivox might see there and to get everybody happy (that's from my memory, chatlog should be up somewhere on the wiki but I don't know where at the moment, link was posted here a few days ago IIRC). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/5588718c/attachment.htm From dale at daleglass.net Mon Sep 24 03:47:42 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 24 03:47:48 2007 Subject: [sldev] Permissions In-Reply-To: <46F78FDA.2090309@blueflash.cc> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> <46F78FDA.2090309@blueflash.cc> Message-ID: <20070924104742.GA21308@bruno.sbruno> On Mon, Sep 24, 2007 at 12:22:18PM +0200, Nicholaz Beresford wrote: > I remember an interview with Daniel Linden where he said that this > was how SL was envisioned but that it really got kick-started > when they entered real commerce. That was sure good for LL because > people are willing to pay tier when they have the impression that > they can earn the money back, but independent of that I'm getting > increasingly annoyed by the whole atmosphere created through > content commerce and would probably do a lot more content in an > open-content themed world. Well, not just the impression :-) I actually earned money from SL, and after more than a year here with tier and premium account I still earned more than I spent. I like that :-) The commercialism doesn't really annoy me as I just don't go to the places that are full of it. There are actually places on the grid that aren't all full of malls. > The thing I would want to see from Linden Labs is for once that > they get their permissions at least working as they are supposed > to. I had at least three items in the last couple of weeks where > permissions I had were lost. Agreed > > Another thing I'd like to see is a GPL style permission, that is > creating a full perm object that remains full perm and can't be > merged/linked/embedded into an less perm object. I'd have a few > ideas how this could lead into sort of parallel universe, at lest > in terms of content. Agreed! I think it would also do good by clarifying what we're up to. I've had to explain that yes, people who license their work under the GPL also sue for copyright infringement :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/b927d78c/attachment-0001.pgp From tofu.linden at lindenlab.com Mon Sep 24 03:55:45 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Sep 24 03:56:02 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F52A15.9070609@blueflash.cc> References: <46F4D041.3060502@gmail.com> <46F4E1A2.4070701@gmail.com> <46F52A15.9070609@blueflash.cc> Message-ID: <46F797B1.3080507@lindenlab.com> Nicholaz Beresford wrote: > > I'm not sure what the correct portable correct version is to make a > > patch thats good for 32 and 64 systems. > > I'd say do it as (unsigned long). ULONG should have a size large > enough on both versions to hold the numeric equivalent of a pointer. If I understand the question correctly, I think intptr_t or uintptr_t are probably what you're looking for. -Tofu From hud at zurich.ibm.com Mon Sep 24 04:18:41 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:18:47 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F0077E.60008@watson.ibm.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F0077E.60008@watson.ibm.com> Message-ID: <46F79D11.9080903@zurich.ibm.com> Mike Monkowski wrote: > Argent Stonecutter wrote: >> From: "Tao Takashi" >> >>> I am not sure it will. I think the mesh and all the things an >>> avatar is made up of will be transferred to the region for >>> simulating it. >> >> >> The region doesn't simulate an avatar. All it does is deliver the >> textures and appearance parameters to the client. The avatar mesh is >> in the client. > > It is now, but do you want to keep it that way? off-load as much to the client as possible (and as we can get away with) seems a reasonable approach. not? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 04:25:38 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:25:48 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F01279.9000706@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <46EEF77F.3040405@gmail.com> <46F01279.9000706@watson.ibm.com> Message-ID: <46F79EB2.9070208@zurich.ibm.com> Mike Monkowski wrote: > Jason Giglio wrote: >> I'm going to ignore the rest of your message, because I think your >> underlying assumptions and understandings were pretty flawed. Lets >> get those sorted out before we get too far ahead of things. > > It's not a matter of sorting them out to get them right unless you're > already sure that you have the "right" architecture. I may have > misrepresented what was originally meant for the diagrams because I > don't know what that was. But I wasn't trying to explain that. I was > just using the existing diagrams for purposes of illustrating where I > thought the information should reside and how it should be transferred > to the viewer. > i think mike's suggestion does make sense and we should discuss it and include in the wiki pages --- one of the work items, IIRC, was to think about alternative ways of structuring the grid. cheers, dirk aka dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 04:23:43 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:27:45 2007 Subject: [sldev] [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F00F4C.9080703@watson.ibm.com> References: <46EEE207.4080801@watson.ibm.com> <1190075181.23349.4.camel@localhost> <46F00F4C.9080703@watson.ibm.com> Message-ID: <46F79E3F.9010705@zurich.ibm.com> Mike Monkowski wrote: > Callum Lerwick wrote: >> Avatar meshes are an asset, thus belong in asset storage. :) > > But when an avatar visits a region, everyone else in the region will > need the mesh information. They should not have to go back to asset > storage to get it. so in that case, if i follow what you are suggesting (i hope i do ;-), the region domain would fetch an AV's mesh info from the asset storage and then provide it to all AVs in the region? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 04:27:58 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:28:32 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> Message-ID: <46F79F3E.3050206@zurich.ibm.com> Argent Stonecutter wrote: > On 18-Sep-2007, at 12:22, Ryan Williams (Which) wrote: >> Argent Stonecutter wrote: >>> From: "Tao Takashi" >>>> I am not sure it will. I think the mesh and all the things an >>>> avatar is made up of will be transferred to the region for >>>> simulating it. > >>> The region doesn't simulate an avatar. All it does is deliver the >>> textures and appearance parameters to the client. The avatar mesh is >>> in the client. > >> It also calculates the collisions between avatars and the rest of the >> world, and runs the scripts in attachments, and makes the decision of >> when to deliver the representation to other agents, which is a >> non-trivial calculation. Maybe you meant something else, but the >> simulator definitely does more than just act as a bit pipe for avatars. > > What I mean is that as far as the sim is concerned, the avatar is a > box. Apart from the overall size, the avatar shape takes no part in > the physical simulation of the avatar, and the sim doesn't take the > mesh and other visual characteristics of the actual avatar into > account when dealing with it. Even scripted attachments don't involve > the sim having to know anything about the mesh or avatar settings... > all attachments are considered to be in the same place as far as the > sim goes. I don't know if that place is the exact center of the > bounding box, but it's not far off it, and the actual prims in the > attachments are all phantom and don't interact in collisions either. the question is: do we want to keep it that way or do we want to open up the possibility of taking the actual shape into account when calculating collisions? the later doesn't prevent us from having a region server that just uses the center point of the avatar... cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 04:29:17 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:29:29 2007 Subject: [sldev] [ARCH] Architecture Working Group in the wiki In-Reply-To: <23bbb49e0709181211u2e46b71bo9d3a35d2a431b70@mail.gmail.com> References: <23bbb49e0709181211u2e46b71bo9d3a35d2a431b70@mail.gmail.com> Message-ID: <46F79F8D.3030208@zurich.ibm.com> Tao Takashi wrote: > Hi! > > I just wanted to summarize a bit what I've done in the wiki for this > project. So it all starts at > > https://wiki.secondlife.com/wiki/Architecture_Working_Group > > > From there I created pages which describe the proposed architecture as > I understood it when Zero was talking about it. Feel free to correct > me there or add more detail. > > Then I also added a Use Case page which already has some use cases and > scenarios on it. Gigs also added some Strategic Goals which might help > in finding the scope. My idea for now is though to think outside any > scope for a while which is the reason for the blue sky scenarios there. > > As not everything fits into use case descriptions (after all they > actually should only explain how the user directly interacts with the > system and are maybe more useful for the viewer. But for now we migth > see the components as the user) I also added a brainstorming section > which is free form: > > https://wiki.secondlife.com/wiki/Brainstorming > > I would define the scope later then by collecting which features and > requirements we want to model. Apparently these will be at least all > the existing ones plus X. Then we could go in depth with the use cases > and define protocols between the components. > > One first workitem might be to discuss other ways of decomposing based > on the requirements we come up with. After we then decide to either > stay with that setup or change it, it will be easier to define use > cases as the components are fixed then. > > Anyway, feel free to edit and hope to meet some of you at Zero's > office hour :-) > > Oh, and does this project need some (temporary) name actually? For me > it's sometimes hard to say people what I am working on and I come up > with something like "new SL architecture" etc. > > cheers, > > Tao > > PS: I am also thinking about doing some in-world meetings to maybe > explain this thing to some more people. There seems to be interest. > And I think it also needs to get publicized more. After all I think > this project is rather drastic in the approach used and the thing > being made and if it's really the start of e new internet then it > should get more attention IMHO :-) tao, count me in on the in-world meetings bit :-) cheers, dirk aka dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/209a1e2a/attachment.htm From secret.argent at gmail.com Mon Sep 24 04:55:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 04:55:42 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F768CE.90908@gmail.com> References: <20070924044026.E6C8541B118@stupor.lindenlab.com> <46F768CE.90908@gmail.com> Message-ID: <0A8760DC-1CBA-49A8-A043-60DAEBA6A7AE@gmail.com> On 24-Sep-2007, at 02:35, Jason Giglio wrote: > Well as I pointed out elsewhere, MS Paint in Win XP+ apparently > does support PNG. Not in Windows 2000, which is still supported (and is the last version of Windows that's big-brother-free). From hud at zurich.ibm.com Mon Sep 24 04:58:23 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 04:58:28 2007 Subject: [sldev] New version of Vivox-SLVoice documentation uploaded to JIRA In-Reply-To: <46F2DC77.6010700@lindenlab.com> References: <46F2DC77.6010700@lindenlab.com> Message-ID: <46F7A65F.30703@zurich.ibm.com> Rob Lanphier wrote: > Hi folks, > > Rather than distributing on this list, I've uploaded new documentation > to this jira task: > https://jira.secondlife.com/browse/VWR-2029 > > The main difference is a less restrictive copyright notice, quoted here: > >> By releasing the specification to the SLVoice interfaces, we hope to >> take another step to help you better >> utilize the voice and communications services Vivox provides. We look >> forward to working with and >> getting feedback from the Second Life Community regarding ways in >> which Vivox can enrich and expand >> communications in Second Life in a scalable, high-quality manner. >> >> This manual, including its content and any portion thereof >> (collectively, the ?Content?), is a work protected >> by copyright and is the sole and exclusive property of Vivox, Inc. >> (?Vivox?). >> The Content is provided ``as is?? and without any expressed or implied >> warranties. In no event will Vivox >> be liable for any direct, indirect, incidental, special, exemplary, or >> consequential damages, however >> caused and on any theory of liability, whether in contract, strict >> liability, or tort (including negligence or >> otherwise) arising in any way out of the use of the Content, even if >> advised of the possibility of such >> damages. >> >> You can provide feedback regarding issues or suggestions related to >> this document its use by sending >> email to sl-feedback@vivox.com, >> > > Sorry for sending the doc as an attachment last time.....it didn't occur > to me to attach in JIRA, and I didn't want to put it on the wiki for > fear that people would assume the notice there applied. > > Rob > thx dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/1750329f/attachment.htm From nicholaz at blueflash.cc Mon Sep 24 05:01:55 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 05:01:59 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <0A8760DC-1CBA-49A8-A043-60DAEBA6A7AE@gmail.com> References: <20070924044026.E6C8541B118@stupor.lindenlab.com> <46F768CE.90908@gmail.com> <0A8760DC-1CBA-49A8-A043-60DAEBA6A7AE@gmail.com> Message-ID: <46F7A733.2060802@blueflash.cc> Argent Stonecutter wrote: > On 24-Sep-2007, at 02:35, Jason Giglio wrote: >> Well as I pointed out elsewhere, MS Paint in Win XP+ apparently does >> support PNG. > > Not in Windows 2000, which is still supported (and is the last version > of Windows that's big-brother-free). Well, I'd say leave BMP in if you want the patch accepted. Taking it out the Lindens can only loose, there's someone bound to complain because it breaks something for someone (and be it just a weird automated system that can only read BMPs) and there's no real benefit (like performance, code size, etc.) in removing it. Btw, there's already an option somewhere in prefs to save screens in compressed format which saves the screenshots in TGA atm. Adding an option for PNG there may be the way to go, or replacing TGA with PNG (as that's bound to break it for less people). Nick From secret.argent at gmail.com Mon Sep 24 05:04:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 05:04:24 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <20070924090722.7FF0341B140@stupor.lindenlab.com> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> Message-ID: > i think that the whole permissions systems is an "honor" system at > best. Sure. So's the DRM in iTunes. But in both cases they're an honor system that works, because people accept the necessity. I could go into a long dissertation as to why "honor system DRM" is adequate, sufficient, and all you can get in any case. But "it works" should be all you need really. From secret.argent at gmail.com Mon Sep 24 05:14:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 05:14:08 2007 Subject: [sldev] Permissions In-Reply-To: <20070924094717.8306141B156@stupor.lindenlab.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> Message-ID: <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> Tao Takashi: > For me it would also be interesting to know how much of the content > in world is > actually bought content and how much is just made for fun (e.g. on > the web > we have right now a big community of people creating stuff just for > fun and > I am interested to know how much this is the case for the SL > community). In my case I make stuff for fun... and then I sell it. And those sales are enough to pay for my tier, which gives me an incentive to take the stuff I'm hacking on and polish it up and release it, so long as it doesn't turn into a 'job'. Dale Glass: > Simply add a new flag: "Bind to domain". When set on an item, the > originating server refuses to hand it out to one owned by somebody > else. This probably needs to be applied by default to all existing content that isn't full perm, just to avoid the absolute uproar that would result. > Note here that I'm not saying what I am simply because I've been > asked to, > I really think having an economy is a good thing for SL, and IMO the > current permissions system is quite reasonable. The permission system as designed is reasonable. There's been some changes to it that have messed things up, like the change to the behavior of inventory in no-mod objects, that should probably be reconsidered. From hud at zurich.ibm.com Mon Sep 24 05:18:02 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 05:18:08 2007 Subject: [sldev] Permissions In-Reply-To: <200709241125.46563.dale@daleglass.net> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <200709241125.46563.dale@daleglass.net> Message-ID: <46F7AAFA.2050604@zurich.ibm.com> Dale Glass wrote: > On Monday 24 September 2007 11:07:00 dirk husemann wrote: > >> i think that the whole permissions systems is an "honor" system at best. >> why? well, the client --- or better: a client --- will always get the >> prim coordinates as well as the texture references from the grid. with >> open source clients you cannot count on nor can you guarantee that they >> will NOT act as a "copy bot" --- with the exception of scripts, but with >> open grids/open sims that will change as well. >> > [...] [...] > Not my personal opinion, but content providers argue that even if a perfect > solution isn't possible, permissions should still exist, if only as a way > of indicating the will of the author. > > There is a certain sense in forcing people to bypass the system, even if > it's very weak. If you bypassed it, you can't really argue you didn't know > what the creator wanted. > > Really, IMO, the permissions system should continue to exist. If you don't > want to restrict your own stuff, then don't, and just release all your > stuff as full perms. But there are a lot of people who will be really > annoyed should it vanish completely. > agreed. i guess what i'm concerned about is the sense of false security some folks might end up with: "ah, we have that permissions system, so my stuff is guaranteed to be safe" --- we should be upfront about what is possible and what is not possible (or what we think is possible and what we think is not possible --- and i could very well be wrong!). -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/4f266bbd/attachment.htm From hud at zurich.ibm.com Mon Sep 24 05:20:58 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 05:21:12 2007 Subject: [sldev] [LICENSING] Vivox SLVoice.exe documentation In-Reply-To: <50321.86.10.79.229.1190630132.squirrel@webmail.terminaldischarge.net> References: <46EF74EF.5070800@lindenlab.com> <46EF762A.5000706@wsu.edu> <46EF9C92.3060506@gmail.com> <46EFAF76.3020203@wsu.edu> <20070918111759.GD5649@bruno.sbruno> <46EFBB9B.6020302@wsu.edu> <46EFEE29.3000709@watson.ibm.com> <46F78F69.60109@zurich.ibm.com> <50321.86.10.79.229.1190630132.squirrel@webmail.terminaldischarge.net> Message-ID: <46F7ABAA.9090201@zurich.ibm.com> nik@terminaldischarge.net wrote: [...] >> the question is: can any of the OS devs make use of that documentation >> to implement a clone given the pedigree? is that information "tainted" >> in any way? >> >> cheers, >> dirk >> > > Which ever linden posted it (sorry my memory isn't so good) has re-posted > the documentation in jira, but this time with alot less restrictive > license. Basically, "use as you will, but vivox will not accept > resonsibilty if anything goes wrong." terms. > yep, saw that, just catching up on a whole week of sldev :-) thought i post anyhow just in case... so: excellent! :-) cheers, dirk > >> -- >> dr dirk husemann, pervasive computing, ibm zurich research lab >> --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/ce4d7bd8/attachment-0001.htm From secret.argent at gmail.com Mon Sep 24 05:22:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 05:23:03 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F79F3E.3050206@zurich.ibm.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> Message-ID: <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> On 24-Sep-2007, at 06:27, dirk husemann wrote: > the question is: do we want to keep it that way or do we want to > open up > the possibility of taking the actual shape into account when > calculating > collisions? the later doesn't prevent us from having a region server > that just uses the center point of the avatar... That would be great, but it would require lots more changes than that: * It would require having the server run animations and keep its view of the animation in sync with the client. * It would require the server handle the avatar's facing, and synchronize that. This would massively increase the amount of real-time network traffic between the server and the client, and make the effect of packet loss and network latency far worse. Hell... I'd be satisfied, for now, just having the avatar's bounding box reduced when you switch to "crouch walking", so you could crawl under obstacles. Actually keeping animations in sync between the client and the server and doing rag-doll animation at a physical level? That's a big big redesign, and may end up being a net loss. From hud at zurich.ibm.com Mon Sep 24 05:24:28 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 05:25:04 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: References: <20070924090722.7FF0341B140@stupor.lindenlab.com> Message-ID: <46F7AC7C.3060204@zurich.ibm.com> Argent Stonecutter wrote: >> i think that the whole permissions systems is an "honor" system at best. > > Sure. So's the DRM in iTunes. But in both cases they're an honor > system that works, because people accept the necessity. I could go > into a long dissertation as to why "honor system DRM" is adequate, > sufficient, and all you can get in any case. But "it works" should be > all you need really. agree. i guess my thinking was about avoiding the impression that we do have a rock-solid-really-enforcing DRM system in LL --- we don't, and we should make it clear that it's more an "honor" system than a rock-solid thingy... ..."managing expectations" i think my colleagues in marketing/sales call it ;-) cheers, dirk > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 05:26:03 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 05:26:12 2007 Subject: [sldev] Permissions In-Reply-To: <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> Message-ID: <46F7ACDB.9080701@zurich.ibm.com> Argent Stonecutter wrote: > Tao Takashi: >> For me it would also be interesting to know how much of the content >> in world is >> actually bought content and how much is just made for fun (e.g. on >> the web >> we have right now a big community of people creating stuff just for >> fun and >> I am interested to know how much this is the case for the SL community). > > In my case I make stuff for fun... and then I sell it. And those sales > are enough to pay for my tier, which gives me an incentive to take the > stuff I'm hacking on and polish it up and release it, so long as it > doesn't turn into a 'job'. > > Dale Glass: >> Simply add a new flag: "Bind to domain". When set on an item, the >> originating server refuses to hand it out to one owned by somebody else. > > This probably needs to be applied by default to all existing content > that isn't full perm, just to avoid the absolute uproar that would > result. also, perhaps modify it slightly to read "refuses to hand it out to one owned by somebody else and not trusted by the original domain"? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Mon Sep 24 05:27:49 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 05:28:03 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> Message-ID: <46F7AD45.2010900@zurich.ibm.com> Argent Stonecutter wrote: > On 24-Sep-2007, at 06:27, dirk husemann wrote: >> the question is: do we want to keep it that way or do we want to open up >> the possibility of taking the actual shape into account when calculating >> collisions? the later doesn't prevent us from having a region server >> that just uses the center point of the avatar... > > That would be great, but it would require lots more changes than that: > > * It would require having the server run animations and keep its view > of the animation in sync with the client. > * It would require the server handle the avatar's facing, and > synchronize that. > > This would massively increase the amount of real-time network traffic > between the server and the client, and make the effect of packet loss > and network latency far worse. > > Hell... I'd be satisfied, for now, just having the avatar's bounding > box reduced when you switch to "crouch walking", so you could crawl > under obstacles. Actually keeping animations in sync between the > client and the server and doing rag-doll animation at a physical > level? That's a big big redesign, and may end up being a net loss. ok...how about we keep the possibility of that at least open? (just thinking about those 100GB-pipe-to-the-home days to come...lol) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From secret.argent at gmail.com Mon Sep 24 05:28:27 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 05:28:33 2007 Subject: [sldev] Re: SLDev Digest, Vol 9, Issue 101 In-Reply-To: <20070924115543.D257E41B186@stupor.lindenlab.com> References: <20070924115543.D257E41B186@stupor.lindenlab.com> Message-ID: <25CFDD9B-2B72-48F8-A57A-BC8FA1F84358@gmail.com> From: dirk husemann > so in that case, if i follow what you are suggesting (i hope i do ;-), > the region domain would fetch an AV's mesh info from the asset storage > and then provide it to all AVs in the region? Not to any more degree than it does for any other asset... ie, as a cache. In the current model, the client connects to the region and the region acts as the cache for everything. In the new model the client connects to the agent host first, and THEN to the region, and the question of where assets are downloaded becomes more complex. From secret.argent at gmail.com Mon Sep 24 06:01:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 06:01:35 2007 Subject: [sldev] Permissions In-Reply-To: <46F7ACDB.9080701@zurich.ibm.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> <46F7ACDB.9080701@zurich.ibm.com> Message-ID: <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> > also, perhaps modify it slightly to read "refuses to hand it out to > one > owned by somebody else and not trusted by the original domain"? What if SL trusts GNUGrid but you don't want to? [X] Exportable to worlds certified by: (X) Second Life ( ) OpenSim ( ) DeepSim ( ) GNUGrid ( ) There.COM ( ) Activeworlds ( ) Habbo ( ) Verisign ( ) Sony Online ( ) Squaresoft ( ) Blizzard Entertainment ( ) Microsoft (X) Department of Homeland Security ( ) Virtual Vatican Certificate Authority ( ) Pizza Hut Game Token Redemption (X) My certificate authority at [192.168.100.1] (yes, some of those items are a little optimistic) From secret.argent at gmail.com Mon Sep 24 06:05:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 06:05:57 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F7AD45.2010900@zurich.ibm.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> <46F7AD45.2010900@zurich.ibm.com> Message-ID: <19479508-2CB3-469E-B5B0-89B0F6153C93@gmail.com> On 24-Sep-2007, at 07:27, dirk husemann wrote: > ok...how about we keep the possibility of [sim-side rag-doll > animation] at least open? (just thinking about those 100GB-pipe-to- > the-home days to come...lol) There's nothing anyone has said in this discussion that implies closing it down. There's no reason that any server would not be able to request resources of any asset type it needs from any source, regardless of the architecture. That's a long way from "let's have the avatar mesh in the region". From tao.takashi at googlemail.com Mon Sep 24 06:32:22 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 06:32:26 2007 Subject: [sldev] Permissions In-Reply-To: <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> <46F7ACDB.9080701@zurich.ibm.com> <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> Message-ID: <23bbb49e0709240632n6f5b24c9w644fcc21a6a2e30f@mail.gmail.com> What about a select between - allow copy inside the originating domain - allow copy inside the originating grid (thus also attached and hopefully trusted domains) - allow copy anywhere You might want to have different versions with different permissions and different prices then. Not sure if the list of grids won't become a little too complex. you might want to upload your content manually then to the grids you trust. Moreover one could think of a permission to copy based on some trust level of the grids but not sure how these could be defined for region domains. And we might also have grids with different permission system (I think it should be pluggable and those could be identified by some URI field like for XML namespaces) and an object might then not be compatible with a certain grid because it uses a different permission model. -- Tao 2007/9/24, Argent Stonecutter : > > > also, perhaps modify it slightly to read "refuses to hand it out to > > one > > owned by somebody else and not trusted by the original domain"? > > What if SL trusts GNUGrid but you don't want to? > > [X] Exportable to worlds certified by: > (X) Second Life > ( ) OpenSim > ( ) DeepSim > ( ) GNUGrid > ( ) There.COM > ( ) Activeworlds > ( ) Habbo > ( ) Verisign > ( ) Sony Online > ( ) Squaresoft > ( ) Blizzard Entertainment > ( ) Microsoft > (X) Department of Homeland Security > ( ) Virtual Vatican Certificate Authority > ( ) Pizza Hut Game Token Redemption > (X) My certificate authority at [192.168.100.1] > > (yes, some of those items are a little optimistic) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/881f99a9/attachment-0001.htm From tillie at xp2.de Mon Sep 24 06:43:33 2007 From: tillie at xp2.de (Tillie Ariantho) Date: Mon Sep 24 06:43:45 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: References: <20070924090722.7FF0341B140@stupor.lindenlab.com> Message-ID: <20070924154333.30lcbg1h7a4g00ko@webmail.readonly.de> Quoting Argent Stonecutter : > [...]I could go into a long dissertation as to why "honor system > DRM" is adequate, sufficient, and all you can get in any case. But > "it works" should be all you need really. I am not sure if all the content creators will be happy with it. Sure you can tell them "it works". Will they believe you? What if it only works 'sometimes'? Some people want to see money for EVERY copy of the things they create. Maybe the bunch of creators will clean up then, some stay, some leave. We'll see. :) -- Tillie From dale at daleglass.net Mon Sep 24 06:47:58 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 24 06:48:05 2007 Subject: [sldev] Permissions In-Reply-To: <23bbb49e0709240632n6f5b24c9w644fcc21a6a2e30f@mail.gmail.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> <46F7ACDB.9080701@zurich.ibm.com> <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> <23bbb49e0709240632n6f5b24c9w644fcc21a6a2e30f@mail.gmail.com> Message-ID: <20070924134758.GA27822@bruno.sbruno> On Mon, Sep 24, 2007 at 03:32:22PM +0200, Tao Takashi wrote: > What about a select between > > - allow copy inside the originating domain > - allow copy inside the originating grid (thus also attached and hopefully > trusted domains) > - allow copy anywhere > > You might want to have different versions with different permissions and > different prices then. > > Not sure if the list of grids won't become a little too complex. you might > want to upload your content manually then to the grids you trust. I think I like the grid list way more. If you upload separately to each grid then they'd be really different assets on each grid. The idea here is to decide whether you can walk from grid X to grid Y and have say, your avatar automatically uploaded there. > Moreover one could think of a permission to copy based on some trust level > of the grids but not sure how these could be defined for region domains. Hmm, not really sure what trust levels there could be here. The way I see it, either you trust a grid to keep your scripts safe or you don't. That's IMO the main issue here, the rest can always be copied copybot style anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/eabfc895/attachment.pgp From belxjander at gmail.com Mon Sep 24 06:58:02 2007 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Mon Sep 24 06:56:16 2007 Subject: [sldev] Permissions In-Reply-To: <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> References: <20070924094717.8306141B156@stupor.lindenlab.com> <63428C1F-5B22-41F0-93A3-891B33BFE94D@gmail.com> <46F7ACDB.9080701@zurich.ibm.com> <6F73EE1D-EA07-4E50-8EDA-3D6AB6956ADA@gmail.com> Message-ID: <1190642282.6005.17.camel@localhost> On Mon, 2007-09-24 at 08:01 -0500, Argent Stonecutter wrote: > > also, perhaps modify it slightly to read "refuses to hand it out to > > one > > owned by somebody else and not trusted by the original domain"? > > What if SL trusts GNUGrid but you don't want to? > > [X] Exportable to worlds certified by: > (X) Second Life > ( ) OpenSim > ( ) DeepSim > ( ) GNUGrid > ( ) There.COM > ( ) Activeworlds > ( ) Habbo > ( ) Verisign > ( ) Sony Online > ( ) Squaresoft > ( ) Blizzard Entertainment > ( ) Microsoft > (X) Department of Homeland Security > ( ) Virtual Vatican Certificate Authority > ( ) Pizza Hut Game Token Redemption > (X) My certificate authority at [192.168.100.1] > > (yes, some of those items are a little optimistic) > _______________________________________________ Please excuse my ignorance, and I am new to this list, The whole problem seems to be the same as "chain of evidence" in forensics... do you trust the server/client chain as any single point of failure breaks the whole security model unconditionally, either you have a complete chain of trust or no chain of trust, no middle ground is the apparent situation, and you have to have end-to-end and transaction security... as soon as any attribute is readable it is copy-enabled, digital systems are that way from the get go, the only secure system is a non-connected system, for the grid itself to be secure with its content then either the protocols and tools themselves are restricted to defined behaviours *1 or limit the entire grid to defined interactions *2, How do you secure a digital system? DRM has failed, or do we flip the security the other way, everyone denied until permitted, exception being "owner/creator" who have default rights? this comes down to how to handle securing the system itself, Mapping the world into something usable for region maintainable constructs is workable similar to DNS, mapping objects within that realm, how about temporary instantiation within the realm server that the client is currently using and the server [accept/denie/reject]s the given action request of the client, disconnection of the client from the security chain is one mechanism, and limits it to the servers for the grid itself, since each region/realm is then down to persistence rules at the server, is any given client allocated a content cache on the server or is the cache entirely handled at the client end?, splitting the object into displayed/non-displayed and pairing it? the displayed being useless without the non-displayed? Argent: what is to stop an individual purchasing a certificate and providing such as a server certificate and being "trusted" and then forwarding to untrusted servers? Im ignoring whether it is for secondlife or another network application at this point, it is already possible to snoop the connection, and with the open source codebase the protocol in-use is readily described, the "closed server space" model seems to be the only means by which anyone has any "content control" at all at this time, or are we going to push everything into the server and have the server provide everything of the security with regards content? DRM has already been proven to be a failure, DeCSS / OpenFairPlay and other tools as applied to existing DRM schemes, how is secondlife to be any different than those other schemes? *1= unable to be maintained with open source as anyone can use a modified client for themselves. *2 = content is locked to origination client/server pairing additional servers are "proxy forward" access to original content, again the problem is in the proxy system for end-to-end linkage, see *1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/397815af/attachment.htm From dale at daleglass.net Mon Sep 24 07:00:47 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Sep 24 07:00:51 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <20070924154333.30lcbg1h7a4g00ko@webmail.readonly.de> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <20070924154333.30lcbg1h7a4g00ko@webmail.readonly.de> Message-ID: <20070924140047.GB27822@bruno.sbruno> On Mon, Sep 24, 2007 at 03:43:33PM +0200, Tillie Ariantho wrote: > Quoting Argent Stonecutter : > > >[...]I could go into a long dissertation as to why "honor system > >DRM" is adequate, sufficient, and all you can get in any case. But > >"it works" should be all you need really. > > I am not sure if all the content creators will be happy with it. Sure you > can > tell them "it works". Will they believe you? What if it only works > 'sometimes'? > Some people want to see money for EVERY copy of the things they create. > Maybe > the bunch of creators will clean up then, some stay, some leave. We'll see. > :) I'm pretty sure the smart ones understand that a 100% guarantee isn't possible. One thing that the ones I talked to want is enforcement. If it's not possible to make assets uncopyable they'd like to be able to get those who do it banned permanently and the damage undone. Problem with that is that LL for quite understandable reasons doesn't really want to play world police. Unverified accounts appear to be a significant problem. Even if you ban whoever copied your stuff, they can come back anyway, and it doesn't seem like LL makes much of an effort to remove the copies they created. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/68be6be3/attachment.pgp From alexander.treptow at zweitgeist.com Mon Sep 24 07:43:31 2007 From: alexander.treptow at zweitgeist.com (atreptow) Date: Mon Sep 24 07:44:09 2007 Subject: [sldev] Debug Assertion Failed Message-ID: <46F7CD12.10501@zweitgeist.com> Hi i got VC++ 2005 Express slviewer-src-RC-1.18.3.4 self converted vcproj files ( https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 ) without qtmllib include #define LL_QUICKTIME_ENABLED 0 current version of cygwin with devel package installed with patch from Nicholaz Beresford for leak debug and in time no idea what i've can do else to get the slviewer starting completely in debug mode. after i tried this version to run with other project files i read about, that there were maybe chances since 1.18.0.4 in the project structur so i converted them by myself: Debug Assertion Failed occurs directly after creating texture cache folder "f" with debug output there are some errors from ll_apr_file_seek and ll_apr_file_read in llapr.cpp of the llcommon project ERROR: ll_apr_file_seek: ASSERT (apr_offset <= 0x7fffffff) and for the "sz" variable the assertion failed error says its occured in program debugview.exe ind file vc/include/xtree in line 619 Expression: invalid operator < are there any solutions to fix this problem and get sl started? greets alex From nicholaz at blueflash.cc Mon Sep 24 07:58:09 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 07:58:15 2007 Subject: [sldev] Debug Assertion Failed In-Reply-To: <46F7CD12.10501@zweitgeist.com> References: <46F7CD12.10501@zweitgeist.com> Message-ID: <46F7D081.8030501@blueflash.cc> I haven't seen this but it's been a while since I did a VS2005 compile. I'd say hack the llapr.cpp before the asssert and output the value of apr_offset (or whatever other assert may be offending) to the logfile, like llinfos << "apr_offset = " << apr_offset << llendl; Then after the assert look at the log wht the offset is and where it's coming from. Also in a debug build you'll easily be able to go down the stack (debug windows, stack) or look at variables (add them to watch or hover the mouse over them). Also, did you cheeck if there's something weird in your cache folder (or just deleted it)? Nick atreptow wrote: > Hi > > i got > VC++ 2005 Express > slviewer-src-RC-1.18.3.4 > > self converted vcproj files ( > https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 ) > without qtmllib include > #define LL_QUICKTIME_ENABLED 0 > > current version of cygwin with devel package installed > with patch from Nicholaz Beresford for leak debug > > and in time no idea what i've can do else to get the slviewer starting > completely in debug mode. > > after i tried this version to run with other project files i read about, > that there were maybe chances since 1.18.0.4 in the project structur > so i converted them by myself: > > Debug Assertion Failed occurs directly after creating texture cache > folder "f" > > with debug output there are some errors from ll_apr_file_seek and > ll_apr_file_read in llapr.cpp of the llcommon project > ERROR: ll_apr_file_seek: ASSERT (apr_offset <= 0x7fffffff) and for the > "sz" variable > > the assertion failed error says its occured in program debugview.exe ind > file vc/include/xtree in line 619 > Expression: invalid operator < > > are there any solutions to fix this problem and get sl started? > > greets alex > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tom at cornish-pasty.com Mon Sep 24 08:14:33 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Mon Sep 24 08:14:27 2007 Subject: [sldev] Debug Assertion Failed In-Reply-To: <46F7D081.8030501@blueflash.cc> Message-ID: <006901c7febd$9d056900$ec001352@tomhome> I did a patch for this a while back. I'm looking for the Jirra now. Try VWR-1464 Also, there is a STL failure from lldarray somewhere. I can't remember, but one of the 'remove' Returns an assert failure value (patch it to return 0). > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of > Nicholaz Beresford > Sent: 24 September 2007 15:58 > To: atreptow > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] Debug Assertion Failed > > > > I haven't seen this but it's been a while since I did > a VS2005 compile. > > I'd say hack the llapr.cpp before the asssert and output > the value of apr_offset (or whatever other assert may be > offending) to the logfile, like > > llinfos << "apr_offset = " << apr_offset << llendl; > > Then after the assert look at the log wht the offset is > and where it's coming from. > > Also in a debug build you'll easily be able to go down the > stack (debug windows, stack) or look at variables (add them > to watch or hover the mouse over them). > > Also, did you cheeck if there's something weird in your > cache folder (or just deleted it)? > > > Nick > > > atreptow wrote: > > Hi > > > > i got > > VC++ 2005 Express > > slviewer-src-RC-1.18.3.4 > > > > self converted vcproj files ( > > > https://wiki.secondlife.com/wiki/Converting_project_files_for_ MSVS2005 ) > without qtmllib include > #define LL_QUICKTIME_ENABLED 0 > > current version of cygwin with devel package installed > with patch from Nicholaz Beresford for leak debug > > and in time no idea what i've can do else to get the slviewer starting > completely in debug mode. > > after i tried this version to run with other project files i read > about, > that there were maybe chances since 1.18.0.4 in the project structur > so i converted them by myself: > > Debug Assertion Failed occurs directly after creating texture cache > folder "f" > > with debug output there are some errors from ll_apr_file_seek and > ll_apr_file_read in llapr.cpp of the llcommon project > ERROR: ll_apr_file_seek: ASSERT (apr_offset <= 0x7fffffff) and for the > "sz" variable > > the assertion failed error says its occured in program debugview.exe > ind > file vc/include/xtree in line 619 > Expression: invalid operator < > > are there any solutions to fix this problem and get sl started? > > greets alex > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tao.takashi at googlemail.com Mon Sep 24 08:15:43 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 08:15:46 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <20070924140047.GB27822@bruno.sbruno> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <20070924154333.30lcbg1h7a4g00ko@webmail.readonly.de> <20070924140047.GB27822@bruno.sbruno> Message-ID: <23bbb49e0709240815x7cac8e8fh2733724909a41585@mail.gmail.com> > Problem with that is that LL for quite understandable reasons doesn't > really want to play world police. But they can at least check their connected region domains and react to abuse reports and eventually ban these domains from the grid. I mean, this is actually the new thing which gets added. Not sure how practical it is though to check these things and how it actually can be proven. (the same might be true for any copies done today though). -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/b679335e/attachment.htm From tao.takashi at googlemail.com Mon Sep 24 08:55:25 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 08:55:27 2007 Subject: [sldev] Re: informal SL architecture meetup in half an hour In-Reply-To: <23bbb49e0709231024m60037bb4ve6325eb724b59e29@mail.gmail.com> References: <23bbb49e0709231024m60037bb4ve6325eb724b59e29@mail.gmail.com> Message-ID: <23bbb49e0709240855g609dd888y7678012aab5daba0@mail.gmail.com> Hi! 2007/9/23, Tao Takashi : > > Just FYI: I am trying to explain the SL architecture working group to some > interested people in about 30 minutes. It won't be too technical but I want > to give them a little bit of insight of what this project is all about. I just posted the transcript for that event along with the slides here: http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ I think now all those ideas and issues just need to get somehow sorted into the wiki. Please also feel free to correct things in the comments where you think something was incorrect. cheers, Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/89693a14/attachment.htm From secret.argent at gmail.com Mon Sep 24 09:01:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 09:01:20 2007 Subject: [sldev] Permissions In-Reply-To: <20070924151432.956D241B18F@stupor.lindenlab.com> References: <20070924151432.956D241B18F@stupor.lindenlab.com> Message-ID: From: Tillie Ariantho > I am not sure if all the content creators will be happy with it. > Sure you can tell them "it works". Will they believe you? What if > it only works 'sometimes'? Of course it only works 'sometimes'. It doesn't have to work 'all the time'. That's the point. And out of all the scripts I've written in SL, the three that sell the best are sold full perm, and two of them are actually BSD licensed. They still sell better than the stuff that's no-transfer. And really, this is not something I can do anything about. This is not something Linden Labs can do anything about. This is not something Apple or Microsoft can do anything about. ALL DRM is honor system DRM. That's inherent in the problem DRM is trying to solve. Pretending that something better than "honor system" DRM is possible outside a Science Fiction novel is fooling yourself, at best. Trying to make DRM stronger than needed to remind people that they're doing something dishonest, trying to actually keep a motivated person from bypassing it, is worse than foolish... it's abusive. > Some people want to see money for EVERY copy of the things they > create. I know. Since that's not technically possible to enforce, I guess they'll have to learn to live with it. > Maybe the bunch of creators will clean up then, some stay, some > leave. We'll see. :) Apple came right out and told the labels that they couldn't get Science Fiction DRM, back before the iTunes Store opened. They seem to be doing OK with that. From secret.argent at gmail.com Mon Sep 24 09:20:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 09:20:50 2007 Subject: [sldev] Re: [ARCH] Permissions (Abh Serechai Belxjander) In-Reply-To: <20070924151432.956D241B18F@stupor.lindenlab.com> References: <20070924151432.956D241B18F@stupor.lindenlab.com> Message-ID: First, DRM is not a tool that prevents copying. It's a tool for encouraging honest behavior. It makes copying inconvenient, and it makes it clear that when you're bypassing it you're dealing with information you're not supposed to be redistributing. So it doesn't need to be perfect, and in fact most of the benefits of DRM are available from even the weakest systems... like the one in iTunes. Trying to do more than that doesn't give you a lot more protection, it just abuses your customers. Abh Serechai Belxjander writes: > Argent: what is to stop an individual purchasing a certificate and > providing such as a server certificate and being "trusted" > and then forwarding to untrusted servers? Just having a certificate won't do you any good. You need to get your certificate signed by one of the people who are in the business of signing certificates. If you want it signed by LL so you can use content for distribution under SL's policies, you have to have a contract with them, and if you violate that contract it's up to LL to enforce... by, for example, putting your certificate in a revocation list. If they do a good job of enforcing it, then people will click [x] Export to regions certified by (x) Linden Labs. If they don't, then people won't. The market will sort things out. > DRM has already been proven to be a failure, DeCSS / OpenFairPlay > and other tools as applied to existing DRM schemes, how is > secondlife to be any different than those other schemes? It isn't. As to whether things like "OpenFairplay" make it a failure, only time will tell. I suspect not, since Apple's let you remove the DRM from your tracks in iTunes from the beginning... and so far that doesn't seem to have hurt Apple and artists are still happy to get distribution through iTunes. But, hey, I could be wrong over the long term... The only thing I'm sure of is that you get into diminishing returns from any stronger DRM than that pretty damn quick. PS, shouldn't the permissions discussion be tagged [ARCH] or [META]? (yes, I forgot too, mea culpa) From alexander.treptow at zweitgeist.com Mon Sep 24 09:28:38 2007 From: alexander.treptow at zweitgeist.com (atreptow) Date: Mon Sep 24 09:29:10 2007 Subject: [sldev] Avatar Viewer Message-ID: <46F7E5B6.60703@zweitgeist.com> Is it possible to write a hardly cropped slviewer that can view every avatar without authenticate to sl, only sending a request or something to the server with data like character name and getting back the data for displaying the avatar. without the possibility to act with this character in the sl-world? for example for a friend viewer that can view all friend avatars and maybe also shows when they are online greets Alex From donovan at lindenlab.com Mon Sep 24 10:22:23 2007 From: donovan at lindenlab.com (Donovan Linden) Date: Mon Sep 24 10:22:52 2007 Subject: [sldev] What is eventlet, and why should you care? Message-ID: Introduction ===== I'm Donovan Linden (Donovan Preston). I started at Linden in May of 2006 to join Zero Linden (Mark Lentczner) in forming Studio Icehouse, whose charter is to "modernize" the second life protocol. We have been slowly doing this by introducing LLSD, capabilities, and designing web services in a REST-style fashion. I have been using Python since 2000, and using non-blocking network I/ O (with the Twisted framework) for most of that time. When I started at Linden, I decided to see if I could use a small open source coroutine-based networking framework, eventlet, written by a friend of mine, Bob Ippolito. Eventlet ===== Why would I want to use eventlet? Eventlet uses coroutines (with the help of the greenlet module) to perform high scalability non-blocking I/O while appearing to the programmer to block. This means code that looks like: socket.write('hello world') Is actually causing a coroutine switch away from this coroutine into a mainloop coroutine, until the syscall select or poll says that socket's file descriptor is ready for writing. This gives a nice balance between the advantages of non-blocking I/O (no preemption and thus no possibility of deadlock, deterministic control flow) and blocking I/O (ease of use, ease of composition, ease of error handling). Usage of eventlet inside of Linden has been a great success. Several key services have been ported from C++ code which depends on the central database to distributed Python web services (the "backbone" architecture). We think the code is small, simple, clear, and powerful, and we invite others to take a look! How can you help? ===== First, I invite you to read the eventlet wiki page, download eventlet, and try out the examples. http://wiki.secondlife.com/wiki/Eventlet Second, Which Linden and I have put together a roadmap for what we would like to do before declaring eventlet "1.0" and doing an official release. Please take a look and see if there is anything you could help with! http://wiki.secondlife.com/wiki/Eventlet_1.0 Donovan Preston From michi at luskwood.org Mon Sep 24 11:05:40 2007 From: michi at luskwood.org (michi@luskwood.org) Date: Mon Sep 24 11:05:53 2007 Subject: [sldev] Permissions - A content creator's view Message-ID: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> Tao Takashi posted recently that he was wondering what content creators thought of these upcoming changes to the structure of the grid, and how permissions relate. A little background, I'm one of the founders of Luskwood Creatures, we've been making avatars since 2003, and we use the income from those avatars to support the area (Luskwood) on the grid. Now, some folks may have argued with me in the past about Copybot, I'm hoping that it doesn't get to that point here - I really believe it does not have to. First of all, I do want to get a few things out of the way. 1) I'm aware that there is no technical way to stop permissions breaches cold. I'm aware that once the information is sent to the client, it can be accessed. 2) I also am aware that expansion of the grid in this matter also increases exposure for content in a positive way. I'm not looking to simplistically say "Don't do it!" - No, but at the same time, I'm pretty positive that there's enough thought and active minds around to come up with -something- that is fair and equitable to everyone; preserving some viability of content production without becoming "messy and restrictive DRM", which I've had my own troubles with in the past. A little background: Our avatars, we sell them moddable and copyable. The only bit we restrict is transfer. We've got no problem with anyone pulling our avs apart, seeing how they're made, modifying them, tweaking them, customizing them, learning from them or making them their own. We also will ALWAYS give a replacement (even though they are set copy-ok) to anyone who's ever bought an avatar from us. We also give free upgrades, even if the new ones are more complex. In this way, I consider our stuff to be pretty open to begin with. I don't believe we restrict fair use -- "first sale doctrine" is another matter, which arguably is a very difficult thing to establish digitally. The only thing we try to deter is folks essentially "hitting a button, turning around and pretending that they're us." - I'll explain a bit more on that stance in a bit. First I do want to differentiate between "DRM" and permissions. DRM is intended to restrict the item down the stream -- it's a technical measure to resist countermeasures. It's aim is control. Permissions, however, I see as an expression of the originator's intent. While there are some built in controls that respect said permissions if the client chooses to engage in that level of trust, it usually doesn't involve cryptography, wrappers, and the 'usability and maintainability' problems mentioned in other threads here. While permissions can be broken, they do at least minimally establish a "norm" and a "trust level", at least defining what you 'should and shouldn't do'. And that's how maybe this should be defined: It's not a matter of "can vs can't", it's a matter of "Should vs shouldn't." An object always CAN be copied or retransmitted. Yes. But keeping permissions (and the 'norm' being that servers, clients do at least respect them) establishes a level of systemic trust and respect as to what the author wishes to be done with their work. It's a matter of choice and expression of that choice. So in that way, it is indeed an honor system. But one that I do not believe adds unneccesary weight to the system: look at unix permissions on files, and simple .htaccess restrictions to web directories. I don't believe those would be considered "DRM", but they are permission controls - indeed breakable if a person is determined enough. But again, to me, the point is establishing a norm where "can" doesn't equal "should". If permissions were gone, a person new to the "new grid" may indeed believe that simply because copies and transferrence, or reassignment of "identification of authorship" is facilitated in the system, it is in fact -encouraged- in the system. It's a matter of sanctions, I think, and norms of what is considered OK to do. Trashing perms says that "this is the norm; we have made the decision for you, you cannot dictate your wishes across to others" - plus I believe making what's essentially an "easy button" to make transfers, you have newcomers who just don't understand and figure that if the option is there, they are supposed to use it. A few things I think could be in place to simply establish a level of norms, without having to dive into the technical examination of what is "possible vs impossible": Remember, the ability to technically defeat these is a known quantity - I'm talking about the establishment of intent, and technical compliance to the level of what is feasible. 1) A simple trust level - Servers that connect to the SL grid at least should purport to follow a similar level of standards (i.e., 'listening' to perms) as the SL grid. Of course, someone could lie. But this at least establishes intent and a norm. 2) I think an extension of permissions to give the ability to comply with copyright as well as copyleft should exist. In addition to "no copy", "no transfer", "no modify"; we could indeed have "may not set nomod" or "may not set no transfer". And the eternally asked-for "may not charge money for trasfer". 3) Grid level permissions, i.e., "May rez/attach on a trusted grid" vs "May rez/attach only on SL grid" or , "May rez/attach anywhere". These, I think, would at least set up some levels of intent. As Forseti said in a post before, - people can choose to not engage the products that people feel are too restricted. As far as "technical feasibility" goes: Often the argument will be, "It can be cracked, so why bother?" - We return to this analogy of, "Any determined burglar will be able to break into your house, but that doesn't mean you leave your door hanging wide open at night." The average lock and key on a door is a pretty weak mechanism. But break-ins are still the exception, and not the rule. And that's what I think should be -able- to be established: that ripping and redistribution is not IMPOSSIBLE (it never will be) - it's just abnormal. (Unless of course that was the author's intent.) "There's nothing we can do that is technically fireproof, so we shouldn't do anything!" is a similar mentality to what many OSS people would never like to hear from a content creator: "It might be tough, so we should drop OSS!" Neither of these are really the right path, or right declaration to make, I believe. There are also slightly different schools of thought regarding artwork vs code. (builds vs scripts). There are going to be a lot of philosophies in the course of development of the new SL: People who think that everything should be locked tight, people who think that everything should be open and free, (both as in open, and as in beer). And people who reside somewhere in the middle, or slightly to either side. Those who choose to produce what they do completely open will likely never be restricted from doing so. I do believe that folks who have had another model work for them for a long time should be able to continue along that path with at least some mechanism of making it the norm -for their productions.- I absolutely believe there is room in SL for several of these models. I also know that in the process of this there'll be flames and disagreements - but I'd just hope that there can be an open dialogue about it. I don't really think saying things like those who set "no transfer" are "evil" is entirely fair. It's enabled us to support a place that a lot of folks - including OSS folks - have enjoyed. I think we've always been fair to people, and will continue to be. You can disagree with a certain model - but that doesn't neccessarily mean that one model should be imposed on another person. We are not talking about restrictions forced upon anyone. Everyone has the choice to participate and parttake to whatever level they feel comfortable. Granted, ideals and philosophies could just be blanket-imposed, but I don't think that would be nearly as positive for the grid(s). Just one set of philosophies and one sort of person on the grid would make for a rather uninteresting place. Thanks, for what it's worth, for reading - and hopefully considering, Michi Lumin Luskwood/Luskwood Creatures From iridium at lindenlab.com Mon Sep 24 11:46:19 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Mon Sep 24 11:47:15 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> Message-ID: <46F805FB.8020708@lindenlab.com> I have found this thread to be as useful as it is substantive. I'm passing this along internally to my team for evaluation. I think it might be interesting to set up an in-world meeting in order to discuss how you would like to see Linden Lab weigh in on permissions issues (and we're working on our abuse system so your points there are taken) in part because many Lindens who would be involved are not subscribed to the SLDev list. The key to this kind of in-world brainstorming for me is actionable feedback and a wide Linden/Resident audience, so if you think that an in-world roundtable would be a useful exercise, please ping me. Otherwise, we might think about sticking this in a wiki so that I can direct my team members to a more organized repository of information on the topic. Iridium michi@luskwood.org wrote: > Tao Takashi posted recently that he was wondering what content creators > thought of these upcoming changes to the structure of the grid, and how > permissions relate. > > A little background, I'm one of the founders of Luskwood Creatures, we've > been making avatars since 2003, and we use the income from those avatars > to support the area (Luskwood) on the grid. Now, some folks may have > argued with me in the past about Copybot, I'm hoping that it doesn't get > to that point here - I really believe it does not have to. > > First of all, I do want to get a few things out of the way. > > 1) I'm aware that there is no technical way to stop permissions breaches > cold. I'm aware that once the information is sent to the client, it can be > accessed. > > 2) I also am aware that expansion of the grid in this matter also > increases exposure for content in a positive way. > > I'm not looking to simplistically say "Don't do it!" - No, but at the same > time, I'm pretty positive that there's enough thought and active minds > around to come up with -something- that is fair and equitable to everyone; > preserving some viability of content production without becoming "messy > and restrictive DRM", which I've had my own troubles with in the past. > > A little background: Our avatars, we sell them moddable and copyable. The > only bit we restrict is transfer. We've got no problem with anyone pulling > our avs apart, seeing how they're made, modifying them, tweaking them, > customizing them, learning from them or making them their own. > > We also will ALWAYS give a replacement (even though they are set copy-ok) > to anyone who's ever bought an avatar from us. We also give free upgrades, > even if the new ones are more complex. > > In this way, I consider our stuff to be pretty open to begin with. I > don't believe we restrict fair use -- "first sale doctrine" is another > matter, which arguably is a very difficult thing to establish digitally. > > The only thing we try to deter is folks essentially "hitting a button, > turning around and pretending that they're us." - I'll explain a bit more > on that stance in a bit. > > First I do want to differentiate between "DRM" and permissions. DRM is > intended to restrict the item down the stream -- it's a technical measure > to resist countermeasures. It's aim is control. > > Permissions, however, I see as an expression of the originator's intent. > While there are some built in controls that respect said permissions if > the client chooses to engage in that level of trust, it usually doesn't > involve cryptography, wrappers, and the 'usability and maintainability' > problems mentioned in other threads here. > > While permissions can be broken, they do at least minimally establish a > "norm" and a "trust level", at least defining what you 'should and > shouldn't do'. And that's how maybe this should be defined: > > It's not a matter of "can vs can't", it's a matter of "Should vs shouldn't." > > An object always CAN be copied or retransmitted. Yes. But keeping > permissions (and the 'norm' being that servers, clients do at least > respect them) establishes a level of systemic trust and respect as to what > the author wishes to be done with their work. It's a matter of choice and > expression of that choice. > > So in that way, it is indeed an honor system. But one that I do not > believe adds unneccesary weight to the system: look at unix permissions on > files, and simple .htaccess restrictions to web directories. I don't > believe those would be considered "DRM", but they are permission controls > - indeed breakable if a person is determined enough. > > But again, to me, the point is establishing a norm where "can" doesn't > equal "should". If permissions were gone, a person new to the "new grid" > may indeed believe that simply because copies and transferrence, or > reassignment of "identification of authorship" is facilitated in the > system, it is in fact -encouraged- in the system. > > It's a matter of sanctions, I think, and norms of what is considered OK to > do. Trashing perms says that "this is the norm; we have made the decision > for you, you cannot dictate your wishes across to others" - plus I believe > making what's essentially an "easy button" to make transfers, you have > newcomers who just don't understand and figure that if the option is > there, they are supposed to use it. > > A few things I think could be in place to simply establish a level of > norms, without having to dive into the technical examination of what is > "possible vs impossible": > > Remember, the ability to technically defeat these is a known quantity - > I'm talking about the establishment of intent, and technical compliance to > the level of what is feasible. > > 1) A simple trust level - Servers that connect to the SL grid at least > should purport to follow a similar level of standards (i.e., 'listening' > to perms) as the SL grid. Of course, someone could lie. But this at least > establishes intent and a norm. > > 2) I think an extension of permissions to give the ability to comply with > copyright as well as copyleft should exist. In addition to "no copy", "no > transfer", "no modify"; we could indeed have "may not set nomod" or "may > not set no transfer". And the eternally asked-for "may not charge money > for trasfer". > > 3) Grid level permissions, i.e., "May rez/attach on a trusted grid" vs > "May rez/attach only on SL grid" or , "May rez/attach anywhere". > > These, I think, would at least set up some levels of intent. As Forseti > said in a post before, - people can choose to not engage the products that > people feel are too restricted. > > As far as "technical feasibility" goes: Often the argument will be, "It > can be cracked, so why bother?" - We return to this analogy of, "Any > determined burglar will be able to break into your house, but that doesn't > mean you leave your door hanging wide open at night." The average lock > and key on a door is a pretty weak mechanism. But break-ins are still the > exception, and not the rule. > > And that's what I think should be -able- to be established: that ripping > and redistribution is not IMPOSSIBLE (it never will be) - it's just > abnormal. (Unless of course that was the author's intent.) > > "There's nothing we can do that is technically fireproof, so we shouldn't > do anything!" is a similar mentality to what many OSS people would never > like to hear from a content creator: "It might be tough, so we should drop > OSS!" > > Neither of these are really the right path, or right declaration to make, > I believe. > > There are also slightly different schools of thought regarding artwork vs > code. (builds vs scripts). > > There are going to be a lot of philosophies in the course of development > of the new SL: People who think that everything should be locked tight, > people who think that everything should be open and free, (both as in > open, and as in beer). And people who reside somewhere in the middle, or > slightly to either side. > > Those who choose to produce what they do completely open will likely never > be restricted from doing so. I do believe that folks who have had another > model work for them for a long time should be able to continue along that > path with at least some mechanism of making it the norm -for their > productions.- I absolutely believe there is room in SL for several of > these models. > > I also know that in the process of this there'll be flames and > disagreements - but I'd just hope that there can be an open dialogue about > it. > > I don't really think saying things like those who set "no transfer" are > "evil" is entirely fair. It's enabled us to support a place that a lot of > folks - including OSS folks - have enjoyed. I think we've always been fair > to people, and will continue to be. > > You can disagree with a certain model - but that doesn't neccessarily mean > that one model should be imposed on another person. We are not talking > about restrictions forced upon anyone. Everyone has the choice to > participate and parttake to whatever level they feel comfortable. > > Granted, ideals and philosophies could just be blanket-imposed, but I > don't think that would be nearly as positive for the grid(s). Just one set > of philosophies and one sort of person on the grid would make for a rather > uninteresting place. > > Thanks, for what it's worth, for reading - and hopefully considering, > > Michi Lumin > Luskwood/Luskwood Creatures > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From monkowsk at watson.ibm.com Mon Sep 24 11:54:55 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Sep 24 11:54:59 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <19479508-2CB3-469E-B5B0-89B0F6153C93@gmail.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> <46F7AD45.2010900@zurich.ibm.com> <19479508-2CB3-469E-B5B0-89B0F6153C93@gmail.com> Message-ID: <46F807FF.60100@watson.ibm.com> I guess the important thing is to not expect the sim to be a monolith. Allow partitioning of the tasks so that if someone is willing to throw the hardware at it, they could do, e.g., collision detection on custom avatar meshes. As you pointed out, this has an effect on the communications load, so it's not just a black box partitioned any way you like. Mike Argent Stonecutter wrote: > On 24-Sep-2007, at 07:27, dirk husemann wrote: > >> ok...how about we keep the possibility of [sim-side rag-doll >> animation] at least open? (just thinking about those 100GB-pipe-to- >> the-home days to come...lol) > > > There's nothing anyone has said in this discussion that implies closing > it down. There's no reason that any server would not be able to request > resources of any asset type it needs from any source, regardless of the > architecture. > > That's a long way from "let's have the avatar mesh in the region". From nicholaz at blueflash.cc Mon Sep 24 11:55:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 11:55:52 2007 Subject: [sldev] [PJIRA] VWR-2571 "Open Content" (Creative Commons/Open Source/GPL style) permission for SL Items Message-ID: <46F8081F.5050608@blueflash.cc> Rob gave me a tip to do the obvious, that is filing my idea about GPL style SL content on JIRA. So I'd like to direct (or solicit) a branch of the "permissions" discussion there (should be easier now that the email notification on JIRA is working). The idea is basically to create a permission within the current system (and it's limitations) to express that a creation should remain open for reuse, remix, etc. in creations of equal end user rights. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Mon Sep 24 12:02:08 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 12:02:36 2007 Subject: [sldev] [PJIRA] VWR-2571 "Open Content" (Creative Commons/Open Source/GPL style) permission for SL Items In-Reply-To: <46F8081F.5050608@blueflash.cc> References: <46F8081F.5050608@blueflash.cc> Message-ID: <46F809B0.40602@blueflash.cc> My god, first it didn't occur to me to file it as JIRA *duh* and now I forget to post the link *double duh* https://jira.secondlife.com/browse/VWR-2571 Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From secret.argent at gmail.com Mon Sep 24 12:04:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 12:04:57 2007 Subject: [sldev] Re: [ARCH//META] Permissions and limitations of distrust In-Reply-To: <1190653498.6005.29.camel@localhost> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <1190653498.6005.29.camel@localhost> Message-ID: <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> On 24-Sep-2007, at 12:04, Abh Serechai Belxjander wrote: > where is the middle ground? You're looking at it as a technical issue. It's not. It's a social one. It's like you're saying "speed limit signs don't stop people speeding, so there's no point posting them". > you get a certificate allocated by verisign, LL have already put > "trust verisign" on their end, No they haven't. Not in this design. They've given YOU, as a creator of an object, the option to choose to trust certificates signed by verisign. If you have checked "verisign" in that example list I posted, then SL will allow your content to be transferred into regions if they have a certificate signed by verisign. If you haven't, it's not even going to ask for that certificate... it'll deny the transfer. From monkowsk at watson.ibm.com Mon Sep 24 12:05:44 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Sep 24 12:06:20 2007 Subject: [sldev] [VWR] Real-time Raytracing, now proof-of-concept on 8+ core. In-Reply-To: <46F551F9.8010006@dzonux.net> References: <46F551F9.8010006@dzonux.net> Message-ID: <46F80A88.1040805@watson.ibm.com> Dzonatas wrote: > Good time to read the article, as it is not being slashdotted anymore. > > "Rendering Games with Raytracing Will Revolutionize Graphics" > > http://www.pcper.com/article.php?aid=455&type=expert&pid=1 If you have a PS3 and want to play with real-time raytracing yourself, you don't have to wait two years for Intel. See http://alphaworks.ibm.com/tech/irt Mike From lenglish5 at cox.net Mon Sep 24 12:16:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 12:16:52 2007 Subject: [sldev] Permissions In-Reply-To: <46F77E34.9010305@zurich.ibm.com> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> Message-ID: <46F80D21.4020701@cox.net> dirk husemann wrote: > SL - Farallon Greyskin wrote: > >> [...] >> >> If there are any changes to the permission system (other than fixes >> for current brokenness like mod/copy objects going no mod when they >> are taken from world when they contain a no mod script) it would be >> nice to be able to do things like set an object for sale /permanently/ >> rather than just for one generation, and possibly allow a temp >> transfer so that everything could be set to "gift" and then the owner >> could give it away and people could regift etc until someone "claimed" >> it... >> >> Farallon >> > i think that the whole permissions systems is an "honor" system at best. > why? well, the client --- or better: a client --- will always get the > prim coordinates as well as the texture references from the grid. with > open source clients you cannot count on nor can you guarantee that they > will NOT act as a "copy bot" --- with the exception of scripts, but with > open grids/open sims that will change as well. > > as the "DRM" debacle of the last years has shown, "DRM" never really > works in the end --- and it always drags with it more problems > (useability, maintainability, etc), that become a pain to interact with. > > just my humble opinion, though. feel free to disagree :-) > > cheers, > dirk > > > The discussion was about "honorable" vs "non-honorable" sim honrs. Wanna get that honorable sim certificate? Disallow these things on your grid. Get reported violating the terms of your agreement and have it verified? Get blacklisted in the community and lose your certificate. From secret.argent at gmail.com Mon Sep 24 12:22:48 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 12:22:55 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> Message-ID: I think Michi's position is completely reasonable (though I suspect that what he posted may be something of a form letter, at least I haven't seen some of the arguments he's opposing on this list... certainly nothing about 'no transfer' being evil), but I would like to make one comment on a tiny point, because there's a huge can of worms that I don't think that any content creator should open. > 2) I think an extension of permissions to give the ability to > comply with > copyright as well as copyleft should exist. In addition to "no > copy", "no > transfer", "no modify"; we could indeed have "may not set nomod" or > "may > not set no transfer". And the eternally asked-for "may not charge > money > for trasfer". "May not set no-mod/copy/transfer" are all interesting options. Applied recursively, they would be enough to implement a copyleft model. And that would by itself remove a lot of the incentive for people to "rip off freebies", because they wouldn't be able to turn them into something that people couldn't pass on. And that may have to be enought, because "May not charge money for transfer" is not implementable without tearing huge holes in LSL and existing content. Implementing that would require getting rid of llGiveInventory() and possibly llRezObject() as well. Otherwise any scripted vendor would bypass it automatically. > 3) Grid level permissions, i.e., "May rez/attach on a trusted grid" vs > "May rez/attach only on SL grid" or , "May rez/attach anywhere". This is what I was getting at with my certificate idea. Let people choose what grids they want to trust with their content. Possibly charge more for a version that can be taken to less trusted grids. From lenglish5 at cox.net Mon Sep 24 12:24:07 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 12:24:10 2007 Subject: [sldev] Permissions In-Reply-To: <200709241142.58284.dale@daleglass.net> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <23bbb49e0709240221n2868fbcfsb1b4a461e4f0da3c@mail.gmail.com> <200709241142.58284.dale@daleglass.net> Message-ID: <46F80ED7.4020604@cox.net> Dale Glass wrote: > On Monday 24 September 2007 11:21:12 Tao Takashi wrote: > >> Regarding an open grid: Wouldn't it still be more practical for somebody >> to copy via a client hack than via a server hack if it's not about >> scripts? Should be easier than trying to get people on your sim to copy >> it. >> > Probably, yeah. > > Have in mind though that content creators are artists and not necessarily > very technically knowledgeable, so some of them will worry about things > that seem quite clear to us. > > Most people are not deliberately dishonest about harge things. if they comprehend emotionally hoow much work something took to create, they tend to be less likely to steal it. If you make it harder for them to steal, while still easy to use, their sense of morality tends to kick in, once again if they casually try to steal a copy of something to pass to their friends. Its a fine balance. 99% and $1.99 downloads from iTunes dissuade most people from trying to crack iTunes protection, even if it isn't perfect. $L100 LInden items also make it easier (either practically or emotionally) to buy most things than to steal them, so most people remain honest. >> Of course scripts are an issue but for the LL grid it will certainly >> come down to be a trust issue. Linden Lab needs will most probably have >> a TOS in place for connecting to their grid. >> >> But as was obvious in the meeting yesterday, the copy problem seems to >> be one of the main issues, at least for some. I haven't yet talked to >> content creators how big they see that issue (and it might also need >> some explanation and beside that an open grid of course offers a bigger >> market and other opportunities than just problems). >> > Well, I was involved in one talk of the sort, and at least from the > conversation I had, I'd say they're VERY worried. > > In fact, they tried very hard to try to convince me of their position, > hoping that I hold enough influence here (hah) to convince people here not > to create a grid design that'd drive them out of business. > > Note here that I'm not saying what I am simply because I've been asked to, > I really think having an economy is a good thing for SL, and IMO the > current permissions system is quite reasonable. > > ------------------------------------------------------------------------ Its always been an honor system on the grid. Certificates will simply extend that honor system to the grid itself. Also, if it becomes known that a dishonest grid owner is stealing EVERYTHING from visitors, including copies of their notes on the best porn sites and transcripts of cyber-dates, users will have more incentive to not visit those sims. From nicholaz at blueflash.cc Mon Sep 24 12:36:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 12:36:50 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> Message-ID: <46F811B8.8010004@blueflash.cc> Argent Stonecutter wrote: >> 2) I think an extension of permissions to give the ability to comply with >> copyright as well as copyleft should exist. In addition to "no copy", "no >> transfer", "no modify"; we could indeed have "may not set nomod" or "may >> not set no transfer". And the eternally asked-for "may not charge money >> for trasfer". > > "May not set no-mod/copy/transfer" are all interesting options. Applied > recursively, they would be enough to implement a copyleft model. And > that would by itself remove a lot of the incentive for people to "rip > off freebies", because they wouldn't be able to turn them into something > that people couldn't pass on. > > And that may have to be enought, because "May not charge money for > transfer" is not implementable without tearing huge holes in LSL and > existing content. Implementing that would require getting rid of > llGiveInventory() and possibly llRezObject() as well. Otherwise any > scripted vendor would bypass it automatically. LOL, I wouldn't expect the system to be perfect in this direction either, but if you keep the current no-permissions by saying they are an expression of intent and while they can be broken, serve a purpose, then I don't see why an opposite expression/intention should not be implemented because it can be circumvented. If speed limit signs are used even if you can ignore them, the same must be true for minimum speed signs. If the object itself carries an expressed intent of "no sale" that the end user can check or observe, there will be enough end users to IM the vendor to death if he circumvents it by a script. It's like GPL licenses in source. What counts is the expressed intent of the creator. Nick From lenglish5 at cox.net Mon Sep 24 12:38:04 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 12:38:07 2007 Subject: [sldev] Re: [ARCH//META] Permissions and limitations of distrust In-Reply-To: <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <1190653498.6005.29.camel@localhost> <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> Message-ID: <46F8121C.3030808@cox.net> Argent Stonecutter wrote: > On 24-Sep-2007, at 12:04, Abh Serechai Belxjander wrote: >> where is the middle ground? > > You're looking at it as a technical issue. It's not. It's a social > one. It's like you're saying "speed limit signs don't stop people > speeding, so there's no point posting them". > >> you get a certificate allocated by verisign, LL have already put >> "trust verisign" on their end, > > No they haven't. Not in this design. > > They've given YOU, as a creator of an object, the option to choose to > trust certificates signed by verisign. > > If you have checked "verisign" in that example list I posted, then SL > will allow your content to be transferred into regions if they have a > certificate signed by verisign. If you haven't, it's not even going to > ask for that certificate... it'll deny the transfer. > Interestingly enough, I was wondering about the legal precedents and trying to explain to a judge that someone hacking their account to transport copyrighted material they owned into a new sim without a trust certificate was wrong and a violation of various kinds of copyright laws. Then I realized that there are already precedents where region codes are supported in DVDs. Hack your video player to play multiple region DVDs and you are violating the law. Start selling or making available for distribution, the content of region coded DVDs, and you're liable for breaking several laws at once. Helping people break the law is also against the law, etc. We're not in virgin legal territory here, IMHO. From secret.argent at gmail.com Mon Sep 24 12:39:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 12:39:30 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <46F807FF.60100@watson.ibm.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> <46F7AD45.2010900@zurich.ibm.com> <19479508-2CB3-469E-B5B0-89B0F6153C93@gmail.com> <46F807FF.60100@watson.ibm.com> Message-ID: <2F5A8C72-A988-431A-97BB-0379CF0E3CA7@gmail.com> On 24-Sep-2007, at 13:54, Mike Monkowski wrote: > I guess the important thing is to not expect the sim to be a > monolith. Allow partitioning of the tasks so that if someone is > willing to throw the hardware at it, they could do, e.g., collision > detection on custom avatar meshes. As you pointed out, this has an > effect on the communications load, so it's not just a black box > partitioned any way you like. Not just the communications load. You'd have to change the protocol to get the client to track the behavior of the sim and vice versa. If you're going to do that, it might be more efficient for the client to handle that level of collision detection (not full on physics, just looking for intersections), and inform the sim when they occur. You probably wouldn't be using this detailed a level of physics for gross physical movements. Games typically have two collision envelopes for characters... a coarse one like the SL bounding box to control when the character is blocked, and a fine one to allow the character to effect objects. Neither of them is detailed down to the mesh level, the fine one is usually based on a stick figure made of convex surfaces around each bone. So walking along, the client would detect that your left foot has hit a box on the ground, and it'll let the sim know that it's occurred and what the impulse vector should be. If the client's updates aren't recent, then the sim would fall back on the coarse bounding box for both purposes. From lenglish5 at cox.net Mon Sep 24 12:40:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 12:40:49 2007 Subject: [sldev] Avatar Viewer In-Reply-To: <46F7E5B6.60703@zweitgeist.com> References: <46F7E5B6.60703@zweitgeist.com> Message-ID: <46F8129F.2020702@cox.net> atreptow wrote: > Is it possible to write a hardly cropped slviewer that can view every > avatar without authenticate to sl, only sending a request or something > to the server with data like character name and getting back the data > for displaying the avatar. without the possibility to act with this > character in the sl-world? > > for example for a friend viewer that can view all friend avatars and > maybe also shows when they are online > > greets > Alex > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > I would think so, but only if you have "physically" been the the presence of your friend. The server never sends stuff that is completely out of range of your camera view, like in, avatar meshes 3 sims over. From michi at luskwood.org Mon Sep 24 12:40:45 2007 From: michi at luskwood.org (michi@luskwood.org) Date: Mon Sep 24 12:40:52 2007 Subject: [sldev] Re: Permissions - A content creator's view (Argent Stonecutter) Message-ID: <17233.140.239.129.98.1190662845.squirrel@webmail2.pair.com> Argent; Not a form letter at all, no, sorry about that; I did compose it at work while working on a formal document so my wording might have been a bit stifled. The remark about no-transfer being "evil", that was actually in an earlier thread - though it's probably not productive to drumbeat that. I do agree with your analogy regarding speed limit signs. And your idea of a "permission for permissions" i.e., "may not set no-mod/copy/transfer" - it's a much simpler approach and less convoluted. But this is the sort of discussion I was speaking of - a back and forth hashing out until a good body of ideas is developed. I'm not claiming to have all (or any) of the final ideas. Am just exposing thoughts to the discussion for reason of dialogue. Michi Lumin From secret.argent at gmail.com Mon Sep 24 13:12:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 13:12:38 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <46F811B8.8010004@blueflash.cc> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <46F811B8.8010004@blueflash.cc> Message-ID: On 24-Sep-2007, at 14:36, Nicholaz Beresford wrote: > LOL, I wouldn't expect the system to be perfect in this direction > either, > but if you keep the current no-permissions by saying they are an > expression > of intent and while they can be broken, serve a purpose, then I > don't see > why an opposite expression/intention should not be implemented > because it > can be circumvented. If speed limit signs are used even if you can > ignore > them, the same must be true for minimum speed signs. The difference is that with scripted vendors being so common, and due to the fact that scripted vendors would automatically bypass ANY kind of "do not resell" restriction, innocent infringement is not just a reasonable defense... it becomes inevitable. A sign that you can bypass without even seeing it is no sign at all... if the "speed limit" sign was behind a tree, and you can prove it, then unless you're in a crooked jurisdiction you'll beat the ticket. > If the object itself carries an expressed intent of "no sale" that the > end user can check or observe, there will be enough end users to IM > the > vendor to death if he circumvents it by a script. But the fact that the product has a "do not resell" permission doesn't mean the guy you bought it from was violating that permission. It may simply be because that guy doesn't want YOU to resell it. Permissions don't apply to the the person who sets them, they're "next owner" restrictions. You could only allow the creator to do that, but that would cause problems for people who use kits in their builds. > It's like GPL licenses in source. What counts is the expressed > intent of the creator. That's a much better idea. Adding a trapdoored license field to the permissions system pointing to a notecard (by UUID), allowing you to put an irrevocable covenant on the asset, would do as well... and be far more versatile. For example, it would mean that people wouldn't be able to say they "didn't know" that the GPLed script in the no-mod avatars they're selling was covered by the GPL. Right click on the object and select "license" and it'll show you all the licenses on that object or its content. The license could even be set so you have to approve it to accept the object, though I suspect many people will decide to shun vendors who abuse that option. That way if you bought the product from "Honest John" and the license says "This object is only to be sold by Original Creator", you know that "Honest John" didn't just set the "no sale" bit. From sl at phoca.com Mon Sep 24 13:13:01 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Mon Sep 24 13:13:12 2007 Subject: [sldev] Re: Permissions - A content creator's view (ArgentStonecutter) In-Reply-To: <17233.140.239.129.98.1190662845.squirrel@webmail2.pair.com> References: <17233.140.239.129.98.1190662845.squirrel@webmail2.pair.com> Message-ID: <1F17E5EE9B6947F0A4AB41132BC35B3C@SanMiguel> What needs to be kept in mind however is a couple of things about the current permission system: 1) The current system works, SL has a robust object sales economy based on it, so it is not so broken that it needs some kind of major change of overhaul like getting rid of no-transfer). If anything it needs maybe a little refinement or addition to. 2) The current permission system as simple as it is is actually quite complex to people that don't really know what they are doing. So any changes or additions should not complexify it any more than it already is. It MAY be possible to even simplify it without giving up any of the current creator freedoms. That being said, I say fix the current bugs in it FIRST before continuing with any serious changes. The object going no copy when an in world copy is made because it contains a no copy inventory is REALLY ANNOYING. I do like the idea of a "GPL" like permission as it was called, though in reality a "This must remain free" permission. I create a lot of things, I sell things, I give away things. But I will NEVER give away a full perm object! Too many people take your good intentions and then rip other people off by reselling them. I would love to see a "Keep this object free" permission :) Farallon ----- Original Message ----- From: To: Sent: Monday, September 24, 2007 12:40 PM Subject: [sldev] Re: Permissions - A content creator's view (ArgentStonecutter) > Argent; > > Not a form letter at all, no, sorry about that; I did compose it at work > while working on a formal document so my wording might have been a bit > stifled. > > The remark about no-transfer being "evil", that was actually in an earlier > thread - though it's probably not productive to drumbeat that. > > I do agree with your analogy regarding speed limit signs. And your idea of > a "permission for permissions" i.e., "may not set no-mod/copy/transfer" - > it's a much simpler approach and less convoluted. > > But this is the sort of discussion I was speaking of - a back and forth > hashing out until a good body of ideas is developed. > > I'm not claiming to have all (or any) of the final ideas. Am just exposing > thoughts to the discussion for reason of dialogue. > > Michi Lumin > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Mon Sep 24 13:24:34 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 13:27:26 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <46F811B8.8010004@blueflash.cc> Message-ID: <46F81D02.3020602@blueflash.cc> > That's a much better idea. Adding a trapdoored license field to the > permissions system pointing to a notecard (by UUID), allowing you to put > an irrevocable covenant on the asset, would do as well... and be far > more versatile. For example, it would mean that people wouldn't be able > to say they "didn't know" that the GPLed script in the no-mod avatars > they're selling was covered by the GPL. > > Right click on the object and select "license" and it'll show you all > the licenses on that object or its content. The license could even be > set so you have to approve it to accept the object, though I suspect > many people will decide to shun vendors who abuse that option. > > That way if you bought the product from "Honest John" and the license > says "This object is only to be sold by Original Creator", you know that > "Honest John" didn't just set the "no sale" bit. I'm all for that, because this would also address another idea I'm having. A lot of Creative Commons work (and I'm purposefully avoiding the the term "art") is driven by attribution. Being it the idea to build a reputation or simply personal satisfaction. In fact I once read an article that a lot of contributions in the sci-fi scene is driven what the author called ego-points. Such a "creators notice" field or even something more advanced could serve to fuel people's drive to create free content, if there is an intangible benefit for it. It would automatically serve as a more prominent form of attribution (more prominent than more, more inspect) and would probably be used in more creative forms (Killroy was here!), which in return may make it more interesting to actually look at these. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From josh at lindenlab.com Mon Sep 24 13:31:58 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Sep 24 13:34:11 2007 Subject: [sldev] [SECURITY] Release Notes for Second Life 1.18.3(5) September 20, 2007 In-Reply-To: <46F38CC6.4030503@blueflash.cc> References: <20070920225155.95F9B41B002@stupor.lindenlab.com> <46F38CC6.4030503@blueflash.cc> Message-ID: <46F81EBE.6060702@lindenlab.com> Nicholaz Beresford wrote: > Argent Stonecutter wrote: >> Did this not apply to the RC, was this fixed without an entry in the >> release notes, or is the RC still vulnerable? > > It's fixed ... it's the practically the only noticeable change > in the source code for this release at all (besides version numbering). Yeah... the fix was merged in but the updated release notes were not. I'll make sure that happens. From 1337mail at gmail.com Mon Sep 24 13:39:09 2007 From: 1337mail at gmail.com (Michael Miller) Date: Mon Sep 24 13:39:11 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F71CEF.1000203@gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> Message-ID: <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> Well, how long until the regressions are fully tested, and the "official" build goes to 1.18.3? -- Mike On 9/23/07, Jason Giglio wrote: > Michael Miller wrote: > > How soon(approximately, of course) until the RCs become stable? > > > > The RCs are stable. The idea is to find out if there are any > regressions, if not, then the RC becomes the release, without further > change. > > -Jason > > From josh at lindenlab.com Mon Sep 24 13:51:38 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Sep 24 13:53:51 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> Message-ID: <46F8235A.3080809@lindenlab.com> Part of the point of the RC process is to avoid introducing new bugs. However, the triage bar ratchets up as time passes. This is our first iteration through a public RC process (although it's conceptually the same as a Beta, but the experience against the main grid is quite different) so we're still tuning the triage bar and don't have a solid time estimate. I'd REALLY REALLY like to have 1.18.3 go gold this week - but I've said that for the past 3 weeks as well. If you want to help, the appropriate query is here: https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=10631 You'll want to analyze it as follows: * Show only UNRESOLVED issues * Make sure you can see the Affects Version/s column * Ignore anything that affects versions other than 1.18.3 RC as well This gives a list of bugs that would appear to be new in 1.18.3. If you see bugs on that filtered list that aren't actually bugs in the 1.18.3 RC (i.e. misfiled as VWR, affects older viewer builds too, etc), then please feel free to edit the bug or call it to my attention. We've been going through this daily and trying to make sure that the reported bugs are, in fact, new (trying to get internal repros if necessary) and if they merit holding back the release of 1.18.3 (i.e. do they meet the triage bar). At the point where we have gone some as-yet undetermined amount of time with no new bugs reported that meet the triage bar, 1.18.3 will "go gold". Michael Miller wrote: > Well, how long until the regressions are fully tested, and the > "official" build goes to 1.18.3? > > -- Mike > > On 9/23/07, Jason Giglio wrote: > >> Michael Miller wrote: >> > How soon(approximately, of course) until the RCs become stable? >> > >> >> The RCs are stable. The idea is to find out if there are any >> regressions, if not, then the RC becomes the release, without further >> change. >> >> -Jason >> >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Mon Sep 24 14:02:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 14:02:20 2007 Subject: [sldev] Permissions In-Reply-To: <200709241125.46563.dale@daleglass.net> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <200709241125.46563.dale@daleglass.net> Message-ID: <1190667722.19728.48.camel@localhost> On Mon, 2007-09-24 at 11:25 +0200, Dale Glass wrote: > Not my personal opinion, but content providers argue that even if a perfect > solution isn't possible, permissions should still exist, if only as a way > of indicating the will of the author. > > There is a certain sense in forcing people to bypass the system, even if > it's very weak. If you bypassed it, you can't really argue you didn't know > what the creator wanted. > > Really, IMO, the permissions system should continue to exist. If you don't > want to restrict your own stuff, then don't, and just release all your > stuff as full perms. But there are a lot of people who will be really > annoyed should it vanish completely. Well, the real issue with DRM systems is, should the will of the author be allowed to usurp the legal rights of the purchaser? Should Apple be able to dictate what software and hardware I can use to play the songs I "purchased" on iTunes? Should Sony be allowed to rootkit any machine I wish to use to play their CDs? When I purchase an avatar on Second Life, should the avatar creator be able to tell me what grids and what sims I can use their avatar on? Should they be able to prevent me from making a backup copy, and prevent me from modifying it? If the answers here are "Yes", then IMHO you really haven't bought anything. I find it ironic that the classic cold war straw man argument against communism was "You aren't even allowed to own your own toothbrush!", and yet, if the poster boys of capitalism such as the MPAA, RIAA and Microsoft had their way, you wouldn't own anything either. You'd merely be purchasing a limited license to view their content, on their terms, on a revocable basis. You're renting, not buying. And guess what, they're already getting their way. (Not that there's anything wrong with renting. Netflix is awesome. However, telling someone they're buying something, when they're really not is *evil* and *wrong*.) (And lets get one thing straight, I'm all for free market capitalism. What the MPAA, RIAA and Microsoft are trying to do, is not a free market. Are we deep enough into politics yet? :) For further study I recommend everyone just go read (or watch) Lawrence Lessig's "Free Culture": http://www.free-culture.cc/ http://randomfoo.net/oscon/2002/lessig/ And while we're at it: http://www.lafkon.net/tc/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/7b9d67e6/attachment-0001.pgp From tao.takashi at googlemail.com Mon Sep 24 14:14:30 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Sep 24 14:14:32 2007 Subject: [sldev] Permissions In-Reply-To: <1190667722.19728.48.camel@localhost> References: <46E806E7.1010104@corp.telexs.nl> <46F77E34.9010305@zurich.ibm.com> <200709241125.46563.dale@daleglass.net> <1190667722.19728.48.camel@localhost> Message-ID: <23bbb49e0709241414i1e0f98cbk4afe12d94255edcd@mail.gmail.com> > > > And while we're at it: > > http://www.lafkon.net/tc/ My favourite video about this topic, I hope everybody watches this. And actually it brings us back to the issue of trust, doesn't it? ;-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/e0659f01/attachment.htm From secret.argent at gmail.com Mon Sep 24 14:50:21 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 14:50:32 2007 Subject: [sldev] Re: [META/LEGAL] Permissions In-Reply-To: <20070924210219.E820C41B261@stupor.lindenlab.com> References: <20070924210219.E820C41B261@stupor.lindenlab.com> Message-ID: <74F5A454-A944-437D-91FD-5179840C89F1@gmail.com> From: Callum Lerwick > Well, the real issue with DRM systems is, should the will of the > author > be allowed to usurp the legal rights of the purchaser? According to the LL TOS, the creator of an object owns the intellectual property, and Linden Labs owns the actual content, so this doesn't come up. In fact, right now, the will of the author can even usurp the rights model that LL originally spelled out. It should not be *possible* to make an object that is both no-copy and no-transfer, and originally that wasn't possible. Since it now is, if someone has accidentally created one they should not be able to transfer it until they correct that. Yes, this means doing a (fairly simple) analysis of the permissions on the object's content when it's transferred. > Should Apple be able to dictate what software and hardware I can > use to > play the songs I "purchased" on iTunes? They don't. They put up a token defense to mollify the labels and then tell you how you can remove the DRM by backing your music up to audio CDs. > Should Sony be allowed to rootkit any machine I wish to use to play > their CDs? Nope. > When I purchase an avatar on Second Life, should the avatar creator be > able to tell me what grids and what sims I can use their avatar on? You purchase the right to use that content in Second Life. You don't purchase the right to take the content out of SL. > If the answers here are "Yes", then IMHO you really haven't bought > anything. You've bought an indefinite license to use that content inside SL via the account that you purchased it through. That's all. I would much prefer to have bought more than that, I'd love to have bought an actual copy of the content that I could download, upload, measure, tape, splice, remix, and ship to Patagonia, and yes it bothers me that I can't buy more than that, but that's how things work in Second Life. They have to, if LL isn't going to be liable for millions of dollars in losses if they shut the grid down. And maybe the TOS shouldn't be able to say what they do, though I suspect that would mean there wouldn't be a Second Life if they did. But that's what they say, and that's all you bought, so arguing about what your legal rights to the property that Linden Labs owns are is a waste of time. From ettore_pasquini at 3dconnexion.com Mon Sep 24 14:53:43 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Mon Sep 24 14:53:50 2007 Subject: [sldev] [VWR] SVC-613 login handshake issue for optional update Message-ID: Are there any immediate workarounds for SVC-613? http://jira.secondlife.com/browse/SVC-613 I have been building off of the Branch_1-18-3-Viewer branch for quite some time and never encountered the problem until today. I guess reverting to 1.18.1.* ? I think 1.18.2 was a required update though, was it not? Ettore From sl at phoca.com Mon Sep 24 15:02:12 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Mon Sep 24 15:02:18 2007 Subject: [sldev] Permissions In-Reply-To: <1190667722.19728.48.camel@localhost> References: <46E806E7.1010104@corp.telexs.nl><46F77E34.9010305@zurich.ibm.com><200709241125.46563.dale@daleglass.net> <1190667722.19728.48.camel@localhost> Message-ID: The short answer to your questions is "yes". SL has a very diverse and open market, and no where is anyone forced to use a certain vendors products if they are too restrictive. People here are free to vote with their $ more than anywhere else. As long as the terms of use are spelled out before the sale and not lied about (though I have run into that in SL) then there is no problem. And example almost no one would argue against: Applying the GPL restricts certain users "rights" in favor of the creator's wishes. And the restrictions are pretty onerous depending on the user's desires. NO ONE would dare say that it was the user's right to not comply with the GPL restrictions should trump the author's wishes in applying it. If you don't want to comply with the GPLs restrictions on user's freedoms then write it yourself or go elsewhere. Same with SL products. Don't like the terms, make it yourself or go elsewhere. Any vendor that loses sales to another will change their tune. I cringe at the state of the entitlement that a huge segment of the population seem to feel themselves in these days. If I want to release something with completely free perms, BSDed, GPLed or reasonably locked down for commercial gain that is my right as the creator, *I* created it, don't like it? Make it yourself or buy it from someone else. The only rights the consumer has is the right to not buy from me, and maybe complain to me about it. (Assuming I'm not lying in my advertisement or anything else shady or illegal of course) The only case where that would not apply is in monopolistic cartels such as the music industry, grocery chains or oil companies (Of which you named a few as examples). If they own 99% of all available product under one roof and there is no reasonable alternative then they must have a leash put on that protects basic rights such as not being forced to pay 100$ for a carton of milk. However, this is NOT the case in SL at all. A real SL example: A certain vendor of a pose stand that was basically free suddenly decided to start charging an arm and a leg for it. So I made my own pose stand and am selling it for cheap and giving it away for free to all my friends. See? The system works! Some creator gets too greedy or onerous (as is their right), there are 100 more ready to take their place. No need to go all trust buster on the fledgling SL creator community just yet :( Farallon ----- Original Message ----- From: "Callum Lerwick" To: Sent: Monday, September 24, 2007 2:02 PM Subject: Re: [sldev] Permissions Well, the real issue with DRM systems is, should the will of the author be allowed to usurp the legal rights of the purchaser? Should Apple be able to dictate what software and hardware I can use to play the songs I "purchased" on iTunes? Should Sony be allowed to rootkit any machine I wish to use to play their CDs? When I purchase an avatar on Second Life, should the avatar creator be able to tell me what grids and what sims I can use their avatar on? Should they be able to prevent me from making a backup copy, and prevent me from modifying it? If the answers here are "Yes", then IMHO you really haven't bought anything. I find it ironic that the classic cold war straw man argument against communism was "You aren't even allowed to own your own toothbrush!", and yet, if the poster boys of capitalism such as the MPAA, RIAA and Microsoft had their way, you wouldn't own anything either. You'd merely be purchasing a limited license to view their content, on their terms, on a revocable basis. You're renting, not buying. And guess what, they're already getting their way. (Not that there's anything wrong with renting. Netflix is awesome. However, telling someone they're buying something, when they're really not is *evil* and *wrong*.) (And lets get one thing straight, I'm all for free market capitalism. What the MPAA, RIAA and Microsoft are trying to do, is not a free market. Are we deep enough into politics yet? :) For further study I recommend everyone just go read (or watch) Lawrence Lessig's "Free Culture": http://www.free-culture.cc/ http://randomfoo.net/oscon/2002/lessig/ And while we're at it: http://www.lafkon.net/tc/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Mon Sep 24 15:01:33 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 15:08:34 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> Message-ID: <1190671293.19728.53.camel@localhost> On Sun, 2007-09-23 at 15:12 -0700, Harold Brown wrote: > They forced the update on the RC's also... have to use .5 Only on Windows. I'm still able to log in with 1.18.3.4 on Linux. Haven't tried 1.18.0.6 yet through... AFAIK OSX isn't vulnerable either, so it shouldn't be forcing upgrades either. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/536f372b/attachment.pgp From seg at haxxed.com Mon Sep 24 15:08:21 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 15:08:44 2007 Subject: [sldev] Re: [META/LEGAL] Permissions In-Reply-To: <74F5A454-A944-437D-91FD-5179840C89F1@gmail.com> References: <20070924210219.E820C41B261@stupor.lindenlab.com> <74F5A454-A944-437D-91FD-5179840C89F1@gmail.com> Message-ID: <1190671701.19728.56.camel@localhost> On Mon, 2007-09-24 at 16:50 -0500, Argent Stonecutter wrote: > But that's what they say, and that's all you bought, so arguing about > what your legal rights to the property that Linden Labs owns are is a > waste of time. I wasn't talking about the current LL grid. I was talking about the future distributed and decentralized dimensional portal web. :) RCP. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/1fcb6ac2/attachment.pgp From anthony at lindenlab.com Mon Sep 24 15:30:28 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Mon Sep 24 15:30:37 2007 Subject: [sldev] Source release for 1.18.2.1 In-Reply-To: <46EAFC0E.7030309@lindenlab.com> References: <46E9C06F.1030203@lindenlab.com> <46EAFC0E.7030309@lindenlab.com> Message-ID: <46F83A84.8020709@lindenlab.com> Hello Everyone, Here's the source for the viewer release last week. Sorry about the oversight. 1.18.2.1 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.2.1 Release note information here: http://blog.secondlife.com/2007/09/19/second-life-1182-is-released/ Checksums: b4ab5c61245a7ae9caa2f8814d9e1d2e slviewer-darwin-libs-1.18.2.1.tar.gz 23ea5c9eccd58fa36e60d168c132730a slviewer-linux-libs-1.18.2.1.tar.gz 9ee61f2b8e4bf29be69b27cfe3a3eab7 slviewer-src-1.18.2.1.tar.gz 0a00c586f7f11cacb46efe2749b3cde2 slviewer-artwork-1.18.2.1.zip 198b3a200683b48d84f7949a0daa76f0 slviewer-src-1.18.2.1.zip f73bcebff66a67df71fbe628bb33b49c slviewer-win32-libs-1.18.2.1.zip SVN checkout: Rob will send email about this once it's up. Enjoy. -Anthony From nicholaz at blueflash.cc Mon Sep 24 15:33:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 15:33:42 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F8235A.3080809@lindenlab.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> Message-ID: <46F83B2C.40302@blueflash.cc> Joshua Bell wrote: > Part of the point of the RC process is to avoid introducing new bugs. > However, the triage bar ratchets up as time passes. This is our first > iteration through a public RC process (although it's conceptually the > same as a Beta, but the experience against the main grid is quite > different) so we're still tuning the triage bar and don't have a solid > time estimate. I'd REALLY REALLY like to have 1.18.3 go gold this week - > but I've said that for the past 3 weeks as well. > [...] Kudos, man ... KUDOS! Nick From nicholaz at blueflash.cc Mon Sep 24 15:50:21 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Sep 24 15:50:47 2007 Subject: [sldev] [ATTN-LINDEN] Who is lindenrobot on JIRA? Message-ID: <46F83F2D.4060300@blueflash.cc> Or more exactly, what is he doing? :-) Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From Anders at Arnholm.se Mon Sep 24 15:59:30 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Mon Sep 24 16:01:49 2007 Subject: [sldev] Re: [ARCH//META] Permissions and limitations of distrust In-Reply-To: <46F8121C.3030808@cox.net> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <1190653498.6005.29.camel@localhost> <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> <46F8121C.3030808@cox.net> Message-ID: <1190674771.10782.14.camel@kitiara> On Mon, 2007-09-24 at 12:38 -0700, Lawson English wrote: > Then I realized that there are already precedents where region codes are > supported in DVDs. Hack your video player to play multiple region DVDs > and you are violating the law. Start selling or making available for > distribution, the content of region coded DVDs, and you're liable for > breaking several laws at once. I can only with some certainly talk about swedish laws, but making a region free dvd player is definitively legal here, about 90% on the market here today is region free. It's wel inside fair use as well. Balp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From josh at lindenlab.com Mon Sep 24 16:11:28 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Sep 24 16:13:42 2007 Subject: [sldev] [VWR] SVC-613 login handshake issue for optional update In-Reply-To: References: Message-ID: <46F84420.6040907@lindenlab.com> Ettore Pasquini wrote: > Are there any immediate workarounds for SVC-613? > > http://jira.secondlife.com/browse/SVC-613 > > I have been building off of the Branch_1-18-3-Viewer branch for quite some > time and never encountered the problem until today. I guess reverting to > 1.18.1.* ? I think 1.18.2 was a required update though, was it not? > Assuming you're specifically asking about the "login handshake issue for optional update" part (VWR-613 is a mess, and appears to mention at least two distinct issues), then the workaround is to update to the latest code (1.18.3.5) which contains the fix. The relevant diff is: Index: C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp =================================================================== --- C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp (revision 69944) +++ C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp (revision 69945) @@ -2613,7 +2613,7 @@ #if !LL_RELEASE_FOR_DOWNLOAD if (option == 2) { - LLStartUp::setStartupState( STATE_WORLD_INIT ); + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); return; } #endif @@ -2629,7 +2629,7 @@ } else { - LLStartUp::setStartupState( STATE_WORLD_INIT ); + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); } return; } From robla at lindenlab.com Mon Sep 24 16:15:43 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Sep 24 16:15:54 2007 Subject: [sldev] [ATTN-LINDEN] Who is lindenrobot on JIRA? In-Reply-To: <46F83F2D.4060300@blueflash.cc> References: <46F83F2D.4060300@blueflash.cc> Message-ID: <46F8451F.4080304@lindenlab.com> On 9/24/07 3:50 PM, Nicholaz Beresford wrote: > Or more exactly, what is he doing? :-) If I told you, I'd have to kill you. It's nefarious and awful. Ok, actually, it's just the username of our importer script. When we pull an issue into our internal tracker, there's a script that copies the title and the description, wraps the description with some prose to make it clear it was pulled in from the external database and that someone else wrote the description (since the person who imported it is marked as the "reporter"), puts a link back outward and says "(Note: important details about this issue, including patches, comments and other attachments, are only available in the public issue tracker. Please use the URL above to access the issue)". It also ensures the number of the internal issue gets published in the public tracker. See, I told you it was nefarious and awful. But, no, I don't have to kill you yet. ;-) Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/c2ea7679/signature.pgp From grazel.cosmo at gmail.com Mon Sep 24 16:37:06 2007 From: grazel.cosmo at gmail.com (Kele Kravelin) Date: Mon Sep 24 16:37:08 2007 Subject: [sldev] What color should I paint the bike shed? In-Reply-To: <46F7A733.2060802@blueflash.cc> References: <20070924044026.E6C8541B118@stupor.lindenlab.com> <46F768CE.90908@gmail.com> <0A8760DC-1CBA-49A8-A043-60DAEBA6A7AE@gmail.com> <46F7A733.2060802@blueflash.cc> Message-ID: <3c1fe370709241637y7e2ad81ayf45ce18dea1d5ba2@mail.gmail.com> I'm ambivilent about BMP but it may be useful to some so is probably best to be left in place. As for PNG it should be added as an option, but not if it removes TGA. Both PNG and TGA are becoming standards (along with JPG, BMP has the least support really) in screenshot formats in various games, especially online MMO style games. Grazel Cosmo On 9/24/07, Nicholaz Beresford wrote: > > > Argent Stonecutter wrote: > > On 24-Sep-2007, at 02:35, Jason Giglio wrote: > >> Well as I pointed out elsewhere, MS Paint in Win XP+ apparently does > >> support PNG. > > > > Not in Windows 2000, which is still supported (and is the last version > > of Windows that's big-brother-free). > > Well, I'd say leave BMP in if you want the patch accepted. Taking it > out the Lindens can only loose, there's someone bound to complain > because it breaks something for someone (and be it just a weird > automated system that can only read BMPs) and there's no real benefit > (like performance, code size, etc.) in removing it. > > Btw, there's already an option somewhere in prefs to save screens in > compressed format which saves the screenshots in TGA atm. Adding > an option for PNG there may be the way to go, or replacing TGA with > PNG (as that's bound to break it for less people). > > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070924/47b2e73f/attachment.htm From secret.argent at gmail.com Mon Sep 24 16:45:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 24 16:46:01 2007 Subject: [sldev] Re: [META/LEGAL] Permissions In-Reply-To: <20070924225053.98FA941B26F@stupor.lindenlab.com> References: <20070924225053.98FA941B26F@stupor.lindenlab.com> Message-ID: From: Callum Lerwick > I wasn't talking about the current LL grid. I was talking about the > future distributed and decentralized dimensional portal web. :) I'm not sure what your point is. In the future web SL will STILL have the right to restrict whether you're allowed to copy their property to a grid/region/domain/kraal/commune/wakalix not under their control. And other domains will have other policies... the point here is that if you set up a mmechanism whereby people can tell the domain they create the content in what policies they're willing to have applied to what they create, the market will favor the domain the provides the best balance between creators and consumers rights. If you don't have such a mechanism then the market will favor the domain that has the most content, and we know what that is and what balance it has selected. From ettore_pasquini at 3dconnexion.com Mon Sep 24 16:51:49 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Mon Sep 24 16:51:47 2007 Subject: [sldev] [VWR] SVC-613 login handshake issue for optional update In-Reply-To: <46F84420.6040907@lindenlab.com> Message-ID: On 9/24/07 4:11 PM, "Joshua Bell" wrote: > Ettore Pasquini wrote: >> >> I have been building off of the Branch_1-18-3-Viewer branch for quite some >> time and never encountered the problem until today. I guess reverting to >> 1.18.1.* ? I think 1.18.2 was a required update though, was it not? >> > Assuming you're specifically asking about the "login handshake issue for > optional update" part (VWR-613 is a mess, and appears to mention at > least two distinct issues), then the workaround is to update to the > latest code (1.18.3.5) which contains the fix. The relevant diff is: Yes, I am referring to the login issue specifically the one that leaves you stuck at the "Initializing World..." message after login. The logger continuously seems in a loop with messages like INFO: idle_startup: Waiting for seed grant .... I have updated to 1.18.3.5, Revision 106 on svn and I did double-check that I'm using the code below (STATE_LOGIN_AUTH_INIT instead of STATE_WORLD_INIT)... I also cleaned the cache, prayed the sl gods... Still no worky. Ettore > > Index: C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp > =================================================================== > --- C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp > (revision 69944) > +++ C:/linden/Branch_1-18-3-Viewer/indra/newview/llstartup.cpp > (revision 69945) > @@ -2613,7 +2613,7 @@ > #if !LL_RELEASE_FOR_DOWNLOAD > if (option == 2) > { > - LLStartUp::setStartupState( STATE_WORLD_INIT ); > + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); > return; > } > #endif > @@ -2629,7 +2629,7 @@ > } > else > { > - LLStartUp::setStartupState( STATE_WORLD_INIT ); > + LLStartUp::setStartupState( STATE_LOGIN_AUTH_INIT ); > } > return; > } > > > -- http://www.3dconnexion.com/ From jun at cat.co.jp Mon Sep 24 19:20:24 2007 From: jun at cat.co.jp (Jun Takemura) Date: Mon Sep 24 19:20:31 2007 Subject: [sldev] test Message-ID: <20070925.112024.104038329.jun@cat.co.jp> Sorry, this is test mail from my SMTP server to mailing list. --- jun@cat.co.jp From soft at lindenlab.com Mon Sep 24 19:26:32 2007 From: soft at lindenlab.com (Soft) Date: Mon Sep 24 19:26:34 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> Message-ID: On 9/24/07, Argent Stonecutter wrote: > I think Michi's position is completely reasonable (though I suspect > that what he posted may be something of a form letter, at least I > haven't seen some of the arguments he's opposing on this list... > certainly nothing about 'no transfer' being evil), but I would like > to make one comment on a tiny point, because there's a huge can of > worms that I don't think that any content creator should open. For what it's worth, these things come up in discussions in Lusk and other in-world areas pretty frequently. I haven't read anything pulled out of the air here, it's just been expressed comprehensively. All for Iridium's idea on a roundtable for this: There are definitely unanswered questions between this and the future distributed grid. From jhurliman at wsu.edu Mon Sep 24 19:54:07 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Sep 24 19:55:02 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: References: <20070924090722.7FF0341B140@stupor.lindenlab.com> Message-ID: <46F8784F.9090205@wsu.edu> Argent Stonecutter wrote: >> i think that the whole permissions systems is an "honor" system at best. > > Sure. So's the DRM in iTunes. But in both cases they're an honor > system that works, because people accept the necessity. I could go > into a long dissertation as to why "honor system DRM" is adequate, > sufficient, and all you can get in any case. But "it works" should be > all you need really. > The comparison to iTunes is a red herring. Do you honestly think that the iTunes store would be successful if there was an easy to use way of downloading any song you wanted for free? The DRM workarounds for iTunes let you remove restrictions from content you already own, which is a far cry from walking around Second Life saving copies of any object, texture, sound, animation, particle script, etc. that you can see (all of which are possible right now and will always be easily possible in the future). John Hurliman From seg at haxxed.com Mon Sep 24 15:18:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 20:09:54 2007 Subject: [sldev] Re: [ARCH] Render unto Caesar the things that are Caesar's In-Reply-To: <2F5A8C72-A988-431A-97BB-0379CF0E3CA7@gmail.com> References: <20070918083742.1CE1A41B0F8@stupor.lindenlab.com> <46F00962.9090909@lindenlab.com> <46F79F3E.3050206@zurich.ibm.com> <0115E947-BDAB-4B34-8908-3AE11771FC94@gmail.com> <46F7AD45.2010900@zurich.ibm.com> <19479508-2CB3-469E-B5B0-89B0F6153C93@gmail.com> <46F807FF.60100@watson.ibm.com> <2F5A8C72-A988-431A-97BB-0379CF0E3CA7@gmail.com> Message-ID: <1190672332.19728.65.camel@localhost> On Mon, 2007-09-24 at 14:39 -0500, Argent Stonecutter wrote: > Not just the communications load. You'd have to change the protocol > to get the client to track the behavior of the sim and vice versa. If > you're going to do that, it might be more efficient for the client to > handle that level of collision detection (not full on physics, just > looking for intersections), and inform the sim when they occur. In the context of a competitive game environment, like say World of Warcraft or Counterstrike, the server has to be authoritative about pretty much everything to prevent (or at least minimise) cheating. Rule #1: Separate policy from mechanism. Ultimately the protocol should not dictate a particular implementation, instead it should be flexible enough to allow for any number of them. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/311bbd54/attachment.pgp From seg at haxxed.com Mon Sep 24 20:09:45 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 20:10:01 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <46F81D02.3020602@blueflash.cc> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <46F811B8.8010004@blueflash.cc> <46F81D02.3020602@blueflash.cc> Message-ID: <1190689785.19728.72.camel@localhost> On Mon, 2007-09-24 at 22:24 +0200, Nicholaz Beresford wrote: > A lot of Creative Commons work (and I'm purposefully avoiding the the term > "art") is driven by attribution. Being it the idea to build a reputation > or simply personal satisfaction. In fact I once read an article that a > lot of contributions in the sci-fi scene is driven what the author called > ego-points. > > Such a "creators notice" field or even something more advanced could serve > to fuel people's drive to create free content, if there is an intangible > benefit for it. It would automatically serve as a more prominent form > of attribution (more prominent than more, more inspect) and would probably > be used in more creative forms (Killroy was here!), which in return may > make it more interesting to actually look at these. Its called "signing your work" and people have been doing it for hundreds (thousands?) of years. Call it watermarking if you want, but whatever you call it, it's really outside the domain of protocol design. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/d95226db/attachment.pgp From seg at haxxed.com Mon Sep 24 21:04:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 21:04:05 2007 Subject: [sldev] Re: [META/LEGAL] Permissions In-Reply-To: References: <20070924225053.98FA941B26F@stupor.lindenlab.com> Message-ID: <1190693041.19728.83.camel@localhost> On Mon, 2007-09-24 at 18:45 -0500, Argent Stonecutter wrote: > From: Callum Lerwick > > I wasn't talking about the current LL grid. I was talking about the > > future distributed and decentralized dimensional portal web. :) > > I'm not sure what your point is. In the future web SL will STILL have > the right to restrict whether you're allowed to copy their property > to a grid/region/domain/kraal/commune/wakalix not under their > control. I do believe my point was: When you license content, you're licensing COMMUNISM! (Or "When liberty becomes license, dictatorship is near", as someone more eloquent and probably less sleep deprived than I, put it...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/c4c6e96a/attachment.pgp From seg at haxxed.com Mon Sep 24 21:57:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 21:57:30 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F8235A.3080809@lindenlab.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> Message-ID: <1190696242.19728.93.camel@localhost> On Mon, 2007-09-24 at 13:51 -0700, Joshua Bell wrote: > Part of the point of the RC process is to avoid introducing new bugs. What I'd like to see from the "RC" process, is a feature freeze. Whats in stays in, whats out stays out. Bugfix only. For example, look what happened with the SSE code. IIRC, it was pushed out as a required update, and, turns out it didn't actually work on non-SSE systems. LL was forced to rip it out and push another update. What should have happened, is the SSE code should have been pushed out in an RC, and then fixed in the next RC, rather than getting ripped out as damage control. (Or maybe it just should have been tested within LL on an Athlon T-bird in the first place, bleh...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070924/431f25f5/attachment.pgp From lenglish5 at cox.net Mon Sep 24 21:59:37 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 21:59:42 2007 Subject: [sldev] [ATTN-LINDEN] Who is lindenrobot on JIRA? In-Reply-To: <46F83F2D.4060300@blueflash.cc> References: <46F83F2D.4060300@blueflash.cc> Message-ID: <46F895B9.9050100@cox.net> Nicholaz Beresford wrote: > > Or more exactly, what is he doing? :-) > > > Nick Workingonit Linden's little brother? From lenglish5 at cox.net Mon Sep 24 22:00:39 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 24 22:00:41 2007 Subject: [sldev] Re: [ARCH//META] Permissions and limitations of distrust In-Reply-To: <1190674771.10782.14.camel@kitiara> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <1190653498.6005.29.camel@localhost> <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> <46F8121C.3030808@cox.net> <1190674771.10782.14.camel@kitiara> Message-ID: <46F895F7.8040804@cox.net> Anders Arnholm wrote: > On Mon, 2007-09-24 at 12:38 -0700, Lawson English wrote: > > >> Then I realized that there are already precedents where region codes are >> supported in DVDs. Hack your video player to play multiple region DVDs >> and you are violating the law. Start selling or making available for >> distribution, the content of region coded DVDs, and you're liable for >> breaking several laws at once. >> > > I can only with some certainly talk about swedish laws, but making a > region free dvd player is definitively legal here, about 90% on the > market here today is region free. It's wel inside fair use as well. > > Balp > > > Is modifying it and then reslling it OK as well? Seems to kind of go against the whole concept of regions... L From roamingryozu at gmail.com Mon Sep 24 23:10:49 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Mon Sep 24 23:10:51 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <46F8784F.9090205@wsu.edu> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <46F8784F.9090205@wsu.edu> Message-ID: <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> On 9/24/07, John Hurliman wrote: > > Argent Stonecutter wrote: > >> i think that the whole permissions systems is an "honor" system at > best. > > > > Sure. So's the DRM in iTunes. But in both cases they're an honor > > system that works, because people accept the necessity. I could go > > into a long dissertation as to why "honor system DRM" is adequate, > > sufficient, and all you can get in any case. But "it works" should be > > all you need really. > > > > The comparison to iTunes is a red herring. Do you honestly think that > the iTunes store would be successful if there was an easy to use way of > downloading any song you wanted for free? The DRM workarounds for iTunes > let you remove restrictions from content you already own, which is a far > cry from walking around Second Life saving copies of any object, > texture, sound, animation, particle script, etc. that you can see (all > of which are possible right now and will always be easily possible in > the future). > > John Hurliman > Of course, it's possible. The point being made wasn't about whether it could be done before or after purchase, however. I think the iTunes comparison is fine in this case. The existence of the Permissions system is doing it's job just fine. It's not smart proof, but it defines intent, and many are fine going by that intent. Those that aren't, know they're 'breaking the rules' when they bypass it. The same concept applies to iTunes. The intent is clear, even if the ability to bypass it is practically built in, or requires purchase first. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/1051f215/attachment.htm From hud at zurich.ibm.com Mon Sep 24 23:22:22 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Sep 24 23:22:29 2007 Subject: [sldev] Permissions In-Reply-To: References: <20070924151432.956D241B18F@stupor.lindenlab.com> Message-ID: <46F8A91E.6060903@zurich.ibm.com> Argent Stonecutter wrote: > From: Tillie Ariantho >> I am not sure if all the content creators will be happy with it. Sure >> you can tell them "it works". Will they believe you? What if it only >> works 'sometimes'? > > Of course it only works 'sometimes'. It doesn't have to work 'all the > time'. That's the point. And out of all the scripts I've written in > SL, the three that sell the best are sold full perm, and two of them > are actually BSD licensed. They still sell better than the stuff > that's no-transfer. excellent! nice to hear stuff like that :-) > > And really, this is not something I can do anything about. This is not > something Linden Labs can do anything about. This is not something > Apple or Microsoft can do anything about. ALL DRM is honor system DRM. > That's inherent in the problem DRM is trying to solve. Pretending that > something better than "honor system" DRM is possible outside a Science > Fiction novel is fooling yourself, at best. Trying to make DRM > stronger than needed to remind people that they're doing something > dishonest, trying to actually keep a motivated person from bypassing > it, is worse than foolish... it's abusive. and as LL has said, they are not going to go down the DRM route. [...] > Apple came right out and told the labels that they couldn't get > Science Fiction DRM, back before the iTunes Store opened. They seem to > be doing OK with that. and more and more labels are going non-DRM lately --- which makes sense: how much do you want to take away from your US 0.99 price per track and spend it on a complicated (and thus costly) DRM system, that just turns away your customers in the long run? dr scofield's DRM law: it only works in the lab. cheers, dirk/dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From seg at haxxed.com Mon Sep 24 23:26:15 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 23:26:19 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> Message-ID: <1190701575.19728.108.camel@localhost> On Mon, 2007-09-24 at 14:05 -0400, michi@luskwood.org wrote: > 1) A simple trust level - Servers that connect to the SL grid at least > should purport to follow a similar level of standards (i.e., 'listening' > to perms) as the SL grid. Of course, someone could lie. But this at least > establishes intent and a norm. > > 2) I think an extension of permissions to give the ability to comply with > copyright as well as copyleft should exist. In addition to "no copy", "no > transfer", "no modify"; we could indeed have "may not set nomod" or "may > not set no transfer". And the eternally asked-for "may not charge money > for trasfer". > > 3) Grid level permissions, i.e., "May rez/attach on a trusted grid" vs > "May rez/attach only on SL grid" or , "May rez/attach anywhere". The problem here, except maybe in the case of scripts, is all this "trusted grid/sim" stuff is a red herring. The real "problem" here is untrusted *clients*. Something you can not prevent short of a Trusted Computing system. How can you prevent someone from "right click, save"-ing an avatar, then re-uploading it as new content on whatever "untrusted grid" they wish? Its how the web works now, why should "future SL" be any different? There is no technical solution to this. Only a social one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/f5b461c1/attachment-0001.pgp From seg at haxxed.com Mon Sep 24 23:34:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Sep 24 23:34:35 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <46F8784F.9090205@wsu.edu> <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> Message-ID: <1190702071.19728.114.camel@localhost> On Tue, 2007-09-25 at 02:10 -0400, Andre Roche wrote: > Of course, it's possible. The point being made wasn't about whether > it could be done before or after purchase, however. I think the > iTunes comparison is fine in this case. The existence of the > Permissions system is doing it's job just fine. It's not smart proof, > but it defines intent, and many are fine going by that intent. Those > that aren't, know they're 'breaking the rules' when they bypass it. > The same concept applies to iTunes. The intent is clear, even if the > ability to bypass it is practically built in, or requires purchase > first. And what happens when the "Right click -> Save" patch comes out? (Which is on my personal to-do list. I've already got a "Hacked godmode on production grid" patch. Which has already proven useful for figuring out why someone's avatar is putting my framerate though the floor, by picking their avatar apart. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/d73f4bbb/attachment.pgp From hud at zurich.ibm.com Tue Sep 25 00:17:03 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Sep 25 00:17:07 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> Message-ID: <46F8B5EF.50408@zurich.ibm.com> michi@luskwood.org wrote: > [...lots of really good stuff deleted...] > Thanks, for what it's worth, for reading - and hopefully considering, > michi, thx for a really good post on the permissions topic! makes a lot of sense. i've to admit i was taking the stand that DRM is not going to work, so let's just drop this whole permissions stuff --- but you are right, permissions is more like attaching a "license" to objects and scripts telling the user this is what i want you to be able to do with the object you just acquired. and it's a license that is rather easy to understand and not a 100 page EULA. so, we should have the following permissions: * copy/no copy * mod/no mod * transfer/no transfer * for sale/not for sale * export to list of region domains/no export * export to region domains trusted by list of region domains and each with the option to make the permission "sticky"; that is, it cannot be taken away "down the road" --- and for the "for sale" permission that would fix the price at L$ 0 if sticky? what do you guys think? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/48704eba/attachment.htm From hud at zurich.ibm.com Tue Sep 25 00:37:38 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Sep 25 00:37:47 2007 Subject: [sldev] Re: [ARCH//META] Permissions and limitations of distrust In-Reply-To: <46F895F7.8040804@cox.net> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <1190653498.6005.29.camel@localhost> <0699AB5E-2E4E-476B-845C-45529D5966E2@gmail.com> <46F8121C.3030808@cox.net> <1190674771.10782.14.camel@kitiara> <46F895F7.8040804@cox.net> Message-ID: <46F8BAC2.5080409@zurich.ibm.com> Lawson English wrote: > Anders Arnholm wrote: >> On Mon, 2007-09-24 at 12:38 -0700, Lawson English wrote: >> >> >>> Then I realized that there are already precedents where region codes >>> are supported in DVDs. Hack your video player to play multiple >>> region DVDs and you are violating the law. Start selling or making >>> available for distribution, the content of region coded DVDs, and >>> you're liable for breaking several laws at once. >>> >> >> I can only with some certainly talk about swedish laws, but making a >> region free dvd player is definitively legal here, about 90% on the >> market here today is region free. It's wel inside fair use as well. >> >> Balp >> >> >> > Is modifying it and then reslling it OK as well? Seems to kind of go > against the whole concept of regions... it is here in switzerland. i always bought my DVD players modded from a bona fide vendor. the whole region code system seems a bit silly as long as you can do private imports of DVDs (or buy them abroad while there and take them with you) --- after all you've paid for the DVD and the right to watch it, haven't you? cheers, dirk > > L > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From jhurliman at wsu.edu Tue Sep 25 00:38:14 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 25 00:39:03 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <1190701575.19728.108.camel@localhost> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <1190701575.19728.108.camel@localhost> Message-ID: <46F8BAE6.4060907@wsu.edu> Callum Lerwick wrote: > On Mon, 2007-09-24 at 14:05 -0400, michi@luskwood.org wrote: > >> 1) A simple trust level - Servers that connect to the SL grid at least >> should purport to follow a similar level of standards (i.e., 'listening' >> to perms) as the SL grid. Of course, someone could lie. But this at least >> establishes intent and a norm. >> >> 2) I think an extension of permissions to give the ability to comply with >> copyright as well as copyleft should exist. In addition to "no copy", "no >> transfer", "no modify"; we could indeed have "may not set nomod" or "may >> not set no transfer". And the eternally asked-for "may not charge money >> for trasfer". >> >> 3) Grid level permissions, i.e., "May rez/attach on a trusted grid" vs >> "May rez/attach only on SL grid" or , "May rez/attach anywhere". >> > > The problem here, except maybe in the case of scripts, is all this > "trusted grid/sim" stuff is a red herring. The real "problem" here is > untrusted *clients*. Something you can not prevent short of a Trusted > Computing system. How can you prevent someone from "right click, > save"-ing an avatar, then re-uploading it as new content on whatever > "untrusted grid" they wish? Its how the web works now, why should > "future SL" be any different? > > There is no technical solution to this. Only a social one. > There is a technical solution to this problem, and I think we should use existing standards wherever possible. All SL clients should adhere to RFC 3514 (http://www.ietf.org/rfc/rfc3514.txt) and any client that plans on not obeying any permission bits should be setting their security flag to 0x1 in any simulator connections. That way we can achieve the same level of security and honor system provided by the current protocol, but in a more open standards fashion. John Hurliman From hud at zurich.ibm.com Tue Sep 25 00:46:39 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Sep 25 00:47:13 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <46F8BAE6.4060907@wsu.edu> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <1190701575.19728.108.camel@localhost> <46F8BAE6.4060907@wsu.edu> Message-ID: <46F8BCDF.4000302@zurich.ibm.com> John Hurliman wrote: > [...] > There is a technical solution to this problem, and I think we should > use existing standards wherever possible. All SL clients should adhere > to RFC 3514 (http://www.ietf.org/rfc/rfc3514.txt) and any client that > plans on not obeying any permission bits should be setting their > security flag to 0x1 in any simulator connections. That way we can > achieve the same level of security and honor system provided by the > current protocol, but in a more open standards fashion. :-) excellent suggestion. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Tue Sep 25 00:50:18 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Sep 25 00:50:20 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <20070925173507.57ae189d.cyeoh@ozlabs.org> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <46F8B5EF.50408@zurich.ibm.com> <20070925173507.57ae189d.cyeoh@ozlabs.org> Message-ID: <46F8BDBA.1020900@zurich.ibm.com> Christopher Yeoh wrote: > [...] >> so, we should have the following permissions: >> >> * copy/no copy >> * mod/no mod >> * transfer/no transfer >> * for sale/not for sale >> > > isn't transfer/sale essentially the same thing but perhaps > with a max value attached? > good point! one less then :-) -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/95589d19/attachment.htm From gigstaggart at gmail.com Tue Sep 25 01:08:39 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 25 01:08:41 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <46F8BAE6.4060907@wsu.edu> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <1190701575.19728.108.camel@localhost> <46F8BAE6.4060907@wsu.edu> Message-ID: <46F8C207.7030309@gmail.com> John Hurliman wrote: > There is a technical solution to this problem, and I think we should use > existing standards wherever possible. All SL clients should adhere to > RFC 3514 (http://www.ietf.org/rfc/rfc3514.txt) and any client that plans > on not obeying any permission bits should be setting their security flag > to 0x1 in any simulator connections. That way we can achieve the same > level of security and honor system provided by the current protocol, but > in a more open standards fashion. Unfortunately, implementations of RFC3514 often infringe on at least one patent from Adobe. Namely: Patent #41232124 - Method and apparatus of protecting informational content using bitfields - Adobe On the plus side, if we manage to dodge this patent, the DMCA would allow enforcement against anyone that utilized a content protection circumvention device, such as the ! operator. There was bill to ban such "logic inverting devices" in congress, but there were some "civil libertarians" (as always) that objected and it wasn't acted on this year. We only need to look at the FCC's broadcast flag to see that these systems do work. -Jason From nicholaz at blueflash.cc Tue Sep 25 01:54:58 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 01:55:25 2007 Subject: [sldev] [ATTN-LINDEN] Who is lindenrobot on JIRA? In-Reply-To: <46F8451F.4080304@lindenlab.com> References: <46F83F2D.4060300@blueflash.cc> <46F8451F.4080304@lindenlab.com> Message-ID: <46F8CCE2.3010203@blueflash.cc> Rob Lanphier wrote: > On 9/24/07 3:50 PM, Nicholaz Beresford wrote: > See, I told you it was nefarious and awful. > But, no, I don't have to kill you yet. ;-) Oh, I think that was pretty straightforward, but that's probably because I'm nefarious and awful ... (ouch, that probably means you'll now kill me anyway :-)) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From secret.argent at gmail.com Tue Sep 25 02:28:49 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 02:28:56 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> Message-ID: <5E3E9C87-FAE5-4CF0-B34A-9881B1576D2F@gmail.com> On 24-Sep-2007, at 21:23, Brian wrote: > All for Iridium's idea on a roundtable for this: There are definitely > unanswered questions between this and the future distributed grid. I'd rather it be in this list or in another list. Because otherwise it'll be during office hours and some of us just can't get in world then. From secret.argent at gmail.com Tue Sep 25 02:37:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 02:37:20 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <20070925025507.B1E3E41B1F9@stupor.lindenlab.com> References: <20070925025507.B1E3E41B1F9@stupor.lindenlab.com> Message-ID: <3EC224A1-4554-4E48-A96A-1F35D41C9E77@gmail.com> From: John Hurliman > The comparison to iTunes is a red herring. Do you honestly think that > the iTunes store would be successful if there was an easy to use > way of > downloading any song you wanted for free? There *is* an easy way of downloading any content _you can see_ in the iTunes store. You can only "see" 30 second clips, true, but when you go to a store in SL you can only see pictures of most of the content... you have to buy it to download it. Or find someone who has bought it, and download their copy... like people do with music. But what we're talking about in THIS context is even closer to the iTunes model. You bought something in-world, or on the iTunes store, and you want to take it to another grid, or play it on a Zune. To do that you have to get SL's or Apple's permission, or bypass the DRM. From jhurliman at wsu.edu Tue Sep 25 02:47:23 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 25 02:48:13 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <3EC224A1-4554-4E48-A96A-1F35D41C9E77@gmail.com> References: <20070925025507.B1E3E41B1F9@stupor.lindenlab.com> <3EC224A1-4554-4E48-A96A-1F35D41C9E77@gmail.com> Message-ID: <46F8D92B.20509@wsu.edu> Argent Stonecutter wrote: > From: John Hurliman >> The comparison to iTunes is a red herring. Do you honestly think that >> the iTunes store would be successful if there was an easy to use way of >> downloading any song you wanted for free? > > There *is* an easy way of downloading any content _you can see_ in the > iTunes store. You can only "see" 30 second clips, true, but when you > go to a store in SL you can only see pictures of most of the > content... you have to buy it to download it. Or find someone who has > bought it, and download their copy... like people do with music. > > But what we're talking about in THIS context is even closer to the > iTunes model. You bought something in-world, or on the iTunes store, > and you want to take it to another grid, or play it on a Zune. To do > that you have to get SL's or Apple's permission, or bypass the DRM. To get something close to that would require a change in how content is delivered to clients. Instead of sending "plaintext" ObjectUpdate packets that describe exactly how prims look and what textures they use and how everything is linked together, you would send encrypted content to the client, and through a closed-source module or some other protection means certain trusted clients (much like the iTunes official software) would be able to view assets but malicious clients that intend on moving assets from one domain to another would be unable to do this, or at least have a difficult time cracking the protection. I want to be clear that this is what you are suggesting as it is much different from other suggestions in this thread. The discussion about trusted/untrusted domains really has nothing to do with this as the weak link in the chain is the clients that have to be able to see these things to have a useful experience. If you are talking about protection of simulator-side only assets such as protected scripts the domain trust problem becomes relevant, but not for basic assets that are being handed out to clients blindly. From secret.argent at gmail.com Tue Sep 25 02:48:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 02:48:59 2007 Subject: [sldev] Re: [META] Permissions In-Reply-To: <46F8A91E.6060903@zurich.ibm.com> References: <20070924151432.956D241B18F@stupor.lindenlab.com> <46F8A91E.6060903@zurich.ibm.com> Message-ID: > and as LL has said, they are not going to go down the DRM route. It's only obfuscation (eg, splitting the header and body of the textures in the texture cache), but since obfuscation is all DRM can do, this is a distinction that makes no difference. > and more and more labels are going non-DRM lately Of the ones that matter to Apple, or to 90% of the population, there's EMI and... EMI. And it was Apple who got them to do that. From hud at zurich.ibm.com Tue Sep 25 02:56:11 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Tue Sep 25 02:56:14 2007 Subject: [sldev] Re: [META] Permissions In-Reply-To: References: <20070924151432.956D241B18F@stupor.lindenlab.com> <46F8A91E.6060903@zurich.ibm.com> Message-ID: <46F8DB3B.8090003@zurich.ibm.com> Argent Stonecutter wrote: >> and as LL has said, they are not going to go down the DRM route. > > It's only obfuscation (eg, splitting the header and body of the > textures in the texture cache), but since obfuscation is all DRM can > do, this is a distinction that makes no difference. > >> and more and more labels are going non-DRM lately > > Of the ones that matter to Apple, or to 90% of the population, there's > EMI and... EMI. And it was Apple who got them to do that. i don't really care who got whom to go non-DRM, i'm only interested in the end result...i've been buying non-DRM MP3s for years and never acquired ANY DRM'ed music. it seems that more people than the RIAA-and-other-greedies suspect are willing to play fair... -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From nicholaz at blueflash.cc Tue Sep 25 03:04:20 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 03:04:25 2007 Subject: [sldev] Google starting 3D world? Message-ID: <46F8DD24.5060107@blueflash.cc> http://translate.google.com/translate?u=http%3A%2F%2Fwww.winfuture.de%2Fnews%2C34592.html&langpair=de%7Cen&hl=de&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools (if the link is broken try google tools with http://www.winfuture.de/news,34592.html) Nick From secret.argent at gmail.com Tue Sep 25 03:10:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 03:11:05 2007 Subject: [sldev] Re: [ARCH] Re: Permissions In-Reply-To: <20070925062620.5020741B269@stupor.lindenlab.com> References: <20070925062620.5020741B269@stupor.lindenlab.com> Message-ID: <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> From: Callum Lerwick > Its called "signing your work" and people have been doing it for > hundreds (thousands?) of years. No, it's more than "signing your work". You can sign and watermark your painting, but that won't tell the guy who bought it who you are or what you were thinking of or the fact that it's 15 out of a limited edition of 30, or anything else that's on the back of the canvas, or in the colophon of the book, or the garment label. Why don't you want people to be able to attach a label? > When you license content, you're licensing COMMUNISM! Traffic lights and speed limit signs are communism too. It's my car, I bought it, and I paid good money for that engine and frame to get a car that's safe at 200 MPH, why should I be limited to 35 on city streets? I'm not going to go 200, of course, but I'm totally safe at 50! And it's midnight, so I'm gonna go 70, and there's nobody coming, so I'm going though that red light... Hello officer. No, sir, I'm not drunk, I'm just exercising my rights as a capitalist! > The problem here, except maybe in the case of scripts, is all this > "trusted grid/sim" stuff is a red herring. No more than the permissions system itself. But the permissions system is necessary, to act as that "speed limit sign". > How can you prevent someone from "right click, > save"-ing an avatar, then re-uploading it as new content on whatever > "untrusted grid" they wish? Well, for one thing, you won't get the clothes that way, just the baked textures. But another grid will be able to get the clothes, and the alternate versions you're not currently wearing, and get it all in the preferred format. > Its how the web works now, why should "future SL" be any different? SL isn't the web. Future SL isn't the web. The web-equivalent is going to be all the domains together. And if you don't like SL's policies, then you can stay in domains that have policies you like. That's how the market works... you don't like the iTunes store, you can stick to eMusic and 3hive. The ARCHITECTURE level is not about what those policies are, but how you express the policies. From tao.takashi at googlemail.com Tue Sep 25 03:15:08 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 25 03:15:11 2007 Subject: [sldev] Google starting 3D world? In-Reply-To: <46F8DD24.5060107@blueflash.cc> References: <46F8DD24.5060107@blueflash.cc> Message-ID: <23bbb49e0709250315o11afb0ffuae17878e03c64151@mail.gmail.com> Hi! I think one of the originating articles is here: http://www.techcrunch.com/2007/09/24/google-preping-a-second-life-competitor/ I am just not sure that the simple question for a GMail account in that questionaire allows for such conclusions that Google is prepping a 3D world. It could also be simply a Facebook competitor without any 3D attached as the November 5 link implies. Probably it could not even be Google although of course there are many links between ASU and Google. ( http://www.techcrunch.com/2007/09/21/google-to-out-open-facebook-on-november-5/ ) So I guess we will find out on November 5th. At least regarding what interfaces there might be, maybe a 3D world might take a little longer. Of course in the end it will all grow together at Google. (then I'd say that many people are expecting Google to add avatars etc. to Google Earth at some point anyway so it's probably just a matter of time. I think they are mostly waiting for our architecture working group to finish it's project ;-) -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/212ae2a9/attachment-0001.htm From tillie at xp2.de Tue Sep 25 03:16:12 2007 From: tillie at xp2.de (Tillie Ariantho) Date: Tue Sep 25 03:16:15 2007 Subject: [sldev] [ATTN-LINDEN] Who is lindenrobot on JIRA? In-Reply-To: <46F83F2D.4060300@blueflash.cc> References: <46F83F2D.4060300@blueflash.cc> Message-ID: <20070925121612.2vt27ykfhi8kcsok@webmail.readonly.de> Quoting Nicholaz Beresford : > Or more exactly, what is he doing? :-) Looks like a script that crosslinks internal to external JIRA entries by found keys. :-) -- Tillie From secret.argent at gmail.com Tue Sep 25 03:29:26 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 03:29:32 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <20070925101516.35DD041B213@stupor.lindenlab.com> References: <20070925101516.35DD041B213@stupor.lindenlab.com> Message-ID: <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> From: John Hurliman > To get something close to that would require a change in how > content is > delivered to clients. [...] > The discussion about trusted/untrusted domains really has nothing > to do > with this as the weak link in the chain is the clients What part of "I know that, this is not a 'technical solution', it's like a 'speed limit' sign" do I have to explain again THIS time? From tillie at xp2.de Tue Sep 25 03:31:18 2007 From: tillie at xp2.de (Tillie Ariantho) Date: Tue Sep 25 03:31:21 2007 Subject: [sldev] Google starting 3D world? In-Reply-To: <23bbb49e0709250315o11afb0ffuae17878e03c64151@mail.gmail.com> References: <46F8DD24.5060107@blueflash.cc> <23bbb49e0709250315o11afb0ffuae17878e03c64151@mail.gmail.com> Message-ID: <20070925123118.up29v7xqrqo0440g@webmail.readonly.de> Quoting Tao Takashi : > (then I'd say that many people are expecting Google to add avatars etc. to > Google Earth at some point anyway so it's probably > just a matter of time. I think they are mostly waiting for our architecture > working group to finish it's project ;-) Yep, I am quite sure. .P Btw. when is the next meeting? Missing Linden office hours? Add my calendar. :-) http://www.google.com/calendar/render?cid=tillie%40xp2.de -- Tillie From jhurliman at wsu.edu Tue Sep 25 03:32:59 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 25 03:33:47 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> References: <20070925101516.35DD041B213@stupor.lindenlab.com> <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> Message-ID: <46F8E3DB.9090008@wsu.edu> Argent Stonecutter wrote: > From: John Hurliman >> To get something close to that would require a change in how content is >> delivered to clients. > [...] >> The discussion about trusted/untrusted domains really has nothing to do >> with this as the weak link in the chain is the clients > > What part of "I know that, this is not a 'technical solution', it's > like a 'speed limit' sign" do I have to explain again THIS time? Speed limits work not because there is a sign on the side of the road, but because there of patrolling officers and radar/laser guns and court fines. There is a very good discussion to be had here about social solutions to the problem, but I don't think it affects the evolution of the architecture technical spec. As long as the system is extensible enough that people can implement a fake permission system on top of it there should be no worries. From nicholaz at blueflash.cc Tue Sep 25 05:15:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 05:15:17 2007 Subject: [sldev] [ANN] Nicholaz Homebrew Message-ID: <46F8FBCF.3040701@blueflash.cc> There's a new nicholaz edition and also Linux build of it. Noteworthy features (differring from Linden RC) are fixed chache clear hiccups and detection plus warning of sim disconnects (redmaps), a stuffed memory leak and ongoing flushes of the keyframe cache. Details, downloads and source here: http://nicholaz-beresford.blogspot.com/ Nick From roamingryozu at gmail.com Tue Sep 25 05:39:08 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Tue Sep 25 05:39:10 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <46F8E3DB.9090008@wsu.edu> References: <20070925101516.35DD041B213@stupor.lindenlab.com> <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> <46F8E3DB.9090008@wsu.edu> Message-ID: <5eff6d3b0709250539o43e7f51cy2c1d1e7a2708c214@mail.gmail.com> On 9/25/07, John Hurliman wrote: > Argent Stonecutter wrote: > > From: John Hurliman > >> To get something close to that would require a change in how content is > >> delivered to clients. > > [...] > >> The discussion about trusted/untrusted domains really has nothing to do > >> with this as the weak link in the chain is the clients > > > > What part of "I know that, this is not a 'technical solution', it's > > like a 'speed limit' sign" do I have to explain again THIS time? > > Speed limits work not because there is a sign on the side of the road, > but because there of patrolling officers and radar/laser guns and court > fines. There is a very good discussion to be had here about social > solutions to the problem, but I don't think it affects the evolution of > the architecture technical spec. As long as the system is extensible > enough that people can implement a fake permission system on top of it > there should be no worries. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > A fake permissions system? I don't think any described implementation of a permissions system is 'fake.' Permissions are a lot like "Rules." Rules can be ignored, but they should be followed. It's a word with a social definition regardless of any technical implementation. American Heritage Dictionary - (p?r-m?sh'?n) n. The act of permitting. Consent, especially formal consent; authorization. I do agree the architecture should be extensible. The real question here is, should a basic permissions system be the standard, and how basic or advanced should it be. With that question in mind, is there good reason why at least a cursory permissions system with cursory enforcement by the official LL client shouldn't be standard, aside from the DRM just doesn't work argument? From robin.cornelius at gmail.com Tue Sep 25 05:44:48 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Sep 25 05:44:52 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: <46F8FBCF.3040701@blueflash.cc> References: <46F8FBCF.3040701@blueflash.cc> Message-ID: On 9/25/07, Nicholaz Beresford wrote: > > There's a new nicholaz edition and also Linux build of it. > > Noteworthy features (differring from Linden RC) are fixed chache > clear hiccups and detection plus warning of sim disconnects (redmaps), > a stuffed memory leak and ongoing flushes of the keyframe cache. Arrrg, just finished packing the last version for AMD64 linux. Right something to do this afternoon now. I am hosting my build at http://www.byteme.org.uk/secondlife-amd64/binary-packages.html In fact I have a complete standalone (opensource) AMD64/linux install there and a debian.deb But if its useful Nicholaz, i can just send you the do-not-directly-run.bin file for AMD64 linux and you can include that as well? Robin From roamingryozu at gmail.com Tue Sep 25 05:46:54 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Tue Sep 25 05:46:56 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <1190702071.19728.114.camel@localhost> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <46F8784F.9090205@wsu.edu> <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> <1190702071.19728.114.camel@localhost> Message-ID: <5eff6d3b0709250546n593c12et133ba4bdea334178@mail.gmail.com> On 9/25/07, Callum Lerwick wrote: > On Tue, 2007-09-25 at 02:10 -0400, Andre Roche wrote: > > Of course, it's possible. The point being made wasn't about whether > > it could be done before or after purchase, however. I think the > > iTunes comparison is fine in this case. The existence of the > > Permissions system is doing it's job just fine. It's not smart proof, > > but it defines intent, and many are fine going by that intent. Those > > that aren't, know they're 'breaking the rules' when they bypass it. > > The same concept applies to iTunes. The intent is clear, even if the > > ability to bypass it is practically built in, or requires purchase > > first. > > And what happens when the "Right click -> Save" patch comes out? > > (Which is on my personal to-do list. I've already got a "Hacked godmode > on production grid" patch. Which has already proven useful for figuring > out why someone's avatar is putting my framerate though the floor, by > picking their avatar apart. :) > Technically nothing, and honestly, without building an entire physical device from scratch, there never will be. (And honestly, even that won't stop it.) I'm not implying in any way that there's a foolproof DRM scheme that can't be cracked in some way. In a lot of situations, something so much as a simple statement of "Don't do that" is enough to stop people from doing something. That's the point. From nicholaz at blueflash.cc Tue Sep 25 05:52:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 05:52:28 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: References: <46F8FBCF.3040701@blueflash.cc> Message-ID: <46F90487.3020206@blueflash.cc> Robin Cornelius wrote: > On 9/25/07, Nicholaz Beresford wrote: >> There's a new nicholaz edition and also Linux build of it. >> >> Noteworthy features (differring from Linden RC) are fixed chache >> clear hiccups and detection plus warning of sim disconnects (redmaps), >> a stuffed memory leak and ongoing flushes of the keyframe cache. > > Arrrg, just finished packing the last version for AMD64 linux. Right > something to do this afternoon now. Same happens here all the time ... whenever I make a version, Lindens come out with a new one :-) But this one should compile straight under Linux, few minor compile quirks with gcc (or forgotten LL_WINDOWS) sorted out. > I am hosting my build at > http://www.byteme.org.uk/secondlife-amd64/binary-packages.html > In fact I have a complete standalone (opensource) AMD64/linux install > there and a debian.deb I'll add them to the blog. When you have something new, just post here or email me and I'll point people there. > But if its useful Nicholaz, i can just send you the > do-not-directly-run.bin file for AMD64 linux and you can include that > as well? I have no idea if it's useful ... never used Linux, so I'm not aware of the benefits of the different builds or what is required for whom. Thanks for efforts! Nick From robin.cornelius at gmail.com Tue Sep 25 05:58:25 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Sep 25 05:58:27 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: <46F90487.3020206@blueflash.cc> References: <46F8FBCF.3040701@blueflash.cc> <46F90487.3020206@blueflash.cc> Message-ID: On 9/25/07, Nicholaz Beresford wrote: > > But if its useful Nicholaz, i can just send you the > > do-not-directly-run.bin file for AMD64 linux and you can include that > > as well? > > I have no idea if it's useful ... never used Linux, so I'm not aware > of the benefits of the different builds or what is required for whom. > Ah sorry, the do-not-directly-run.bin IS the main executable for secondlife on linux, they use a script in the top level directory to pass some parameters to it thats all. Its pretty much the linux version of the secondlife.exe in windows. My version is for AMD64 (64bit) processors thats all and Lillys is for 32 bit processors so both needed for different people. But looking its probably better if I just host the required files and you can make a link or a blog entry etc. I am trying to follow your builds ATM, as I have been having loads of stability again now on the last one. SL was fully usable again for me. But i need a 64bit linux version. Robin From nicholaz at blueflash.cc Tue Sep 25 06:09:34 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 06:09:38 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: References: <46F8FBCF.3040701@blueflash.cc> <46F90487.3020206@blueflash.cc> Message-ID: <46F9088E.8080806@blueflash.cc> Robin Cornelius wrote: > But looking its probably better if I just host the required files and > you can make a link or a blog entry etc. Yep, that would be my preference. I linked yours already. Now if someone would make a Mac build .... :-D Nick From jef at pleiades.ca Tue Sep 25 06:28:10 2007 From: jef at pleiades.ca (Jonathan Freedman) Date: Tue Sep 25 06:28:19 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: <46F9088E.8080806@blueflash.cc> References: <46F8FBCF.3040701@blueflash.cc> <46F90487.3020206@blueflash.cc> <46F9088E.8080806@blueflash.cc> Message-ID: <46F90CEA.6050406@pleiades.ca> > Now if someone would make a Mac build .... :-D Don't mind if I do ;) I teach till Thursday though, so it will have to wait until then. I presume that you have the source for your changes published somewhere ? Also, have you incorporated the terraforming patch (VWR-2331) that Gigs made about a week ago ? Cheers Jonathan Freedman / otakup0pe Neumann VP Operations Pleiades Consulting From tao.takashi at googlemail.com Tue Sep 25 06:44:45 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 25 06:44:55 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <5eff6d3b0709250539o43e7f51cy2c1d1e7a2708c214@mail.gmail.com> References: <20070925101516.35DD041B213@stupor.lindenlab.com> <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> <46F8E3DB.9090008@wsu.edu> <5eff6d3b0709250539o43e7f51cy2c1d1e7a2708c214@mail.gmail.com> Message-ID: <23bbb49e0709250644v76180071j6e60b31fc489804e@mail.gmail.com> 2007/9/25, Andre Roche : I do agree the architecture should be extensible. The real question > here is, should a basic permissions system be the standard, and how > basic or advanced should it be. What does "standard" mean here? I would think the important part for the protocol is just that it needs to make sure that the permission system can be plugged. The policy which I'd think comes close to be the "standard" will probably be the one by Linden Lab for now basically because they will have the biggest grid in the beginning. But it will still be just bound to that grid. Other grids like osgrid or deepgrid might want to choose maybe a system without permissions or completely different ones (or maybe one that just has a license field and it's more a contract). The Linden Lab one will most probably be very much the same as it is right now maybe with additional permissions regarding grid and region domain transfer. So in the end we'd have a protocol definition which describes how to define which permission system to used (or is used by that object/domain/whatever) and then there will be additional documents describing the various permission system which people will implement. - Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/f07615b5/attachment.htm From tao.takashi at googlemail.com Tue Sep 25 06:49:27 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 25 06:49:29 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <5E3E9C87-FAE5-4CF0-B34A-9881B1576D2F@gmail.com> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <5E3E9C87-FAE5-4CF0-B34A-9881B1576D2F@gmail.com> Message-ID: <23bbb49e0709250649v64a2d60enf5c5b4e505434991@mail.gmail.com> 2007/9/25, Argent Stonecutter : > > On 24-Sep-2007, at 21:23, Brian wrote: > > All for Iridium's idea on a roundtable for this: There are definitely > > unanswered questions between this and the future distributed grid. > > I'd rather it be in this list or in another list. Because otherwise > it'll be during office hours and some of us just can't get in world > then. But then again some people might feel uncomfortable on this (very technical) list. I am for some roundtable which might attract hopefully more content creators. It does not mean that everybody on here needs to attend as well as long as somebody reports back with a summary of issues, possible solutions etc. So the first thing at this meeting should be to define somebody to do the report (transcript is fine, too but usually hard to read and it might be easier to just take some notes during the meeting). I think it's important to have as many forums about such issues as possible so that nobody has the feeling that there is some disconnected group on some mailing list deciding about other people's future and OTOH not to have the feeling that we discuss great things here but the world "outside" does not understand us. And of course it would be important that Linden Lab gets more involved about these issues because they will decide in the end what they will implement on their grid. -- Tao _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/7fcc9fd7/attachment.htm From nicholaz at blueflash.cc Tue Sep 25 06:53:32 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 06:53:39 2007 Subject: [sldev] [ANN] Nicholaz Homebrew In-Reply-To: <46F90CEA.6050406@pleiades.ca> References: <46F8FBCF.3040701@blueflash.cc> <46F90487.3020206@blueflash.cc> <46F9088E.8080806@blueflash.cc> <46F90CEA.6050406@pleiades.ca> Message-ID: <46F912DC.7060402@blueflash.cc> Jon, source code is here: http://www.blueflash.cc/users/nicholaz/BleedingEdge/~source/ It contains patches or alternately a set with all changed files to just copy over an original Linden path. Dunno how Mac builds but there are three new files to compile in the files.lst for Linux (nb*.cpp). The terra patch is not included because I don't have an installer and avoid to change existing xui files (under Windows you put my exe and a few new GUI files into the the SecondLife folder and either start the Linden secondlife.exe or my nicholaz.exe, so the Linden files need to remain unchanged). But feel free to mod the whole process for the Mac (dunno if or how to deal with the redistribution problems there) or throw patches on top. Nick Jonathan Freedman wrote: > >> Now if someone would make a Mac build .... :-D > > Don't mind if I do ;) I teach till Thursday though, so it will have to > wait until then. I presume that you have the source for your changes > published somewhere ? Also, have you incorporated the terraforming patch > (VWR-2331) that Gigs made about a week ago ? > > Cheers > > Jonathan Freedman / otakup0pe Neumann > VP Operations > Pleiades Consulting > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tofu.linden at lindenlab.com Tue Sep 25 06:58:56 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Sep 25 06:59:05 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <46F8B5EF.50408@zurich.ibm.com> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <46F8B5EF.50408@zurich.ibm.com> Message-ID: <46F91420.4000507@lindenlab.com> dirk husemann wrote: > so, we should have the following permissions: ... > * for sale/not for sale This seems a fine example of something which is not technically enforceable to an appreciable degree (I mean - even less so than no-copy; consider the myriad ways in which you or your vendor may technically accept some money and technically give an item but with no clear mechanically-traceable correlation between these events). It's a great example, though, of an attribute which an item can at least carry around as a non-resettable flag so that the purchaser can know that the seller didn't have permission to be selling that item in the first place, albeit too late. A lockdown-able free-text license field is perhaps the ultimate extrapolation of that idea, though also perhaps a technical cop-out. An arbitrary license for objects seems very similar (albeit potentially legally stronger - though I Am Not A Lawyer) to the existing Covenant scheme for land, though I'm not sure how much utility/traction the Covenant scheme has proven to have so far. -Tofu From nicholaz at blueflash.cc Tue Sep 25 07:33:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 07:33:32 2007 Subject: [sldev] Permissions - A content creator's view In-Reply-To: <46F91420.4000507@lindenlab.com> References: <15795.140.239.129.98.1190657140.squirrel@webmail7.pair.com> <46F8B5EF.50408@zurich.ibm.com> <46F91420.4000507@lindenlab.com> Message-ID: <46F91C36.7060706@blueflash.cc> Tofu Linden wrote: > An arbitrary license for objects seems very similar (albeit > potentially legally stronger - though I Am Not A Lawyer) to the > existing Covenant scheme for land, though I'm not sure how much > utility/traction the Covenant scheme has proven to have so far. I think it would be a step into the direction of social engeneering. If you have a place where to look that's a good start ... like the headers or license.txt in source code. It may not help with people who like to break rules, but take PG/ Mature for sims for example. I (and I guess most people) see the flag and modify their behavior accordingly or just leave. Sure with PG there's abuse reporting, which is about as weak as copy protection via permissions, but it helps to structure the relationships between residents, owners, visitors. If there is a way to communicate intent, people can act accordingly and I'd not underestimate the power of complaints (like IMing or pestering or boycotting a vendor who had violated the content creator's intent). If "never for sale" or "copyleft" or "see license" would be a well known flag displayed in the inventory (like currently "No modify"), it's hard to imagine a shop owner would accidentally miss it. I believe that most people are acting fair most of the time, it's just that currently the tools for a particular camp of creators aren't really there. Nick From secret.argent at gmail.com Tue Sep 25 07:37:08 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 07:37:20 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <20070925125832.9DDE341B278@stupor.lindenlab.com> References: <20070925125832.9DDE341B278@stupor.lindenlab.com> Message-ID: From: John Hurliman > Speed limits work not because there is a sign on the side of the road, > but because there of patrolling officers and radar/laser guns and > court > fines. We have those, from the DMCA down to the TOS. The officers might be pretty lax right now, but they're not completely absent, and people act as if they were there even when they're not (just like in the real world, come to think of it). They'll need to be able to post signs you can't miss seeing to operate at the edge of the grid. > There is a very good discussion to be had here about social > solutions to the problem, but I don't think it affects the > evolution of > the architecture technical spec. In so far as the spec has to be able to support some mechanism for regions to negotiate whether they're going to permit content to leave (or for that matter enter) *on a per-asset basis* it does. From: "Andre Roche" > With that question in mind, is there good reason why at least a > cursory permissions system with cursory enforcement by the official LL > client shouldn't be standard, aside from the DRM just doesn't work > argument? I can't think of any, so long as it's possible for the region to notify the client what permissions apply in that region where they don't match the SL standard... so you don't get to CompletelyOpenGrid and discover that the client is keeping you from reading the source to a script just because it's in an object you don't own. That is, I think the policy needs to be that the region is the arbiter of permissions, and the creator of an asset is the arbiter of what kind of regions they're willing to let their content be delivered to, and the architecture should make sure that this is possible. From Dana.Fagerstrom at Sun.COM Tue Sep 25 07:59:23 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Sep 25 07:56:47 2007 Subject: [sldev] security Message-ID: <46F9224B.4060307@sun.com> Folks, This may be an easy question but since I'm working on very little sleep I thought I'd just ask - Is there a page on the wiki that discusses how secure Second Life is? I'm looking for something that discusses what messages between the viewer and the grid are encrypted. It would be great if everything was but I don't think that's the case. Of course I'm about to dive into the source. I was just hoping to find something on the wiki and found nothing. Thanks, D From rui.granja at gmail.com Tue Sep 25 08:18:27 2007 From: rui.granja at gmail.com (Rui Granja) Date: Tue Sep 25 08:18:30 2007 Subject: [sldev] Proxy support in SL client Message-ID: <6d746f280709250818p6c23d726p535807b828d429d8@mail.gmail.com> Hi, I work for a financial institution which aims to operate in SL. Since our corporate policy mandates that internet access be performed through a proxy server (either HTTP or SOCKS) and considering that proxy support seems to be a popular request for users in corporate environments I was wondering if there are any plans to provide this feature. I'm aware of both the SLSquid and the openvpn/yourfreedom workarounds but they do not seem to be an option in our case. I've tried using a socksifier but haven?t managed to get that working yet (unlike many other applications that lack native socks proxy support it doesn't work out of the box). Has anyone in a similar environment managed to get SL running? Thanks in advance, Rui From seg at haxxed.com Tue Sep 25 08:56:07 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 08:56:12 2007 Subject: [sldev] Re: [ARCH] Re: Permissions In-Reply-To: <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> References: <20070925062620.5020741B269@stupor.lindenlab.com> <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> Message-ID: <1190735767.19728.129.camel@localhost> On Tue, 2007-09-25 at 05:10 -0500, Argent Stonecutter wrote: > From: Callum Lerwick > > Its called "signing your work" and people have been doing it for > > hundreds (thousands?) of years. > > No, it's more than "signing your work". You can sign and watermark > your painting, but that won't tell the guy who bought it who you are > or what you were thinking of or the fact that it's 15 out of a > limited edition of 30, or anything else that's on the back of the > canvas, or in the colophon of the book, or the garment label. Why > don't you want people to be able to attach a label? Is that what I said? What I ment to say is you can tag and label your content however you want, using EXIF tags or ID3 or by scribbling it all down in the corner of a texture or whatever it is you want to do. Its a solved issue. Its a non-issue. And it has little to nothing to do with SL protocol design. > > When you license content, you're licensing COMMUNISM! > > Traffic lights and speed limit signs are communism too. No, "communism" would be leasing your car from the state. Ooops, ran a stop sign? I'm afraid you'll have to return The People's car, citizen. Immediately. You have a seriously myopic view of things, Argent. That much is very clear. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/8df0d36d/attachment.pgp From secret.argent at gmail.com Tue Sep 25 09:08:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 09:08:31 2007 Subject: [sldev] Re: [META] Permissions - A content creator's view In-Reply-To: <20070925143722.0E10A41B2A1@stupor.lindenlab.com> References: <20070925143722.0E10A41B2A1@stupor.lindenlab.com> Message-ID: On 25-Sep-2007, at 09:37, sldev-request@lists.secondlife.com wrote: From: Tofu Linden >> * for sale/not for sale > This seems a fine example of something which is not technically > enforceable to an appreciable degree [...] It's a great example, > though, of an attribute which an item can at least carry around as > a non-resettable flag so that the purchaser can know that the > seller didn't have permission to be selling that item in the first > place, albeit too late. A lockdown-able free-text license field is > perhaps the ultimate extrapolation of that idea, though also > perhaps a technical cop-out. I'm not sure that "cop-out" is appropriate. A free form license field (however implemented) is about as far as you can go technically with certain kinds of permissions. Another thing that just occurred to me... how about two fields? One settable by the creator, one settable by the owner, and both readable by the client in world, or in inventory, or by a script for assets in- world. The former would hold license information, contact information, advertising, and formatted configuration information for scripts. The latter could hold the owner's notes, and it could hold configuration information as well. This would also solve the problems of setting attributes on objects for modified clients to read, AND provide a place other than notecards for configuration information. In JIRA as SVC-701. From nik at terminaldischarge.net Tue Sep 25 09:19:37 2007 From: nik at terminaldischarge.net (nik@terminaldischarge.net) Date: Tue Sep 25 09:19:45 2007 Subject: [sldev] SL and Mono Message-ID: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> Just wondering if anyone knows what happened with it? I'm just being a curious bunny. Nik From seg at haxxed.com Tue Sep 25 09:22:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 09:22:39 2007 Subject: [sldev] Google starting 3D world? In-Reply-To: <23bbb49e0709250315o11afb0ffuae17878e03c64151@mail.gmail.com> References: <46F8DD24.5060107@blueflash.cc> <23bbb49e0709250315o11afb0ffuae17878e03c64151@mail.gmail.com> Message-ID: <1190737352.19728.134.camel@localhost> On Tue, 2007-09-25 at 12:15 +0200, Tao Takashi wrote: > (http://www.techcrunch.com/2007/09/21/google-to-out-open-facebook-on-november-5/) Oh, I love how they start out their mission to "out open" facebook... with a super secret, invite only, NDA meeting. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/93e11343/attachment.pgp From gigstaggart at gmail.com Tue Sep 25 09:22:39 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 25 09:22:42 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <46F8E3DB.9090008@wsu.edu> References: <20070925101516.35DD041B213@stupor.lindenlab.com> <05696C92-F74B-4C7A-9F52-CB5A6963249B@gmail.com> <46F8E3DB.9090008@wsu.edu> Message-ID: <46F935CF.3080200@gmail.com> John Hurliman wrote: > Speed limits work not because there is a sign on the side of the road, > but because there of patrolling officers and radar/laser guns and court > fines. There is a very good discussion to be had here about social Last I checked there were some pretty serious fines for copyright infringement too. Regardless of what the RIAA/MPAA whine, the vast majority of people do not violate copyright in a significant way. -Jason From dale at daleglass.net Tue Sep 25 09:23:36 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Sep 25 09:23:50 2007 Subject: [sldev] Re: [META] Permissions - A content creator's view In-Reply-To: References: <20070925143722.0E10A41B2A1@stupor.lindenlab.com> Message-ID: <200709251823.42777.dale@daleglass.net> On Tuesday 25 September 2007 18:08:16 Argent Stonecutter wrote: > Another thing that just occurred to me... how about two fields? One > settable by the creator, one settable by the owner, and both readable > by the client in world, or in inventory, or by a script for assets in- > world. The former would hold license information, contact > information, advertising, and formatted configuration information for > scripts. The latter could hold the owner's notes, and it could hold > configuration information as well. > > This would also solve the problems of setting attributes on objects > for modified clients to read, AND provide a place other than > notecards for configuration information. Suppose it sounds pretty good, but I'd prefer to have a separate functionality for configuration instead. Something like llGetSettingFloat("Update interval", 5.0); Notecards are very annoying to parse to get configuration info, and are slow too. IMO a specific mechanism would be much preferrable. Now, not 100% sure how exactly to do it, maybe just store a key/string value pair, and let the coder deal with that. Not ideal, but would be a huge improvement already. Perhaps make it store lists directly, that has the advantage of being able to store anything losslessly and not needing a function per datatype. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/80765b45/attachment.pgp From gigstaggart at gmail.com Tue Sep 25 09:24:28 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 25 09:24:30 2007 Subject: [sldev] Re: [ARCH] Re: Permissions In-Reply-To: <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> References: <20070925062620.5020741B269@stupor.lindenlab.com> <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> Message-ID: <46F9363C.2090006@gmail.com> Argent, Must you start an entirely new thread every time you reply? It's making this very difficult to read because you've caused the permission discussion to be spread across 6 or 7 different threads. From seg at haxxed.com Tue Sep 25 09:46:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 09:46:42 2007 Subject: [sldev] Re: [META] Permissions - A content creator's view In-Reply-To: <200709251823.42777.dale@daleglass.net> References: <20070925143722.0E10A41B2A1@stupor.lindenlab.com> <200709251823.42777.dale@daleglass.net> Message-ID: <1190738799.19728.145.camel@localhost> On Tue, 2007-09-25 at 18:23 +0200, Dale Glass wrote: > Suppose it sounds pretty good, but I'd prefer to have a separate > functionality for configuration instead. > > Something like llGetSettingFloat("Update interval", 5.0); > > Notecards are very annoying to parse to get configuration info, and are > slow too. IMO a specific mechanism would be much preferrable. > > Now, not 100% sure how exactly to do it, maybe just store a key/string > value pair, and let the coder deal with that. Not ideal, but would be a > huge improvement already. > > Perhaps make it store lists directly, that has the advantage of being able > to store anything losslessly and not needing a function per datatype. Yes please! On MUCKs, all objects have a property list attached, which you can edit by hand and access with scripts. http://www.belfry.com/fuzzball/muckhelp.html#PropHelp http://www.belfry.com/fuzzball/mpihelp.html#PropFuncs http://www.belfry.com/fuzzball/mufman.html#PropOps -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/de5800f9/attachment.pgp From josh at lindenlab.com Tue Sep 25 09:47:01 2007 From: josh at lindenlab.com (Joshua Bell) Date: Tue Sep 25 09:49:13 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <1190696242.19728.93.camel@localhost> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> <1190696242.19728.93.camel@localhost> Message-ID: <46F93B85.4020501@lindenlab.com> Callum Lerwick wrote: > On Mon, 2007-09-24 at 13:51 -0700, Joshua Bell wrote: > >> Part of the point of the RC process is to avoid introducing new bugs. >> > > What I'd like to see from the "RC" process, is a feature freeze. Whats > in stays in, whats out stays out. Bugfix only. > Exactly. (Well, not just feature freeze - bugfix freeze too apart from newly introduced regressions. There's no distinction from the code perspective - any bugfix is as likely to destabilize the code as a feature change of the same magnitude. We have a ton of additional bug fixes waiting in the wings - see the "release" code drops - but pulling them into the RC would destabilize it tool.) The down side is a potentially vicious circle: If it consistently takes a long time to stabilize a release, the number of pending changes waiting for the next release piles up. And the more changes that go into a release, the longer it'll take to stabilize. Which can lead to a temptation to take shortcuts around the process. (I suspect that this is mitigated in either a smaller development team or in the classic boxed-software waterfall development cycle - during the stabilization phase, everyone is doing nothing but stabilization. In our case, the incoming bug rate is low enough that most developers are unblocked and continuing to work on other bugfix work or features. As the user base increases this may change.) Any help we can get in triaging and fixing bugs identified during the RC process will go a LONG way to maintaining the process and the stability of the codebase, by showing the value of the process in consistent quality and more predictable dates. From jef at pleiades.ca Tue Sep 25 10:15:50 2007 From: jef at pleiades.ca (Jonathan Freedman) Date: Tue Sep 25 10:15:56 2007 Subject: [sldev] SL and Mono In-Reply-To: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> References: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> Message-ID: <46F94246.4070405@pleiades.ca> Hi, According to various sources (mostly Donovan Linden and Which Linden on twitter) mono is now in some kind of final testing phase internally. Presumably once LL is satisfied with it ,we will be rolled out to the public in one capacity or another. Personally I like the idea of a mono-enabled sim which contains only a large (active) volcano. We can throw scripts compiled with mono into this volcano, and pray that they work. Cheers Jonathan Freedman / otakup0pe Neumann VP Operations Pleiades Consulting nik@terminaldischarge.net wrote: > Just wondering if anyone knows what happened with it? > > I'm just being a curious bunny. > > Nik > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Tue Sep 25 10:33:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 10:33:36 2007 Subject: [sldev] Re: [META] Permissions - A content creator's view In-Reply-To: <200709251823.42777.dale@daleglass.net> References: <20070925143722.0E10A41B2A1@stupor.lindenlab.com> <200709251823.42777.dale@daleglass.net> Message-ID: On 25-Sep-2007, at 11:23, Dale Glass wrote: > Suppose it sounds pretty good, but I'd prefer to have a separate > functionality for configuration instead. So would I, but the last time I brought up a key/value based scheme I got knocked back. And configuration (and the 'owner' field, and script access) are really secondary. > Notecards are very annoying to parse to get configuration info, and > are > slow too. IMO a specific mechanism would be much preferrable. Notecards are not my first choice, I just suggested it as an implementation because it may involve a smaller... and fixed size... change to the asset record... and thus be more palatable to LL. See SVC-701 for another possibility... something like: list config = llParseString2List(llGetNotice(NOTICE_OWNER), [";","\n"], []); From secret.argent at gmail.com Tue Sep 25 10:36:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 10:36:50 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: <46F9363C.2090006@gmail.com> References: <20070925062620.5020741B269@stupor.lindenlab.com> <400E2CA3-0133-4B7D-8321-15392B8A7537@gmail.com> <46F9363C.2090006@gmail.com> Message-ID: I'm trying to follow the requested flagging convention. Apparently I'm the only one who is. :( From lenglish5 at cox.net Tue Sep 25 10:36:48 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 25 10:38:11 2007 Subject: [sldev] SL and Mono In-Reply-To: <46F94246.4070405@pleiades.ca> References: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> <46F94246.4070405@pleiades.ca> Message-ID: <46F94730.5000305@cox.net> Jonathan Freedman wrote: > Hi, > > According to various sources (mostly Donovan Linden and Which Linden > on twitter) mono is now in some kind of final testing phase > internally. Presumably once LL is satisfied with it ,we will be rolled > out to the public in one capacity or another. > > Personally I like the idea of a mono-enabled sim which contains only a > large (active) volcano. We can throw scripts compiled with mono into > this volcano, and pray that they work. > > Cheers In fact, you're not too far off from reality. The first mono sims will be special sandboxes that you go and test your scripts in to see if, and how badly, they break. 50-150x normal speed may do odd things with some scripts. From iridium at lindenlab.com Tue Sep 25 10:38:32 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Tue Sep 25 10:39:30 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <23bbb49e0709250649v64a2d60enf5c5b4e505434991@mail.gmail.com> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <5E3E9C87-FAE5-4CF0-B34A-9881B1576D2F@gmail.com> <23bbb49e0709250649v64a2d60enf5c5b4e505434991@mail.gmail.com> Message-ID: <46F94798.2030108@lindenlab.com> I suggested a roundtable for a few reasons, one of which Tao pointed out. Yes, this discussion applies to many more Residents than the group currently contributing to this list. Some of those Residents are technically oriented but don't subscribe to SLDev for a number of reasons that I won't get into. Additionally, this discussion ought to involve many more Lindens than are subscribed to SLDev, namely Lindens that work on policy issues. This thread is very, very long and at this point, scattered (as Gigs pointed out). I hope someone is pasting into a wiki to ensure a more effective way of aggregating this information. Iridium Tao Takashi wrote: > 2007/9/25, Argent Stonecutter >: > > On 24-Sep-2007, at 21:23, Brian wrote: > > All for Iridium's idea on a roundtable for this: There are > definitely > > unanswered questions between this and the future distributed grid. > > I'd rather it be in this list or in another list. Because otherwise > it'll be during office hours and some of us just can't get in world > then. > > > > But then again some people might feel uncomfortable on this (very > technical) list. I am for some roundtable which might attract > hopefully more content creators. It does not mean that everybody on > here needs to attend as well as long as somebody reports back with a > summary of issues, possible solutions etc. So the first thing at this > meeting should be to define somebody to do the report (transcript is > fine, too but usually hard to read and it might be easier to just take > some notes during the meeting). > > I think it's important to have as many forums about such issues as > possible so that nobody has the feeling that there is some > disconnected group on some mailing list deciding about other people's > future and OTOH not to have the feeling that we discuss great things > here but the world "outside" does not understand us. > > And of course it would be important that Linden Lab gets more involved > about these issues because they will decide in the end what they will > implement on their grid. > > -- Tao > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > taotakashi@gmail.com > http://taotakashi.wordpress.com > http://worldofsl.com > > RL: Christian Scholz, cs@comlounge.net > http://mrtopf.de > > http://comlounge.net > http://comlounge.tv > http://mrtopf.tv > http://dev.comlounge.net > IRC: MrTopf/Tao_T > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/dc915f5f/attachment.htm From tao.takashi at googlemail.com Tue Sep 25 10:42:43 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Sep 25 10:42:49 2007 Subject: [sldev] Re: Permissions - A content creator's view (michi@luskwood.org) In-Reply-To: <46F94798.2030108@lindenlab.com> References: <20070924180558.8DD6041B1F2@stupor.lindenlab.com> <5E3E9C87-FAE5-4CF0-B34A-9881B1576D2F@gmail.com> <23bbb49e0709250649v64a2d60enf5c5b4e505434991@mail.gmail.com> <46F94798.2030108@lindenlab.com> Message-ID: <23bbb49e0709251042q4b5861f1o622294192e4e138c@mail.gmail.com> 2007/9/25, Iridium Linden : > > I suggested a roundtable for a few reasons, one of which Tao pointed out. > Yes, this discussion applies to many more Residents than the group currently > contributing to this list. Some of those Residents are technically oriented > but don't subscribe to SLDev for a number of reasons that I won't get into. > Additionally, this discussion ought to involve many more Lindens than are > subscribed to SLDev, namely Lindens that work on policy issues. This thread > is very, very long and at this point, scattered (as Gigs pointed out). I > hope someone is pasting into a wiki to ensure a more effective way of > aggregating this information. > I tried to start a summary earlier today: https://wiki.secondlife.com/wiki/DRM%2C_IP_and_permissions It's a very brief summary though and it does not summarize the discussion paths. Feel free to add. -- Tao -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/d4444c7d/attachment.htm From secret.argent at gmail.com Tue Sep 25 10:49:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Sep 25 10:49:28 2007 Subject: [sldev] Re: [VIEWER] Proxy support in SL client In-Reply-To: <20070925164915.528DB41B2DD@stupor.lindenlab.com> References: <20070925164915.528DB41B2DD@stupor.lindenlab.com> Message-ID: <4097185A-9147-4FC0-AB91-3F154365FCBC@gmail.com> From: "Rui Granja" > I work for a financial institution which aims to operate in SL. Since > our corporate policy mandates that internet access be performed > through a proxy server (either HTTP or SOCKS) and considering that > proxy support seems to be a popular request for users in corporate > environments I was wondering if there are any plans to provide this > feature. I filed a related problem report in Jira: VWR-1115 http://jira.secondlife.com/browse/VWR-1115 You might want to add comments, open a new PR, or vote for this one to be fixed. My problem isn't quite the same as yours, since I'm only blocked for HTTP because of the lack of proxy support. Since only one other person has bothered to vote for this, I ended up just putting up with it. Apparently it's not a "popular request" in SL. :p Since you have a business case for this, you might be able to get some kind of DMZ approved. From lenglish5 at cox.net Tue Sep 25 10:52:48 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 25 10:53:03 2007 Subject: [sldev] mockup of interface for patch I'm working on Message-ID: <46F94AF0.6090706@cox.net> This is a mock up of the interface for a patch I'm working on. The proposed patch will extend the functions of the LSL editing window inside the client. You click on the left side and get a nested folder/outline list for categories of functions, events and keywords. The right side gives you a longer or shorter list depending on how focused you want your categories, Once you select a keyword, it automatically (or via the "paste" button) pastes the keyword or entire function into the LSL editor. For info that doesn't display well in SL, you can go directly to the webpage its from. The functions and other info will be stored in an XML file that comes with the client, if the Lindens accept the patch, so you don't have to go to the wiki for the function name/variable list. There's a lot left to do, including somehow (hopefully by perl script) grabbing the info for functions, constants and events from the 200 or so webpages on the LSL wiki. But I've got it to the point now where (fingers crossed) I think I can get it to work as shown. Comments? Suggestions, specifically on the interface? The actual capabilities of this are pretty much set in stone as far as I'm concerned. It's a big enough project already, thanks. Lawson Engilsh aka Saijanai Kuhn -------------- next part -------------- Skipped content of type multipart/related From adaradius at gmail.com Tue Sep 25 10:57:14 2007 From: adaradius at gmail.com (Ada Radius) Date: Tue Sep 25 10:57:18 2007 Subject: [sldev] Permissions Message-ID: Whatever evolves out of this discussion on Permissions, I hope the non-profit/edu sector is taken into consideration, too. I have a gallery iSL, and show images that are borrowed, with permission, from RL non-profits (university, museum, etc.), with the intent that they be distributed for free for edu purpose, with as much protection as I can manage, to make sure the images are not sold by the transferee. And that I document my efforts. My solution has been to turn the images into textures, and "frame" them onto objects, assign Copy-No Transfer, so that no one else can sell them, and charge L$0 or L$1, plus keep visitor counter records, so that I can document distribution. It's "best efforts", not a perfect solution. And I need the No Transfer perm for this purpose. Ada Radius -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/a0f2190e/attachment.htm From seg at haxxed.com Tue Sep 25 10:59:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 10:59:56 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <5eff6d3b0709250546n593c12et133ba4bdea334178@mail.gmail.com> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <46F8784F.9090205@wsu.edu> <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> <1190702071.19728.114.camel@localhost> <5eff6d3b0709250546n593c12et133ba4bdea334178@mail.gmail.com> Message-ID: <1190743194.19728.149.camel@localhost> On Tue, 2007-09-25 at 08:46 -0400, Andre Roche wrote: > In a lot of situations, something so much as a simple statement of > "Don't do that" is enough to stop people from doing something. That's > the point. Yes, and all it takes is ONE person to ignore your "Please don't copy this" plea, save it and re-upload it with full permissions, and start handing out copies like candy, to render your whole "please" scheme moot. Its pointless. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/ef8fa726/attachment.pgp From jhurliman at wsu.edu Tue Sep 25 11:09:14 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 25 11:10:09 2007 Subject: [sldev] Re: [ARCH] Permissions In-Reply-To: References: <20070925125832.9DDE341B278@stupor.lindenlab.com> Message-ID: <46F94ECA.5050905@wsu.edu> Argent Stonecutter wrote: > > From: "Andre Roche" >> With that question in mind, is there good reason why at least a >> cursory permissions system with cursory enforcement by the official LL >> client shouldn't be standard, aside from the DRM just doesn't work >> argument? > > I can't think of any, so long as it's possible for the region to > notify the client what permissions apply in that region where they > don't match the SL standard... so you don't get to CompletelyOpenGrid > and discover that the client is keeping you from reading the source to > a script just because it's in an object you don't own. > > That is, I think the policy needs to be that the region is the arbiter > of permissions, and the creator of an asset is the arbiter of what > kind of regions they're willing to let their content be delivered to, > and the architecture should make sure that this is possible. > I agree with you, I think there was a general consensus at the architecture working group meeting that there needs to be a concept of domain trust that applies to transferable assets. I don't want to get that issue confused with the bitmasks being sent to clients that is supposed to pass as a permission system though. Something like that can easily be implemented through an extension. Just like on the web you can add Javascript to disable right-clicking of images which is a fine honor system, but there is nothing in the HTTP protocol to attach permission bits to html and images. Domain trust != bitmasks being sent to the client John Hurliman From nicholaz at blueflash.cc Tue Sep 25 11:16:25 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 11:16:56 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F93B85.4020501@lindenlab.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> <1190696242.19728.93.camel@localhost> <46F93B85.4020501@lindenlab.com> Message-ID: <46F95079.3000009@blueflash.cc> Joshua Bell wrote: > Any help we can get in triaging and fixing bugs identified during the RC > process will go a LONG way to maintaining the process and the stability > of the codebase, by showing the value of the process in consistent > quality and more predictable dates. Well, as far as I'm concerned and what I hear from users, seen in source and browsing (although not in depth) through the RC JIRA, 1.18.3.5 is good to go. Meaning that I'm not aware of anything obvious that wasn't in earlier releases (the only two things were the red tracker beam/arrow and the erroneous double notifyObservers()). I may have missed something minor, but over all it's definitely an improvement over 1.18.2 Nick From josh at lindenlab.com Tue Sep 25 11:28:04 2007 From: josh at lindenlab.com (Joshua Bell) Date: Tue Sep 25 11:30:18 2007 Subject: [sldev] 1.18.2.1 source code In-Reply-To: <46F95079.3000009@blueflash.cc> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> <1190696242.19728.93.camel@localhost> <46F93B85.4020501@lindenlab.com> <46F95079.3000009@blueflash.cc> Message-ID: <46F95334.3090409@lindenlab.com> Nicholaz Beresford wrote: > > Joshua Bell wrote: >> Any help we can get in triaging and fixing bugs identified during the >> RC process will go a LONG way to maintaining the process and the >> stability of the codebase, by showing the value of the process in >> consistent quality and more predictable dates. > > Well, as far as I'm concerned and what I hear from users, seen in source > and browsing (although not in depth) through the RC JIRA, 1.18.3.5 is > good to go. FYI, here are the outstanding issues we're looking at: VWR-2419: Constant crashes, crash when logging in, friends list not displaying properly VWR-2543: View item under group proposals crashes viewer under certain conditions VWR-2552: Telehub gui very broken in RC VWR-2560: Forced reversion installer fails VWR-2557: Not receieving group IM chat except for group admins VWR-2517: Can't add users to parcel ban list in RC VWR-2529: "Use Grid" in the edit window no longer persists across logins There's high probability that most of these are pre-existing bugs (i.e. present in 1.18.2) and therefore shouldn't block 1.18.3, but we need to verify. From jhurliman at wsu.edu Tue Sep 25 12:12:46 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Sep 25 12:13:33 2007 Subject: [sldev] Re: [VIEWER] Proxy support in SL client In-Reply-To: <6d746f280709250818p6c23d726p535807b828d429d8@mail.gmail.com> References: <6d746f280709250818p6c23d726p535807b828d429d8@mail.gmail.com> Message-ID: <46F95DAE.9050902@wsu.edu> Rui Granja wrote: > Hi, > > I work for a financial institution which aims to operate in SL. Since > our corporate policy mandates that internet access be performed > through a proxy server (either HTTP or SOCKS) and considering that > proxy support seems to be a popular request for users in corporate > environments I was wondering if there are any plans to provide this > feature. > > I'm aware of both the SLSquid and the openvpn/yourfreedom workarounds > but they do not seem to be an option in our case. I've tried using a > socksifier but haven?t managed to get that working yet (unlike many > other applications that lack native socks proxy support it doesn't > work out of the box). > > Has anyone in a similar environment managed to get SL running? > > Thanks in advance, > > Rui I haven't tried it myself but here are some instructions for using SL with Proxifier; you should be able to ignore the extra steps about creating an SL account and using the third party ShoopedLife client. http://tetravalency.org/SL/unbannable.htm John Hurliman From roamingryozu at gmail.com Tue Sep 25 13:26:32 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Tue Sep 25 13:26:34 2007 Subject: [sldev] Re: Re: Permissions (dirk husemann) In-Reply-To: <1190743194.19728.149.camel@localhost> References: <20070924090722.7FF0341B140@stupor.lindenlab.com> <46F8784F.9090205@wsu.edu> <5eff6d3b0709242310i22ee02b1y75d201298223642c@mail.gmail.com> <1190702071.19728.114.camel@localhost> <5eff6d3b0709250546n593c12et133ba4bdea334178@mail.gmail.com> <1190743194.19728.149.camel@localhost> Message-ID: <5eff6d3b0709251326h21f7396ag23cc267769722319@mail.gmail.com> I'm sorry Seg, but your argument sounds a lot like, "You can't live forever, so why not die tomorrow?" I can tell you from the experience of having one of my products in SL duplicated, improved upon, and sold for a lower price than mine. Another person duplicated, added many new features, and sells for twice as much as mine. In both cases, they purchased mine, but granted, they didn't directly rip my scripts. Just nearly duplicated functionality. It didn't really hurt. My sales are still improving actually! Granted, they're not handing out full permissions copies. I'm not convinced that would change anything, all things considered. On 9/25/07, Callum Lerwick wrote: > On Tue, 2007-09-25 at 08:46 -0400, Andre Roche wrote: > > In a lot of situations, something so much as a simple statement of > > "Don't do that" is enough to stop people from doing something. That's > > the point. > > Yes, and all it takes is ONE person to ignore your "Please don't copy > this" plea, save it and re-upload it with full permissions, and start > handing out copies like candy, to render your whole "please" scheme > moot. > > Its pointless. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From sl at phoca.com Tue Sep 25 13:36:05 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Sep 25 13:36:15 2007 Subject: [sldev] SL and Mono In-Reply-To: <46F94246.4070405@pleiades.ca> References: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> <46F94246.4070405@pleiades.ca> Message-ID: ----- Original Message ----- From: "Jonathan Freedman" To: Sent: Tuesday, September 25, 2007 10:15 AM Subject: Re: [sldev] SL and Mono > Hi, > > According to various sources (mostly Donovan Linden and Which Linden on > twitter) mono is now in some kind of final testing phase internally. > Presumably once LL is satisfied with it ,we will be rolled out to the > public in one capacity or another. > > Personally I like the idea of a mono-enabled sim which contains only a > large (active) volcano. We can throw scripts compiled with mono into this > volcano, and pray that they work. > ??? I am currently trying to code up an automaton pet in LSL and the 16k limitations on the script sizes (code and data) are insanely limiting. Not to mention the SLOWNESS of the iterpreter and thnigs that are downright nutty such as eventless scripts still taking huge amounts of sim script time. (I've coded event based messaging sytems more than once and that should just NEVER be) The sooner the aging LSL engine is replaced the better! (with the caveat that... the replacement works as it should of course :) In the future Iam am even MORE looking forward to being able to use other languages on SL, (My left nut for a switch! Or some kind of "message"->"function" jump table functionality like any normal framework would have :D) though I know in the initial push it will merely be just an LSL compiler/interpreter. The hinted at efficiency increases alone are to die for :D Farallon From sl at phoca.com Tue Sep 25 13:43:52 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Sep 25 13:43:57 2007 Subject: [sldev] Permissions In-Reply-To: References: Message-ID: This is a common problem and is IMHO one of the VERY FEW things that really need serious consideration in this permission discussion. I too will not release anything full perms because of this and do exactly as you described. An additional permission of "Public Domain" or whatever you want to call it (Please DON'T call it "GPL") would be something that would be very useful. I also would like to see an "Always for sale" flag as well. If I made a nice plant and sold it for 30L and someone else sees it on their land, it would be nice to have the option to just allow them to buy it right there rather than having to look up the creator and then search for their store... Farallon ----- Original Message ----- From: Ada Radius To: sldev@lists.secondlife.com Sent: Tuesday, September 25, 2007 10:57 AM Subject: [sldev] Permissions Whatever evolves out of this discussion on Permissions, I hope the non-profit/edu sector is taken into consideration, too. I have a gallery iSL, and show images that are borrowed, with permission, from RL non-profits (university, museum, etc.), with the intent that they be distributed for free for edu purpose, with as much protection as I can manage, to make sure the images are not sold by the transferee. And that I document my efforts. My solution has been to turn the images into textures, and "frame" them onto objects, assign Copy-No Transfer, so that no one else can sell them, and charge L$0 or L$1, plus keep visitor counter records, so that I can document distribution. It's "best efforts", not a perfect solution. And I need the No Transfer perm for this purpose. Ada Radius _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Tue Sep 25 13:45:58 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 25 13:46:00 2007 Subject: [sldev] SL and Mono In-Reply-To: References: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> <46F94246.4070405@pleiades.ca> Message-ID: <46F97386.4030606@cox.net> SL - Farallon Greyskin wrote: > ----- Original Message ----- From: "Jonathan Freedman" > To: > Sent: Tuesday, September 25, 2007 10:15 AM > Subject: Re: [sldev] SL and Mono > > >> Hi, >> >> According to various sources (mostly Donovan Linden and Which Linden >> on twitter) mono is now in some kind of final testing phase >> internally. Presumably once LL is satisfied with it ,we will be >> rolled out to the public in one capacity or another. >> >> Personally I like the idea of a mono-enabled sim which contains only >> a large (active) volcano. We can throw scripts compiled with mono >> into this volcano, and pray that they work. >> > > ??? > > I am currently trying to code up an automaton pet in LSL and the 16k > limitations on the script sizes (code and data) are insanely limiting. > Not to mention the SLOWNESS of the iterpreter and thnigs that are > downright nutty such as eventless scripts still taking huge amounts of > sim script time. (I've coded event based messaging sytems more than > once and that should just NEVER be) > > The sooner the aging LSL engine is replaced the better! (with the > caveat that... the replacement works as it should of course :) > > In the future Iam am even MORE looking forward to being able to use > other languages on SL, (My left nut for a switch! Or some kind of > "message"->"function" jump table functionality like any normal > framework would have :D) though I know in the initial push it will > merely be just an LSL compiler/interpreter. The hinted at efficiency > increases alone are to die for :D > > Keep in mind that there will likely be NO perceptable increase in speed for any script that uses mostly "throttled" function calls, like llSetParamas, etc. Any function that has an artificial delay mentioned in the secondlife.com SLS wiki will keep that delay intact for the foreseeable future. Its the "pure" lsl that doesn't involve setting prim-related stuff, that will see the speedup. This will make AI, AL and the like calculations much, much faster, but wont' improve the responsiveness of barebones scripts in any way at all. From seg at haxxed.com Tue Sep 25 13:55:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 13:55:23 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <46F4E1A2.4070701@gmail.com> References: <46F4D041.3060502@gmail.com> <46F4E1A2.4070701@gmail.com> Message-ID: <1190753719.26208.30.camel@localhost> On Sat, 2007-09-22 at 10:34 +0100, Robin Cornelius wrote: > Robin Cornelius wrote: > > > > (gdb) bt > > #0 0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) > > at libopenjpeg/dwt.c:166 > > #1 0x0000000001dcdfaf in dwt_decode_tile (tilec=0x845ede0, stop=0, > > Looking at frame #1 i've found the problem > > in dwt.c line 623 we have pointer truncation > > h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ; Comcast decided to change the IP of the server running my domain without really warning us, long story short, this thread only just got through to me. I was unaware this code was causing an actual bug, though usually I'm running with the DWT vectorization patch, which happens to fix it. :) My patch that adds an opj_aligned_malloc() to do aligned allocations with was merged a bit ago, but I overlooked the DWT. Patching the DWT to use opj_aligned_malloc() is in with the DWT vectorization patch, which has not got merged yet. I can separate that out into its own patch, and probably get it merged right away. Upstream was asking me about that bit of code. :) Though really, all you need to do is eliminate the pointer mangling entirely and go with a plain malloc. On Linux x86_64, all heap allocations are already 16 byte aligned. On i386, or anything else, alignment shouldn't be strictly required because the vectorization patch hasn't been merged. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/ca49b57f/attachment.pgp From seg at haxxed.com Tue Sep 25 14:07:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 14:08:07 2007 Subject: [sldev] [VWR] OpenJPEG backtraces (Robin Cornelius) In-Reply-To: <46F54283.1010907@blueflash.cc> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <59398304-7A72-4B9C-A962-A025F437E902@gmail.com> <46F528FB.4000806@dzonux.net> <814270DA-4894-4FDD-A2CD-A229BF416C49@gmail.com> <46F54283.1010907@blueflash.cc> Message-ID: <1190754438.26208.32.camel@localhost> On Sat, 2007-09-22 at 18:27 +0200, Nicholaz Beresford wrote: > > I could see pointer masking being a problem, though I'd like to know of > > any compilers on machines newer than a DECsystem-20 where this would be > > a problem. > > MSVC doesn't allow modulo or bit-ops on pointers. Neither does GCC. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/e9c70183/attachment.pgp From seg at haxxed.com Tue Sep 25 14:35:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 14:35:57 2007 Subject: [sldev] The "Fix SL challenge" In-Reply-To: <46F44995.2000407@speakeasy.net> References: <46F44995.2000407@speakeasy.net> Message-ID: <1190756153.26208.35.camel@localhost> On Fri, 2007-09-21 at 18:45 -0400, Alan Grimes wrote: > About Twenty years ago there was a game that I used to play on my 286-10 > called "Stunt Driver" it let you build your own race tracks by dropping > tiles onto a grid and then gave you a full 3D vector graphics simulation > that actually worked quite well within its limitations. > Float the Linden!! (crash the dollar!) More patching, less gum flapping. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/03ee5d09/attachment.pgp From sl at phoca.com Tue Sep 25 15:04:20 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Sep 25 15:04:26 2007 Subject: [sldev] SL and Mono In-Reply-To: <46F97386.4030606@cox.net> References: <51397.86.10.79.229.1190737177.squirrel@webmail.terminaldischarge.net> <46F94246.4070405@pleiades.ca> <46F97386.4030606@cox.net> Message-ID: ----- Original Message ----- From: "Lawson English" To: "SL - Farallon Greyskin" Cc: Sent: Tuesday, September 25, 2007 1:45 PM Subject: Re: [sldev] SL and Mono > Keep in mind that there will likely be NO perceptable increase in speed > for any script that uses mostly "throttled" function calls, like > llSetParamas, etc. Any function that has an artificial delay mentioned in > the secondlife.com SLS wiki will keep that delay intact for the > foreseeable future. Its the "pure" lsl that doesn't involve setting > prim-related stuff, that will see the speedup. > > This will make AI, AL and the like calculations much, much faster, but > wont' improve the responsiveness of barebones scripts in any way at all. > > Oh yeah :) The real problem for me (and well any sim owner) currently is "idle" scripts. Probably 90% maybe more of the script time used in a sim are scripts that are not currently doing anything, just waiting for events, or even scripts that have NO "registered" event handlers. Someone used a script to set a texture rotation, the script is now effectively dead but still takes up script time, there are hundreds or thousands of these dead scripts in sims and in purchased goods. At WORST they should take up sim memory, but not interpreter time. If that single problem were/is fixed I think that alone would reduce sim lag tremendously. I would be willing to bet that that is actually a large part of the mono speedup if the tests were done on sims full of scripts ;) Farallon From nicholaz at blueflash.cc Tue Sep 25 16:33:55 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Sep 25 16:34:29 2007 Subject: [sldev] [VIEWER] RC-showstoppers (was 1.18.2.1 source code) In-Reply-To: <46F95334.3090409@lindenlab.com> References: <2c99c46e0709221345x129c0c28s44a90b1651da2972@mail.gmail.com> <46F6DDD8.60808@gmail.com> <2c99c46e0709231855h1f10adbev95bab55347230795@mail.gmail.com> <46F71CEF.1000203@gmail.com> <2c99c46e0709241339v76eea225l290bc4d9e6b84de6@mail.gmail.com> <46F8235A.3080809@lindenlab.com> <1190696242.19728.93.camel@localhost> <46F93B85.4020501@lindenlab.com> <46F95079.3000009@blueflash.cc> <46F95334.3090409@lindenlab.com> Message-ID: <46F99AE3.5070608@blueflash.cc> Joshua Bell wrote: > Nicholaz Beresford wrote: >> > VWR-2419: Constant crashes, crash when logging in, friends list not > displaying properly Was there in 1.18.2.0 (the environment field for the first reporter says it). > VWR-2543: View item under group proposals crashes viewer under certain > conditions Can be fixed with a no-brainer (null pointer check), will file a patch, but crashes all the same in 1.18.0.6. Will assign to myself. > VWR-2552: Telehub gui very broken in RC Can't test ... don't have access to telehub. > VWR-2560: Forced reversion installer fails That may be a real one, but probably just relative to the RC channel. > VWR-2557: Not receieving group IM chat except for group admins Can't repro. > VWR-2517: Can't add users to parcel ban list in RC Can partially repro, but also in 1.18.0.6 > VWR-2529: "Use Grid" in the edit window no longer persists across logins Resolved by initial reporter as "cannot repro" (today/yesterday). Nick From seg at haxxed.com Tue Sep 25 19:49:34 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Sep 25 19:49:39 2007 Subject: [sldev] [VWR] OpenJPEG backtraces In-Reply-To: <200709231502.38993.dale@daleglass.net> References: <20070922122412.4777841AFE3@stupor.lindenlab.com> <1190531245.7423.17.camel@kitiara> <46F661B0.6000802@dzonux.net> <200709231502.38993.dale@daleglass.net> Message-ID: <1190774974.26208.67.camel@localhost> On Sun, 2007-09-23 at 15:02 +0200, Dale Glass wrote: > Isn't malloc/new supposed to align already on the largest boundary needed > by the architecture? Meaning, if the largest alignment needed is 32 bits, > then everything returned by malloc should be 32 bits aligned. Well there's a few issues here. One being, though 16 byte alignment may not be strictly necessary, it can result in better performance due to... lets just call it arcane details of the way CPU caches work. :) That's probably why it was already trying to align the pointer. The other issue being SSE. x86 only needed 8 byte alignment until SSE came along, so for the most part most x86 libc's still only do 8 byte alignment. SSE strictly requires 16 byte alignment. This is all of course x86 centric, and I have no idea how much of this applies to PPC and whatnot. Though I know Linux x86_64 always aligns to 16 bytes, (Well, mine does at least) and so does OSX (according to an official TechNote) so you don't have to do anything special there. I don't suppose someone could pull OpenJPEG from SVN and tell me if it breaks on Solaris. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070925/da010fdf/attachment.pgp From lnxhkr at gmail.com Tue Sep 25 20:46:49 2007 From: lnxhkr at gmail.com (=?ISO-8859-1?Q?J=FCrgen_Lehmann?=) Date: Tue Sep 25 20:46:51 2007 Subject: [sldev] [PATCH] Export Prims Message-ID: I saw a post earlier by Callum about working on an export/import prims function, no sense in duplicating work so here is what I have so far. Only export and it just writes very basic data to a hardcoded filename, needs work. Patch was created against the 1.18.1.2 branch in SVN. Index: llviewermenu.cpp =================================================================== --- llviewermenu.cpp (revision 106) +++ llviewermenu.cpp (working copy) @@ -1946,6 +1946,123 @@ } }; +class LLObjectEnableExport : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLViewerObject* object = gViewerWindow->lastObjectHit(); + bool new_value = (object != NULL); + if (new_value) + { + // Disable for avatars, we can only export prims + LLVOAvatar* avatar = find_avatar_from_object(object); + new_value = (avatar == NULL); + } + gMenuHolder->findControl(userdata["control"].asString())->setValue(new_value); + return true; + } +}; + +class LLObjectExport : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLViewerObject* object = gViewerWindow->lastObjectHit(); + if (!object) return true; + + LLVOAvatar* avatar = find_avatar_from_object(object); + + // Can't export avatars (at least not yet...) + if (!avatar) + { + export_object(); + } + + return true; + } +}; + +void export_object() +{ + LLObjectSelectionHandle selection = gSelectMgr->getSelection(); + LLViewerObject* root_object = NULL; + LLViewerObject* object = NULL; + LLSelectNode* node = selection->getFirstRootNode(); + if(!node) return; + + object = root_object = node->getObject(); + if(!object) return; + if (object->isAvatar()) + { + // ...don't export avatars + llwarns << "Exporting avatars is currently unsupported" << llendl; + return; + } + + // Build a list of everything that we'll actually be exporting + LLDynamicArray export_objects; + + // Add the root object to the export list + export_objects.put(object); + + // Iterate over all of this objects children + LLViewerObject::child_list_t child_list = object->getChildren(); + + for (LLViewerObject::child_list_t::iterator i = child_list.begin(); i != child_list.end(); ++i) + { + LLViewerObject* child = *i; + + // Put the child objects on the export list + export_objects.put(child); + } + + // FIXME: Open a save dialog instead of hardcoding this + std::ostringstream exportSaveName; + exportSaveName << gDirUtilp->getExpandedFilename(LL_PATH_PER_SL_ACCOUNT, "export.xml"); + llofstream exportFile(exportSaveName.str().c_str()); + + // Create an LLSD object that will hold the entire tree structure + LLSD llsd; + + S32 object_index = 0; + + while((object_index < export_objects.count())) + { + object = export_objects.get(object_index++); + LLUUID id = object->getID(); + + llinfos << "Exporting prim " << object->getID().asString() << llendl; + + // Create an LLSD object that represents this prim. It will be injected in to the LLSD + // tree structure + LLSD prim_llsd; + + prim_llsd["uuid"] = object->getID(); + prim_llsd["localid"] = (int)object->getLocalID(); + // FIXME: What is the proper protocol for storing vectors in LLSD? + //prim_llsd["position"] = object->getPosition(); + //prim_llsd["scale"] = object->getScale(); + // FIXME: What is the proper protocol for storing quaternions in LLSD? + //prim_llsd["rotation"] = object->getRotation(); + + LLVolumeParams params = object->getVolume()->getParams(); + prim_llsd["volume"] = params.asLLSD(); + + // FIXME: Textures + // FIXME: Flex + // FIXME: Light + // FIXME: Sculpt + + // TODO: Is this the best way to convert the localID integer to a string? + std::stringstream ss; + ss << object->getLocalID(); + llsd[ss.str().c_str()] = prim_llsd; + } + + LLSDSerialize::toPrettyXML(llsd, exportFile); + exportFile.close(); +} + bool handle_go_to() { // JAMESDEBUG try simulator autopilot @@ -7767,6 +7884,7 @@ addMenu(new LLObjectAttachToAvatar(), "Object.AttachToAvatar"); addMenu(new LLObjectReturn(), "Object.Return"); addMenu(new LLObjectReportAbuse(), "Object.ReportAbuse"); + addMenu(new LLObjectExport(), "Object.Export"); addMenu(new LLObjectMute(), "Object.Mute"); addMenu(new LLObjectBuy(), "Object.Buy"); addMenu(new LLObjectEdit(), "Object.Edit"); @@ -7779,6 +7897,7 @@ addMenu(new LLObjectEnableWear(), "Object.EnableWear"); addMenu(new LLObjectEnableReturn(), "Object.EnableReturn"); addMenu(new LLObjectEnableReportAbuse(), "Object.EnableReportAbuse"); + addMenu(new LLObjectEnableExport(), "Object.EnableExport"); addMenu(new LLObjectEnableMute(), "Object.EnableMute"); addMenu(new LLObjectEnableBuy(), "Object.EnableBuy"); Index: llviewermenu.h =================================================================== --- llviewermenu.h (revision 106) +++ llviewermenu.h (working copy) @@ -104,6 +104,8 @@ bool handle_object_open(); bool handle_go_to(); +void export_object(); + // Export to XML or Collada void handle_export_selected( void * ); Index: skins/xui/en-us/menu_pie_object.xml =================================================================== --- skins/xui/en-us/menu_pie_object.xml (revision 106) +++ skins/xui/en-us/menu_pie_object.xml (working copy) @@ -57,8 +57,12 @@ + -