From johnniecarling at gmail.com Sun Jun 1 01:41:40 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Sun Jun 1 01:41:45 2008 Subject: [sldev] GPL violation? Message-ID: <200806010441.41299.johnniecarling@gmail.com> Looks like somebody is selling a modified copy of the SL Viewer (the "NakedLife Viewer") http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 or secondlife://Vendetta/145/180/30 in world. interesting license terms they have. ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT You expressly agree that, by using this viewer, it is to be used in accordance of, and in compliance with, the Second Life Terms of Service Agreement, and any National, State, or Local laws. This may be up to, and including, consent of the parties you choose to view in this manner. It is the express responsibility of any user of this software to ensure compliance with the aforementioned. By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited. Failure to comply with the foregoing will result in immediate revocation of the limited license. Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF LICENSOR From danteferret at gmail.com Sun Jun 1 02:00:13 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sun Jun 1 02:00:15 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > or secondlife://Vendetta/145/180/30 in world. > > interesting license terms they have. > > ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT > You expressly agree that, by using this viewer, it is to be used in > accordance > of, and in compliance with, the Second Life Terms of Service Agreement, and > any National, State, or Local laws. This may be up to, and including, > consent > of the parties you choose to view in this manner. It is the express > responsibility of any user of this software to ensure compliance with the > aforementioned. By purchasing this software, you are using the same under a > limited license agreement. Any additional duplication, distribution, or > modification of this software is expressly prohibited. Failure to comply > with > the foregoing will result in immediate revocation of the limited license. > Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF > LICENSOR > > > > > _______________________________________________ > 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/20080601/f61e4b44/attachment.htm From darien_caldwell at comcast.net Sun Jun 1 02:12:27 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Sun Jun 1 02:12:24 2008 Subject: [sldev] GPL violation? References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> Message-ID: <001d01c8c3c7$9d6db4e0$667ba8c0@a644000> Many games have 'naked' patches for them, i'm frankly not suprised someone did this with SL. I just wonder how they get the skin texture without clothes, doesn't each person's client send a baked composite of all layers? ----- Original Message ----- From: Dante Tucker To: Johnnie Carling Cc: sldev Sent: Sunday, June 01, 2008 2:00 AM Subject: Re: [sldev] GPL violation? I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling wrote: Looks like somebody is selling a modified copy of the SL Viewer (the "NakedLife Viewer") http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 or secondlife://Vendetta/145/180/30 in world. interesting license terms they have. ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT You expressly agree that, by using this viewer, it is to be used in accordance of, and in compliance with, the Second Life Terms of Service Agreement, and any National, State, or Local laws. This may be up to, and including, consent of the parties you choose to view in this manner. It is the express responsibility of any user of this software to ensure compliance with the aforementioned. By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited. Failure to comply with the foregoing will result in immediate revocation of the limited license. Such revocation will be without compensation. REFUNDS AT SOLE DISCRETION OF LICENSOR _______________________________________________ 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/20080601/aaef2abf/attachment-0001.htm From robin.cornelius at gmail.com Sun Jun 1 02:44:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Jun 1 02:44:51 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <48426F8A.9030904@gmail.com> Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") I love this too "* The ability to browse in websites, the NakedLife viewer is connecting to a database in order to check for updates and authenticate your product." Goodbye privacy, goodbye passwords -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080601/cab2342e/signature.pgp From qieniangao at gmail.com Sun Jun 1 05:24:12 2008 From: qieniangao at gmail.com (Qie Niangao) Date: Sun Jun 1 05:24:16 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> I've been trying to keep quiet about this (mostly), because I thought it was just an innocent waste of time, kludging onto the UI something more flexibly implemented by script (once LSL gets features again), but now NAV has me scared. If there is indeed a *hint* of a long-term objective to remove LMs from Inventory, then that implies they'd no longer be first-class assets, which in turn means they'd no longer be available to scripts nor containable in objects. And all this for the grossly flawed and depressingly self-limiting Viewer=Browser analogy. Please stop NAV. Seriously, just stop. This is on a path to break much, much more than it fixes. Re-assess what's actually needed for Landmarks (mostly, they need structured content available to LSL, and availability from Profile Picks). Try not to fall victim to the Viewer=Browser canard. (E.g., the very last thing we need is to be whacking the grid with "Back" / "Next" TP buttons!) Then, before any UI design starts, make sure any changes apply to all asset types and operations on all Inventory classes. It's fine to use Landmarks as a test case, but it should test something that actually matters. From tom at streamsense.net Sun Jun 1 06:44:00 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Sun Jun 1 06:45:15 2008 Subject: [sldev] GPL violation? In-Reply-To: <200806010441.41299.johnniecarling@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> Message-ID: <4842A7A0.9040205@streamsense.net> I have filed a complaint to SLExchange, and I have also lodged an abuse report inworld (secondlife://Vendetta/145/180/30). In no terms is this product legal, I suggest others do the same. ~Tom Johnnie Carling wrote: > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > or secondlife://Vendetta/145/180/30 in world. > tps://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cenji.neutra at gmail.com Sun Jun 1 07:17:19 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Sun Jun 1 07:17:25 2008 Subject: [sldev] GPL violation? Message-ID: > From: "Dante Tucker" > To: "Johnnie Carling" > Date: Sun, 1 Jun 2008 05:00:13 -0400 > Subject: Re: [sldev] GPL violation? > I don't even remotly understand the viewers license terms. But I would think it is clear this is not allowed. Not sure which aspect you're referring to when you say "clear this is not allowed" Dante, but I know that the GPL certainly allows the sale of derivative works (binary and/or source). That's part of the 'freedom' granted in all Free Software licenses. However, if you purchase a copy then you're entitled to the source of their modifications (according to the GPL license). So, if you do purchase a copy, ask them for the source of their changes and they won't give them to you - then they are in violation of the GPL license terms. You're also within your right to resell or give away that viewer too (source included of course). From anthonyrbundy at gmail.com Sun Jun 1 07:31:17 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Jun 1 07:31:16 2008 Subject: [sldev] GPL violation? In-Reply-To: <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> Message-ID: <4842B2B5.2050309@gmail.com> Could someone explain to me why this violates GPL? I'm not saying that something like this doesn't go against some other rules (like TOS or community standards), and I'm definitely not supporting it as a product, but I'm not sure why it was brought up as a GPL violation? As long as any modifications they make are available for the original source (for free), and that the source of their product is available when requested, isn't it following GPL? I only bring it up because I want to understand GPL a bit better. Tony Dante Tucker wrote: > I don't even remotly understand the viewers license terms. But I would > think it is clear this is not allowed. > > On Sun, Jun 1, 2008 at 4:41 AM, Johnnie Carling > > wrote: > > Looks like somebody is selling a modified copy of the SL Viewer > (the "NakedLife Viewer") > > http://uncensored.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=713647 > > or secondlife://Vendetta/145/180/30 in world. > > interesting license terms they have. > > ATTENTION: DISCLAIMER AND LIMITED END-USER LICENSE AGREEMENT > You expressly agree that, by using this viewer, it is to be used > in accordance > of, and in compliance with, the Second Life Terms of Service > Agreement, and > any National, State, or Local laws. This may be up to, and > including, consent > of the parties you choose to view in this manner. It is the express > responsibility of any user of this software to ensure compliance > with the > aforementioned. By purchasing this software, you are using the > same under a > limited license agreement. Any additional duplication, > distribution, or > modification of this software is expressly prohibited. Failure to > comply with > the foregoing will result in immediate revocation of the limited > license. > Such revocation will be without compensation. REFUNDS AT SOLE > DISCRETION OF > LICENSOR > > > > > _______________________________________________ > 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 ordinal.malaprop at fastmail.fm Sun Jun 1 08:15:03 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sun Jun 1 08:15:08 2008 Subject: [sldev] GPL violation? In-Reply-To: <4842B2B5.2050309@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: It says "By purchasing this software, you are using the same under a limited license agreement. Any additional duplication, distribution, or modification of this software is expressly prohibited." Those would seem to me to count as further restrictions incompatible with the rights granted by the GPL ("Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.") so they would be in breach of the GPL by conveying the product with those restrictions. On 1 Jun 2008, at 15:31, Tony wrote: > Could someone explain to me why this violates GPL? > > I'm not saying that something like this doesn't go against some > other rules (like TOS or community standards), and I'm definitely > not supporting it as a product, but I'm not sure why it was brought > up as a GPL violation? > As long as any modifications they make are available for the > original source (for free), and that the source of their product is > available when requested, isn't it following GPL? > I only bring it up because I want to understand GPL a bit better. > > Tony From sakkaku at gmail.com Sun Jun 1 08:29:33 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Sun Jun 1 08:29:36 2008 Subject: [sldev] GPL violation? In-Reply-To: <4842B2B5.2050309@gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> On Sun, Jun 1, 2008 at 9:31 AM, Tony wrote: > Could someone explain to me why this violates GPL? > > I'm not saying that something like this doesn't go against some other rules > (like TOS or community standards), and I'm definitely not supporting it as a > product, but I'm not sure why it was brought up as a GPL violation? > As long as any modifications they make are available for the original source > (for free), and that the source of their product is available when > requested, isn't it following GPL? > I only bring it up because I want to understand GPL a bit better. > > Tony > Under the GPL any derivative works have to release the source (they can charge up to the cost of the binary form tho). So if you release a 3k viewer, then you could theoretically charge 3k for the source too, but you still have to have the source available. Read the license, it is well written and you need to know what your getting into if you do commercial development. From anthonyrbundy at gmail.com Sun Jun 1 09:43:57 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Jun 1 09:43:56 2008 Subject: [sldev] GPL violation? In-Reply-To: References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> Message-ID: <4842D1CD.4020306@gmail.com> Ahh, I see. Yes that definitely conflicts with the original GPL which cannot be modified. I should have read their own license a bit closer. I wonder if their distribution includes the original license at all then... ordinal.malaprop@fastmail.fm wrote: > It says "By purchasing this software, you are using the same under a > limited license agreement. Any additional duplication, distribution, > or modification of this software is expressly prohibited." Those would > seem to me to count as further restrictions incompatible with the > rights granted by the GPL ("Each time you convey a covered work, the > recipient automatically receives a license from the original > licensors, to run, modify and propagate that work, subject to this > License.") so they would be in breach of the GPL by conveying the > product with those restrictions. > > > On 1 Jun 2008, at 15:31, Tony wrote: > >> Could someone explain to me why this violates GPL? >> >> I'm not saying that something like this doesn't go against some other >> rules (like TOS or community standards), and I'm definitely not >> supporting it as a product, but I'm not sure why it was brought up >> as a GPL violation? >> As long as any modifications they make are available for the original >> source (for free), and that the source of their product is available >> when requested, isn't it following GPL? >> I only bring it up because I want to understand GPL a bit better. >> >> Tony > > From secret.argent at gmail.com Sun Jun 1 09:51:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 09:50:07 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On 2008-06-01, at 09:17, Cenji Neutra wrote: > Not sure which aspect you're referring to when you say "clear this > is not allowed" Dante, but I know that the GPL certainly allows the > sale of derivative works (binary and/or source). But it doesn't allow you to add additional restrictions to the license. Their restriction to a single avatar is clearly in violation. From danteferret at gmail.com Sun Jun 1 10:33:47 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sun Jun 1 10:33:49 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: <4d211a610806011033w2d46491dw1301fb140ee5a4c5@mail.gmail.com> Just to be clear. I was taking into account the fact that the seller is refusing to give out the source in my assessment of "what is allowed". On Sun, Jun 1, 2008 at 10:17 AM, Cenji Neutra wrote: > > From: "Dante Tucker" > > To: "Johnnie Carling" > > Date: Sun, 1 Jun 2008 05:00:13 -0400 > > Subject: Re: [sldev] GPL violation? > > I don't even remotly understand the viewers license terms. But I would > think it is clear this is not allowed. > > Not sure which aspect you're referring to when you say "clear this is > not allowed" Dante, but I know that the > GPL certainly allows the sale of derivative works (binary and/or > source). That's part of the 'freedom' granted in > all Free Software licenses. However, if you purchase a copy then > you're entitled to the source of their > modifications (according to the GPL license). So, if you do purchase > a copy, ask them for the source of > their changes and they won't give them to you - then they are in > violation of the GPL license terms. > You're also within your right to resell or give away that viewer too > (source included 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/20080601/3e9a7c66/attachment.htm From soft at lindenlab.com Sun Jun 1 10:54:58 2008 From: soft at lindenlab.com (Soft) Date: Sun Jun 1 10:55:00 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On Sun, Jun 1, 2008 at 11:51 AM, Argent Stonecutter wrote: > On 2008-06-01, at 09:17, Cenji Neutra wrote: >> >> Not sure which aspect you're referring to when you say "clear this is not >> allowed" Dante, but I know that the GPL certainly allows the sale of >> derivative works (binary and/or source). > > But it doesn't allow you to add additional restrictions to the license. > Their restriction to a single avatar is clearly in violation. We definitely haven't granted a closed license to a naked avatar viewer if that's the question here. If anyone who has a patch in the viewer has already contacted the person offering this viewer, please consider forwarding any response you receive to our legal eagles. You have just as much standing to engage them about any GPL violation as we have, and may have the freedom to move more quickly here. But please do start with an attempt to educate, as they may not realize it if they really are violating the only license that would allow them to redistribute our/your work. The goal should be correcting the situation, not piling on. From apotheus at slexchange.com Sun Jun 1 11:48:28 2008 From: apotheus at slexchange.com (Apotheus Silverman) Date: Sun Jun 1 11:48:32 2008 Subject: [sldev] Email from external servers to LSL scripts failing? Message-ID: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> Hi all, This isn't exactly a development-related issue, but this seems to be the best place to ask where others might have similar experience. I'm curious if anyone else is having this problem. For the past 2.5 days or so our mail server is getting near 100% read timeouts and connect timeouts from data.agni.lindenlab.com when trying to send email to scripted objects. I called the concierge line and was told that they are aware of an issue, but the rep assured me the problem isn't widespread. It's now a day later and my server logs say otherwise. Is anyone else seeing this problem? Is anyone *not* seeing it? -- Regards, Jay Geeseman (AKA Apotheus Silverman in Second Life) SL Exchange, http://www.slexchange.com/ From robin.cornelius at gmail.com Sun Jun 1 12:03:48 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Jun 1 12:03:52 2008 Subject: [sldev] GPL violation? In-Reply-To: References: Message-ID: On 6/1/08, Argent Stonecutter wrote: > On 2008-06-01, at 09:17, Cenji Neutra wrote: > > Not sure which aspect you're referring to when you say "clear this is not > allowed" Dante, but I know that the GPL certainly allows the sale of > derivative works (binary and/or source). > > > > But it doesn't allow you to add additional restrictions to the license. > Their restriction to a single avatar is clearly in violation. > Not just the single avatar but the following statement:- "Any additional duplication, distribution, or modification of this software is expressly prohibited" This is clearly a MASSIVE licence change and goes against everything the GPL stands for (not that you can make any licence change with out the copyright holders agreement) but this is particuary bad. Robin From apotheus at slexchange.com Sun Jun 1 12:06:16 2008 From: apotheus at slexchange.com (Apotheus Silverman) Date: Sun Jun 1 12:06:19 2008 Subject: [sldev] Re: Email from external servers to LSL scripts failing? In-Reply-To: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> References: <47322fe00806011148gfd0ac49n4cafe4481a593733@mail.gmail.com> Message-ID: <47322fe00806011206x73f31c82g6e01772c093a6172@mail.gmail.com> Wrong list. Sorry about that. :-/ On Sun, Jun 1, 2008 at 2:48 PM, Apotheus Silverman wrote: > Hi all, > > This isn't exactly a development-related issue, but this seems to be > the best place to ask where others might have similar experience. > > I'm curious if anyone else is having this problem. For the past 2.5 > days or so our mail server is getting near 100% read timeouts and > connect timeouts from data.agni.lindenlab.com when trying to send > email to scripted objects. I called the concierge line and was told > that they are aware of an issue, but the rep assured me the problem > isn't widespread. It's now a day later and my server logs say > otherwise. > > Is anyone else seeing this problem? Is anyone *not* seeing it? > > -- > Regards, > > Jay Geeseman (AKA Apotheus Silverman in Second Life) > SL Exchange, http://www.slexchange.com/ > From secret.argent at gmail.com Sun Jun 1 12:52:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 12:51:13 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: I think that it might be worthwhile to bring up plugin APIs, in particular plugin APIs that could be used by commercial software. There's a sticky situation here, because the GPL does not exclude plugin APIs... only APIs that are shipped with the OS the software it's running on (what could be called the libc exception, since that's one of the big reasons it was originally created... to allow GCC to be used on operating systems where it needed to use the standard C library provided by the OS). The reason for this is that otherwise you could use a "null" plugin as a general cutout to link *anything* to GPLed code, reducing the GPL to the LGPL. This in theory extends to Flash content on prims or in the in-world browser, and to Quicktime (if you're building the GPLed client you can't use the quicktime libraries because Quicktime isn't shipped with Windows), and who knows what else. I think LL needs to come up with some kind of explicit exception, like the FOSS exception, for SOME kind of plugin API, or else explicitly rule out plugins for GPL clients. From jacek.antonelli at gmail.com Sun Jun 1 13:24:45 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sun Jun 1 13:24:48 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> Message-ID: <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> On Sun, Jun 1, 2008 at 7:24 AM, Qie Niangao wrote: > If there is indeed a *hint* of a long-term > objective to remove LMs from Inventory, then that implies they'd no > longer be first-class assets, which in turn means they'd no longer be > available to scripts nor containable in objects. Ugh. Sorry, but it often upsets me when someone starts an obviously unfounded rumour ("Landmarks are going to be removed from inventory omgz!") and then it catches on and turns into hysteria. I've been closely following the Nav & LM project since it was first announced. I've been attending the meetings where it's discussed, and talking directly with the Vectorform people working on the project. So let me say, with full certainty based on all the knowledge I have of this project, that there is NO PLAN TO REMOVE LMs FROM INVENTORY, neither in the short term nor the long term. There was, at the first meeting, the _question_ "Should LMs be removed from inventory?" -- gathering input from Residents. It was swiftly objected to by myself and other Residents, for all the reasons people have given here on the mailing list. The fact that they sought to gather feedback about a topic does not constitute a plan. Believe me, if there was any indication that they _were_ planning to do anything of the sort, I would raise hell until they changed thier minds ;-P. But there's not. No plan. Not removing LMs from inventory. Capiche? In fact, one of their stated objectives on the wiki page is: "Backward compatibility: Everything we do must be backward compatible and seamlessly integrated with the existing system (with all of the scripted objects in IW stores right now, for example). To ensure backward compatibility, conducting a sort of "inventory assessment" on Landmark functionality IW will be necessary." See < http://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project#Requirements > It would be helpful if someone from Vectorform could step in and give an official word that removing LM from inventory is not on the agenda, and maybe we can quash this rumor before it gets out of hand. > Then, before any UI design starts, make sure any changes apply to all > asset types and operations on all Inventory classes. It's fine to use > Landmarks as a test case, but it should test something that actually > matters. One step at a time, I say. The current plan, which is still not finalized, involves a number of useful new features which could later be extended to inventory items in general: 1. An easier way to organize and manage them in inventory folders as you create / receive them. 2. A space for your own comments / description (in addition to creator-set description, I believe), which might become searchable in the future. 3. A space for tags, which also might become searchable. Honestly, I'd rather have them testing this out on a relatively minor feature -- if it breaks, I'd rather have Landmarks not working for a few days, than having objects, scripts, or clothing not working! Once the wrinkles are ironed out and it seems to be working well, then it could be extended to other inventory types. But that's outside the scope of the current project. - Jacek From kwerks.sl at gmail.com Sun Jun 1 13:28:15 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Sun Jun 1 13:28:22 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> IANAL, but the unofficial FAQ seems to attempt to account for this usage https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ On Sun, Jun 1, 2008 at 3:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. > > There's a sticky situation here, because the GPL does not exclude plugin > APIs... only APIs that are shipped with the OS the software it's running on > (what could be called the libc exception, since that's one of the big > reasons it was originally created... to allow GCC to be used on operating > systems where it needed to use the standard C library provided by the OS). > The reason for this is that otherwise you could use a "null" plugin as a > general cutout to link *anything* to GPLed code, reducing the GPL to the > LGPL. > > This in theory extends to Flash content on prims or in the in-world > browser, and to Quicktime (if you're building the GPLed client you can't use > the quicktime libraries because Quicktime isn't shipped with Windows), and > who knows what else. > > I think LL needs to come up with some kind of explicit exception, like the > FOSS exception, for SOME kind of plugin API, or else explicitly rule out > plugins for GPL clients. > > _______________________________________________ > 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/20080601/5a092c35/attachment.htm From sakkaku at gmail.com Sun Jun 1 14:06:17 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Sun Jun 1 14:06:19 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> On Sun, Jun 1, 2008 at 3:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. > > There's a sticky situation here, because the GPL does not exclude plugin > APIs... only APIs that are shipped with the OS the software it's running on > (what could be called the libc exception, since that's one of the big > reasons it was originally created... to allow GCC to be used on operating > systems where it needed to use the standard C library provided by the OS). > The reason for this is that otherwise you could use a "null" plugin as a > general cutout to link *anything* to GPLed code, reducing the GPL to the > LGPL. > > This in theory extends to Flash content on prims or in the in-world browser, > and to Quicktime (if you're building the GPLed client you can't use the > quicktime libraries because Quicktime isn't shipped with Windows), and who > knows what else. > > I think LL needs to come up with some kind of explicit exception, like the > FOSS exception, for SOME kind of plugin API, or else explicitly rule out > plugins for GPL clients. > For the most part the GPL allows you to use GPL'd code so long as you do not actually "include" that code into your binary with the exclusion of language libraries (like the c standard libraries). You can make an executable around a library then pipe data between your closed source program and the wrapped library, provided you release the wrapper containing GPL'd code as open source. You can get around the GPL, by buying rights to the library from the developers (as they still have the rights to it) or going through rather interesting schemes, but it is designed to make FOSS easy and commercial (closed source) hell. The idea is that open source apps get a free ride while commercial applications will need to fork out the dough (like they normally would anyway). From jay_reynolds_freeman at mac.com Sun Jun 1 15:17:35 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sun Jun 1 15:17:40 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> Message-ID: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> So I have been looking at the SL Viewer Architecture Wiki, and babbling a bit as I page through 600 000 lines of source code, trying to learn about the whens, hows, and wherefores of information about objects in SL, that are near the agent, being downloaded to the client. Stuff in the wiki is rather thin, but there are several possibly promising pages that seem to be limited to group access; they include the pages for Culling, Groups, and the Rendering System. Alas, the wiki also seems not entirely clear on what group can access them, or how to go about joining it. I have a project in which it would be nice to modify the client to make available a list of non-phantom SL objects that are near the agent, and I am not sure where to start to create such a list, or what is available by way of a starting point. (I won't waste bandwidth with what I would do with such a list if I had it unless someone is interested.) Any tips to documentation or to useful functions or data structures in the code itself would be much appreciated. Or, tips on how to gain access to those wiki pages ... -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From stephany at lindenlab.com Sun Jun 1 16:13:41 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Sun Jun 1 16:13:44 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> Message-ID: <48432D25.7020300@lindenlab.com> Hi everyone, Thanks for providing more background and history on the project, Jacek. At this moment in time, removing Landmarks from the inventory is NOT on our list of things to do as part of this project. I apologize for any confusion or concern that our earlier wiki comments (from our first meeting, as Jacek noted) may have caused. Stephany Jacek Antonelli wrote: > On Sun, Jun 1, 2008 at 7:24 AM, Qie Niangao wrote: > >> If there is indeed a *hint* of a long-term >> objective to remove LMs from Inventory, then that implies they'd no >> longer be first-class assets, which in turn means they'd no longer be >> available to scripts nor containable in objects. >> > > Ugh. Sorry, but it often upsets me when someone starts an obviously > unfounded rumour ("Landmarks are going to be removed from inventory > omgz!") and then it catches on and turns into hysteria. > > I've been closely following the Nav & LM project since it was first > announced. I've been attending the meetings where it's discussed, and > talking directly with the Vectorform people working on the project. So > let me say, with full certainty based on all the knowledge I have of > this project, that there is NO PLAN TO REMOVE LMs FROM INVENTORY, > neither in the short term nor the long term. > > There was, at the first meeting, the _question_ "Should LMs be removed > from inventory?" -- gathering input from Residents. It was swiftly > objected to by myself and other Residents, for all the reasons people > have given here on the mailing list. The fact that they sought to > gather feedback about a topic does not constitute a plan. Believe me, > if there was any indication that they _were_ planning to do anything > of the sort, I would raise hell until they changed thier minds ;-P. > But there's not. No plan. Not removing LMs from inventory. Capiche? > > In fact, one of their stated objectives on the wiki page is: "Backward > compatibility: Everything we do must be backward compatible and > seamlessly integrated with the existing system (with all of the > scripted objects in IW stores right now, for example). To ensure > backward compatibility, conducting a sort of "inventory assessment" on > Landmark functionality IW will be necessary." > > See < http://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project#Requirements > > > It would be helpful if someone from Vectorform could step in and give > an official word that removing LM from inventory is not on the agenda, > and maybe we can quash this rumor before it gets out of hand. > > >> Then, before any UI design starts, make sure any changes apply to all >> asset types and operations on all Inventory classes. It's fine to use >> Landmarks as a test case, but it should test something that actually >> matters. >> > > One step at a time, I say. The current plan, which is still not > finalized, involves a number of useful new features which could later > be extended to inventory items in general: > > 1. An easier way to organize and manage them in inventory folders as > you create / receive them. > 2. A space for your own comments / description (in addition to > creator-set description, I believe), which might become searchable in > the future. > 3. A space for tags, which also might become searchable. > > Honestly, I'd rather have them testing this out on a relatively minor > feature -- if it breaks, I'd rather have Landmarks not working for a > few days, than having objects, scripts, or clothing not working! Once > the wrinkles are ironed out and it seems to be working well, then it > could be extended to other inventory types. But that's outside the > scope of the current project. > > - Jacek > _______________________________________________ > 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/20080601/06eb8f84/attachment.htm From t8 at pobox.com Sun Jun 1 17:26:41 2008 From: t8 at pobox.com (Sato Meiji) Date: Sun Jun 1 17:26:44 2008 Subject: [sldev] Standard grid identifier string? Message-ID: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Does anyone know if there is a standard way to identify a grid in a human readable way? (i.e. a string). Not just the SL grids (main, beta etc) but a way that would include other VW grids? For SL and opensim-based grids I was considering: 1) Using the shard (as reported by the HTTP X_SECONDLIFE_SHARD header) and domain, such as "production.secondlife.com", "testing.secondlife.com", " production.centralgrid.com" etc 2) Using something like agni.secondlife.com Note in both cases they don't need to be valid domains (I'm using them as a human readable 'relm' specifiers) Is there a defacto way LL uses internally (or in the SL protocols) to identify grids? What about those out there who've recently added 3rd-party grid support to the viewer - how are grids identified in config files etc? Just wondered if there is an 'accepted' way in use or one emerging before I reinvent things. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080601/d5e86756/attachment.htm From secret.argent at gmail.com Sun Jun 1 18:54:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 18:53:12 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> References: <7b61e3970806011328m5e9f277byd6a1e30ec60c4559@mail.gmail.com> Message-ID: <4C736DE8-15A4-43CC-8B4C-8863E460456F@gmail.com> On 2008-06-01, at 15:28, JB Kraft wrote: > IANAL, but the unofficial FAQ seems to attempt to account for this > usage > > https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ Well, that's unofficial, and I'm not sure I see where it accounts for plugins. The FLOSS exception does not apply in this case. Quicktime and Flash are not Free/Libre/Open Source. In fact http://wiki.secondlife.com/wiki/Third_Party_Libraries points out that Quicktime is not covered by the FLOSS exception. From secret.argent at gmail.com Sun Jun 1 18:59:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 18:58:48 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> Message-ID: <37E8001A-7207-495C-B6B2-DB68DA853DA9@gmail.com> On 2008-06-01, at 16:06, Matthew Underwood wrote: > For the most part the GPL allows you to use GPL'd code so long as you > do not actually "include" that code into your binary with the > exclusion of language libraries (like the c standard libraries). Language libraries are not actually an exception. Libraries shipped with the OS are, which is where the C library generally comes in. The meaning of "the OS" is normally treated VERY strictly by the FSF... embedded implementations of operating systems like Interix are not considered an exception, though they should be. Yes, there are mechanisms to create cutouts, I've talked about some on the past myself, but they strongly limit the potential for plugins. > The idea is that open source apps get a free ride while > commercial applications will need to fork out the dough (like they > normally would anyway). And what I'm talking about is the client-side equivalent of scripted HUDs. Not things like the CSI client. From secret.argent at gmail.com Sun Jun 1 19:01:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 19:00:11 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <48432D25.7020300@lindenlab.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> Message-ID: <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> On 2008-06-01, at 18:13, Stephany Filimon wrote: > At this moment in time, removing Landmarks from the inventory is > NOT on our list of things to do as part of this project. I > apologize for any confusion or concern that our earlier wiki > comments (from our first meeting, as Jacek noted) may have caused. Could you update the section in the Wiki under "Food for Thought" then? From secret.argent at gmail.com Sun Jun 1 19:02:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 1 19:01:49 2008 Subject: [sldev] Standard grid identifier string? In-Reply-To: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> References: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Message-ID: Interesting idea. On 2008-06-01, at 19:26, Sato Meiji wrote: > Note in both cases they don't need to be valid domains (I'm using > them as a human readable 'relm' specifiers) The latter should probably be com.secondlife.*something*.agni then, to make it clear that it's an identifier and not a domain. From lenglish5 at cox.net Sun Jun 1 20:10:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Jun 1 20:10:18 2008 Subject: [sldev] Standard grid identifier string? In-Reply-To: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> References: <3995e1ae0806011726m25a707cfh99bee98c57376c1e@mail.gmail.com> Message-ID: <48436496.40908@cox.net> Sato Meiji wrote: > Does anyone know if there is a standard way to identify a grid in a > human readable way? (i.e. a string). > Not just the SL grids (main, beta etc) but a way that would include > other VW grids? > For SL and opensim-based grids I was considering: > > 1) Using the shard (as reported by the HTTP X_SECONDLIFE_SHARD header) > and domain, such as "production.secondlife.com > ", "testing.secondlife.com > ", "production.centralgrid.com > " etc > > 2) Using something like agni.secondlife.com > > Note in both cases they don't need to be valid domains (I'm using them > as a human readable 'relm' specifiers) > > Is there a defacto way LL uses internally (or in the SL protocols) to > identify grids? What about those out there who've recently added > 3rd-party grid support to the viewer - how are grids identified in > config files etc? > > Just wondered if there is an 'accepted' way in use or one emerging > before I reinvent things. > Thanks. > I'd look at the Map API VAG page, talk to the people listed, and attend AW Groupies and Zero Linden office hours (and read transcripts of them): https://wiki.secondlife.com/wiki/Map_API_VAG https://wiki.secondlife.com/wiki/Category:AW_Groupies#Chat_Logs Its been a point of controversy how to identify non-LL virtual worlds. The OpenSim folk have their own ideas too, I am sure. https://wiki.secondlife.com/wiki/Category:AW_Groupies#External_Resources Lawson From tulla at lindenlab.com Mon Jun 2 09:13:35 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi Linden)) Date: Mon Jun 2 09:13:40 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> Message-ID: <48441C2F.9090209@lindenlab.com> This is to be expected. Dave's first email mentioned that the feature would require at least a GeForce 8 to run. Enabling it on 7 series or lower hardware will have similarly bad results. Dante Tucker wrote: > I've been distributing this viewer to a group of mine for testing. So > far In 100% of cases, 7 series Nvidia cards crash on the last step. 8 > and 9 series seem to have no problem. > > On Sat, May 31, 2008 at 10:59 AM, Robin Cornelius > > wrote: > > Dave Parks wrote: > > So getting the awesome out of that branch is a little obscure: > > > > 1) Make sure atmospheric shaders and avatar hardware skinning > are enabled. > > 2) Make sure the debug setting RenderDeferred is set to FALSE > > 3) Set RenderUseFBO to TRUE > > 4) Set RenderDeferred to TRUE > > > > It's only been tested on GeForce 8 cards in Windows (Vista and > XP), but > > I don't see why it shouldn't work in linux. I'd be amazed if it > works > > in OSX since it relies on branching in the shader and a large > > instruction count limit. It's also quite unoptimized and VERY > > experimental. > > With all that i mind i tried anyway but get a crash, now i am not > sure i > am starting the options up incorrectly or if anything else should be > disabled first. Latest SVN on (my) linux crashes when trying to do > something with the shaders, it crashes when i try step 4. Also i'm > on a > 64 bit system if that matters and i'm pushing my luck with my Geforce > 7100, but though i would see what happened anyway even if it ran > slowly. > > > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/pointLightV.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/pointLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/pointLightF.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/pointLightF.glsl > 2008-05-31T14:49:49Z INFO: dumpObjectLog: Fragment info > ------------- > (8) : warning C7531: global type sampler2DRect requires "#extension > GL_ARB_texture_rectangle : enable" before use > (58) : warning C7011: implicit cast from "vec4" to "vec3" > (58) : warning C7011: implicit cast from "vec4" to "vec3" > (58) : warning C7011: implicit cast from "vec4" to "vec3" > > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 0 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 1 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 2 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 3 > 2008-05-31T14:49:49Z INFO: mapUniformTextureChannel: Assigned to > texture > channel 4 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightV.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/sunLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightF.glsl class 1 > 2008-05-31T14:49:49Z INFO: loadShaderFile: Looking in > /usr/share/omvviewer/app_settings/shaders/class1/deferred/sunLightF.glsl > 2008-05-31T14:49:49Z WARNING: linkProgramObject: GLSL Linker Error: > 2008-05-31T14:49:49Z WARNING: dumpObjectLog: Fragment info > ------------- > (9) : warning C7531: global type sampler2DRect requires "#extension > GL_ARB_texture_rectangle : enable" before use > (227) : warning C7549: OpenGL does not allow C style initializers > (268) : warning C7011: implicit cast from "int" to "float" > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (262) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (271) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (267) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > (274) : error C6013: Only arrays of texcoords may be indexed in this > profile, and only with a loop index variable > > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link shader: > Deffered Sun Shader > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link using > shader > level 1. Trying again using shader level 0. > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightV.glsl class 0 > 2008-05-31T14:49:49Z INFO: loadShaderFile: GLSL Shader file not found: > deferred/sunLightV.glsl > 2008-05-31T14:49:49Z INFO: loadShaderFile: Loading shader file: > deferred/sunLightF.glsl class 0 > 2008-05-31T14:49:49Z INFO: loadShaderFile: GLSL Shader file not found: > deferred/sunLightF.glsl > 2008-05-31T14:49:49Z WARNING: createShader: Failed to link shader: > Deffered Sun Shader > 2008-05-31T14:49:49Z > x86_64-linux-client-release/llrender/llrendertarget.cpp(159) : error > 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? > > > _______________________________________________ > 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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Quidquid latine dictum sit, altum sonatur." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric M. Tulla tulla@lindenlab.com Graphics Programmer Linden Lab 1 Broadway Street, 14th Floor Cambridge, MA 02142 cell: 617.388.7971 From monkowsk at watson.ibm.com Mon Jun 2 11:06:38 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:07:42 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: <484436AE.9010701@watson.ibm.com> Jay Reynolds Freeman wrote: > So I have been looking at the SL Viewer Architecture Wiki, and > babbling a bit as I page through 600 000 lines of source code, > trying to learn about the whens, hows, and wherefores of information > about objects in SL, that are near the agent, being downloaded > to the client. > > Stuff in the wiki is rather thin, but there are several possibly > promising pages that seem to be limited to group access; they > include the pages for Culling, Groups, and the Rendering System. > Alas, the wiki also seems not entirely clear on what group > can access them, or how to go about joining it. Sorry to disappoint you, but those aren't pages requiring special access, those are pages that are yet to be created. You can try searching the wiki or the archives of the mailing list. I started putting together a page on Culling by gathering bits from the mailing list, but I haven't got around to editing it. I'll send you the rough draft. Mike From lenglish5 at cox.net Mon Jun 2 11:19:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 11:19:53 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <484436AE.9010701@watson.ibm.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> Message-ID: <484439C5.6070004@cox.net> Mike Monkowski wrote: > Jay Reynolds Freeman wrote: >> So I have been looking at the SL Viewer Architecture Wiki, and >> babbling a bit as I page through 600 000 lines of source code, >> trying to learn about the whens, hows, and wherefores of information >> about objects in SL, that are near the agent, being downloaded >> to the client. >> >> Stuff in the wiki is rather thin, but there are several possibly >> promising pages that seem to be limited to group access; they >> include the pages for Culling, Groups, and the Rendering System. >> Alas, the wiki also seems not entirely clear on what group >> can access them, or how to go about joining it. > > Sorry to disappoint you, but those aren't pages requiring special > access, those are pages that are yet to be created. > > You can try searching the wiki or the archives of the mailing list. > > I started putting together a page on Culling by gathering bits from > the mailing list, but I haven't got around to editing it. I'll send > you the rough draft. > > I'd like to remind everyone to PLEASE let other people know what you're doing. At the least, putting [[Category: AW Groupies]] at the bottom of a wiki page will list it in the articles page for AW Groupies. Even better, do that AND put a link to it under https://wiki.secondlife.com/wiki/AW_Groupies#AWG_and_citizen_pages How will anyone ever find what you have done to document the protocols and so on if you don't at least do that? If you don't feel it belongs under the protocol/communication heading, please feel free to create a new heading, say, viewer documentation or viewer architecture or something. Thanks. Lawson From monkowsk at watson.ibm.com Mon Jun 2 11:34:50 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:35:09 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> Message-ID: <48443D4A.1090609@watson.ibm.com> Bj Raz wrote: > What I see here is the possibility for inter continuity between objects > within other virtual worlds, like WoW and characters to come and > interact with in SL. Now you are breaching 3D worlds and making them > one world. each world can go to SL. That is what I see. Avatar > transport between 3D worlds. Data encapsulation, from one platform > (virtual world) to another. > WoW -> SL I strongly disagree. I see no reason to transfer objects and avatars between different worlds. I can see reason to transfer them between different shards of the same base world, but between different worlds, all you need to transfer is identity. It's reasonable to expect to be able to chat with someone in a different world or to transport to another world, but what is the point of transferring 3D objects? If you want your avatar to look the same in WoW and SL, you can modify them using each world's editor, but you don't have to use the same mesh and morphs. To use an analogy, I can play Quicktime movies and Flash animations in the same browser, and I wouldn't be surprised to find a converter that can translate Flash into Quicktime, but I wouldn't expect to be able to play the Quicktime movie in a Flash viewer. Mike From monkowsk at watson.ibm.com Mon Jun 2 11:41:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 11:43:22 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <484439C5.6070004@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> Message-ID: <48443EDE.5090200@watson.ibm.com> Lawson English wrote: > Mike Monkowski wrote: > >> Jay Reynolds Freeman wrote: >> >>> So I have been looking at the SL Viewer Architecture Wiki, and >>> babbling a bit as I page through 600 000 lines of source code, >>> trying to learn about the whens, hows, and wherefores of information >>> about objects in SL, that are near the agent, being downloaded >>> to the client. >>> >>> Stuff in the wiki is rather thin, but there are several possibly >>> promising pages that seem to be limited to group access; they >>> include the pages for Culling, Groups, and the Rendering System. >>> Alas, the wiki also seems not entirely clear on what group >>> can access them, or how to go about joining it. >> >> >> Sorry to disappoint you, but those aren't pages requiring special >> access, those are pages that are yet to be created. >> >> You can try searching the wiki or the archives of the mailing list. >> >> I started putting together a page on Culling by gathering bits from >> the mailing list, but I haven't got around to editing it. I'll send >> you the rough draft. >> >> > I'd like to remind everyone to PLEASE let other people know what you're > doing. At the least, putting [[Category: AW Groupies]] at the bottom of > a wiki page will list it in the articles page for AW Groupies. Even > better, do that AND put a link to it under > https://wiki.secondlife.com/wiki/AW_Groupies#AWG_and_citizen_pages > > How will anyone ever find what you have done to document the protocols > and so on if you don't at least do that? > > If you don't feel it belongs under the protocol/communication heading, > please feel free to create a new heading, say, viewer documentation or > viewer architecture or something. Huh? I'm pretty sure Jay is referring to the page titled "Viewer Architecture." The page already exists, but has nothing to do with AWG or AW Groupies. Did I miss something? Mike From sakkaku at gmail.com Mon Jun 2 11:48:27 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 11:48:30 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48443D4A.1090609@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> Message-ID: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> On Mon, Jun 2, 2008 at 1:34 PM, Mike Monkowski wrote: > Bj Raz wrote: >> >> What I see here is the possibility for inter continuity between objects >> within other virtual worlds, like WoW and characters to come and interact >> with in SL. Now you are breaching 3D worlds and making them one world. each >> world can go to SL. That is what I see. Avatar transport between 3D >> worlds. Data encapsulation, from one platform (virtual world) to another. >> WoW -> SL > > I strongly disagree. I see no reason to transfer objects and avatars > between different worlds. I can see reason to transfer them between > different shards of the same base world, but between different worlds, all > you need to transfer is identity. > > It's reasonable to expect to be able to chat with someone in a different > world or to transport to another world, but what is the point of > transferring 3D objects? If you want your avatar to look the same in WoW > and SL, you can modify them using each world's editor, but you don't have to > use the same mesh and morphs. > > To use an analogy, I can play Quicktime movies and Flash animations in the > same browser, and I wouldn't be surprised to find a converter that can > translate Flash into Quicktime, but I wouldn't expect to be able to play the > Quicktime movie in a Flash viewer. > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Why not? Today you can play literally hundreds of video formats in the same player whereas several years ago you would be literally forced to have different players for different codecs. Having the ability to represent other worlds via a set standard would allow many unique opportunities. Imagine being able to watch tournaments within different games, being able to chat with friends in different worlds, etc. While it may not be feasible now, if you push you could likely end up with one or two companies participating. From bos at lindenlab.com Mon Jun 2 11:49:13 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 2 11:49:14 2008 Subject: [sldev] cmake-9 latest test results In-Reply-To: References: Message-ID: <484440A9.6010403@lindenlab.com> Hi, Robin - Thank you for taking the time to try this stuff out again. Your reports have been very helpful, and I appreciate your effort. > Current public cmake-9 status (on windows) seems to be ;- > > 1) The previous mentioned dependency of copy_win_scripts (can work > around by removing dependency reference) I just checked in a fix for this. > 2) VSTool.exe fails with an error (not critical) > Running 'tools\\vstool\\VSTool.exe --solution > build-VC90\\SecondLife.sln --config RelWithDebInfo --startup > secondlife-bin' in 'C:\\cmake-9\\indra' > Opening solution: build-VC90\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC90... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\cmake-9\indra\build-VC90\SecondLife.sln This isn't my baby, but I'll make sure it gets a look. > 3) Compiling is successful in VC90 (Visual C++ 2008) Excellent! > 4) Linking links against a not supplied ll_intel_memops.lib (missing > export file in libs zip?) does not seem to be required We don't have permission to redistribute that. I've made linking against it conditional on its presence. > 6) post-build fails due to missing script :- > Performing Post-Build Event... > C:\Python25\python25.exe: can't open file > 'C:/cmake-9/indra/newview/postbuild_win32.py': [Errno 2] No such file > or directory Oops, added. > 7) Executing the binary built in "Debug" results in missing > OpenJPEGd.dll (in fact the default build is RelWithDebInf but this > didn't get set due to (2). Need to rebuild in these different modes to > complete tests. OK. I hope that if we can fix vstool, this one will resolve itself. References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> Message-ID: <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> Excuse me if I missed it, but shouldn't it be mentioned in the design doc how the landmarks will end up in the inventory. Will those folders you make in the landmark panel also be created in the inventory landmark folder? Or will they just be dropped in the main list, and we have to clean up the clutter by hand? Frans. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/4a09983c/attachment.htm From carjay at gmx.net Mon Jun 2 13:09:45 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Jun 2 13:09:58 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48441C2F.9090209@lindenlab.com> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> Message-ID: <48445389.5050709@gmx.net> Eric M. Tulla (BigPapi Linden) wrote: > This is to be expected. Dave's first email mentioned that the feature > would require at least a GeForce 8 to run. Enabling it on 7 series or > lower hardware will have similarly bad results. > > Dante Tucker wrote: >> 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? Looking at the FBO and pipeline code I think it's the deferred sun shadow shader which stops the 7s in its track. It uses a double floating point texture (FP32) along with linear filtering which is only possible starting with G8x GPUs. But would probably not be of much use even if it worked since I guess the sun shader (which is not linking) is necessary for it to work. There are really quite some differences between G7x and G8x, for some features it's not just a case of "a bit slower" but a "can't work". You need fallback paths for all of these and those aren't present yet. Carsten From carjay at gmx.net Mon Jun 2 13:16:28 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Jun 2 13:16:32 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48445389.5050709@gmx.net> References: <200805232003.05484.johnniecarling@gmail.com><483A1168.4 040107@lindenlab.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> Message-ID: <4844551C.5020009@gmx.net> Carsten Juttner wrote: > > It uses a double floating point texture (FP32) along with linear > filtering which is only possible starting with G8x GPUs. Oops, FP32 is of course not a double but "just" a single precision float. Carsten From lenglish5 at cox.net Mon Jun 2 13:55:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 13:56:00 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48443EDE.5090200@watson.ibm.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> Message-ID: <48445E5D.4020203@cox.net> Mike Monkowski wrote: > > Huh? I'm pretty sure Jay is referring to the page titled "Viewer > Architecture." The page already exists, but has nothing to do with > AWG or AW Groupies. Did I miss something? > > Mike > > Nyah, but I did. Added a reference from AW Groupies page to it and back. Lawson From lenglish5 at cox.net Mon Jun 2 13:59:56 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 13:59:58 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> Message-ID: <48445F4C.8050305@cox.net> Matthew Underwood wrote: > [...] > Why not? Today you can play literally hundreds of video formats in > the same player whereas several years ago you would be literally > forced to have different players for different codecs. Having the > ability to represent other worlds via a set standard would allow many > unique opportunities. > > Imagine being able to watch tournaments within different games, being > able to chat with friends in different worlds, etc. While it may not > be feasible now, if you push you could likely end up with one or two > companies participating. > _______________________________________________ > Well, the current AWG focus is on the near-term goal of interoperability (including asset-sharing in some cases) between SL and OpenSim worlds. Linden Lab and IBM are also working on a universal avatar specification. Long-term, various companies and organizations are already working on interoperability, multiple viewer support, etc. https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources Lawson From monkowsk at watson.ibm.com Mon Jun 2 15:22:28 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 15:24:01 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> Message-ID: <484472A4.2030104@watson.ibm.com> Matthew Underwood wrote: > Having the > ability to represent other worlds via a set standard would allow many > unique opportunities. > > Imagine being able to watch tournaments within different games, being > able to chat with friends in different worlds, etc. This is where I don't get it. Streaming video? Sure. Chat? Sure. Even portals to other worlds makes sense as a way of transferring identity. Those don't involve 3D objects or avatar meshes. But why would you want to shoot an arrow in WoW and have it land in SL? Mike From sakkaku at gmail.com Mon Jun 2 15:30:27 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 15:30:29 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484472A4.2030104@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> Message-ID: <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> On Mon, Jun 2, 2008 at 6:22 PM, Mike Monkowski wrote: > Matthew Underwood wrote: >> >> Having the >> ability to represent other worlds via a set standard would allow many >> unique opportunities. >> >> Imagine being able to watch tournaments within different games, being >> able to chat with friends in different worlds, etc. > > This is where I don't get it. Streaming video? Sure. Chat? Sure. Even > portals to other worlds makes sense as a way of transferring identity. > Those don't involve 3D objects or avatar meshes. But why would you want to > shoot an arrow in WoW and have it land in SL? > > Mike > I don't really see that happening. For the most part that would open up a lot of security issues (imagine 10 turrets being transported into WoW, I am sure that would go well with blizzard...). I think it would be better to stop thinking of it as streaming "video" so much as streaming the world and allowing interaction. From gigstaggart at gmail.com Mon Jun 2 15:55:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 2 15:55:28 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48445E5D.4020203@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> <48445E5D.4020203@cox.net> Message-ID: <48447A4C.1080400@gmail.com> Lawson English wrote: > Nyah, but I did. Added a reference from AW Groupies page to it and back. > > Lawson What does viewer culling have to do with the AWG? If your criteria are that broad, you could include every page in the wiki. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080602/1d2899c0/smime.bin From monkowsk at watson.ibm.com Mon Jun 2 16:08:36 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 16:09:13 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48445F4C.8050305@cox.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> Message-ID: <48447D74.2050704@watson.ibm.com> Lawson English wrote: > Well, the current AWG focus is on the near-term goal of interoperability > (including asset-sharing in some cases) between SL and OpenSim worlds. They aren't really different worlds, though, just different implementations of the same virtual world. > Linden Lab and IBM are also working on a universal avatar specification. Although I work at IBM, I haven't heard anything beyond the initial announcement. Anyone else know if there's been any progress? It's net even clear to me if this means avatar meshes or avatar identities, which are very different things. > Long-term, various companies and organizations are already working on > interoperability, multiple viewer support, etc. Why? What advantage is there to sharing builds or avatar meshes across different platforms? Are they worth the effort? Mike From monkowsk at watson.ibm.com Mon Jun 2 16:12:28 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 16:13:05 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> Message-ID: <48447E5C.4080808@watson.ibm.com> Matthew Underwood wrote: > I think it would > be better to stop thinking of it as streaming "video" so much as > streaming the world and allowing interaction. What kind of interaction? Mike From danteferret at gmail.com Mon Jun 2 16:21:39 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 2 16:21:44 2008 Subject: [sldev] branches/shadow-draft missing llrender.cpp In-Reply-To: <48445389.5050709@gmx.net> References: <200805232003.05484.johnniecarling@gmail.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> Message-ID: <4d211a610806021621m61c13a04ue332757e20652d7e@mail.gmail.com> Your emails kinda messed up, theres a "Dante Tucker wrote:" and following that, stuff I never wrote. Oh and also, Dave never actualy stated it would require a GeForce 8, I don't know where everyone got that idea from. Thats why I was simply confirming his suspicion that it did not run on earlier cards. On Mon, Jun 2, 2008 at 4:09 PM, Carsten Juttner wrote: > Eric M. Tulla (BigPapi Linden) wrote: > >> This is to be expected. Dave's first email mentioned that the feature >> would require at least a GeForce 8 to run. Enabling it on 7 series or lower >> hardware will have similarly bad results. >> >> Dante Tucker wrote: >> >>> 2008-05-31T14:49:49Z ERROR: addColorAttachment: WTF? >>> >> > > Looking at the FBO and pipeline code I think it's the deferred sun shadow > shader which stops the 7s in its track. > > It uses a double floating point texture (FP32) along with linear filtering > which is only possible starting with G8x GPUs. > > But would probably not be of much use even if it worked since I guess the > sun shader (which is not linking) is necessary for it to work. > > There are really quite some differences between G7x and G8x, for some > features it's not just a case of "a bit slower" but a "can't work". > > You need fallback paths for all of these and those aren't present yet. > > > Carsten > > > _______________________________________________ > 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/20080602/a696e98c/attachment.htm From bos at lindenlab.com Mon Jun 2 16:24:37 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 2 16:24:40 2008 Subject: [sldev] CMake project merged to release branch! Message-ID: <48448135.6090805@lindenlab.com> I'm pleased to announce that our release (aka "trunk") branch is now built using CMake on all platforms. This should have a number of benefits for the developer community: One source of all build information, for every platform. On Windows, upport for Visual Studio 2005 and 2008. Easier to develop and maintain patches. For docs, see here: http://wiki.secondlife.com/wiki/CMake I've made a quick pass over developer info for other wiki pages, but please feel welcome to edit and update those pages as appropriate. I've been editing wiki pages all afternoon, and my brain has melted. References: <200805232003.05484.johnniecarling@gmail.com> <484167E4.2050006@gmail.com> <4d211a610805310856p40e52e1y8e21671003f8a345@mail.gmail.com> <48441C2F.9090209@lindenlab.com> <48445389.5050709@gmx.net> <4d211a610806021621m61c13a04ue332757e20652d7e@mail.gmail.com> Message-ID: <484486A2.3090108@gmx.net> Dante Tucker wrote: > Your emails kinda messed up, theres a "Dante Tucker wrote:" and > following that, stuff I never wrote. > Oh and also, Dave never actualy stated it would require a GeForce 8, I > don't know where everyone got that idea from. Thats why I was simply > confirming his suspicion that it did not run on earlier cards. Hm, yes, truly sorry, actually that was a stupid mistake (deleted too much of the original mail) since the reply was really directed at Robin to confirm that there's obviously not a simply fix to make this work on G7x cards (the log entry was posted by Robin in reply to your mail). Carsten From sakkaku at gmail.com Mon Jun 2 16:54:23 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon Jun 2 16:54:25 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447E5C.4080808@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> Message-ID: <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> On Mon, Jun 2, 2008 at 6:12 PM, Mike Monkowski wrote: > Matthew Underwood wrote: > >> I think it would >> be better to stop thinking of it as streaming "video" so much as >> streaming the world and allowing interaction. > > What kind of interaction? > > Mike > Don't ask me as I am a nobody :P From monkowsk at watson.ibm.com Mon Jun 2 17:22:10 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jun 2 17:22:46 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> Message-ID: <48448EB2.8070701@watson.ibm.com> Matthew Underwood wrote: > On Mon, Jun 2, 2008 at 6:12 PM, Mike Monkowski wrote: > >>Matthew Underwood wrote: >> >> >>>I think it would >>>be better to stop thinking of it as streaming "video" so much as >>>streaming the world and allowing interaction. >> >>What kind of interaction? >> >>Mike >> > > > Don't ask me as I am a nobody :P No fair. You were thinking of something. I don't intend to criticize; I just want to understand. It takes many eyes to see the future. :-) mike From lenglish5 at cox.net Mon Jun 2 17:32:08 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 17:32:11 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48447A4C.1080400@gmail.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <484436AE.9010701@watson.ibm.com> <484439C5.6070004@cox.net> <48443EDE.5090200@watson.ibm.com> <48445E5D.4020203@cox.net> <48447A4C.1080400@gmail.com> Message-ID: <48449108.4000006@cox.net> Jason Giglio wrote: > Lawson English wrote: > >> Nyah, but I did. Added a reference from AW Groupies page to it and back. >> >> Lawson >> > > What does viewer culling have to do with the AWG? If your criteria are > that broad, you could include every page in the wiki. > > -Jason > Eh, the AWG is about LL's 2-year plan. The AW Groupies is a bit more open, and in fact, documenting protocols for the OGP will eventually require understanding how the viewer draws things, I think, so its still within the formal "AWG" mandate, in the long run. Lawson From lenglish5 at cox.net Mon Jun 2 17:35:10 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 17:35:12 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447D74.2050704@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> Message-ID: <484491BE.3040905@cox.net> Mike Monkowski wrote: > Lawson English wrote: >> Well, the current AWG focus is on the near-term goal of >> interoperability (including asset-sharing in some cases) between SL >> and OpenSim worlds. > > They aren't really different worlds, though, just different > implementations of the same virtual world. > >> Linden Lab and IBM are also working on a universal avatar specification. > > Although I work at IBM, I haven't heard anything beyond the initial > announcement. Anyone else know if there's been any progress? It's > net even clear to me if this means avatar meshes or avatar identities, > which are very different things. > >> Long-term, various companies and organizations are already working on >> interoperability, multiple viewer support, etc. > > Why? What advantage is there to sharing builds or avatar meshes > across different platforms? Are they worth the effort? > > Mike > You'd have to ask the OpenViewer people. , Also there was some IBM guy who spoke at the Japan 2008 VW conference a few days ago along with Philip Rosen. He was hyped on going well beyond preserving avatar identity. In fact, he correct Phil LInden's 10-year timeline for full interoperability wtih non-SL-compatible worlds, and suggested it would be far, FAR sooner than that. Lawson From dmahalko at gmail.com Mon Jun 2 17:44:21 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 2 17:44:23 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: On Sun, Jun 1, 2008 at 5:17 PM, Jay Reynolds Freeman wrote: > So I have been looking at the SL Viewer Architecture Wiki, and > babbling a bit as I page through 600 000 lines of source code, > trying to learn about the whens, hows, and wherefores of information > about objects in SL, that are near the agent, being downloaded > to the client. > > Stuff in the wiki is rather thin, but there are several possibly > promising pages that seem to be limited to group access; they > include the pages for Culling, Groups, and the Rendering System. > Alas, the wiki also seems not entirely clear on what group > can access them, or how to go about joining it. Probably the best place to look for object tracking and summarizing, is in code related to the mini-map. The mini-map seems to be a live display of all objects the client has downloaded and is rendering in your vicinity, as well as showing the sims that are currently communicating with your client. The mini-map seems to act as a sort of summary of primitives and other data being actively monitored by the client, so tapping into its code could give you most of the object data you seek.. (I wonder if the mini-map may have started life as debugging tool just to monitor this background information, but later moved into general use as a common user's tool.) - Scalar Tardis / Dale Mahalko From lenglish5 at cox.net Mon Jun 2 18:24:59 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 18:25:03 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> Message-ID: <48449D6B.2040406@cox.net> Dale Mahalko wrote: > On Sun, Jun 1, 2008 at 5:17 PM, Jay Reynolds Freeman > wrote: > >> So I have been looking at the SL Viewer Architecture Wiki, and >> babbling a bit as I page through 600 000 lines of source code, >> trying to learn about the whens, hows, and wherefores of information >> about objects in SL, that are near the agent, being downloaded >> to the client. >> >> Stuff in the wiki is rather thin, but there are several possibly >> promising pages that seem to be limited to group access; they >> include the pages for Culling, Groups, and the Rendering System. >> Alas, the wiki also seems not entirely clear on what group >> can access them, or how to go about joining it. >> > > Probably the best place to look for object tracking and summarizing, > is in code related to the mini-map. The mini-map seems to be a live > display of all objects the client has downloaded and is rendering in > your vicinity, as well as showing the sims that are currently > communicating with your client. The mini-map seems to act as a sort of > summary of primitives and other data being actively monitored by the > client, so tapping into its code could give you most of the object > data you seek.. > > (I wonder if the mini-map may have started life as debugging tool just > to monitor this background information, but later moved into general > use as a common user's tool.) > > I believe the mini-map is generated server-side, about once a week. Lawson From secret.argent at gmail.com Mon Jun 2 18:38:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 2 18:36:45 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48443D4A.1090609@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> Message-ID: <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> On 2008-06-02, at 13:34, Mike Monkowski wrote: > If you want your avatar to look the same in WoW and SL, you can > modify them using each world's editor, but you don't have to use > the same mesh and morphs. I don't believe that it's possible to create an avatar in WoW that will look like any of my avatars in SL, and frankly I have no interest in playing Warcraft or Everquest or any other MMORPG until that changes. > To use an analogy, I can play Quicktime movies and Flash animations > in the same browser, and I wouldn't be surprised to find a > converter that can translate Flash into Quicktime, but I wouldn't > expect to be able to play the Quicktime movie in a Flash viewer. Up until QT 7.3.1 you could play Flash animations inside quicktime, and Quicktime is just a packaging mechanism for various codecs, many of which can also be used by Quicktime. This is not a matter of translation, it's is a matter of both Flash Video and Quicktime supporting the same standards. From secret.argent at gmail.com Mon Jun 2 18:47:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 2 18:46:26 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48448EB2.8070701@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> Message-ID: On 2008-06-02, at 19:22, Mike Monkowski wrote: > No fair. You were thinking of something. I don't intend to > criticize; I just want to understand. It takes many eyes to see > the future. :-) OK. At the moment, my avatar in SL is a ferret. Four legged, about two feet long, which is big for a ferret, I admit, but until LL loosens up on the mesh and skeleton that's the best I can do. I have a collar with feathers stuck in it that I wear sometimes. If a friend of mine invites me to visit him in WoW, is it possible for me to visit him as this avatar? From tateru.nino at gmail.com Mon Jun 2 19:08:15 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 19:08:55 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> Message-ID: <4844A78F.9050605@weblogsinc.com> Argent Stonecutter wrote: > On 2008-06-02, at 19:22, Mike Monkowski wrote: >> No fair. You were thinking of something. I don't intend to >> criticize; I just want to understand. It takes many eyes to see the >> future. :-) > > OK. At the moment, my avatar in SL is a ferret. Four legged, about two > feet long, which is big for a ferret, I admit, but until LL loosens up > on the mesh and skeleton that's the best I can do. > > I have a collar with feathers stuck in it that I wear sometimes. > > If a friend of mine invites me to visit him in WoW, is it possible for > me to visit him as this avatar? That would, of course, require the transfer of the avatar, the account, attachments, textures, LSL scripts(!), animations. Essentially a bit of a free-for-all, asset/content transfer, AND have the scripts reliably executed at the destination. Let me go out on a very tenuous limb here and suggest "fat chance". -- Tateru Nino http://www.massively.com/ From cjac at colliertech.org Mon Jun 2 19:51:47 2008 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Mon Jun 2 19:52:50 2008 Subject: [sldev] patch to ELFIO Message-ID: <7B0351D2-088D-410D-9C0A-621789EF44E5@colliertech.org> Hey folks, I've been trying to ease the pain of building the viewer dependencies over the last week. As I mentioned in an earlier message, I've built a gar-based system to build the dependencies listed here: http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) #Installing_the_required_dependencies_.28prepackaged_by_Linden_labs.29 The source for the system, which I've called GARINDRA, is available in subversion here: svn co http://svn.colliertech.org/svn/trunk/garindra I've made a pre-release tarball and placed it here: http://www.colliertech.org/downloads/garindra/garindra-pre0.0.1.tar.bz2 When I get a few more minutes, I'll add the last remaining dependencies. In order to reduce the delta between the libs generated by GARINDRA and the stock configurations, I've created a patch to the ELFIO lib which allows a shared object to be built using libtool. I've sent the patch to the maintainer and hosted it here: http://www.colliertech.org/downloads/garindra/ELFIO.diff The distribution of EIFIO with this patch applied is hosted here: http://www.colliertech.org/downloads/garindra/elfio-1.0.3.1.tar.gz I'd love to get some feedback :) Cheers, C.J. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080602/ca9c5783/attachment.htm From lenglish5 at cox.net Mon Jun 2 20:31:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 2 20:31:45 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844A78F.9050605@weblogsinc.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> Message-ID: <4844BB1F.4040902@cox.net> Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason From missannotoole at yahoo.com Mon Jun 2 22:05:02 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 2 22:05:08 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Message-ID: <104754.31574.qm@web59111.mail.re1.yahoo.com> And how will an asset (any type) be prevented from being carried off of one world to another world when the asset creator forbids transport of said asset from one world to another? Is there a real corporate IP lawyer from LL and IBM involved in this effort to prevent legal errors from being coded? ----- Original Message ---- From: Lawson English To: Tateru Nino Cc: sldev Mailing List Sent: Monday, June 2, 2008 11:31:43 PM Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason _______________________________________________ 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/20080602/f0458c6b/attachment-0001.htm From tateru.nino at gmail.com Mon Jun 2 22:15:27 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 22:16:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <104754.31574.qm@web59111.mail.re1.yahoo.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <4844D36F.1050705@weblogsinc.com> Assets are already transported between worlds, no code required. Look at the number of content assets in SL that have been ripped from other worlds and from assorted games. I swear, if I see yet another cybernetic vampire castle made from Unreal 2 textures, I'll probably hurl. Ann Otoole wrote: > And how will an asset (any type) be prevented from being carried off > of one world to another world when the asset creator forbids transport > of said asset from one world to another? Is there a real corporate IP > lawyer from LL and IBM involved in this effort to prevent legal errors > from being coded? > > > ----- Original Message ---- > From: Lawson English > To: Tateru Nino > Cc: sldev Mailing List > Sent: Monday, June 2, 2008 11:31:43 PM > Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO > MPEG-V ... > > Tateru Nino wrote: > > > > > > Argent Stonecutter wrote: > >> On 2008-06-02, at 19:22, Mike Monkowski wrote: > >>> No fair. You were thinking of something. I don't intend to > >>> criticize; I just want to understand. It takes many eyes to see the > >>> future. :-) > >> > >> OK. At the moment, my avatar in SL is a ferret. Four legged, about > >> two feet long, which is big for a ferret, I admit, but until LL > >> loosens up on the mesh and skeleton that's the best I can do. > >> > >> I have a collar with feathers stuck in it that I wear sometimes. > >> > >> If a friend of mine invites me to visit him in WoW, is it possible > >> for me to visit him as this avatar? > > That would, of course, require the transfer of the avatar, the > > account, attachments, textures, LSL scripts(!), animations. > > Essentially a bit of a free-for-all, asset/content transfer, AND have > > the scripts reliably executed at the destination. > > > > Let me go out on a very tenuous limb here and suggest "fat chance". > > > Well, WoW and EQ are closed worlds. However, there's every possibility > that Wonderland, Croquet, and similar, more open, virtual worlds, will > be willing to let any and all such things in. The questions are: > > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and > its appearance? > how willing will said world be to let the avie keep its origianl name > and other such thigns? > how willing will said world be to let an externally generated avie be a > "first class" citizen? > > and so on. > > The most compatible will be something like an IBM-LL agreement where IBM > hosts its own sub-grid. > Slightly less compatible will be grids running a plain vanilla SL-like > world with full "trust." > > And it gets less compatible from there, > > Lwason > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From darien_caldwell at comcast.net Mon Jun 2 22:21:45 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Mon Jun 2 22:22:03 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <3B60A93948B840A3A8B17E0F1442B666@a644000> It's kind of a moot point. People are already carting off content from SL to OpenSim. Yes not Scripts, but everything else. You can thank things like that 'Second Inventory' program for that. Ann, it just doesn't fit in the scope of an open source world to have closed source data. If you have anything remotely valuable, patented, or actual RL 'IP', i would suggest you not bring it into SL. If you already have, take steps to get it out. You may as well lay it on your front lawn otherwise. ----- Original Message ----- From: Ann Otoole To: sldev Mailing List Sent: Monday, June 02, 2008 10:05 PM Subject: Re: Interoperability;was: [sldev] Call for requirements: ISO MPEG-V ... And how will an asset (any type) be prevented from being carried off of one world to another world when the asset creator forbids transport of said asset from one world to another? Is there a real corporate IP lawyer from LL and IBM involved in this effort to prevent legal errors from being coded? ----- Original Message ---- From: Lawson English To: Tateru Nino Cc: sldev Mailing List Sent: Monday, June 2, 2008 11:31:43 PM Subject: Re: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>> No fair. You were thinking of something. I don't intend to >>> criticize; I just want to understand. It takes many eyes to see the >>> future. :-) >> >> OK. At the moment, my avatar in SL is a ferret. Four legged, about >> two feet long, which is big for a ferret, I admit, but until LL >> loosens up on the mesh and skeleton that's the best I can do. >> >> I have a collar with feathers stuck in it that I wear sometimes. >> >> If a friend of mine invites me to visit him in WoW, is it possible >> for me to visit him as this avatar? > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND have > the scripts reliably executed at the destination. > > Let me go out on a very tenuous limb here and suggest "fat chance". > Well, WoW and EQ are closed worlds. However, there's every possibility that Wonderland, Croquet, and similar, more open, virtual worlds, will be willing to let any and all such things in. The questions are: how willing is LL to let specific assets loose? how compatible will the destination world be with the avatar stuff and its appearance? how willing will said world be to let the avie keep its origianl name and other such thigns? how willing will said world be to let an externally generated avie be a "first class" citizen? and so on. The most compatible will be something like an IBM-LL agreement where IBM hosts its own sub-grid. Slightly less compatible will be grids running a plain vanilla SL-like world with full "trust." And it gets less compatible from there, Lwason _______________________________________________ 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/20080602/f0cfc032/attachment.htm From tateru.nino at gmail.com Mon Jun 2 22:22:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 2 22:23:17 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <104754.31574.qm@web59111.mail.re1.yahoo.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> Message-ID: <4844D51F.50109@weblogsinc.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/316f8994/attachment.htm From gigstaggart at gmail.com Tue Jun 3 00:25:07 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 3 00:25:11 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <48448135.6090805@lindenlab.com> References: <48448135.6090805@lindenlab.com> Message-ID: <4844F1D3.1090301@gmail.com> Bryan O'Sullivan wrote: > I'm pleased to announce that our release (aka "trunk") branch is now > built using CMake on all platforms. > I don't see it. Trunk doesn't seem to have it. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080603/d1d410ad/smime-0001.bin From kfa at gmx.net Tue Jun 3 01:34:25 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 01:34:35 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844BB1F.4040902@cox.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> Message-ID: <48450211.50408@gmx.net> Lawson English wrote: > Tateru Nino wrote: >> >> >> Argent Stonecutter wrote: >>> On 2008-06-02, at 19:22, Mike Monkowski wrote: >>>> No fair. You were thinking of something. I don't intend to >>>> criticize; I just want to understand. It takes many eyes to see the >>>> future. :-) >>> >>> OK. At the moment, my avatar in SL is a ferret. Four legged, about >>> two feet long, which is big for a ferret, I admit, but until LL >>> loosens up on the mesh and skeleton that's the best I can do. >>> >>> I have a collar with feathers stuck in it that I wear sometimes. >>> >>> If a friend of mine invites me to visit him in WoW, is it possible >>> for me to visit him as this avatar? >> That would, of course, require the transfer of the avatar, the >> account, attachments, textures, LSL scripts(!), animations. >> Essentially a bit of a free-for-all, asset/content transfer, AND have >> the scripts reliably executed at the destination. >> >> Let me go out on a very tenuous limb here and suggest "fat chance". >> > Well, WoW and EQ are closed worlds. However, there's every possibility > that Wonderland, Croquet, and similar, more open, virtual worlds, will > be willing to let any and all such things in. The questions are: > > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and > its appearance? > how willing will said world be to let the avie keep its origianl name > and other such thigns? > how willing will said world be to let an externally generated avie be a > "first class" citizen? > > and so on. > > The most compatible will be something like an IBM-LL agreement where IBM > hosts its own sub-grid. > Slightly less compatible will be grids running a plain vanilla SL-like > world with full "trust." > > And it gets less compatible from there, > > Lwason > > The main question to answer for any such thing to happen is, where's the business angle to justify such an effort? Creating interfaces and mappings between spaces that were never made with interoperability in mind is not a trivial task. Ultimately the customer, the user will have to pay for it to be enabled. Is there anything you want to do so badly that you'd part with your hard earned L$, PED, gold nuggets or real world currency? And, even before that, what's the business advantage for the respective companies running those worlds? When reading about this discussion I spontaneously dismissed the idea, but upon second thought that is not so clear indeed. A while ago I played Entropia Universe, and took a brief glimpse at EVE Online. I too had fantasies of being somehow able to move my avatar between them. I have no clue what purpose it serves, but the idea is cool in a very fundamental way. Apart from the technical challenge, you'd have to crack the business models first. If a company makes money by selling you stuff they make in-house, wouldn't they find it hard to see the advantage in opening the floodgate. Why would e.g. MindArk, CCP or Microsoft want that? Why would Linden Labs? Those being answered, we'd have a starting point. Hope I didn't miss a piece. Felix From robin.cornelius at gmail.com Tue Jun 3 02:26:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 02:26:32 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4844F1D3.1090301@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 8:25 AM, Jason Giglio wrote: > Bryan O'Sullivan wrote: >> I'm pleased to announce that our release (aka "trunk") branch is now >> built using CMake on all platforms. >> > > I don't see it. Trunk doesn't seem to have it. > I have not seen any SVN commits in the last few days so i presume thats internally and i assume it will sync up when soft does the weekly sync. But any chance of getting a sync earlier so i can rattle through some tests again? Robin From secret.argent at gmail.com Tue Jun 3 02:43:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:42:33 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844A78F.9050605@weblogsinc.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> Message-ID: On 2008-06-02, at 21:08, Tateru Nino wrote: > That would, of course, require the transfer of the avatar, the > account, attachments, textures, LSL scripts(!), animations. > Essentially a bit of a free-for-all, asset/content transfer, AND > have the scripts reliably executed at the destination. Or the creation of a ferret avatar in a new format (MPEG-V?) supported by SL and WoW, with a skeleton, mesh, and animations in standard formats, and support by SL and WoW for them. I'm not sure that any less aggressive goal is worth pursuing. From secret.argent at gmail.com Tue Jun 3 02:46:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:45:19 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4844D36F.1050705@weblogsinc.com> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> <4844D36F.1050705@weblogsinc.com> Message-ID: <12A023CA-901B-48F2-ABE0-3DB92CBCB6DF@gmail.com> On 2008-06-03, at 00:15, Tateru Nino wrote: > Assets are already transported between worlds, no code required. > Look at the number of content assets in SL that have been ripped > from other worlds and from assorted games. Naughty naughty, you're not supposed to let that skeleton out of the closet! Everyone's supposed to pretend that people who rip images from other games or poser default animations and sell them in Second Life are really content creators! From secret.argent at gmail.com Tue Jun 3 02:52:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 02:51:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <3B60A93948B840A3A8B17E0F1442B666@a644000> References: <104754.31574.qm@web59111.mail.re1.yahoo.com> <3B60A93948B840A3A8B17E0F1442B666@a644000> Message-ID: On 2008-06-03, at 00:21, Darien Caldwell wrote: > It's kind of a moot point. People are already carting off content > from SL to OpenSim. Yes not Scripts, but everything else. You can > thank things like that 'Second Inventory' program for that. Well, things like SLICE. Second Inventory actually enforces tighter controls than SL. I got it to try and simplify sharing the stuff I create with my alts, but the restrictions it imposes make it all but useless even for products that are 100% mine. I believe they eventually gave up their scheme of requiring you to buy a separate copy of each of your alts, but by that time I'd given up on it... it was less work to set everything full perm, transfer it from Argent Stonecutter to Argent David, and reset the next owner permissions. From secret.argent at gmail.com Tue Jun 3 03:02:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 03:01:04 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48450211.50408@gmx.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> Message-ID: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> On 2008-06-03, at 03:34, Felix Duesenburg wrote: > The main question to answer for any such thing to happen is, > where's the business angle to justify such an effort? Creating > interfaces and mappings between spaces that were never made with > interoperability in mind is not a trivial task. Ultimately the > customer, the user will have to pay for it to be enabled. Is there > anything you want to do so badly that you'd part with your hard > earned L$, PED, gold nuggets or real world currency? I've spent hundreds of dollars on my avatar over the past three years: that and land rent for the Coonspiracy is where pretty much everything I earn in SL goes to. Why wouldn't I spend real money to carry that around with me? > And, even before that, what's the business advantage for the > respective companies running those worlds? Getting people who would have absolutely no interest in visiting WoW as an elf or a thinly disguised hobbit to play the game? People willing to pay a premium to have a custom avatar, but not willing to pay a penny to be a dark elf no matter how fantastic a costume Sony or Blizzard or whoever come up for it? From aimee at ama-zing.co.uk Tue Jun 3 03:45:13 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jun 3 03:45:18 2008 Subject: Fwd: [sldev] Need to learn about object download to the client... References: Message-ID: <65755B93-07D5-47D1-992B-BF6CD2D5A7FF@ama-zing.co.uk> > On Jun 3, 2008, at 02:24, Lawson English wrote: > >> > Dale Mahalko wrote: > >> Probably the best place to look for object tracking and summarizing, >> is in code related to the mini-map. The mini-map seems to be a live >> display of all objects the client has downloaded and is rendering in >> your vicinity, as well as showing the sims that are currently >> communicating with your client. > > I believe the mini-map is generated server-side, about once a week. I think you're thinking about the main map textures. You can watch objects moving around in the grey overlay on the mini-map, it's generated live. Aimee. > (Oops wrong reply button again, sorry about the two copies Lawson :) From kfa at gmx.net Tue Jun 3 05:25:12 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 05:25:16 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <48453828.50503@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 03:34, Felix Duesenburg wrote: >> The main question to answer for any such thing to happen is, where's >> the business angle to justify such an effort? Creating interfaces and >> mappings between spaces that were never made with interoperability in >> mind is not a trivial task. Ultimately the customer, the user will >> have to pay for it to be enabled. Is there anything you want to do so >> badly that you'd part with your hard earned L$, PED, gold nuggets or >> real world currency? > > I've spent hundreds of dollars on my avatar over the past three years: > that and land rent for the Coonspiracy is where pretty much everything I > earn in SL goes to. Why wouldn't I spend real money to carry that around > with me? > >> And, even before that, what's the business advantage for the >> respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW as > an elf or a thinly disguised hobbit to play the game? People willing to > pay a premium to have a custom avatar, but not willing to pay a penny to > be a dark elf no matter how fantastic a costume Sony or Blizzard or > whoever come up for it? > Great :) Needed to elicit that mention... I keep forgetting that others like to think differently. I'm not so focused on designing my appearance, more on the aspect of all these worlds/games being used as communication tools. Now, who is going to be able to convince Blizzard and the rest that they want that, too? My guess is that this will be a task of the magnitude of creating a standard for videotape or disk formats... bringing mighty competitors to work together and compromise. Talk about herding cats, big fat ones. From soft at lindenlab.com Tue Jun 3 07:55:44 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 07:55:47 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 4:26 AM, Robin Cornelius wrote: > On Tue, Jun 3, 2008 at 8:25 AM, Jason Giglio wrote: >> Bryan O'Sullivan wrote: >>> I'm pleased to announce that our release (aka "trunk") branch is now >>> built using CMake on all platforms. >>> >> >> I don't see it. Trunk doesn't seem to have it. >> > > I have not seen any SVN commits in the last few days so i presume > thats internally and i assume it will sync up when soft does the > weekly sync. But any chance of getting a sync earlier so i can rattle > through some tests again? I've pushed the current source - have a look at release/. I'm iterating over some Mac cmake export issues right now and installing VS2008 to see how the export fares there. I'll push another today with the things I know about resolved. Please speak up as you find issues with Linux or other Windows build platforms. The cmake release merge marks the point where we -do- start paying close attention to VS2005 and VS2008 builds as well, so if you've been holding back... From kelly at lindenlab.com Tue Jun 3 08:31:52 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 08:31:58 2008 Subject: [sldev] Need to learn about object download to the client... In-Reply-To: <48449D6B.2040406@cox.net> References: <79e704e0806011406i6fce328el41ab27143c55d998@mail.gmail.com> <7EEDF745-63CA-45BA-B9F5-D61FB2F1C0C2@mac.com> <48449D6B.2040406@cox.net> Message-ID: <484563E8.3050008@lindenlab.com> Lawson English wrote: > Dale Mahalko wrote: >> Probably the best place to look for object tracking and summarizing, >> is in code related to the mini-map. The mini-map seems to be a live >> display of all objects the client has downloaded and is rendering in >> your vicinity, as well as showing the sims that are currently >> communicating with your client. The mini-map seems to act as a sort of >> summary of primitives and other data being actively monitored by the >> client, so tapping into its code could give you most of the object >> data you seek.. >> >> (I wonder if the mini-map may have started life as debugging tool just >> to monitor this background information, but later moved into general >> use as a common user's tool.) >> >> > I believe the mini-map is generated server-side, about once a week. > > > Lawson > Nope, the mini map is generated on the fly in the viewer. The tiles in the world map are generated server-side and are not used in the mini map. - Kelly From mrfrans at gmail.com Tue Jun 3 08:32:44 2008 From: mrfrans at gmail.com (Frans) Date: Tue Jun 3 08:32:48 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <7765f2c60806030832u69fd6812ga0f4de73eea1b4e2@mail.gmail.com> > > Getting people who would have absolutely no interest in visiting WoW as an > elf or a thinly disguised hobbit to play the game? People willing to pay a > premium to have a custom avatar, but not willing to pay a penny to be a dark > elf no matter how fantastic a costume Sony or Blizzard or whoever come up > for it? > It is not just a question if Blizzard and Sony would like that, but also a hardware restriction. They keep avatar modification down, to ensure a reasonable group of people can run the game decently. So even if they are friendly to the idea to let you pay to have your custom avatar, on a large scale it would have a deteriorating for their other customers experience. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/99df7477/attachment.htm From robin.cornelius at gmail.com Tue Jun 3 08:46:32 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 08:46:47 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 3:55 PM, Soft wrote: > Please speak up as you find issues with Linux or other Windows build > platforms. The cmake release merge marks the point where we -do- start > paying close attention to VS2005 and VS2008 builds as well, so if > you've been holding back... > As at r88840/r605 We still have a reference to :- if (WINDOWS) add_subdirectory(copy_win_scripts) endif (WINDOWS) in indra/CMakeLists.txt And no empty folder or flags around the check so its a cmake fail. and VSTool.exe is still not adjusting the projects, same error as before. Running a patch build (VC 2008) of all the possible options to see what comes out the other end... Robin From kelly at lindenlab.com Tue Jun 3 08:52:24 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 08:52:28 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> Message-ID: <484568B8.8010705@lindenlab.com> Argent Stonecutter wrote: > On 2008-06-03, at 03:34, Felix Duesenburg wrote: >> The main question to answer for any such thing to happen is, where's >> the business angle to justify such an effort? Creating interfaces and >> mappings between spaces that were never made with interoperability in >> mind is not a trivial task. Ultimately the customer, the user will >> have to pay for it to be enabled. Is there anything you want to do so >> badly that you'd part with your hard earned L$, PED, gold nuggets or >> real world currency? > > I've spent hundreds of dollars on my avatar over the past three years: > that and land rent for the Coonspiracy is where pretty much everything > I earn in SL goes to. Why wouldn't I spend real money to carry that > around with me? > >> And, even before that, what's the business advantage for the >> respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW > as an elf or a thinly disguised hobbit to play the game? People > willing to pay a premium to have a custom avatar, but not willing to > pay a penny to be a dark elf no matter how fantastic a costume Sony or > Blizzard or whoever come up for it? > > I do not think Sony or Blizzard would want that. The key component in the WoW / EQ / AoC interoperability scenario is creative control. None of these products are trying to host a free form virtual world. They are trying to tell a story, they want their characters and their content to match the story they are telling. And the people paying them to play want that story, they want elfs and/or barbarians and adventure and slaying etc etc. They don't want robot overlords from SL, or fashion models or tinies or furies or goreans. The people who have no interest in visiting WoW as an elf etc are not going to be interested in its story or game play - they aren't the target audience and no one would expect them to join WoW. Blizzard does not want to ruin the experience for their millions of paying customers to satisfy the people who aren't interested in their product. That just makes no sense at all. It is not reasonable to ever expect this sort of product to even desire content exchange with other virtual worlds - independent of what technology allows. At most they may be willing to work with identity exchange and communication protocols. Even then consider that in WoW they restrict communication between their own players (no cross faction communication). In short these are not "virtual worlds", they are MMO stories or MMO games but not virtual worlds. The people who don't want to be an Elf etc don't want to play WoW. Effort on interoperability should be focused on the products (potential and existing) that would actually want it. - Kelly From darien_caldwell at comcast.net Tue Jun 3 08:53:55 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Tue Jun 3 08:53:59 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... Message-ID: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> -------------- Original message ---------------------- From: Argent Stonecutter > On 2008-06-03, at 00:21, Darien Caldwell wrote: > > It's kind of a moot point. People are already carting off content > > from SL to OpenSim. Yes not Scripts, but everything else. You can > > thank things like that 'Second Inventory' program for that. > > Well, things like SLICE. Second Inventory actually enforces tighter > controls than SL. I got it to try and simplify sharing the stuff I > create with my alts, but the restrictions it imposes make it all but > useless even for products that are 100% mine. I believe they > eventually gave up their scheme of requiring you to buy a separate > copy of each of your alts, but by that time I'd given up on it... it > was less work to set everything full perm, transfer it from Argent > Stonecutter to Argent David, and reset the next owner permissions. Well, I have had several people tell me Second Inventory makes importing items from Second Life to OpenSim a breeze. I believe Second Inventory writes assets to one's hard drive, and it seems these files can then be imported into OpenSim somehow. Perhaps they have found a way to circumvent restrictions the programmer placed within the program. From soft at lindenlab.com Tue Jun 3 08:54:13 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 08:54:15 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 10:46 AM, Robin Cornelius wrote: > On Tue, Jun 3, 2008 at 3:55 PM, Soft wrote: >> Please speak up as you find issues with Linux or other Windows build >> platforms. The cmake release merge marks the point where we -do- start >> paying close attention to VS2005 and VS2008 builds as well, so if >> you've been holding back... >> > > As at r88840/r605 > > We still have a reference to :- > > if (WINDOWS) > add_subdirectory(copy_win_scripts) > endif (WINDOWS) > > in indra/CMakeLists.txt > > And no empty folder or flags around the check so its a cmake fail. Thanks. I fixed that in cmake-9, but not in time to make cmake-9-merge for the release merge. I'll pull that over. From monkowsk at watson.ibm.com Tue Jun 3 09:03:11 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 09:03:34 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> Message-ID: <48456B3F.1070305@watson.ibm.com> I didn't feel like spamming the list with separate replies to each note, so I put them all together here so that anyone who's not interested can just delete a single note. First, although there are technical difficulties, which Tateru Nino pointed out: > That would, of course, require the transfer of the avatar, the account, attachments, textures, LSL scripts(!), animations. Essentially a bit of a free-for-all, asset/content transfer, AND have the scripts reliably executed at the destination. > Let me go out on a very tenuous limb here and suggest "fat chance". and IP issues, which Lawson English pointed out: > how willing is LL to let specific assets loose? > how compatible will the destination world be with the avatar stuff and its appearance? > how willing will said world be to let the avie keep its origianl name and other such thigns? > how willing will said world be to let an externally generated avie be a "first class" citizen? > and so on. and business models, which Felix Duesenberg discussed: > The main question to answer for any such thing to happen is, where's the business angle to justify such an effort? Creating interfaces and mappings between spaces that were never made with interoperability in mind is not a trivial task. Ultimately the customer, the user will have to pay for it to be enabled. Is there anything you want to do so badly that you'd part with your hard earned L$, PED, gold nuggets or real world currency? And, even before that, what's the business advantage for the respective companies running those worlds? > Apart from the technical challenge, you'd have to crack the business models first. If a company makes money by selling you stuff they make in-house, wouldn't they find it hard to see the advantage in opening the floodgate. Why would e.g. MindArk, CCP or Microsoft want that? Why would Linden Labs? Those being answered, we'd have a starting point. Hope I didn't miss a piece. and also > Now, who is going to be able to convince Blizzard and the rest that they want that, too? My guess is that this will be a task of the magnitude of creating a standard for videotape or disk formats... bringing mighty competitors to work together and compromise. Talk about herding cats, big fat ones. and the fact that some transfers are already taking place, which Tateru Nino pointed out: > Assets are already transported between worlds, no code required. Look at the number of content assets in SL that have been ripped from other worlds and from assorted games. > I swear, if I see yet another cybernetic vampire castle made from Unreal 2 textures, I'll probably hurl. that's not really the question I was asking. I'm not so concerned with the question "How?" but rather the question "Why?" Christopher Yeoh wrote: > Between say WoW and SL it may not be important, but between SL and say something > like ActiveWorlds or other virtual world environments with similar purposes > it will be very valuable to not have to reimplement a version of a build > or tailor/dress an avatar for each world. which I understand to be a means to minimize effort. But this leads to a couple more questions: Why would you want to do the same thing in two worlds if there were a mechanism to travel between the two worlds? And aren't building, tailoring, and dressing the fun parts? Why would you want to minimize those? But there are other points of view that I never considered. Felix Duesenberg wrote: > When reading about this discussion I spontaneously dismissed the idea, but upon second thought that is not so clear indeed. A while ago I played Entropia Universe, and took a brief glimpse at EVE Online. I too had fantasies of being somehow able to move my avatar between them. I have no clue what purpose it serves, but the idea is cool in a very fundamental way. and > Great :) Needed to elicit that mention... I keep forgetting that others like to think differently. I'm not so focused on designing my appearance, more on the aspect of all these worlds/games being used as communication tools. I think I have the same bias. But Argent Stonecutter wrote: > I don't believe that it's possible to create an avatar in WoW that will > look like any of my avatars in SL, and frankly I have no interest in > playing Warcraft or Everquest or any other MMORPG until that changes. and > OK. At the moment, my avatar in SL is a ferret. Four legged, about two feet long, which is big for a ferret, I admit, but until LL loosens up on the mesh and skeleton that's the best I can do. > > I have a collar with feathers stuck in it that I wear sometimes. > > If a friend of mine invites me to visit him in WoW, is it possible for me to visit him as this avatar? and also > I've spent hundreds of dollars on my avatar over the past three years: that and land rent for the Coonspiracy is where pretty much everything I earn in SL goes to. Why wouldn't I spend real money to carry that around with me? > >> And, even before that, what's the business advantage for the respective companies running those worlds? > > Getting people who would have absolutely no interest in visiting WoW as an elf or a thinly disguised hobbit to play the game? People willing to pay a premium to have a custom avatar, but not willing to pay a penny to be a dark elf no matter how fantastic a costume Sony or Blizzard or whoever come up for it? which seems to imply that identity is not just an abstract concept that manifests itself differently in different worlds, but rather something visual, that cannot be extended with approximate recreations. Even if WoW allowed ferret avatars, it wouldn't be the same ferret. Am I interpreting this correctly? Mike From sldev at bitparts.org Tue Jun 3 09:11:53 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 09:12:04 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <48456D49.5020105@bitparts.org> I just doubled the memory in my PC from 1.5g to 3g. Since I knew that SL would perform perfectly fine with 2g (having performed well with 1.5g), I loaded up a RAMDisk driver and created a 1G RAMDisk. Testing with various software indicated that the drive was performing phenomenally fast, as expected. I loaded up SL, and set my Cache Folder to a new folder on that empty 1G RAMDisk, and fired things up. SL immediately created the various cache files & structures on the RAMDisk, so I know things were running as intended. The result? Even after loading everything in the sim into the cache, tping between two locations (in the same sim, but outside of draw distance from each other) resulted in ZERO perceptible texture loading speedup. Loading from the RAMDisk was as slow as loading from regular disk. I presume, therefor, that the real bottleneck in the cache isn't reading from the drive. This is horribly dismaying. What progress is there toward an improved caching mechanism? Is there a way to store the textures in a decoded, ready-to-use fashion? Why is the cache so slow? -Buckaroo Mu ps - P4 3ghz, 3gb PC3200 memory, 8600GTS, 320g SATA-2 disk. From soft at lindenlab.com Tue Jun 3 09:28:47 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 09:28:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48456D49.5020105@bitparts.org> References: <48456D49.5020105@bitparts.org> Message-ID: On Tue, Jun 3, 2008 at 11:11 AM, Buckaroo Mu wrote: > What progress is there toward an improved > caching mechanism? Is there a way to store the textures in a decoded, > ready-to-use fashion? Why is the cache so slow? The cache isn't exceptionally slow - it's the jpeg2000 decode that really bites here, and storing those decoded would use copious amounts of disk space. The quickest win would be multiple image decoding threads, seeing as most PCs have two or more cores. No idea if anyone's touching that in the near future, though. From lists at hippygeek.co.uk Tue Jun 3 09:36:56 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Tue Jun 3 09:37:34 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48447D74.2050704@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> Message-ID: <48457328.6070009@hippygeek.co.uk> Mike Monkowski wrote: > Why? What advantage is there to sharing builds or avatar meshes > across different platforms? Are they worth the effort? My answer is a resounding yes! The sharing of assets between different 3D worlds is a crucial part of my personal vision of a 3D web. I should add the disclaimer here that I enter this discussion from a background in web technology rather than gaming engines and have quite different views of some architectural points than is perhaps the norm on this list. I can not see how inter-operable 3D worlds can even consider not having avatars which can travel between worlds and objects which the avatar can take with them. Yes, new security models are necessary (you don't want spammers turning up to your peaceful scene brandishing huge billboards), but that is just one of the challenges ahead. The idea of a consistent avatar in principle is similar to the images people can associate with their name in a discussion forum on the web. Interoperability for me would be anyone being able to create a 3D scene in the same way that anyone can create a web page, anyone being able to run a chat server in the same way that anyone can run a Jabber server or IRC server. It would be wandering between 3D scenes in the same way that people browse the web. In terms of business models - why not 3D representations of online stores, advertising in virtual spaces... in short the same business models that surround the web. But really I'm not sure that business models have a great deal to do with creating technology standards. The W3C doesn't tell you how to make money on the web, it tells you how to make a standards compliant web site that everyone can use and will work with the rest of the web. I think any attempt at building business values into technical standards will result in a collection of walled gardens with a frustratingly inconsistent user experience, and never reach the full commercial potential that we've seen with the World Wide Web. Sticking with my 3D Web example, an avatar is just an X3D resource which can be served from a web server and included into a X3D scene in the same way that an HTML resource can be embedded in an iframe in a web page. That's my point of view, from a web perspective, of interoperability. -- Ben Francis http://tola.me.uk From sldev at bitparts.org Tue Jun 3 09:54:13 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 09:54:27 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <48457735.9060900@bitparts.org> Soft wrote: > On Tue, Jun 3, 2008 at 11:11 AM, Buckaroo Mu wrote: > >> What progress is there toward an improved >> caching mechanism? Is there a way to store the textures in a decoded, >> ready-to-use fashion? Why is the cache so slow? >> > > The cache isn't exceptionally slow - it's the jpeg2000 decode that > really bites here, and storing those decoded would use copious amounts > of disk space. The quickest win would be multiple image decoding > threads, seeing as most PCs have two or more cores. No idea if > anyone's touching that in the near future, though. > > Given the dirt-cheap price of HD space these days, why bother compressing the cache, given that the decode is so expensive time-wise? Enlarge the cache maximum size, and toss out the compression - at least give us an option to try it, and see. A simple checkbox or debug option "UseCompressedCache" or somesuch defaulted to yes - then those of us with plenty of space can try it out. People are screaming about texture load times - I can't imagine they wouldn't sacrifice some disk space for a large boost in performance. From danteferret at gmail.com Tue Jun 3 10:03:14 2008 From: danteferret at gmail.com (Dante Tucker) Date: Tue Jun 3 10:03:16 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457735.9060900@bitparts.org> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> Message-ID: <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> I definatly second this as an option. Provided there is no technical reason this can't be done :) On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu wrote: > > > Given the dirt-cheap price of HD space these days, why bother compressing > the cache, given that the decode is so expensive time-wise? Enlarge the > cache maximum size, and toss out the compression - at least give us an > option to try it, and see. A simple checkbox or debug option > "UseCompressedCache" or somesuch defaulted to yes - then those of us with > plenty of space can try it out. People are screaming about texture load > times - I can't imagine they wouldn't sacrifice some disk space for a large > boost in performance. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/59e37d3b/attachment.htm From tateru.nino at gmail.com Tue Jun 3 10:08:43 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 10:09:23 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> Message-ID: <48457A9B.1010704@weblogsinc.com> Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From robin.cornelius at gmail.com Tue Jun 3 10:10:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 10:10:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48456D49.5020105@bitparts.org> References: <48456D49.5020105@bitparts.org> Message-ID: > > The result? Even after loading everything in the sim into the cache, tping > between two locations (in the same sim, but outside of draw distance from > each other) resulted in ZERO perceptible texture loading speedup. Loading > from the RAMDisk was as slow as loading from regular disk. I presume, > therefor, that the real bottleneck in the cache isn't reading from the > drive. This is horribly dismaying. What progress is there toward an improved > caching mechanism? Is there a way to store the textures in a decoded, > ready-to-use fashion? Why is the cache so slow? > Are you *sure* all textures are indeed being loaded from the cache and not being requested from the servers. I noticed some excessively large texture downloading when doing textures tests and i would have expected many of them to be in the cache but they were not (or may be they had just been culled/purged). I didn't do a lot of testing specifically in this area but the texture console can help also adding debug lines to lltexturefetch.cpp is probably a good check too to see which textures take which path. Robin From robin.cornelius at gmail.com Tue Jun 3 10:15:02 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 10:15:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457A9B.1010704@weblogsinc.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: On Tue, Jun 3, 2008 at 6:08 PM, Tateru Nino wrote: > Use a PNG or vanilla jpg compressor to save space on disk (and let the user > set the compression quality with a slider to let them decide how much > bang-for-the-buck they want out of their chosen megabytes of storage), then > you've got far less work to do decoding than the jpeg2000 decompressor -- or > so I presume. If I got all that fatally wrong, just whack me with a rolled > up man page. Format must be capable of saving alpha channels as well. i don't believe standard jpeg does this. You also have the overhead of an additional encoding which may only be done once, but if you are flicking around would be come a headache and would just get turned off. Also re encoding, need to be careful if it was lossless image, especially sculpties or they will just turn to **** with compression artifacts. Most (processor) efficient way to save files is to just save the LLRawImage data as it is, then it can be directly recalled into a new LLRawImage when its recalled. This should maximize speed and disk space usage at the same time ;-) Robin From sldev at bitparts.org Tue Jun 3 10:28:42 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 10:28:52 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <48457F4A.4060508@bitparts.org> Robin Cornelius wrote: > Are you *sure* all textures are indeed being loaded from the cache and > not being requested from the servers. I noticed some excessively large > texture downloading when doing textures tests and i would have > expected many of them to be in the cache but they were not (or may be > they had just been culled/purged). I didn't do a lot of testing > specifically in this area but the texture console can help also adding > debug lines to lltexturefetch.cpp is probably a good check too to see > which textures take which path. > > Robin > > Positive. Waited until everything had fully rezzed, turned slowly & repeated the process - etc. Stayed in one area about 30 minutes. Tped (actually warpPos'ed) to another area of the sim, then came right back - and texture loading was a slow as disk-based cache. Various other methods of testing backed up these results. From monkowsk at watson.ibm.com Tue Jun 3 10:48:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 10:49:47 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484568B8.8010705@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> Message-ID: <484583F1.9020505@watson.ibm.com> Kelly Linden wrote: > In short these [WoW / EQ / AoC] are not "virtual worlds", they are MMO stories or MMO > games but not virtual worlds. The people who don't want to be an Elf > etc don't want to play WoW. Effort on interoperability should be > focused on the products (potential and existing) that would actually > want it. I'm not a supply-sider so that fact that Sony or Blizzard don't "actually want it" doesn't seem like a useful predictor of the future. Would you consider Little Big Planet to be a MMO game or a virtual world? The pigeonholes are changing. Mike From sean at lindenlab.com Tue Jun 3 11:10:37 2008 From: sean at lindenlab.com (Sean Lynch) Date: Tue Jun 3 11:10:39 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> On Tue, Jun 3, 2008 at 10:15 AM, Robin Cornelius wrote: > Format must be capable of saving alpha channels as well. i don't > believe standard jpeg does this. You also have the overhead of an > additional encoding which may only be done once, but if you are > flicking around would be come a headache and would just get turned > off. Also re encoding, need to be careful if it was lossless image, > especially sculpties or they will just turn to **** with compression > artifacts. > > Most (processor) efficient way to save files is to just save the > LLRawImage data as it is, then it can be directly recalled into a new > LLRawImage when its recalled. This should maximize speed and disk > space usage at the same time ;-) > I suspect PNG with a zlib compression level of 1-3 would be faster overall due to saving the time to read the data off the disk. Of course, the compression level only affects compression speed. Perhaps it's time to revisit the format textures are stored in on the asset system. Or maybe we'll do that after allowing externally hosted HTTP textures. I believe the main advantages of jpeg2000 are the less distressing artifacts for high compression and the ability to decode progressively without looking like crap during the download. High compression factor, as people have mentioned, is pretty irrelevant, so progressive jpeg with a 75-90% quality level and some postprocessing might be just as good with far less CPU usage? I thought we already had a separate texture decoding thread; isn't that what "enable multiple threads" does in the advanced menu? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/2cd81264/attachment.htm From monkowsk at watson.ibm.com Tue Jun 3 11:10:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 3 11:17:02 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48457328.6070009@hippygeek.co.uk> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> Message-ID: <48458901.8030002@watson.ibm.com> I cringe every time I hear 3D virtual worlds discussed as "The 3D Web." The 2D web is primarily static, one directional, and lonely. Yes, there are chat rooms, MySpace, and blogs--the Web 2.0 stuff--but when you're talking about "3D representations of online stores, advertising in virtual spaces... in short the same business models that surround the web" you're not talking about communication and collaboration, you're still talking about marketing. If you call it Web 3.0, then I might give you the benefit of the doubt, but if you're still talking about "The 3D Web," I don't think you understand virtual worlds. "The Web" is about providing. Virtual worlds are about collaborating. Mike Ben Francis wrote: > My answer is a resounding yes! The sharing of assets between different > 3D worlds is a crucial part of my personal vision of a 3D web. I should > add the disclaimer here that I enter this discussion from a background > in web technology rather than gaming engines and have quite different > views of some architectural points than is perhaps the norm on this list. > > I can not see how inter-operable 3D worlds can even consider not having > avatars which can travel between worlds and objects which the avatar can > take with them. Yes, new security models are necessary (you don't want > spammers turning up to your peaceful scene brandishing huge billboards), > but that is just one of the challenges ahead. > > The idea of a consistent avatar in principle is similar to the images > people can associate with their name in a discussion forum on the web. > > Interoperability for me would be anyone being able to create a 3D scene > in the same way that anyone can create a web page, anyone being able to > run a chat server in the same way that anyone can run a Jabber server or > IRC server. It would be wandering between 3D scenes in the same way that > people browse the web. > > In terms of business models - why not 3D representations of online > stores, advertising in virtual spaces... in short the same business > models that surround the web. But really I'm not sure that business > models have a great deal to do with creating technology standards. The > W3C doesn't tell you how to make money on the web, it tells you how to > make a standards compliant web site that everyone can use and will work > with the rest of the web. I think any attempt at building business > values into technical standards will result in a collection of walled > gardens with a frustratingly inconsistent user experience, and never > reach the full commercial potential that we've seen with the World Wide > Web. > > Sticking with my 3D Web example, an avatar is just an X3D resource which > can be served from a web server and included into a X3D scene in the > same way that an HTML resource can be embedded in an iframe in a web page. > > That's my point of view, from a web perspective, of interoperability. > From kelly at lindenlab.com Tue Jun 3 11:19:09 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Jun 3 11:19:10 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484583F1.9020505@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> Message-ID: <48458B1D.8030502@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/6cd345b1/attachment.htm From mark.burhop at gmail.com Tue Jun 3 12:22:51 2008 From: mark.burhop at gmail.com (Mark Burhop) Date: Tue Jun 3 12:22:56 2008 Subject: [sldev] Re: UC presentation on Importing Geometry into SL In-Reply-To: <773a33dc0805291459m4902844ao6c2d77f19b8da38@mail.gmail.com> References: <773a33dc0805291459m4902844ao6c2d77f19b8da38@mail.gmail.com> Message-ID: <773a33dc0806031222m49b67936j1199ee51c9bedf31@mail.gmail.com> FYI - happening now. On Thu, May 29, 2008 at 5:59 PM, Mark Burhop wrote: > I wanted to let you know the University of Cincinnati will be doing a > presentation from Orlando next week on importing geometry into Second Life. > Siemens has a conference there and have sponsored some of their work. > > > > The presentation will be done in Second Life from 4:30 to 5:30 EST (1:30 > SLT) Tue 6/3/2008 so just click on the SLURL below: > > > http://slurl.com/secondlife/Siemens%20innovation%20Connection/168/157/22/ > > As a side note, I know there are a lot of people running into the > limitations of prims, sculpties, and prim counts for bringing in data from > their favorite 3D tool. I'd love to hear more discussion and idea sharing > on the general problem. > > Mark (Burhop Piccard) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/5bfb7089/attachment.htm From carjay at gmx.net Tue Jun 3 12:40:05 2008 From: carjay at gmx.net (Carsten Juttner) Date: Tue Jun 3 12:40:13 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <3736d47a0806031110h397d1896g7d12b47564ec4012@mail.gmail.com> Message-ID: <48459E15.1020503@gmx.net> Sean Lynch wrote: > > I thought we already had a separate texture decoding thread; isn't > that what "enable multiple threads" does in the advanced menu? I looked at that code a while ago, from what I saw threads are always enabled (but note that not every "thread" that is derived from one of the thread classes is actually run threaded. The place to look at here is initThreads() in llappviewer.cpp. So if I see this correctly, texture decoding and texture caching thread are currently run threaded, only the texture fetching is not. As for the advanced switch "Run Multiple Threads": if it is enabled, the texture decoding and caching threads are run in parallel with rendering, else they are put to sleep right before (but they are not frozen so I guess depending on the workload it's possible that one of them extends into the begin of rendering which is probably the cause for VWR-4067 since it occured in a debug build where things naturally run a bit slower). Also if MEM_TRACK is defined, threading is disabled (all "threads" run in the main thread in this case). Carsten From sldev at bitparts.org Tue Jun 3 13:01:33 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 13:01:44 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: <4845A31D.10002@bitparts.org> > Most (processor) efficient way to save files is to just save the > LLRawImage data as it is, then it can be directly recalled into a new > LLRawImage when its recalled. This should maximize speed and disk > space usage at the same time ;-) > This is my thought. If I want to compress the cache, I'll tell Windows to compress that folder - no, not seriously. I have something on the order of 100gb free on my main storage drive - I'd be more than willing to commit 10g of that to SL cache, and storing the objects as flat-out decompressed ready-to-use (llRawImage?) data would be the logical thing to do. From missannotoole at yahoo.com Tue Jun 3 15:26:12 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 3 15:26:15 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <617974.16404.qm@web59110.mail.re1.yahoo.com> Time Warner is going to try forcing metered bandwith on the cable modem community they serve. So the ugly head of the end of unlimited bandwith use raises it's head once again. (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) Has anyone measured actual bandwith utilization to the point people can predict their usage per month before they get slapped with killer bills? The reason I mention this is because, although I am also a fan of reduced compression overhead, there will no doubt be trade offs required. Perhaps there is a way to make compression/decompression more efficient? ----- Original Message ---- From: Tateru Nino To: Dante Tucker Cc: Second Life Developer Mailing List Sent: Tuesday, June 3, 2008 1:08:43 PM Subject: Re: [sldev] Cache speed experiment & results... Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/49b29f7c/attachment.htm From dmahalko at gmail.com Tue Jun 3 15:59:40 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 15:59:43 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845A31D.10002@bitparts.org> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: The price of huge storage capacities has fallen like a stone in the past two years. It seems crazy that I should be able to buy a 250 gig 7200 RPM SATA-3.0 hard drive for US$58 on NewEgg. I do wonder if the drive manufacturers are looking over their shoulder and fearing the arrival of solid state drives. Therefore, I would be in favor of storing uncompressed cache data for all cache types, including sound files, and without a defined storage limit. Even a 10 gig cache seems far too small. Just as LL raises the bar with WindLight for higher performance 3D cards, it should also raise the bar for performance increases via huge uncompressed caches. SL wants 10 gig for basic performance, and optionally, 100 gig for enhanced performance? Well, sure, I suppose I can handle that. There are however filesystem limitations that may cause slowdowns, and there may be diminishing returns at some point if only the local OS is relied upon for huge caching storage. I would be interested to see what performance gain is possible by have a dedicated slave MySQL database running on the client PC when using a ridiculously huge cache size.. Windows isn't good at dealing with directories containing tens of thousands of files. Ever tried opening a folder containing 20,000 files? There is a delay of several seconds trying to do this in Windows. Also the hidden MFT and directory structures can become ridiculously fragmented, also leading to slowdowns. A proper local database engine would likely deal with these huge numbers of tiny files more efficiently than the local operating system. An alternative would be to leave a large portion of system memory free to cache these huge directory structures alongside the client, say 2-4 gig of memory free, over and above what the client is using. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 3:01 PM, Buckaroo Mu wrote: > This is my thought. If I want to compress the cache, I'll tell Windows to > compress that folder - no, not seriously. I have something on the order of > 100gb free on my main storage drive - I'd be more than willing to commit 10g > of that to SL cache, and storing the objects as flat-out decompressed > ready-to-use (llRawImage?) data would be the logical thing to do. From robin.cornelius at gmail.com Tue Jun 3 16:13:34 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jun 3 16:13:40 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <4845D01E.5070309@gmail.com> Dale Mahalko wrote: > > There are however filesystem limitations that may cause slowdowns, and > there may be diminishing returns at some point if only the local OS is > relied upon for huge caching storage. I would be interested to see > what performance gain is possible by have a dedicated slave MySQL > database running on the client PC when using a ridiculously huge cache > size.. From what figures i have seen from random googling file system should still be significantly quicker access than via MySQL. I started hacking in a mysql read/write for the cache, just for the hell of it but fully expect it to be slower than the cache and its on the big stack of things to do. > > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. Yes this is an issue where the DB's could achieve better performance. Or possibly caches such as squid although how that could directly be used with the current set up is not obvious to me. Linux has optimisation options if you know a FS will be used for lots of files Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/b3cbbc54/signature-0001.pgp From tongb at ohio.edu Tue Jun 3 17:01:09 2008 From: tongb at ohio.edu (Bruce Tong) Date: Tue Jun 3 17:01:12 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> I'm pulling down the .zip files containing the source to a Windows box and I don't find the develop.py script. I don't see it in the TAR balls on my Linux box either, though I pulled them down last week. I'm guessing the CMake support is something I'm only going to find pulling source from SVN right now, or am I just blind? I've looked around the source folders and re-read a dozen wiki pages and I must be missing something. On Tue, Jun 3, 2008 at 10:55 AM, Soft wrote: >>>> I'm pleased to announce that our release (aka "trunk") branch is now >>>> built using CMake on all platforms. >>> >>> I don't see it. Trunk doesn't seem to have it. >> >> I have not seen any SVN commits in the last few days so i presume >> thats internally and i assume it will sync up when soft does the >> weekly sync. But any chance of getting a sync earlier so i can rattle >> through some tests again? > > I've pushed the current source - have a look at release/. I'm > iterating over some Mac cmake export issues right now and installing > VS2008 to see how the export fares there. I'll push another today with > the things I know about resolved. > > Please speak up as you find issues with Linux or other Windows build > platforms. The cmake release merge marks the point where we -do- start > paying close attention to VS2005 and VS2008 builds as well, so if > you've been holding back... -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Tue Jun 3 17:09:27 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 17:09:34 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <4f335a50806031701x609b03eanb112b46ea5f651e8@mail.gmail.com> Message-ID: You'd need to pull from subversion, or you can download the tarballs/zip files linked from a message in the sldev-commits mailing list. The most recent release commit is here: https://lists.secondlife.com/pipermail/sldev-commits/2008-June/000858.html On Tue, Jun 3, 2008 at 7:01 PM, Bruce Tong wrote: > I'm pulling down the .zip files containing the source to a Windows box > and I don't find the develop.py script. I don't see it in the TAR > balls on my Linux box either, though I pulled them down last week. > > I'm guessing the CMake support is something I'm only going to find > pulling source from SVN right now, or am I just blind? I've looked > around the source folders and re-read a dozen wiki pages and I must be > missing something. > > On Tue, Jun 3, 2008 at 10:55 AM, Soft wrote: >>>>> I'm pleased to announce that our release (aka "trunk") branch is now >>>>> built using CMake on all platforms. >>>> >>>> I don't see it. Trunk doesn't seem to have it. >>> >>> I have not seen any SVN commits in the last few days so i presume >>> thats internally and i assume it will sync up when soft does the >>> weekly sync. But any chance of getting a sync earlier so i can rattle >>> through some tests again? >> >> I've pushed the current source - have a look at release/. I'm >> iterating over some Mac cmake export issues right now and installing >> VS2008 to see how the export fares there. I'll push another today with >> the things I know about resolved. >> >> Please speak up as you find issues with Linux or other Windows build >> platforms. The cmake release merge marks the point where we -do- start >> paying close attention to VS2005 and VS2008 builds as well, so if >> you've been holding back... > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > From kfa at gmx.net Tue Jun 3 17:12:00 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 3 17:12:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <4845DDD0.70305@gmx.net> Dale Mahalko wrote: > ... > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > Reiser4 is excellent with exactly these requirements. It's not mature enough to be considered reliable for critical systems, but for a cache? It doesn't help that Reiser himself is removed from the development process, but it's still there and the source available. Shouldn't that be possible to be included as a virtual filesystem even under Windows? I also always thought it must be a good way to boost performance if the cache lived on its own partition, like a Linux swap partition. For the Linux version of SL this would even sound like the most natural way to do it. Setting such a thing up on an existing Windows machine has a slight fear factor attached and is not for everyone, but if a savvy user can handle it, why not offer. I'm speculating, but the difference could be dramatic, especially if we had a better file system than NTFS on that partition. > > A proper local database engine would likely deal with these huge > numbers of tiny files more efficiently than the local operating > system. Yes, but the usual architecture with the database running as a localhost server is not ideal for our situation since everything is squeezed back and forth through the network system, plus SQL parsing, unnecessarily. With MySQL you could build directly on top of the storage engine though, even bypassing the parsing with direct API calls. It would just serve as a virtual file system the same way as suggested above. I still believe that Reiser4 would be even faster. And according to the description on its (now defunct) website, they claimed reaching 94% package density with small files. Felix From open at autistici.org Tue Jun 3 17:15:55 2008 From: open at autistici.org (Opensource Obscure) Date: Tue Jun 3 17:15:58 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> Message-ID: <9d9cb078fe67b0a06978abad84317d50@localhost> On Tue, 3 Jun 2008 09:55:44 -0500, Soft wrote: > Please speak up as you find issues with Linux or other Windows build > platforms. I'm new to this, please be patient. I'm on Linux Ubuntu 8.04 32bit and I managed to build the viewer some weeks ago on the same system. I'm using the tarballs at http://svn.secondlife.com/trac/linden/changeset/598 Here's what I did: tar xzf slviewer-linux-libs-... tar xzf slviewer-src-... unzip slviewer-artwork-... tar xzf fmodapi375linux.tar.gz cp fmodapi375linux/api/inc/* linden/libraries/i686-linux/include/ cp fmodapi375linux/api/libfmod-3.75.so linden/libraries/i686-linux/lib_release_client/ cd linden/indra/ ./develop.py cd viewer-linux-i686/ make I got errors as descripted in VWR-4456, so I modified indra/cmake/00-Common.cmake according to Michelle2 Zenovka's patch. I also had to install libboost-program-options-dev. If I get it right, the issue with libboost is known, however this library is not directly mentioned at the wiki page https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) Should I add it as a dependency somewhere in that page? At the next try, I got this: [100%] Built target secondlife-bin [100%] Generating ../../newview/secondlife-stripped-globalsyms [100%] Generating ../../newview/secondlife-stripped [100%] Generating ../../newview/SecondLife-i686-1.20.6.0.tar.bz2 File ".../linden/indra/newview/viewer_manifest.py", line 230 def nsi_file_commands(self, install=True): ^ SyntaxError: invalid syntax make[2]: *** [../newview/SecondLife-i686-1.20.6.0.tar.bz2] Error 1 make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 make: *** [all] Error 2 hope this helps. Opensource Obscure http://friendfeed.com/oobscure From steve at lindenlab.com Tue Jun 3 17:17:35 2008 From: steve at lindenlab.com (Steve Bennetts (Steve Linden)) Date: Tue Jun 3 17:17:37 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: <4845DF1F.6060007@lindenlab.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080603/77939afa/signature.pgp From dahliatrimble at gmail.com Tue Jun 3 17:45:06 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 3 17:45:08 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845DDD0.70305@gmx.net> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: If the goal were to improve seek time in a cache, how about keeping the cache on one of those readyboost-capable usb flash drives? They can have seek times as low as 1 ms or better, although the transfer rate and write times arent all that fast. Then again it's probably moot if the bottleneck is the decoding :/ On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: > Dale Mahalko wrote: > >> ... >> Windows isn't good at dealing with directories containing tens of >> thousands of files. Ever tried opening a folder containing 20,000 >> files? There is a delay of several seconds trying to do this in >> Windows. Also the hidden MFT and directory structures can become >> ridiculously fragmented, also leading to slowdowns. >> >> > Reiser4 is excellent with exactly these requirements. It's not mature > enough to be considered reliable for critical systems, but for a cache? It > doesn't help that Reiser himself is removed from the development process, > but it's still there and the source available. Shouldn't that be possible to > be included as a virtual filesystem even under Windows? > > I also always thought it must be a good way to boost performance if the > cache lived on its own partition, like a Linux swap partition. For the Linux > version of SL this would even sound like the most natural way to do it. > Setting such a thing up on an existing Windows machine has a slight fear > factor attached and is not for everyone, but if a savvy user can handle it, > why not offer. I'm speculating, but the difference could be dramatic, > especially if we had a better file system than NTFS on that partition. > > > > > A proper local database engine would likely deal with these huge > > numbers of tiny files more efficiently than the local operating > > system. > > Yes, but the usual architecture with the database running as a localhost > server is not ideal for our situation since everything is squeezed back and > forth through the network system, plus SQL parsing, unnecessarily. With > MySQL you could build directly on top of the storage engine though, even > bypassing the parsing with direct API calls. It would just serve as a > virtual file system the same way as suggested above. I still believe that > Reiser4 would be even faster. And according to the description on its (now > defunct) website, they claimed reaching 94% package density with small > files. > > Felix > > _______________________________________________ > 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/20080603/98809374/attachment-0001.htm From lists at hippygeek.co.uk Tue Jun 3 17:49:43 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Tue Jun 3 17:50:18 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48458901.8030002@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> <48458901.8030002@watson.ibm.com> Message-ID: <4845E6A7.4070105@hippygeek.co.uk> Mike Monkowski wrote: > I cringe every time I hear 3D virtual worlds discussed as "The 3D Web." The 3D Web is one method of delivering 3D scenes over a network and is a term used by the Web3D Consortium who define standards to do just that. I do not intend to use the terms "3D Web" and "Virtual Worlds" interchangeably. The 3D web is just one approach which in combination with other Internet standards (for authentication, instant messaging, currency etc.) can be used to create virtual worlds. That's what my disclaimer was for. > The 2D web is primarily static, one directional, and lonely. I would not describe the web applications I use every day with any of those words. > Yes, there are chat rooms, MySpace, and blogs--the Web 2.0 stuff-- Web 2.0 = Web 1.0 > but when you're talking about "3D representations of online stores, > advertising in virtual spaces... in short the same business models > that surround the web" you're not talking about communication and > collaboration, you're still talking about marketing. My point really was that the business models are in the applications, not the platform. Perhaps the examples I gave weren't very imaginative, but that's because I think we're discussing architectures, not business plans here. > > If you call it Web 3.0, then I might give you the benefit of the > doubt, but if you're still talking about "The 3D Web," I don't think > you understand virtual worlds. I'm sorry, but as far as I'm concerned web 3.0 is as much of a ridiculous term as web 2.0. The web is the web, it is continuously evolving and I believe is only currently in its early stages. The kind of things people refer to as "Web 2.0" are simply realizing the read/write nature originally intended by Sir Tim Berners-Lee (see his book, Weaving the Web). The term 3D Web describes quite precisely what it is I'm talking about. XML served over HTTP (or alternative asynchronous protocols) which represents web resources as 3D graphics. > "The Web" is about providing. Virtual worlds are about collaborating. I would argue that the web is an information space and virtual worlds are one way of representing that information. Collaboration can happen in many ways. If you want to call the new web standards that the W3C is currently working on "Web 3.0" then fair enough. But they are certainly more than just delivering static text in one direction, they are about device independent, distributed applications with a focus on collaboration and multimodal user interfaces to semantically rich data - The 3D Web is part of the web of the future. Anyway, in defending my semantics I have strayed off the original point. The point is that assets should be able to move between virtual worlds and this should be built in as standard from the start, not using a never ending list of import/export scripts in the future. MMORPGs are one use (for entertainment) of virtual worlds which may require certain stylistic restrictions on content, but this does not mean that other applications (perhaps the majority) would not want to be able to freely move assets between 3D scenes. Apologies for being long winded! Regards Ben -- Ben Francis http://tola.me.uk From soft at lindenlab.com Tue Jun 3 17:53:30 2008 From: soft at lindenlab.com (Soft) Date: Tue Jun 3 17:53:33 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <61a5f47b10aafc4ff71eb929813bd563@localhost> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> Message-ID: On Tue, Jun 3, 2008 at 7:13 PM, Opensource Obscure wrote: > > I also had to install libboost-program-options-dev. If I get it > right, the issue with libboost is known, however this library is > not directly mentioned at the wiki page > https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) > Should I add it as a dependency somewhere in that page? Please do. All of the compiling pages are going to need an overhaul, but that can wait for the 1.21 viewer branch, after cmake has completely settled in. > At the next try, I got this: > > [100%] Built target secondlife-bin > [100%] Generating ../../newview/secondlife-stripped-globalsyms > [100%] Generating ../../newview/secondlife-stripped > [100%] Generating ../../newview/SecondLife-i686-1.20.6.0.tar.bz2 > File ".../linden/indra/newview/viewer_manifest.py", line 230 > def nsi_file_commands(self, install=True): > ^ > SyntaxError: invalid syntax > make[2]: *** [../newview/SecondLife-i686-1.20.6.0.tar.bz2] Error 1 > make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 > make: *** [all] Error 2 That's been fixed in a subsequent release dump. Try grabbing the newest and I suspect you'll make it clean through. From dmahalko at gmail.com Tue Jun 3 18:10:13 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 18:10:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: I do apologize, but it appears I'm conflating two different caching problems. The one I'm thinking about involves enlarging the number of individual files in the cache by 10 to 100 times. This leads to file search and directory caching problems, and might need a separate partition or DB management engine to handle hundreds of thousands of locally cached files. An optional fully-decoded cache likely would not run into these problems, since it would end up being a second but identical directory structure equal to the current one, except containing all-uncompressed data. A 2x increase in directory structure size probably would not significantly change the file lookup performance.. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 7:45 PM, Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping the > cache on one of those readyboost-capable usb flash drives? They can have > seek times as low as 1 ms or better, although the transfer rate and write > times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ From sakkaku at gmail.com Tue Jun 3 18:11:54 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue Jun 3 18:11:57 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping the > cache on one of those readyboost-capable usb flash drives? They can have > seek times as low as 1 ms or better, although the transfer rate and write > times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > > On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: >> >> Dale Mahalko wrote: >>> >>> ... >>> Windows isn't good at dealing with directories containing tens of >>> thousands of files. Ever tried opening a folder containing 20,000 >>> files? There is a delay of several seconds trying to do this in >>> Windows. Also the hidden MFT and directory structures can become >>> ridiculously fragmented, also leading to slowdowns. >>> >> >> Reiser4 is excellent with exactly these requirements. It's not mature >> enough to be considered reliable for critical systems, but for a cache? It >> doesn't help that Reiser himself is removed from the development process, >> but it's still there and the source available. Shouldn't that be possible to >> be included as a virtual filesystem even under Windows? >> >> I also always thought it must be a good way to boost performance if the >> cache lived on its own partition, like a Linux swap partition. For the Linux >> version of SL this would even sound like the most natural way to do it. >> Setting such a thing up on an existing Windows machine has a slight fear >> factor attached and is not for everyone, but if a savvy user can handle it, >> why not offer. I'm speculating, but the difference could be dramatic, >> especially if we had a better file system than NTFS on that partition. >> >> > >> > A proper local database engine would likely deal with these huge >> > numbers of tiny files more efficiently than the local operating >> > system. >> >> Yes, but the usual architecture with the database running as a localhost >> server is not ideal for our situation since everything is squeezed back and >> forth through the network system, plus SQL parsing, unnecessarily. With >> MySQL you could build directly on top of the storage engine though, even >> bypassing the parsing with direct API calls. It would just serve as a >> virtual file system the same way as suggested above. I still believe that >> Reiser4 would be even faster. And according to the description on its (now >> defunct) website, they claimed reaching 94% package density with small >> files. >> >> Felix SQLite in a single user environment is incredibly fast so long as you don't let the database grow too large. Of course you have to figure out how efficiently textures can be stored and retrieved in SQL compared to the current caching system. On a side note: Does anyone know where it defines the polygon meshes for rendering cubes. I really want to try forcing untwisted, un-holed cubes down to 1-2 polygons per side and see if that will help out with the frame rate. I tried looking through the source but it is lacking in [helpful] comments. From lenglish5 at cox.net Tue Jun 3 19:04:09 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 3 19:04:11 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4845E6A7.4070105@hippygeek.co.uk> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <48445F4C.8050305@cox.net> <48447D74.2050704@watson.ibm.com> <48457328.6070009@hippygeek.co.uk> <48458901.8030002@watson.ibm.com> <4845E6A7.4070105@hippygeek.co.uk> Message-ID: <4845F819.4020708@cox.net> Ben Francis wrote: > [...] > > Anyway, in defending my semantics I have strayed off the original point. > > The point is that assets should be able to move between virtual worlds > and this should be built in as standard from the start, not using a > never ending list of import/export scripts in the future. > > MMORPGs are one use (for entertainment) of virtual worlds which may > require certain stylistic restrictions on content, but this does not > mean that other applications (perhaps the majority) would not want to > be able to freely move assets between 3D scenes. > > Apologies for being long winded! There are topics that the AW Groupies deal with regularly in group IM, and in the weekly meetings at Thornbridgetown and Zero Linden's office in Grasmere. From the way you discuss things, I get the impression you're not participating in either the theoretical discussions or in their practical implementation via the OGP (AKA SLOGP). Can it be that you're not familiar with them? Lawson https://wiki.secondlife.com/wiki/Category:AW_Groupies#Chat_Logs http://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 From secret.argent at gmail.com Tue Jun 3 19:17:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:15:55 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48453828.50503@gmx.net> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <48453828.50503@gmx.net> Message-ID: On 2008-06-03, at 07:25, Felix Duesenburg wrote: > My guess is that this will be a task of the magnitude of creating a > standard for videotape or disk formats. You think it's that simple? that's encouraging! :) From nexeus at nexeusfatale.com Tue Jun 3 19:23:12 2008 From: nexeus at nexeusfatale.com (Nexeus Fatale) Date: Tue Jun 3 19:23:16 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> Message-ID: I wonder if anyone has tested the run multiple threads and have found any improvements - Nexeus On Tue, Jun 3, 2008 at 9:11 PM, Matthew Underwood wrote: > On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: >> If the goal were to improve seek time in a cache, how about keeping the >> cache on one of those readyboost-capable usb flash drives? They can have >> seek times as low as 1 ms or better, although the transfer rate and write >> times arent all that fast. >> >> Then again it's probably moot if the bottleneck is the decoding :/ >> >> On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: >>> >>> Dale Mahalko wrote: >>>> >>>> ... >>>> Windows isn't good at dealing with directories containing tens of >>>> thousands of files. Ever tried opening a folder containing 20,000 >>>> files? There is a delay of several seconds trying to do this in >>>> Windows. Also the hidden MFT and directory structures can become >>>> ridiculously fragmented, also leading to slowdowns. >>>> >>> >>> Reiser4 is excellent with exactly these requirements. It's not mature >>> enough to be considered reliable for critical systems, but for a cache? It >>> doesn't help that Reiser himself is removed from the development process, >>> but it's still there and the source available. Shouldn't that be possible to >>> be included as a virtual filesystem even under Windows? >>> >>> I also always thought it must be a good way to boost performance if the >>> cache lived on its own partition, like a Linux swap partition. For the Linux >>> version of SL this would even sound like the most natural way to do it. >>> Setting such a thing up on an existing Windows machine has a slight fear >>> factor attached and is not for everyone, but if a savvy user can handle it, >>> why not offer. I'm speculating, but the difference could be dramatic, >>> especially if we had a better file system than NTFS on that partition. >>> >>> > >>> > A proper local database engine would likely deal with these huge >>> > numbers of tiny files more efficiently than the local operating >>> > system. >>> >>> Yes, but the usual architecture with the database running as a localhost >>> server is not ideal for our situation since everything is squeezed back and >>> forth through the network system, plus SQL parsing, unnecessarily. With >>> MySQL you could build directly on top of the storage engine though, even >>> bypassing the parsing with direct API calls. It would just serve as a >>> virtual file system the same way as suggested above. I still believe that >>> Reiser4 would be even faster. And according to the description on its (now >>> defunct) website, they claimed reaching 94% package density with small >>> files. >>> >>> Felix > > SQLite in a single user environment is incredibly fast so long as you > don't let the database grow too large. Of course you have to figure > out how efficiently textures can be stored and retrieved in SQL > compared to the current caching system. > > On a side note: Does anyone know where it defines the polygon meshes > for rendering cubes. I really want to try forcing untwisted, un-holed > cubes down to 1-2 polygons per side and see if that will help out with > the frame rate. I tried looking through the source but it is lacking > in [helpful] comments. > _______________________________________________ > 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 Jun 3 19:34:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:33:06 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <484568B8.8010705@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> Message-ID: <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> On 2008-06-03, at 10:52, Kelly Linden wrote: > Argent Stonecutter wrote: >> On 2008-06-03, at 03:34, Felix Duesenburg wrote: >>> And, even before that, what's the business advantage for the >>> respective companies running those worlds? >> >> Getting people who would have absolutely no interest in visiting >> WoW as an elf or a thinly disguised hobbit to play the game? >> People willing to pay a premium to have a custom avatar, but not >> willing to pay a penny to be a dark elf no matter how fantastic a >> costume Sony or Blizzard or whoever come up for it? > I do not think Sony or Blizzard would want that. And that's probably a good thing. For Linden Labs, anyway. :) But that doesn't mean there's no companies that do... good golly, I can think of at least one example. > It is not reasonable to ever expect this sort of product to even > desire content exchange with other virtual worlds Maybe. Maybe not. D&D was designed to appeal to people who wanted to play elves and hobbits and things, and pretty soon people started coming up with other kinds of fantasy settings, and TSR came up with SF-based games, and then Steve Jackson came up with GURPS... the Grand Universal Role Playing System, and pretty soon everyone, including whoever owns D&D this week, had a "universal role playing system" ... I think the newest iteration of D&D is the D20 universal role playing system. As virtual role playing environments evolve, people playing in the equivalent of Gamma World and Champions and D&D and Runequest and Car Wars are going to eventually want to get together, as their avatars. You're going to have the online equivalents of Munden's Bar, where all the metaverses come together. And you're going to have role playing scenarios played out in the Gallimaufry, or whatever this universal nexus is called. Because that's what happened in the tabletop role playing world. So it doesn't really matter whether Blizzard *right now* wants this to happen. Someone will. Linden Labs thinks Second Life should be that place. I kind of agree, but part of me kind of doesn't, and part of me is off making fun of the other two parts of me... Where was I? > In short these are not "virtual worlds", they are MMO stories or > MMO games but not virtual worlds. The people who don't want to be > an Elf etc don't want to play WoW. Effort on interoperability > should be focused on the products (potential and existing) that > would actually want it. It doesn't matter to me whether it's Blizzard or Sony or someone who isn't even around yet is the first one to come up with a universal MMO, the *business case* for it will be "Getting people who don't want to visit (insert other MMO here) as an (insert Tolkein-derived species here) to play". Effort on interoperability is still going to be constrained by "you're not going to be able to transport scripted attachments into GUMMOS (Grand Universal MMO System) worlds". Whatever universal avatar format that evolves, it's going to have to handle custom meshes, skeletons, and animations. From secret.argent at gmail.com Tue Jun 3 19:37:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:35:47 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> References: <060320081553.8604.484569130005E3E00000219C221655140604040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: On 2008-06-03, at 10:53, darien_caldwell@comcast.net wrote: > Well, I have had several people tell me Second Inventory makes > importing items from Second Life to OpenSim a breeze. I'm sure it does, for stuff you own and have full permissions for. It doesn't care if you're connecting to SL or Opensim, but it won't even download stuff from SL unless it's full perm. Now if you use Slice or Ogre to rip the textures and clone the prims some other way, hey, I'm sure SI doesn't know you did that. From secret.argent at gmail.com Tue Jun 3 19:46:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:45:16 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48456B3F.1070305@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <4839F354.7030602@cox.net> <1F737607-F523-44A3-98BE-D83C7CAB488A@gmail.com> <483A3613.2070802@cox.net> <483A455B.8020900@cox.net> <49EEA41F-F29C-46DD-BD03-8D9E22E2FE46@gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <8D00BB3A-F9C8-4884-9133-0F44EDF6DF3A@gmail.com> <48456B3F.1070305@watson.ibm.com> Message-ID: <381ADC16-98FD-4B83-A265-3723B8C1B5D5@gmail.com> On 2008-06-03, at 11:03, Mike Monkowski wrote: > But this leads to a couple more questions: Why would you want to > do the same thing in two worlds if there were a mechanism to travel > between the two worlds? Who said anything about *doing the same thing*? > And aren't building, tailoring, and dressing the fun parts? For some people, yes. For others role playing is. And even if building is the fun part, building the same thing over and over again isn't. Think ahead to when there's a dozen companies with their own Grand Universal MMO or VR systems. > which seems to imply that identity is not just an abstract concept > that manifests itself differently in different worlds, but rather > something visual, that cannot be extended with approximate > recreations. Sure, it can be extended with approximate recreations... to a point. But the capabilities some worlds provide to recreate an avatar are simply too crude. Hell, the Argent who built the lunar base in "Sociopolitical Ramifications" in 1994 is still beyond the ability of SL to implement as an avatar. Some things, text still works better for. > Even if WoW allowed ferret avatars, it wouldn't be the same ferret. Maybe, maybe not. Probably not... pretty much everyone in WoW looks the same to me. Even if WoW added ferret avatars, would it have jerboas? Or binturongs, fossas, yapoks, civets, meerkats, or cape hunting dogs? Or bearded rastas with dreadlocks down to the ground, like one of my neighbors? From secret.argent at gmail.com Tue Jun 3 19:48:39 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:47:24 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> Message-ID: On 2008-06-03, at 11:28, Soft wrote: > The cache isn't exceptionally slow - it's the jpeg2000 decode that > really bites here, and storing those decoded would use copious amounts > of disk space. I'm willing to use copious amounts of disk space. I've got 150GB doing nothing but SL. If it took 100 times the disk to store 1GB of cache decoded, I'd still have 50GB free. From secret.argent at gmail.com Tue Jun 3 19:51:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 19:50:07 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48457A9B.1010704@weblogsinc.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> Message-ID: On 2008-06-03, at 12:08, Tateru Nino wrote: > Use a PNG or vanilla jpg compressor to save space on disk (and let > the user set the compression quality with a slider to let them > decide how much bang-for-the-buck they want out of their chosen > megabytes of storage), Um, I don't think that would be a good idea. At least not for JPG. Lossy compression, remember? PNG, maybe. From secret.argent at gmail.com Tue Jun 3 20:03:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 3 20:01:50 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> On 2008-06-03, at 17:59, Dale Mahalko wrote: > There are however filesystem limitations that may cause slowdowns, and > there may be diminishing returns at some point if only the local OS is > relied upon for huge caching storage. I would be interested to see > what performance gain is possible by have a dedicated slave MySQL > database running on the client PC when using a ridiculously huge cache > size.. My experience with storing big objects in databases is that filesystems kick databases butts for performance when it comes to big objects. And we're not talking about small files... even a 64x64 image is 16k, which is getting into the range where databases start getting unhappy. A 256x256 is definitely in the BLOB range. > Windows isn't good at dealing with directories containing tens of > thousands of files. Nobody is, so you store the texture for 550e8400-e29b-41d4-a716-446655440000 In $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on linux, or %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on Windows. From sldev at bitparts.org Tue Jun 3 21:20:14 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:20:25 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> Message-ID: <484617FE.40708@bitparts.org> Dale Mahalko wrote: > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > > The problem with opening an explorer window with large numbers of files in a single folder is not reading the files themselves, but the fact that Windows will read in the /entire/ directory, then sort it by whichever method is currently defaulted. Plus, this limitation can be worked around (as someone else pointed out) by adding additional layers of folders for the first X octets of the UUID. From sldev at bitparts.org Tue Jun 3 21:22:55 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:23:06 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4845DF1F.6060007@lindenlab.com> References: <48456D49.5020105@bitparts.org> <4845DF1F.6060007@lindenlab.com> Message-ID: <4846189F.9090409@bitparts.org> Steve Bennetts (Steve Linden) wrote: > We actually have image decoding working on a separate thread, but have > not tested it enough to ship it enabled. > > You can find the setting under Advanced > Rendering > Run Multiple > Threads. > > First thing I do when installing a new copy of SL is to enable "Run Multiple Threads". Have never noticed a problem, and see a slight - VERY slight - increase in texture rendering. I figure if it is /possible/ for it to speed things up, and doesn't adversely affect the experience, might as well turn it on. From sldev at bitparts.org Tue Jun 3 21:25:59 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:26:10 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <48461956.2020104@bitparts.org> Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping > the cache on one of those readyboost-capable usb flash drives? They > can have seek times as low as 1 ms or better, although the transfer > rate and write times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > Bad idea. Flash has limited write-cycles, you don't want to use it as a cache - you'll burn it out faster than you could believe.Besides, if seek times were the bottleneck, the RAMdisk experiment would have shown noticeable improvement. The bottleneck is definitely in the decoding. That's why I'm encouraging a test of caching raw data rather than re-compressed. From sldev at bitparts.org Tue Jun 3 21:29:53 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Jun 3 21:30:04 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48461A41.5080208@bitparts.org> Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head > once again. > > The reason I mention this is because, although I am also a fan of > reduced compression overhead, there will no doubt be trade offs > required. Perhaps there is a way to make compression/decompression > more efficient? > We're not talking about downloading raw, uncompressed data from SL across your bandwidth - we're talking about how the client currently REcompresses (or only saves the already-compressed) textures when storing them to the local disk cache. The change I'm talking about won't affect your bandwidth, but it will require more disk space for your cache. We've established that the real bottleneck with rendering textures from cache is decoding them from the JPG2000 format - so if we could decompress them once, after they come down the wire, then cache them decompressed, we would get rid of one of the major bottlenecks to texture render speed. No more grey blobs every time you turn around. From tateru.nino at gmail.com Tue Jun 3 21:32:47 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:33:26 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48461AEF.2020307@weblogsinc.com> We've always had capped and metered bandwidth out here (most countries do). We've got to watch our SL bandwidth consumption pretty much every day, and throttle back as necessary to keep within limits. If you're on a commercial, metered connection (most of those outside North America), SL is fantastically expensive to connect to - even metered residential connections can run into an end-of-month bill of hundreds or thousands of dollars if you're not paying attention. Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head > once again. > (Presumably because of those few horrid torrent/movie downloaders > messing everything up for the rest of the planet. Yes thats right, > instead of closing off the pipes used by the abusers they choose to > make more money by harming the community in general. Typical Time > Warner choice as opposed to upgrading their antiquated copper wire > infrastructure eh? anyway i worry that heavy SL users (such as content > creators) may be about to lose any further incentive for bothering > with virtual worlds...) > > Has anyone measured actual bandwith utilization to the point people > can predict their usage per month before they get slapped with killer > bills? > > The reason I mention this is because, although I am also a fan of > reduced compression overhead, there will no doubt be trade offs > required. Perhaps there is a way to make compression/decompression > more efficient? > > > ----- Original Message ---- > From: Tateru Nino > To: Dante Tucker > Cc: Second Life Developer Mailing List > Sent: Tuesday, June 3, 2008 1:08:43 PM > Subject: Re: [sldev] Cache speed experiment & results... > > Compromise? A lighterweight compressed cache format? Admittedly, yes, > the textures would still be coming down as jpeg2000 - which means they > would have to be decoded and recompressed before they went in the cache > - which is wasteful. But it's wasteful once per texture transfer, not > once per texture fetched from the cache. > > Use a PNG or vanilla jpg compressor to save space on disk (and let the > user set the compression quality with a slider to let them decide how > much bang-for-the-buck they want out of their chosen megabytes of > storage), then you've got far less work to do decoding than the jpeg2000 > decompressor -- or so I presume. If I got all that fatally wrong, just > whack me with a rolled up man page. > > Dante Tucker wrote: > > I definatly second this as an option. Provided there is no technical > > reason this can't be done :) > > > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > > >> wrote: > > > > > > > > Given the dirt-cheap price of HD space these days, why bother > > compressing the cache, given that the decode is so expensive > > time-wise? Enlarge the cache maximum size, and toss out the > > compression - at least give us an option to try it, and see. A > > simple checkbox or debug option "UseCompressedCache" or somesuch > > defaulted to yes - then those of us with plenty of space can try > > it out. People are screaming about texture load times - I can't > > imagine they wouldn't sacrifice some disk space for a large boost > > in performance. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Tue Jun 3 21:34:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:35:25 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> Message-ID: <48461B5F.7090303@weblogsinc.com> Also you get a limited (though large) number of write cycles to any byte before it wears out and stops responding. Dahlia Trimble wrote: > If the goal were to improve seek time in a cache, how about keeping > the cache on one of those readyboost-capable usb flash drives? They > can have seek times as low as 1 ms or better, although the transfer > rate and write times arent all that fast. > > Then again it's probably moot if the bottleneck is the decoding :/ > > On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg > wrote: > > Dale Mahalko wrote: > > ... > Windows isn't good at dealing with directories containing tens of > thousands of files. Ever tried opening a folder containing 20,000 > files? There is a delay of several seconds trying to do this in > Windows. Also the hidden MFT and directory structures can become > ridiculously fragmented, also leading to slowdowns. > > > Reiser4 is excellent with exactly these requirements. It's not > mature enough to be considered reliable for critical systems, but > for a cache? It doesn't help that Reiser himself is removed from > the development process, but it's still there and the source > available. Shouldn't that be possible to be included as a virtual > filesystem even under Windows? > > I also always thought it must be a good way to boost performance > if the cache lived on its own partition, like a Linux swap > partition. For the Linux version of SL this would even sound like > the most natural way to do it. Setting such a thing up on an > existing Windows machine has a slight fear factor attached and is > not for everyone, but if a savvy user can handle it, why not > offer. I'm speculating, but the difference could be dramatic, > especially if we had a better file system than NTFS on that > partition. > > > > > > A proper local database engine would likely deal with these huge > > numbers of tiny files more efficiently than the local operating > > system. > > Yes, but the usual architecture with the database running as a > localhost server is not ideal for our situation since everything > is squeezed back and forth through the network system, plus SQL > parsing, unnecessarily. With MySQL you could build directly on top > of the storage engine though, even bypassing the parsing with > direct API calls. It would just serve as a virtual file system the > same way as suggested above. I still believe that Reiser4 would be > even faster. And according to the description on its (now defunct) > website, they claimed reaching 94% package density with small files. > > Felix > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Tue Jun 3 21:37:28 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 3 21:38:07 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846189F.9090409@bitparts.org> References: <48456D49.5020105@bitparts.org> <4845DF1F.6060007@lindenlab.com> <4846189F.9090409@bitparts.org> Message-ID: <48461C08.3030708@weblogsinc.com> Buckaroo Mu wrote: > Steve Bennetts (Steve Linden) wrote: >> We actually have image decoding working on a separate thread, but >> have not tested it enough to ship it enabled. >> >> You can find the setting under Advanced > Rendering > Run Multiple >> Threads. >> >> > First thing I do when installing a new copy of SL is to enable "Run > Multiple Threads". Have never noticed a problem, and see a slight - > VERY slight - increase in texture rendering. I figure if it is > /possible/ for it to speed things up, and doesn't adversely affect the > experience, might as well turn it on. > Ditto. Though I may well have seen a few of those deadlocks that were mentioned. -- Tateru Nino http://www.massively.com/ From gigstaggart at gmail.com Tue Jun 3 22:04:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 3 22:04:59 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <48462277.30708@gmail.com> Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once again. > (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) I'm all for metered bandwidth. I'd love to pay for what I use, instead of subsidizing other people's usage. This whole idea of selling something as unlimited, that isn't unlimited, created this problem in the first place. In the Second Life case, I think it just comes down to being able to choose your cache behavior. Metered users can choose to cache more aggressively (and keep more compressed items cached locally) to reduce the bandwidth usage. Unmetered users might instead choose a different behavior. There are some tweakables here that I don't think are going to ever be universally right for everyone. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/15e0146c/smime-0001.bin From darien_caldwell at comcast.net Tue Jun 3 22:30:05 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Tue Jun 3 22:30:09 2008 Subject: [sldev] Cache speed experiment & results... References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> If you were to run the client at full bandwidth available (1500kb) non stop 24/7, you would use up the proposed 240 gbit a month Comcast is proposing in 48 hours. Fortunately, most people don't eat up that much. A sustained data rate of 275kbps 8 hours a day for 30 days would use up the 240 gbit limit. Key word is sustained, sitting in a sim doing nothing it's rare you get a transfer rate over 50kbps. It would be interesting to see how a normal session averages out however. This certainly will impact heavy users (like me), but to the average user, they won't see any problems. ----- Original Message ----- From: Ann Otoole To: Second Life Developer Mailing List Sent: Tuesday, June 03, 2008 3:26 PM Subject: Re: [sldev] Cache speed experiment & results... Time Warner is going to try forcing metered bandwith on the cable modem community they serve. So the ugly head of the end of unlimited bandwith use raises it's head once again. (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) Has anyone measured actual bandwith utilization to the point people can predict their usage per month before they get slapped with killer bills? The reason I mention this is because, although I am also a fan of reduced compression overhead, there will no doubt be trade offs required. Perhaps there is a way to make compression/decompression more efficient? ----- Original Message ---- From: Tateru Nino To: Dante Tucker Cc: Second Life Developer Mailing List Sent: Tuesday, June 3, 2008 1:08:43 PM Subject: Re: [sldev] Cache speed experiment & results... Compromise? A lighterweight compressed cache format? Admittedly, yes, the textures would still be coming down as jpeg2000 - which means they would have to be decoded and recompressed before they went in the cache - which is wasteful. But it's wasteful once per texture transfer, not once per texture fetched from the cache. Use a PNG or vanilla jpg compressor to save space on disk (and let the user set the compression quality with a slider to let them decide how much bang-for-the-buck they want out of their chosen megabytes of storage), then you've got far less work to do decoding than the jpeg2000 decompressor -- or so I presume. If I got all that fatally wrong, just whack me with a rolled up man page. Dante Tucker wrote: > I definatly second this as an option. Provided there is no technical > reason this can't be done :) > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > wrote: > > > > Given the dirt-cheap price of HD space these days, why bother > compressing the cache, given that the decode is so expensive > time-wise? Enlarge the cache maximum size, and toss out the > compression - at least give us an option to try it, and see. A > simple checkbox or debug option "UseCompressedCache" or somesuch > defaulted to yes - then those of us with plenty of space can try > it out. People are screaming about texture load times - I can't > imagine they wouldn't sacrifice some disk space for a large boost > in performance. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ------------------------------------------------------------------------------ _______________________________________________ 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/20080603/3575a63f/attachment.htm From missannotoole at yahoo.com Tue Jun 3 22:39:58 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 3 22:40:00 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <175218.2716.qm@web59111.mail.re1.yahoo.com> Looks like SL uses about 4MB per minute if your doing anything like moving around. You'll get about 24 hours of SL time per month from Time Warner at the rate SL uses bandwith. (assuming my math is correct) I.e.; 5GB per month max and $1 per GB over. And the Comcast mode of operation will be to cancel accounts of people that use a lot of bandwith. So SL users will simply be kicked off the internet unless the "auto lag system" to slow the connections down works. But that will kill off those users from using SL anyway. Looks like SL may be coming to an end along with most use of the internet unless a political solution is hammered in to force the internet service providers to use the money they have been making to bring the US network infrastructure up to modern standards. All this metaverse effort may be totally moot now. But really.. I observed bandwidth without SL running and just using stuff like yahoo mail and pretty websites with lots of google ad sense and especially news websites uses about the same bandwidth as SL if you actively use a web browser. I think the cable companies are going to get themselves in trouble with this entire sham they are perpetuating. I seriously doubt Google and the news media is going to be real positive to the thought that use of the internet will effectively cease because using the internet will cost more than gasoline. Guess we will see. Back to the reality of SLDev. I think some serious effort will be needed to knock down bandwidth utilization in general if SL and metaverses in general are to survive the ISP greed factor. I.e.; SL and metaverses will need to run smooth over DSL since thats where all the internet business will be going. DSL and direct TV for television entertainment. The days of the internet as a streaming media medium in the USA appear to be over. Suffice to say cache performance and storage capacity may need to be escalated to showstopper level criticality. This is important enough for metaverse involved companies to get on Congress about immediately. Thats enough of this depressing topic. I look forward to seeing progress on the cache performance and http texture pipeline soon. ----- Original Message ---- From: Jason Giglio To: Ann Otoole Cc: Second Life Developer Mailing List Sent: Wednesday, June 4, 2008 1:04:55 AM Subject: Re: [sldev] Cache speed experiment & results... Ann Otoole wrote: > Time Warner is going to try forcing metered bandwith on the cable modem community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once again. > (Presumably because of those few horrid torrent/movie downloaders messing everything up for the rest of the planet. Yes thats right, instead of closing off the pipes used by the abusers they choose to make more money by harming the community in general. Typical Time Warner choice as opposed to upgrading their antiquated copper wire infrastructure eh? anyway i worry that heavy SL users (such as content creators) may be about to lose any further incentive for bothering with virtual worlds...) I'm all for metered bandwidth. I'd love to pay for what I use, instead of subsidizing other people's usage. This whole idea of selling something as unlimited, that isn't unlimited, created this problem in the first place. In the Second Life case, I think it just comes down to being able to choose your cache behavior. Metered users can choose to cache more aggressively (and keep more compressed items cached locally) to reduce the bandwidth usage. Unmetered users might instead choose a different behavior. There are some tweakables here that I don't think are going to ever be universally right for everyone. -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/52d48864/attachment.htm From dmahalko at gmail.com Tue Jun 3 23:06:55 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 3 23:06:57 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: For OS-filesystem caches permitting hundreds of thousands to millions of cached files, perhaps a follow-behind cache optimizer process would work better and provide more organizational efficiency. To start a new cache, just make 256 subdirectories: Cache\00\* to Cache\ff\* The client walks this tree when adding files to the cache and makes a note of any directory which has exceeded some maximum performance limit, say 10,000 GUIDs in a directory. When the user is Away, the cache optimizer process goes to each of these flagged subdirectories, and will split that directory into 256 subdirectories: - Cache\4c\* was found to contain over 10,000 GUIDs, so make it Cache\4c\00\* to Cache \4c\ff\* and move the files into their respective subdirectories. - At some later time, perhaps months later, Cache\4c\e3\* was found to contain over 10,000 GUIDs so make it Cache\4c\e3\00\* to Cache\4c\e3\ff\* and move the files into their respective subdirectories Once a directory level has been forked, the client walks as deep as necessary whenever adding new GUIDs to the cache. This would keep the number of subdirectories small and fast when there are few files, but allows the cache to branch out into as many smaller branches as necessary, to keep file counts per directory low and allow fast file searching by limiting each subbranch to 256 subdirectories. Since GUID assignments are apparently random, it would be a waste of time to create deep subbranches before they are needed since many branches would likely remain empty, and empty branches must be iterated through when looking for a file. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 10:03 PM, Argent Stonecutter wrote: > Nobody is, so you store the texture for > > 550e8400-e29b-41d4-a716-446655440000 > > In > > $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on > linux, or > %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on > Windows. From seg at haxxed.com Tue Jun 3 23:41:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 3 23:41:31 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: References: Message-ID: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> On Sun, Jun 1, 2008 at 2:52 PM, Argent Stonecutter wrote: > I think that it might be worthwhile to bring up plugin APIs, in particular > plugin APIs that could be used by commercial software. I think it would be more productive to create a plugin API, develop some plugins, THEN argue about licensing once we actually have something to argue about. Right now its just utterly unproductive hypothetical handwaving. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/3bc819a0/attachment-0001.htm From Anders at Arnholm.se Tue Jun 3 23:58:57 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Jun 3 23:59:43 2008 Subject: [sldev] GPL violation? In-Reply-To: <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> References: <200806010441.41299.johnniecarling@gmail.com> <4d211a610806010200l763be63ble259539c0a0a5454@mail.gmail.com> <4842B2B5.2050309@gmail.com> <79e704e0806010829y6be5a9fds5fe6ccd26f93b340@mail.gmail.com> Message-ID: <20080604065857.GC19105@arnholm.se> On Sun, Jun 01, 2008 at 10:29:33AM -0500, Matthew Underwood wrote: > On Sun, Jun 1, 2008 at 9:31 AM, Tony wrote: > Under the GPL any derivative works have to release the source (they > can charge up to the cost of the binary form tho). So if you release > a 3k viewer, then you could theoretically charge 3k for the source > too, but you still have to have the source available. Read the But not extra un the 3K you took for the binary release, also you can?t limit your customers form selling and changing the product. I work in the borderline berween open source (mainly GPL) and properitary additions. / Balp -- o_ Anders Arnholm, o/ /\ anders@arnholm.se /|_, \\ http://anders.arnholm.se/ / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/8020d68a/attachment.pgp From seg at haxxed.com Wed Jun 4 00:07:33 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 4 00:07:35 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <175218.2716.qm@web59111.mail.re1.yahoo.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> Message-ID: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> On Wed, Jun 4, 2008 at 12:39 AM, Ann Otoole wrote: > All this metaverse effort may be totally moot now. > Imminent death of the net predicted. How much bandwidth does WoW take, or Xbox Live? ISPs may not give a crap about SL, but pissing off users of cash cows like WoW and Xbox Live would be an epic PR blunder on their part. Online content delivery is the future. And by future, I mean now. Any ISPs standing in the way are going to find themselves losing customers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/6f25f6dd/attachment.htm From kfa at gmx.net Wed Jun 4 00:13:42 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 00:13:48 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <48453828.50503@gmx.net> Message-ID: <484640A6.3040603@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 07:25, Felix Duesenburg wrote: >> My guess is that this will be a task of the magnitude of creating a >> standard for videotape or disk formats. > > > You think it's that simple? that's encouraging! :) > > LOL :) No - not as simple, as the technology we're talking about is x times more involved - I said 'magnitude' and meant to draw the comparison with the almost war-like scenario we had until there finally was only one left. From dmahalko at gmail.com Wed Jun 4 00:31:22 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 00:31:25 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> Message-ID: I don't play much D&D, but I know exactly what sort of thing you are referring to. A good example is called Neverwinter Nights. It has its own built-in story plus a construction environment where you can build your own D&D environment with your own story and your own rules, using two-dimensional tiles containing 2.5D objects. There are hundreds of private Neverwinter Nights servers where you can login and enter a custom virtual world created by a small group of D&D fanatics, each with their own story but built on the common virtual-world platform, just like how the old text-based MUDs worked. I thought the construction concepts of Neverwinter Nights were interesting.... and yet so limited. Builds are always limited to the 2.5D tiling system and as a builder you are essentially stuck with whatever predefined 2.5D tile sets exist, and with limited event-scripting and environment-customization ability. What SL and/or MPEG-V needs to offer to D&D MMO GMs and players is something like Neverwinter Nights, but taken to a full-3D experience with fully customizable virtual environment not limited to a tiling system. It needs to be able to include the storytelling and environmental possibilities of Everquest, WoW, Eve, and all other MMO's combined, to allow whatever virtual scenario a crazed D&D GM wants to dream up. - Scalar Tardis / Dale Mahalko On Tue, Jun 3, 2008 at 9:34 PM, Argent Stonecutter wrote: > As virtual role playing environments evolve, people playing in the > equivalent of Gamma World and Champions and D&D and Runequest and Car Wars > are going to eventually want to get together, as their avatars. You're going > to have the online equivalents of Munden's Bar, where all the metaverses > come together. From dmahalko at gmail.com Wed Jun 4 00:42:04 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 00:42:05 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> Message-ID: For WoW, bandwidth usage depends on your play style. WoW is completely playable as a single player on 30 kbit dialup, though voice cannot be used. I know because this is what was stuck with using, for two years. Also up to 5-man groups are playable, with a good 40-50 kbit connection, though there can be lag in busy fights, and still no voice is allowed. Larger groups are generally not possible on dialup, and entering a massively crowded city area (like IronForge, before there were multiple auction locations) would lag out and knock a dialup player offline. But even for raids the bandwidth doesn't go much over 256 kbit, so WoW is fairly lightweight. But just remember that it has around 9 gigabytes of data precached on every player's computer and that is only changed via infrequently-applied large unified patches.. - Scalar Tardis / Dale Mahalko On Wed, Jun 4, 2008 at 2:07 AM, Callum Lerwick wrote: > How much bandwidth does WoW take From kfa at gmx.net Wed Jun 4 00:46:36 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 00:46:42 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <4846485C.90107@gmx.net> Argent Stonecutter wrote: > On 2008-06-03, at 17:59, Dale Mahalko wrote: >> There are however filesystem limitations that may cause slowdowns, and >> there may be diminishing returns at some point if only the local OS is >> relied upon for huge caching storage. I would be interested to see >> what performance gain is possible by have a dedicated slave MySQL >> database running on the client PC when using a ridiculously huge cache >> size.. > > My experience with storing big objects in databases is that filesystems > kick databases butts for performance when it comes to big objects. And > we're not talking about small files... even a 64x64 image is 16k, which > is getting into the range where databases start getting unhappy. A > 256x256 is definitely in the BLOB range. > >> Windows isn't good at dealing with directories containing tens of >> thousands of files. > > Nobody is, so you store the texture for > > 550e8400-e29b-41d4-a716-446655440000 > > In > > $CACHEDIR/textures/55/0e/84/00/550e8400-e29b-41d4-a716-446655440000 on > linux, or > %CACHEDIR%\textures\55\0e\84\00\550e8400-e29b-41d4-a716-446655440000 on > Windows. > I don't know where I read that... someone tell me if it's just a rumour. Can it be true that for reasons related to the historical evolution of Windows, it's still a wee bit faster if filenames sticked to the old 8.3 convention? If that is so, just break the filename up into parts with no more than 8 characters. What we have here is simply the hex-ascii representation of a 128 bit number, requiring 32 characters to encode. The dashes are superfluous and can be omitted. Thus, %CACHEDIR%\textures\550e8400\e29b41d4\a7164466\55440000.tga Dismiss if this is rubbish. From gbrandon at gmail.com Wed Jun 4 00:59:40 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 00:59:43 2008 Subject: [sldev] RevokePermissions Message-ID: Hey all, just wanted to ask if there's been any discussion as to why the RevokePermissions message hasn't been implemented in the official viewer. It seems to be in working order all this time from what I can tell. But the official viewer even goes so far as to warn that you "can't revoke this" in the PERMISSION_DEBIT dialog. Is there some issue with it that noone is aware of? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/09f4a395/attachment.htm From tateru.nino at gmail.com Wed Jun 4 01:54:33 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 4 01:55:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <175218.2716.qm@web59111.mail.re1.yahoo.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> Message-ID: <48465849.4090507@weblogsinc.com> We get 20GB/month, right now - which is really the best we can get for the foreseeable future. We're just a couple days into the month and having to throttle usage back to make sure we'll get to the end of it. Ann Otoole wrote: > Looks like SL uses about 4MB per minute if your doing anything like > moving around. > > You'll get about 24 hours of SL time per month from Time Warner at the > rate SL uses bandwith. (assuming my math is correct) > I.e.; 5GB per month max and $1 per GB over. > > And the Comcast mode of operation will be to cancel accounts of people > that use a lot of bandwith. So SL users will simply be kicked off the > internet unless the "auto lag system" to slow the connections down > works. But that will kill off those users from using SL anyway. > > Looks like SL may be coming to an end along with most use of the > internet unless a political solution is hammered in to force the > internet service providers to use the money they have been making to > bring the US network infrastructure up to modern standards. > > All this metaverse effort may be totally moot now. > > But really.. I observed bandwidth without SL running and just using > stuff like yahoo mail and pretty websites with lots of google ad sense > and especially news websites uses about the same bandwidth as SL if > you actively use a web browser. I think the cable companies are going > to get themselves in trouble with this entire sham they are > perpetuating. I seriously doubt Google and the news media is going to > be real positive to the thought that use of the internet will > effectively cease because using the internet will cost more than gasoline. > > Guess we will see. Back to the reality of SLDev. > > I think some serious effort will be needed to knock down bandwidth > utilization in general if SL and metaverses in general are to survive > the ISP greed factor. > I.e.; SL and metaverses will need to run smooth over DSL since thats > where all the internet business will be going. DSL and direct TV for > television entertainment. The days of the internet as a streaming > media medium in the USA appear to be over. > > Suffice to say cache performance and storage capacity may need to be > escalated to showstopper level criticality. > > This is important enough for metaverse involved companies to get on > Congress about immediately. > > Thats enough of this depressing topic. I look forward to seeing > progress on the cache performance and http texture pipeline soon. > > > ----- Original Message ---- > From: Jason Giglio > To: Ann Otoole > Cc: Second Life Developer Mailing List > Sent: Wednesday, June 4, 2008 1:04:55 AM > Subject: Re: [sldev] Cache speed experiment & results... > > Ann Otoole wrote: > > Time Warner is going to try forcing metered bandwith on the cable > modem community they serve. > > So the ugly head of the end of unlimited bandwith use raises it's > head once again. > > (Presumably because of those few horrid torrent/movie downloaders > messing everything up for the rest of the planet. Yes thats right, > instead of closing off the pipes used by the abusers they choose to > make more money by harming the community in general. Typical Time > Warner choice as opposed to upgrading their antiquated copper wire > infrastructure eh? anyway i worry that heavy SL users (such as content > creators) may be about to lose any further incentive for bothering > with virtual worlds...) > > I'm all for metered bandwidth. I'd love to pay for what I use, instead > of subsidizing other people's usage. This whole idea of selling > something as unlimited, that isn't unlimited, created this problem in > the first place. > > In the Second Life case, I think it just comes down to being able to > choose your cache behavior. Metered users can choose to cache more > aggressively (and keep more compressed items cached locally) to reduce > the bandwidth usage. > > Unmetered users might instead choose a different behavior. There are > some tweakables here that I don't think are going to ever be universally > right for everyone. > > -Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jun 4 01:57:59 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 4 01:58:39 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> Message-ID: <48465917.1010005@weblogsinc.com> Callum Lerwick wrote: > On Wed, Jun 4, 2008 at 12:39 AM, Ann Otoole > wrote: > > All this metaverse effort may be totally moot now. > > > Imminent death of the net predicted. > > How much bandwidth does WoW take, or Xbox Live? ISPs may not give a > crap about SL, but pissing off users of cash cows like WoW and Xbox > Live would be an epic PR blunder on their part. > > Online content delivery is the future. And by future, I mean now. Any > ISPs standing in the way are going to find themselves losing customers. > Well, most MMOs use a fraction of the bandwidth. You can play most of them on dialup. Since the content pre-exists at the client-side, there's very little data to exchange. Even less, when you take into account that a lot of processing can be done in the client itself. -- Tateru Nino http://www.massively.com/ From belxjander at gmail.com Wed Jun 4 04:20:55 2008 From: belxjander at gmail.com (Belxjander Serechai) Date: Wed Jun 4 04:20:58 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> Message-ID: <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> What is actually being transported and what are the spaces being transported between? if OSgrid.org is my room and the LL SL grid is the next room...then there is an obvious compatability, same root tech, however transfer of AV concept would remain local to the owner while others may see entirely different AV forms in MMORPG systems, as for content (Asset) provision, I see Web style Server Farms happening... each Farm having own key... something like a "keyring" function for access seems appropriate, as content providers would host for a creator, and each item would need a user/creator/provider keychain, as for Inventory, a similar model can be introduced... as far as AVs are concerned... this is a "root" object of transfer, whats needed to support the AV?, What "objects" is the AV going to have "come with it" ala "Airport baggage""... I forsee something similar to an "Airport" for Inter-realm transfers... similar to International customs, each "realm" OSgrid/LLSL/WoW/... needs to define what it will and will not "import" as baggage permissions, and then the technology has to provide for inter-connection, ... every "site" is going to need "grid" and "user" support with allocation for "anonymous" users being part of the "passport" keychain, as you are talking about Identity, you need to have a representation of Identity in each "realm" or VW, and then an interconnection agreement as well, The standards as I see it need to focus on making the interconnection and access of assets being "user/server/provider" keyed so that any individuals Items are permissible, I use 'Freija Yoshikawa' on both the Linden and OSgrid realms, I would want for the login on each to represent the same AV, the material on OSgrid started there, and the material on the Linden grid started on the LLSL grid, I would have a "Suitcase" where I would "pack" what I wish to keep with me, and then travel between the two,... when I am in the OSgrid using the LLSL AV, I would expect *my* view on my local machine to remain the same, however, I personally do not expect what other people to see to be the same (maybe I am given a "basic visitor" AV to start?) Once I am on the OSgrid realm, what is stopping me from purchasing or making content there, and this is where the travel interconnect agreement comes into play, are "Materia"(Assets/Inventory) I make on the OSgrid using the LLSL AV presence with OSgrid Passport(UserLogin) going to be hosted where? the answer to that seems obvious to me... I am on the OSgrid, therefore hosting for Inventory remains on OSgrid, the only issue I see is how to make any interconnect between realms allow for "luggage" like a suitcase... or some kind of "permissible" hosting, What is to stop a User Client from "keeping" access to Assets and Inventory when crossing between grid/realms? example 2: I travel back from OSgrid to LLSL using Freija Yoshikawa, my "Primary" Inventory is now LLSL again with full access restored, and the OSgrid Inventory is now "Secondary"... in this case I may have full login and access to both LL and OSgrid services... a modular client with Inventory access to both systems as Full credentialled login... transfer of inventory would become easy... but the key to the above examples is actually "walled garden" model with an interconnect... every "web site" I visit I consider to be a walled garden, disney/microsoft/borland/... whomever... they want to "keep" custom with you each realm without interconnect loses customers... where are they coming from? Customers are visiting through Interconnects... a Web Browser is interconnect to ALL web services through a common HTTP/HTML standard, I see a base requirement of Assets and Inventory needing the same kind of paired protocol/format evolution, Ive already worked up a basic idea that would work and still provide for some legal concerns to be dealt with... but would require that any SecondLife grid style system with content creation is not just *any interconnect will do*... LL is first provider for the SecondLife grid and protocol, now we need for a non-LL business to be providing a grid as well, along with an interconnection agreement and mechanism in place. just because there is a legal divide between LL and OS about code (GPL/BSD license)... does not mean there needs to also be a non-communication divide as well, the only division there is legal and related to the code (GPL doing pacman to BSD) Yes the above can be a "walled garden" but I see the above as "provider" gardens and interconnects between garden "realms" how many business will use the same provider ? and who will access each providers system for a given service ? The above model does have the LL"main" and LL"teen" grid approach in seperating Adult material from minors... they WILL find out eventually,... just dont let the technology override the parents choices... There is also another social impact... provision of the grid AND the business ON that grid are not the same company ... LL does the grid, IBM/Microsoft/etc... market on their grid... there is nothing stopping alternative providers of grid services... but there does need to be an honourable means of marketing to the end users to let them decide where to go... Do you go to Tahiti or the Bahamas or Japan for a Holiday ? or are you going for other reasons? How about Europe? ALL of the above is available seperately and is a rehash of a conversation I had on the EFnet/#OpenSIM IRC channel, the first thing about a "3D" system like SL is that there is still the 2D mapping limitation... each "realm" may be "flat" but whats to stop an alternate region mapping things in 3D as well? Im personally hacking at a modified OpenSIM to run a cube of grid regions... going *any direction* beyond a region boundary in X Y or Z axis *will* step you to another region... whats to stop a given "region" within a grid having the special "interconnect" property? and promoting anyone who enters that region as being TP'd to a "staging island" region... call it Teleport/Stargate/DimensionJump/... Whatever... the name doesnt matter so much as getting from A(origin realm) to B(target realm) Any Client no matter HOW feature rich is still a "browser" for each of the virtual worlds... is the "world" it is accessing "complete" or only "part"? LLSL and OSgrid are now fragments of that "world"... with the result split... therefore to appease everyone.. allow for a non-single provider... *make* the market by providing for it... either content within the realms or the realms themselves, ( I am looking to make realm service and content seperate ) Contact Names ?IM & Email?Abh??????? ?IRC & Chat?Belxjander Serechai ?LLSL/OSgrid?Freija Yoshikawa ?Real?Life??Jeremy Sutherland I also play on Guild Wars / Exteel and Fury systems occasionally, ... On Wed, Jun 4, 2008 at 4:31 PM, Dale Mahalko wrote: > I don't play much D&D, but I know exactly what sort of thing you are > referring to. A good example is called Neverwinter Nights. It has its > own built-in story plus a construction environment where you can build > your own D&D environment with your own story and your own rules, using > two-dimensional tiles containing 2.5D objects. There are hundreds of > private Neverwinter Nights servers where you can login and enter a > custom virtual world created by a small group of D&D fanatics, each > with their own story but built on the common virtual-world platform, > just like how the old text-based MUDs worked. > > I thought the construction concepts of Neverwinter Nights were > interesting.... and yet so limited. Builds are always limited to the > 2.5D tiling system and as a builder you are essentially stuck with > whatever predefined 2.5D tile sets exist, and with limited > event-scripting and environment-customization ability. > > What SL and/or MPEG-V needs to offer to D&D MMO GMs and players is > something like Neverwinter Nights, but taken to a full-3D experience > with fully customizable virtual environment not limited to a tiling > system. It needs to be able to include the storytelling and > environmental possibilities of Everquest, WoW, Eve, and all other > MMO's combined, to allow whatever virtual scenario a crazed D&D GM > wants to dream up. > > - Scalar Tardis / Dale Mahalko > > On Tue, Jun 3, 2008 at 9:34 PM, Argent Stonecutter > wrote: >> As virtual role playing environments evolve, people playing in the >> equivalent of Gamma World and Champions and D&D and Runequest and Car Wars >> are going to eventually want to get together, as their avatars. You're going >> to have the online equivalents of Munden's Bar, where all the metaverses >> come together. > _______________________________________________ > 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 Jun 4 06:02:21 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:01:12 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48462277.30708@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> Message-ID: On 2008-06-04, at 00:04, Jason Giglio wrote: > I'm all for metered bandwidth. I don't think "metered bandwidth" is a good term. Bandwidth is "how much you can transmit per unit of time", and is metered in units of bits-per-second. My bandwidth is capped to 256 kilobits per second, for example. This is good enough to play SL, but not enough to stream HD movies (or stream anything while I'm playing SL). What we're talking about here needs a different term. It's not a bandwidth cap, it's a total traffic cap. I prefer real bandwidth caps to traffic caps because I don't care if the guy next door who's running a 5 megabyte per second download is going to get capped off sooner, while he's doing it I'm still suffering. Either way I'd much rather be able to use my whole disk for cache, with no limits other than disk space, to the current scheme. From secret.argent at gmail.com Wed Jun 4 06:13:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:12:00 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On 2008-06-04, at 01:06, Dale Mahalko wrote: > Since GUID assignments are apparently random, it would be a waste of > time to create deep subbranches before they are needed since many > branches would likely remain empty, and empty branches must be > iterated through when looking for a file. I didn't pull this scheme out of thin air. I actively use it. There's no searching or iterating by the client needed. No empty directories are created. When you create an object in the cache, you do something like this: sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, uuid+6, uuid); if(!(fp = fopen(filename, "w"))) { filename[2] = 0; success = mkdir(filename); filename[2] = '/'; if(success != ERR) { filename[4] = 0; success = mkdir(filename); filename[4] = '/'; } if(success != ERR) { filename[6] = 0; success = mkdir(filename); filename[6] = '/'; } if(success != ERR) { filename[8] = 0; success = mkdir(filename); filename[8] = '/'; } if(success != ERR) { fp = fopen(filename, "w"); } if(!fp) { fatal(filename, strerror(errno)); } } This means that when opening a cached file you have a single system call: sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, uuid+6, uuid); if(!(fp = fopen(filename, "r"))) { fatal(filename, strerror(errno)); } This avoids populating the tree unnecessarily, while making the common operation (reading from cache) MUCH faster than if the file name varies depending on depth. From secret.argent at gmail.com Wed Jun 4 06:17:56 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:16:39 2008 Subject: Plugins (Re: [sldev] GPL violation?) In-Reply-To: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> References: <1218b5bc0806032341h661790eh6cc419325f556e8f@mail.gmail.com> Message-ID: On 2008-06-04, at 01:41, Callum Lerwick wrote: > I think it would be more productive to create a plugin API, develop > some plugins, THEN argue about licensing once we actually have > something to argue about. Right now its just utterly unproductive > hypothetical handwaving. There's been a couple of plugin APIs designed, and prototypes for what could be possible plugins created, and distributed as custom builds of SL. Things kind of stalled, though, partly because of a lack of feedback from LL. From secret.argent at gmail.com Wed Jun 4 06:29:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:28:36 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846485C.90107@gmx.net> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846485C.90107@gmx.net> Message-ID: <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> On 2008-06-04, at 02:46, Felix Duesenburg wrote: > I don't know where I read that... someone tell me if it's just a > rumour. Can it be true that for reasons related to the historical > evolution of Windows, it's still a wee bit faster if filenames > sticked to the old 8.3 convention? Not in NTFS. If you're using FAT32, it's possible. that would make it maybe... %CACHEDIR%\textures\55\0e\84\00e2\9b41d4\a7164466\55440000 You still want the early levels to be limited to a maximum of 256 entries, otherwise you end up with the problem of tens of thousands of entries in a directory again. From secret.argent at gmail.com Wed Jun 4 06:37:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 06:35:51 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <48BF74A3-B473-4EFA-B5C4-05A8E445B361@gmail.com> <4880eb1a0806040420t398d1488s87621b0dd7402851@mail.gmail.com> Message-ID: <4EDB3E4B-99CF-4C2D-A67F-9D70A29F0730@gmail.com> On 2008-06-04, at 06:20, Belxjander Serechai wrote: > as far as AVs are concerned... this is a "root" object of transfer, > whats needed to support the AV?, For arbitrary avatars: a skeleton, a set of meshes, textures, and animations. For an avatar holding an object that could be represented by attached objects and an object mesh, or a more complex skeleton and mesh. These may not exactly match the internal formats of any of the worlds involved, and would have to be approximated for each. From sakkaku at gmail.com Wed Jun 4 07:22:43 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed Jun 4 07:23:01 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846485C.90107@gmx.net> <7AA72AD2-28AC-4C52-AC0F-CA3A8DA59A83@gmail.com> Message-ID: <79e704e0806040722r714421bbra8021abe1864bf67@mail.gmail.com> If a compatibility flag is set then NTFS generates an 8.3 name based on the filename. You can often see the effects of this with the old(er) office that had to have a shorter name in order to open the file, it would create a temporary file (or link?) and open that. On Wed, Jun 4, 2008 at 8:29 AM, Argent Stonecutter wrote: > On 2008-06-04, at 02:46, Felix Duesenburg wrote: >> >> I don't know where I read that... someone tell me if it's just a rumour. >> Can it be true that for reasons related to the historical evolution of >> Windows, it's still a wee bit faster if filenames sticked to the old 8.3 >> convention? > > Not in NTFS. If you're using FAT32, it's possible. that would make it > maybe... > > %CACHEDIR%\textures\55\0e\84\00e2\9b41d4\a7164466\55440000 > > You still want the early levels to be limited to a maximum of 256 entries, > otherwise you end up with the problem of tens of thousands of entries in a > directory again. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dmahalko at gmail.com Wed Jun 4 09:37:09 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Jun 4 09:37:12 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <48457735.9060900@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: My only concern is that the GUID distribution is may be just merely pseudo-random. When this system was dreamed up at the start of SL, did anyone actually do studies of the randomness of the distributions? I do not know if LL is using a randomness algorithm rigorously tested by professional mathematicians and statisticians, or if it just something Cory Ondrejka threw together one day and called good. It is possible that the GUID distribution is not as truly random as we may think, and many GUIDs end up falling into certain branches, sort of like how a 3D array of dots may appear random from one angle but end up all aligning into an even grid when rotated properly. As far as I know, no one has yet tried caching absolutely everything LL throws at them and just never deleting anything, and running statistics on that, so no one outside LL knows where the GUIDs tend to fall at this point. Your suggested method is four levels deep, and offers up to four billion subdirectories for GUIDs to fall into, which seems granular enough... but what if for some reason they all end up piling up into just a few of these branches? Then you'll end up with 50,000+ GUIDs sitting in Cache\00\41\31\d1\* and no way to split that any deeper. For an "ultimate, never-delete" local cache spanning terabytes of local storage, I am in favor of allowing for splitting all the way to the "bottom" if necessary, up to 19 directories deep, to deal with possible pseudo-random distribution problems. At this ridiculously deep splitting, there can only ever be 256 GUIDs per directory, at the bottom-most level. %CACHEDIR%\textures\55\0e\84\00\55\0e\84\00\e2\9b\41\d4\a7\16\44\66\55\44\00\00 While some people will debate the value of this vs just requesting the data from LL directly, I am also still looking for caching options for people with extremely limited bandwidth. This could be laying the foundation for the design of a local network proxy/cache server. I am aware that public schools must share a minuscule network pipe with hundreds of students, and the only way to effectively deal with SL in a school environment is to have some sort of local building-wide asset-cache server. With regard to the ISP bandwidth limiting problem also being discussed, imagine if an ISP could buy a "Second Life Asset Appliance" similar to the current Google Search Appliance. They could effectively cut user traffic to LL in half or less by caching all assets locally and transparently proxying SL asset requests, and meanwhile be able to offer a greater quality of service to all other users of their network.. - Scalar Tardis / Dale Mahalko On Wed, Jun 4, 2008 at 8:13 AM, Argent Stonecutter wrote: > I didn't pull this scheme out of thin air. I actively use it. > > There's no searching or iterating by the client needed. No empty directories > are created. When you create an object in the cache, you do something like > this: > > sprintf(filename, "%2.2s/%2.2s/%2.2s/%2.2s/%s", uuid, uuid+2, uuid+4, > uuid+6, uuid); > if(!(fp = fopen(filename, "w"))) { > filename[2] = 0; success = mkdir(filename); filename[2] = '/'; > if(success != ERR) { filename[4] = 0; success = mkdir(filename); > filename[4] = '/'; } > if(success != ERR) { filename[6] = 0; success = mkdir(filename); > filename[6] = '/'; } > if(success != ERR) { filename[8] = 0; success = mkdir(filename); > filename[8] = '/'; } > if(success != ERR) { fp = fopen(filename, "w"); } > if(!fp) { fatal(filename, strerror(errno)); } > } From Celierra at gmail.com Wed Jun 4 09:54:53 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Jun 4 09:54:56 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko wrote: > My only concern is that the GUID distribution is may be just merely > pseudo-random. ... Why not hash the (entire) GUID and use that instead? ~Cel From q at lindenlab.com Wed Jun 4 10:17:41 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Jun 4 10:18:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko > wrote: >> My only concern is that the GUID distribution is may be just merely >> pseudo-random. ... > > Why not hash the (entire) GUID and use that instead? The point of a GUID is that it's already random. Or more correctly, "merely" pseudo-random. Not that most computers have a handy source of true randomness anyway. Our GUID generation code is found in lluuid.h/.cpp. There are comments in there that indicate that we've thought about distribution and the quality of our randomness before. Which makes sense, given that we have to store *all* of those assets ourselves. If they had a tendency to sort themselves into buckets, we'd have a lot more trouble managing them than any external caching scheme will. I don't think this is something to bother with. Q From monkowsk at watson.ibm.com Wed Jun 4 10:21:43 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jun 4 10:23:13 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <48458B1D.8030502@lindenlab.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> <48458B1D.8030502@lindenlab.com> Message-ID: <4846CF27.90007@watson.ibm.com> Kelly Linden wrote: > Sorry, Perhaps my response was pigeonholed? :) Didn't mean to. :-) > "Effort on interoperability should be focused on the products (potential > and existing) that would actually want it. " And I would say "Effort on interoperability should be focused on the customers (potential and existing) that would actually want it." The focus is different. > The actual example being discussed was WoW, the specific reason given > was a user who didn't want to play WoW because they wanted a fully > customizable avatar in WoW because they didn't like elves and similar. > WoW is not going to want to upset their millions of paying subscribers > by allowing arbitrary content in world - it just isn't the product that > WoW is. And people who don't like elves aren't the customers for WoW. > Almost all other MMORPGs in existance today fall into that category. I > think this will be true of many games for a good long time. I don't disagree, except perhaps in the meaning of "long time." > Now that I've written this I realize what is being discussed isn't > really 'interoperability' but a small subset of it: content exchange. > What I have said primarily focuses on this aspect of interoperability, > and this isn't probably even the biggest part, nor the most important. My feelings are the same as yours, but, as my wife often points out, most people do not think the way I do. :-) I'm trying to understand why content exchange is at all important to anyone. > There are definitely places where interoperability is not only possible > but highly desired. My point is just to focus efforts there. Even > products that may not want full interoperability (such as content > exchange) may be interested in other forms of interoperability such as > communication or authentication or a standard viewer (which is I think > what started this thread). It might be beneficial even to WoW to be > able to get customers without them needing to install new software on > their machine. In fact that future probably puts dollar signs in many > an Exec's eyes. Those dollar signs often distort one's vision. :-) > Little Big Planet is interesting because it does have facilities for > content creation ..... however from what I have seen that content > creation is still somewhat limited. The characters have a specific > look, the content has a specific look. Perhaps it isn't as vital to the > product as WoW and similar content-creation-less products, and perhaps > LBP is a potential customer for content exchange interoperability. > After thinking about this I think it is very important to be clear about > what form interoperability is being discussed and to allow and encourage > varying degrees of interoperability. I brought up Little Big Planet because it doesn't fit either of the categories: MMO game or virtual world. I imagine that more MMO games might begin to include content creation. But back to the main topic. You say that "LBP is a potential customer for content exchange interoperability." Why? Just because it has content? Or does the content exchange provide synergy? Mike From cenji.neutra at gmail.com Wed Jun 4 10:37:04 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Wed Jun 4 10:37:07 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: > From: "Dale Mahalko" > To: "Argent Stonecutter" > Date: Wed, 4 Jun 2008 11:37:09 -0500 > Subject: Re: [sldev] Cache speed experiment & results... [...] > It is possible that the GUID distribution is not as truly random as we > may think, [...] I've not looked at the source, but if LL implemented the standard for UUIDs (aka GUIDs) then they shouldn't be completely random at all. UUIDs aren't made up of all random parts - they have components that have to be generated in specific ways, only some of which are intended to be random. The original (V1) UUIDs actually contain the network card Mac address of the computer that generated it (!) Look at SL keys - they are all of the form xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx for a start - and there are other internal consistencies I believe. It may be that LL didn't follow the standard at all and just made up their own system of course. -Cenji. From kelly at lindenlab.com Wed Jun 4 10:42:14 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jun 4 10:42:21 2008 Subject: Interoperability; was: [sldev] Call for requirements: ISO MPEG-V ... In-Reply-To: <4846CF27.90007@watson.ibm.com> References: <3e3ef2f00805240129o6dd73af2uc1935995cdaf0ed1@mail.gmail.com> <483AC424.6050500@gmail.com> <483B20E6.6070709@cox.net> <483B24A2.7040200@cox.net> <48443D4A.1090609@watson.ibm.com> <79e704e0806021148r5f4bc894l7005adcfd788b4f1@mail.gmail.com> <484472A4.2030104@watson.ibm.com> <79e704e0806021530r6c6d062eq4f203269fb91c638@mail.gmail.com> <48447E5C.4080808@watson.ibm.com> <79e704e0806021654r1a6aac53y6dab11d49ec4ab0a@mail.gmail.com> <48448EB2.8070701@watson.ibm.com> <4844A78F.9050605@weblogsinc.com> <4844BB1F.4040902@cox.net> <48450211.50408@gmx.net> <4D5E73C2-04F9-4731-B470-966313A3689A@gmail.com> <484568B8.8010705@lindenlab.com> <484583F1.9020505@watson.ibm.com> <48458B1D.8030502@lindenlab.com> <4846CF27.90007@watson.ibm.com> Message-ID: <4846D3F6.6070007@lindenlab.com> Mike Monkowski wrote: > I brought up Little Big Planet because it doesn't fit either of the > categories: MMO game or virtual world. I imagine that more MMO games > might begin to include content creation. > > But back to the main topic. You say that "LBP is a potential customer > for content exchange interoperability." Why? Just because it has > content? Or does the content exchange provide synergy? > > Mike At that point, yeah, I just meant that it has user-generated-content and so could potentially be a customer for content exchange - at least more so than products that do not have user-generated-content. - Kelly From sakkaku at gmail.com Wed Jun 4 10:44:17 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed Jun 4 10:44:20 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: Message-ID: <79e704e0806041044q14b8bc6coba63993c430e482b@mail.gmail.com> http://en.wikipedia.org/wiki/UUID There are several standards, some relying solely on a random number. Given the range of these numbers (128bit), I don't think they would collide easily (shoot they probably will eventually collide). On Wed, Jun 4, 2008 at 12:37 PM, Cenji Neutra wrote: >> From: "Dale Mahalko" >> To: "Argent Stonecutter" >> Date: Wed, 4 Jun 2008 11:37:09 -0500 >> Subject: Re: [sldev] Cache speed experiment & results... > [...] >> It is possible that the GUID distribution is not as truly random as we >> may think, > [...] > > I've not looked at the source, but if LL implemented the standard for > UUIDs (aka GUIDs) then they shouldn't be completely random at all. > UUIDs aren't made up of all random parts - they have components that > have to be generated in specific ways, only some of which are intended > to be random. The original (V1) UUIDs actually contain the network > card Mac address of the computer that generated it (!) > > Look at SL keys - they are all of the form > xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx for a start - and there are other > internal consistencies I believe. > > It may be that LL didn't follow the standard at all and just made up > their own system of course. > -Cenji. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From alex at lindenlab.com Wed Jun 4 11:44:06 2008 From: alex at lindenlab.com (Alex Dailey) Date: Wed Jun 4 11:44:09 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org><4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com><48457A9B.1010704@weblogs inc.com><4845A31D.10002@bitparts.org><897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <4846E276.8050809@lindenlab.com> A humorous side note to this. The distribution of uuid's is so random and there is so much 'space' between values, that Cory et al. joked about putting phony assets in the early range, ...0000000, 0000001 that rezz'ed signs saying things like, "Give up now!" and "Abandon your quest or despair!" for people who tried to guess asset_id's starting from the beginning of the uuid range. Kent Quirk (Q Linden) wrote: > > On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > >> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko >> wrote: >>> My only concern is that the GUID distribution is may be just merely >>> pseudo-random. ... >> >> Why not hash the (entire) GUID and use that instead? > > The point of a GUID is that it's already random. Or more correctly, > "merely" pseudo-random. Not that most computers have a handy source of > true randomness anyway. > > Our GUID generation code is found in lluuid.h/.cpp. There are comments > in there that indicate that we've thought about distribution and the > quality of our randomness before. > > Which makes sense, given that we have to store *all* of those assets > ourselves. If they had a tendency to sort themselves into buckets, > we'd have a lot more trouble managing them than any external caching > scheme will. I don't think this is something to bother with. > > Q > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at lindenlab.com Wed Jun 4 11:54:29 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 11:54:31 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846E276.8050809@lindenlab.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <4846E276.8050809@lindenlab.com> Message-ID: That said, there *are* stripes of consecutive IDs out there. :) Check out a few elder Linden LLUUIDs. On Wed, Jun 4, 2008 at 1:44 PM, Alex Dailey wrote: > A humorous side note to this. The distribution of uuid's is so random and > there is so much 'space' between values, that Cory et al. joked about > putting phony assets in the early range, ...0000000, 0000001 that rezz'ed > signs saying things like, "Give up now!" and "Abandon your quest or > despair!" for people who tried to guess asset_id's starting from the > beginning of the uuid range. > > Kent Quirk (Q Linden) wrote: >> >> On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: >> >>> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko wrote: >>>> >>>> My only concern is that the GUID distribution is may be just merely >>>> pseudo-random. ... >>> >>> Why not hash the (entire) GUID and use that instead? >> >> The point of a GUID is that it's already random. Or more correctly, >> "merely" pseudo-random. Not that most computers have a handy source of true >> randomness anyway. >> >> Our GUID generation code is found in lluuid.h/.cpp. There are comments in >> there that indicate that we've thought about distribution and the quality of >> our randomness before. >> >> Which makes sense, given that we have to store *all* of those assets >> ourselves. If they had a tendency to sort themselves into buckets, we'd have >> a lot more trouble managing them than any external caching scheme will. I >> don't think this is something to bother with. >> >> Q >> _______________________________________________ >> 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 secret.argent at gmail.com Wed Jun 4 12:02:43 2008 From: secret.argent at gmail.com (Argent) Date: Wed Jun 4 12:02:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> Message-ID: <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> On 6/4/08, Dale Mahalko wrote: > My only concern is that the GUID distribution is may be just merely > pseudo-random. When this system was dreamed up at the start of SL, > did anyone actually do studies of the randomness of the distributions? I believe the SL UUIDs are actually generated randomly, often on the user's computer(!), with a variety of seeds. But if that turns out to be an issue... don't forget that this is just a cache, there's no issue with *changing it* to take other bits from the UUID for the first couple of levels. You could even use a simple CRC or other cheap polynomial on the UUID to generate a 16-bit value for the first two levels. If the UUID is still used for the rest of the file name, you don't even need to version the cache, all that will happen is you'll get cache misses when the algorithm changes and the old files will eventually age out of the cache. From mrfrans at gmail.com Wed Jun 4 12:12:45 2008 From: mrfrans at gmail.com (Frans) Date: Wed Jun 4 12:12:50 2008 Subject: [sldev] RevokePermissions In-Reply-To: References: Message-ID: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> I suspect that there isn't a list kept on the servers to what you have given permission_debit. So it would only be usefull for things you do know of, which in most cases you can revoke by reseting the script anyway. On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby wrote: > Hey all, just wanted to ask if there's been any discussion as to why the > RevokePermissions message hasn't been implemented in the official viewer. > It seems to be in working order all this time from what I can tell. But the > official viewer even goes so far as to warn that you "can't revoke this" in > the PERMISSION_DEBIT dialog. Is there some issue with it that noone is > aware of? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/8b82bb38/attachment.htm From soft at lindenlab.com Wed Jun 4 12:13:20 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 12:13:23 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <4845A31D.10002@bitparts.org> <897E699C-7AAD-405E-866A-59980A186AB7@gmail.com> <16309a040806041202y50fa4653ve6fa098f55ef23a0@mail.gmail.com> Message-ID: On Wed, Jun 4, 2008 at 2:02 PM, Argent wrote: > On 6/4/08, Dale Mahalko wrote: >> My only concern is that the GUID distribution is may be just merely >> pseudo-random. When this system was dreamed up at the start of SL, >> did anyone actually do studies of the randomness of the distributions? > > I believe the SL UUIDs are actually generated randomly, often on the > user's computer(!), with a variety of seeds. The ones generated in the viewer are placeholders until the asset is assigned a proper ID as part of the asset storage process. If any type client-generated UUIDs persists, that should be filed as a security issue in JIRA. From mrfrans at gmail.com Wed Jun 4 12:22:12 2008 From: mrfrans at gmail.com (Frans) Date: Wed Jun 4 12:22:18 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <48465917.1010005@weblogsinc.com> References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> Message-ID: <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> 5GB doesn't sounds like much if you video chat and use services like joost and hulu. -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/d4dbf1f0/attachment.htm From nexeus at nexeusfatale.com Wed Jun 4 12:34:09 2008 From: nexeus at nexeusfatale.com (Nexeus Fatale) Date: Wed Jun 4 12:34:11 2008 Subject: [sldev] RevokePermissions In-Reply-To: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> References: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> Message-ID: Isn't it just easier to, when running the script, set the permission changes in the entry state or rezzed state? On Wed, Jun 4, 2008 at 3:12 PM, Frans wrote: > I suspect that there isn't a list kept on the servers to what you have > given permission_debit. So it would only be usefull for things you do know > of, which in most cases you can revoke by reseting the script anyway. > > On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby > wrote: > >> Hey all, just wanted to ask if there's been any discussion as to why the >> RevokePermissions message hasn't been implemented in the official viewer. >> It seems to be in working order all this time from what I can tell. But the >> official viewer even goes so far as to warn that you "can't revoke this" in >> the PERMISSION_DEBIT dialog. Is there some issue with it that noone is >> aware of? >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming > _______________________________________________ > 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/20080604/d48f2d3d/attachment.htm From darien_caldwell at comcast.net Wed Jun 4 12:48:54 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Wed Jun 4 12:49:05 2008 Subject: [sldev] Cache speed experiment & results... Message-ID: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? -------------- Original message ---------------------- From: Alex Dailey > A humorous side note to this. The distribution of uuid's is so random > and there is so much 'space' between values, that Cory et al. joked > about putting phony assets in the early range, ...0000000, 0000001 that > rezz'ed signs saying things like, "Give up now!" and "Abandon your quest > or despair!" for people who tried to guess asset_id's starting from the > beginning of the uuid range. > > Kent Quirk (Q Linden) wrote: > > > > On Jun 4, 2008, at 12:54 PM, Celierra Darling wrote: > > > >> On Wed, Jun 4, 2008 at 12:37 PM, Dale Mahalko > >> wrote: > >>> My only concern is that the GUID distribution is may be just merely > >>> pseudo-random. ... > >> > >> Why not hash the (entire) GUID and use that instead? > > > > The point of a GUID is that it's already random. Or more correctly, > > "merely" pseudo-random. Not that most computers have a handy source of > > true randomness anyway. > > > > Our GUID generation code is found in lluuid.h/.cpp. There are comments > > in there that indicate that we've thought about distribution and the > > quality of our randomness before. > > > > Which makes sense, given that we have to store *all* of those assets > > ourselves. If they had a tendency to sort themselves into buckets, > > we'd have a lot more trouble managing them than any external caching > > scheme will. I don't think this is something to bother with. > > > > Q > > _______________________________________________ > > 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 robin.cornelius at gmail.com Wed Jun 4 13:25:36 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 13:25:42 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: <4846FA40.4010102@gmail.com> darien_caldwell@comcast.net wrote: > This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your specific question its 1/4294967296 (1 in about 4.2 billion). Chance of winning the UK lottery is about 1/14 Million for a perspective BUT i can generate *vastly* more assets than i can ever buy lottery tickets and they are being generated by a lot of sources. But 8 may provide a useful sort providing you do allow for the possibility of a collision and have a fall back to higher precision. Either that or i've gone nuts and cant do math(s) any more, which is not an unreasonable assumption. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/814ce701/signature.pgp From robin.cornelius at gmail.com Wed Jun 4 13:27:31 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 13:27:36 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> Message-ID: <4846FAB3.1060009@gmail.com> Robin Cornelius wrote: > darien_caldwell@comcast.net wrote: >> This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? >> > > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). Oh assuming a perfect random (white) distribution of cause, any error, grouping, bais or offset throws this to the dogs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/0e059355/signature-0001.pgp From thordain at thordain.com Wed Jun 4 13:28:19 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jun 4 13:28:22 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> Message-ID: Maybe I'm just reading this wrong, but the bandwidth is availible in tiers. I haven't used Road Runner for some years, but it _used_ to be $50.00 PERIOD. Now it's "* [T]iers will range from $29.95 a month for... 768 kilobits per second and a 5-gigabyte monthly cap to $54.90 per month for... 15 megabits per second and a 40-gigabyte cap".* At 40GB per month, that's 40,960MB per month which (assuming your calculations are correct at 4MB per minute) is 28 days straight access without ceasing activity. Don't get me wrong, I think Time Warner is shooting below the belt with a max 40GB cap, but tiered access makes perfect sense. Grandma who wants to read her GMail from her grandsons and browse the internet for better sugar cookie recipies shouldn't have to pay $49.99 a month, and she'll never use 40GB. Also, they appear to be offering symmetric 15MBps for their higher tier plan (probably trying to compete with FIOS) which is quite an upgrade from what they used to offer. I'm not defending Time Warner Cable here because for the most part I think they're a bunch of idiots (having used their services for years), but I'm hearing an awful lot of doom and gloom about "SL and the media-rich internet going away now" and I just don't think that's going to happen here. TWC is the only major broadband service provider in the US offering a cap of less than 100-GB/month, and they are doing this as a trial for two months where they won't even be charging overage fees. If their pilot program goes bad (and tiered access for them has before) they'll likely ditch it. If not, AT&T and Verizon both sell 7Mbps DSL plans with unlimited bandwidth for around $30.00. My feeling is alot of people will be switching to DSL at that point if they don't see the light. On Wed, Jun 4, 2008 at 3:22 PM, Frans wrote: > 5GB doesn't sounds like much if you video chat and use services like joost > and hulu. > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming > _______________________________________________ > 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/20080604/0a7596bb/attachment.htm From soft at lindenlab.com Wed Jun 4 13:37:40 2008 From: soft at lindenlab.com (Soft) Date: Wed Jun 4 13:37:43 2008 Subject: LLUUID collisions - was Re: [sldev] Cache speed experiment & results... Message-ID: On Wed, Jun 4, 2008 at 2:48 PM, wrote: > This reminds me of something I once pondered. Do you think the UUIDs > are random enough, that one could rely on a comparison of only the > first 8 digits as a sort of quick and dirty identification? What would the > chance be of a false match in such a case? http://en.wikipedia.org/wiki/Birthday_problem#Generalizations From q at lindenlab.com Wed Jun 4 14:17:11 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Jun 4 14:17:18 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> Message-ID: <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> On Jun 4, 2008, at 4:25 PM, Robin Cornelius wrote: > darien_caldwell@comcast.net wrote: >> This reminds me of something I once pondered. Do you think the >> UUIDs are random enough, that one could rely on a comparison of >> only the first 8 digits as a sort of quick and dirty >> identification? What would the chance be of a false match in such a >> case? >> > > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits > its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). > > Chance of winning the UK lottery is about 1/14 Million for a > perspective > BUT i can generate *vastly* more assets than i can ever buy lottery > tickets and they are being generated by a lot of sources. But 8 may > provide a useful sort providing you do allow for the possibility of a > collision and have a fall back to higher precision. > > Either that or i've gone nuts and cant do math(s) any more, which is > not > an unreasonable assumption. There are a couple more issues here: a) UUIDs are constructed from a collection of bytes, some of which are a timestamp. Using a subset of them might well lead to collisions. b) The probability of a collision if you only use 8 bits is about 1.1% if you have 10K items, and about 68% if you have 100K items. That seems WAY too high to me. It's the birthday "paradox" -- the probability that two people have the same birthday. In python, the formula is: import math def birthday(n, bits): return 1. - math.exp((-(n*n) / (2.*pow(2, bits)))) >>> birthday(10000, 32) 0.011574031737030754 >>> birthday(100000, 32) 0.68781309569379223 >>> birthday(1000, 32) 0.00011640854582628535 Why bother? Comparing strings is slowest if they agree, and fastest if they disagree...so you only pay for a full length comparison if they're the same, which is then swamped by what you do with the item once you've found it. This definitely feels like an unnecessary "optimization". From robin.cornelius at gmail.com Wed Jun 4 14:44:40 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 14:44:49 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> Message-ID: <48470CC8.60702@gmail.com> Kent Quirk (Q Linden) wrote: > There are a couple more issues here: > > a) UUIDs are constructed from a collection of bytes, some of which are a > timestamp. Using a subset of them might well lead to collisions. > b) The probability of a collision if you only use 8 bits is about 1.1% > if you have 10K items, and about 68% if you have 100K items. That seems > WAY too high to me. It's the birthday "paradox" -- the probability that > two people have the same birthday. In python, the formula is: Yes of cause and thanks soft for the link too. I only considered a single match which was a straight probability but we are considering a match in a pool where any member can match any other member so the actual resultant probability drops substantially in relation to the square of the pool size. I did warn you about my math(s) ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080604/449d7649/signature.pgp From Celierra at gmail.com Wed Jun 4 14:51:48 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Jun 4 14:51:52 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: On Wed, Jun 4, 2008 at 3:48 PM, wrote: > This reminds me of something I once pondered. Do you think the UUIDs are random enough, that one could rely on a comparison of only the first 8 digits as a sort of quick and dirty identification? What would the chance be of a false match in such a case? > The texture console already does this. :) But the tradeoff for the texture console is much better than for looking up in the cache, since the full UUID would be overkill for the console's purposes. ~Cel From darien_caldwell at comcast.net Wed Jun 4 16:24:12 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jun 4 16:24:17 2008 Subject: [sldev] Cache speed experiment & results... References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <57365872-AE9B-4AD3-858F-8900AAD2EE58@lindenlab.com> Message-ID: <87EE6574C29C413CB85C0E4165C2EB07@a644000> Thanks Quarl, Robin, and Soft for your replies. Initially i was thinking like Robin first stated, but was concerned I might be missing something. And I was. :) ----- Original Message ----- From: "Kent Quirk (Q Linden)" To: Cc: ; "Second Life Developer Mailing List" Sent: Wednesday, June 04, 2008 2:17 PM Subject: Re: [sldev] Cache speed experiment & results... > > On Jun 4, 2008, at 4:25 PM, Robin Cornelius wrote: > >> darien_caldwell@comcast.net wrote: >>> This reminds me of something I once pondered. Do you think the UUIDs >>> are random enough, that one could rely on a comparison of only the >>> first 8 digits as a sort of quick and dirty identification? What would >>> the chance be of a false match in such a case? >>> >> >> Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its >> 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your >> specific question its 1/4294967296 (1 in about 4.2 billion). >> >> Chance of winning the UK lottery is about 1/14 Million for a perspective >> BUT i can generate *vastly* more assets than i can ever buy lottery >> tickets and they are being generated by a lot of sources. But 8 may >> provide a useful sort providing you do allow for the possibility of a >> collision and have a fall back to higher precision. >> >> Either that or i've gone nuts and cant do math(s) any more, which is not >> an unreasonable assumption. > > There are a couple more issues here: > > a) UUIDs are constructed from a collection of bytes, some of which are a > timestamp. Using a subset of them might well lead to collisions. > b) The probability of a collision if you only use 8 bits is about 1.1% if > you have 10K items, and about 68% if you have 100K items. That seems WAY > too high to me. It's the birthday "paradox" -- the probability that two > people have the same birthday. In python, the formula is: > > import math > def birthday(n, bits): > return 1. - math.exp((-(n*n) / (2.*pow(2, bits)))) > > >>> birthday(10000, 32) > 0.011574031737030754 > >>> birthday(100000, 32) > 0.68781309569379223 > >>> birthday(1000, 32) > 0.00011640854582628535 > > > Why bother? Comparing strings is slowest if they agree, and fastest if > they disagree...so you only pay for a full length comparison if they're > the same, which is then swamped by what you do with the item once you've > found it. This definitely feels like an unnecessary "optimization". > > > From jake at lindenlab.com Wed Jun 4 17:15:35 2008 From: jake at lindenlab.com (Jake Simpson) Date: Wed Jun 4 17:15:40 2008 Subject: [sldev] Puppettering Branch Message-ID: <48473027.9090101@lindenlab.com> Some of you may have noticed there's a new build package on S3 named "Puppeteering". The link to it is here - http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset urls is http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) I wanted to give you some background on what it is, why it's there and what it can do. Puppeteering is a project that we had going last year that we dropped in order to focus on stability issues. Note, at the time this was a pretty contentious move, some internal people were fairly upset about it (one even quit over it) but it was deemed necessary for focus on stability to be the main issue. Also, using a mouse to actually generate animation is less instinctual than we had originally imagined and that was another nail in the coffin. The basic idea of the project was to enable real time animation of the avatar, via mouse so that you can animate on the fly and other people can see you doing it. Therefore there is (obviously) some simulator side code that's not being released and which is not in our current simulator releases, nor is there much intent to really make it so. However, the client side code works fine without the simulator data passing code - it's just that no one else logged in can see you when you do the puppeteering animation. Now we recently resurrected this code and have distributed it to various partners who have items in the works that might well end up using this code - basically we've given it to them, said "see if you can make something compelling with it, and if you can, we may reconsider finishing up the simulator code and pushing it through". Anyway, to cut a long story short we (myself and Robla) thought about it and said "Well, if they can't, maybe the SLDev crew can do something with this" and with that we decided to publish the code to you guys. The code itself is somewhat complete - there are definitely some things we would do differently and there are still definitely bugs in there, but right now it's pretty unlikely that we will return to this to complete it or refactor that which we would want to change with the code and intent as it stands. So, this is unsupported code, lets be clear, but it's out there and if you guys can do cool things with it then we would definitely love to see it. It's based off 1.19.1 by the way, and we do actually have a region on aditi that is running the simulator code (note, again, this code is relatively incomplete and the simulator could well crash) named Puppeteering (You may well need to log directly into it by they way). Enjoy. Jake Simpson From loom at loomiverse.net Wed Jun 4 17:26:08 2008 From: loom at loomiverse.net (Loom) Date: Wed Jun 4 17:26:10 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: References: <175218.2716.qm@web59111.mail.re1.yahoo.com> <1218b5bc0806040007l67c6cce1m65a79cb6e3283e82@mail.gmail.com> <48465917.1010005@weblogsinc.com> <7765f2c60806041222r4fceeebfo29365a0da3082006@mail.gmail.com> Message-ID: FWIW, Australia has had metered broadband for years. Aside from the argument about whether that is good or bad, it hasn't stopped us using the internet, Secondlife, torrents, p2p, WoW or much else I can't say I'm happy with what seems to be happening in the US, since it is justifies what our ISP's have been doing for years, but I am farily confident that it isn't going to end SL for anyone. Loom Kish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/4c9554b1/attachment.htm From loom at loomiverse.net Wed Jun 4 17:41:42 2008 From: loom at loomiverse.net (Loom) Date: Wed Jun 4 17:41:44 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> Message-ID: On 04/06/2008, Darien Caldwell wrote: > > If you were to run the client at full bandwidth available (1500kb) non > stop 24/7, you would use up the proposed 240 gbit a month Comcast is > proposing in 48 hours. Fortunately, most people don't eat up that much. A > sustained data rate of 275kbps 8 hours a day for 30 days would use up the > 240 gbit limit. Key word is sustained, sitting in a sim doing nothing > it's rare you get a transfer rate over 50kbps. It would be interesting to > see how a normal session averages out however. This certainly will impact > heavy users (like me), but to the average user, they won't see any problems. > > I think that you might be comparing Gigabits and Gigabytes there, since bandwidth is measured in Gbps and the cap is measured in GB. 275kbps for 8 hours a day for 30 days is about 24 GB, not 240 and thats allowing 10 bits to the byte to err on the side of caution Using the same number 1500kbps used 24/7 would take just under 20 days to use 250GB Loom Kish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3f3e52d3/attachment.htm From darien_caldwell at comcast.net Wed Jun 4 18:06:27 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jun 4 18:06:32 2008 Subject: [sldev] Cache speed experiment & results... References: <617974.16404.qm@web59110.mail.re1.yahoo.com><3F4CFF5865E24F59AA9AD162B7A0DAAA@a644000> Message-ID: <164E7CC7409F4E0887935BDC18DA3561@a644000> You are probably right. I've always found the units a little confusing. But i like your numbers even better than mine. ^.^ ----- Original Message ----- From: Loom To: Second Life Developer Mailing List Sent: Wednesday, June 04, 2008 5:41 PM Subject: Re: [sldev] Cache speed experiment & results... On 04/06/2008, Darien Caldwell wrote: If you were to run the client at full bandwidth available (1500kb) non stop 24/7, you would use up the proposed 240 gbit a month Comcast is proposing in 48 hours. Fortunately, most people don't eat up that much. A sustained data rate of 275kbps 8 hours a day for 30 days would use up the 240 gbit limit. Key word is sustained, sitting in a sim doing nothing it's rare you get a transfer rate over 50kbps. It would be interesting to see how a normal session averages out however. This certainly will impact heavy users (like me), but to the average user, they won't see any problems. I think that you might be comparing Gigabits and Gigabytes there, since bandwidth is measured in Gbps and the cap is measured in GB. 275kbps for 8 hours a day for 30 days is about 24 GB, not 240 and thats allowing 10 bits to the byte to err on the side of caution Using the same number 1500kbps used 24/7 would take just under 20 days to use 250GB Loom Kish ------------------------------------------------------------------------------ _______________________________________________ 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/20080604/6c43ba2b/attachment.htm From gbrandon at gmail.com Wed Jun 4 19:12:35 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 19:12:39 2008 Subject: [sldev] RevokePermissions In-Reply-To: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> References: <7765f2c60806041212i25b53fd9pff59a018197dcb61@mail.gmail.com> Message-ID: In some cases, I think it'd be good enough to just have a menu option like Tools > Revoke Permissions (or Advanced?) for now. Like if you gave someone's attachment permission to play animations and they abused it, you could just select it and then hit that menu option The server-side list is an interesting idea, wonder if that's perhaps what it was waiting on? On Wed, Jun 4, 2008 at 3:12 PM, Frans wrote: > I suspect that there isn't a list kept on the servers to what you have > given permission_debit. So it would only be usefull for things you do know > of, which in most cases you can revoke by reseting the script anyway. > > On Wed, Jun 4, 2008 at 9:59 AM, Brandon Lockaby > wrote: > >> Hey all, just wanted to ask if there's been any discussion as to why the >> RevokePermissions message hasn't been implemented in the official viewer. >> It seems to be in working order all this time from what I can tell. But the >> official viewer even goes so far as to warn that you "can't revoke this" in >> the PERMISSION_DEBIT dialog. Is there some issue with it that noone is >> aware of? >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > -- > Jeroen Frans > The Vesuvius Group > http://www.thevesuviusgroup.com > http://www.linkedin.com/in/mrfrans > SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/3033e7a6/attachment.htm From secret.argent at gmail.com Wed Jun 4 19:24:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 19:23:14 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FAB3.1060009@gmail.com> References: <060420081948.26811.4846F1A6000293DE000068BB221556888404040A990B040E0CA1020A079D0E0B@comcast.net> <4846FA40.4010102@gmail.com> <4846FAB3.1060009@gmail.com> Message-ID: <42DFFCF9-0BFB-480F-B26F-0D40D562382A@gmail.com> On 2008-06-04, at 15:27, Robin Cornelius wrote: > Robin Cornelius wrote: >> Well for the 1st digit there is a 1/16 chance of a hit, for 2 >> digits its >> 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your >> specific question its 1/4294967296 (1 in about 4.2 billion). > > Oh assuming a perfect random (white) distribution of cause, any error, > grouping, bais or offset throws this to the dogs. Of course the next question is... what's the consequences of a false positive? If it's "you compare the whole thing", it doesn't matter. A common trick in C is something like this: if(*s == *t && strcmp(s, t)==0) { ... } If *s and *t are uniformly distributed, you save 255/256 calls. If they're both letters, you save 25 out of 26. If that's in a tight loop, it's worth doing. From secret.argent at gmail.com Wed Jun 4 19:29:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 4 19:28:17 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> > Anyway, to cut a long story short we (myself and Robla) thought > about it and said "Well, if they can't, maybe the SLDev crew can do > something with this" and with that we decided to publish the code > to you guys. What I'd like to do with this would require server-side access. I don't want to drag my hand with my mouse, I want to tell my hand "track this prim". And I want to do it from a script. Why? Well, how about so I can walk along holding someone's hand, because they're wearing the prim I'm tracking... not because we're both riding a vehicle that's animating walks for both of us. So when I'm riding a vehicle, it can make my hands hold onto the handlebars, without my having to change the animation based on the avatar size. Automated puppetteering. From me at signpostmarv.name Wed Jun 4 21:28:06 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Jun 4 21:28:12 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <48476B56.6040004@signpostmarv.name> Argent Stonecutter wrote: >> Anyway, to cut a long story short we (myself and Robla) thought about >> it and said "Well, if they can't, maybe the SLDev crew can do >> something with this" and with that we decided to publish the code to >> you guys. > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand > "track this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's hand, > because they're wearing the prim I'm tracking... not because we're > both riding a vehicle that's animating walks for both of us. > > So when I'm riding a vehicle, it can make my hands hold onto the > handlebars, without my having to change the animation based on the > avatar size. > > Automated puppetteering. something along those lines ? : http://jira.secondlife.com/browse/SVC-2478 http://jira.secondlife.com/browse/SVC-2479 ~ Marv -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/dbe32273/smime.bin From gbrandon at gmail.com Wed Jun 4 21:53:48 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Jun 4 21:53:51 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: Assuming LL doesn't write a simulator for you, might I suggest the possiblity of using slproxy to emulate the server-side behaviors? :D On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter wrote: > Anyway, to cut a long story short we (myself and Robla) thought about it >> and said "Well, if they can't, maybe the SLDev crew can do something with >> this" and with that we decided to publish the code to you guys. >> > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand "track > this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's hand, because > they're wearing the prim I'm tracking... not because we're both riding a > vehicle that's animating walks for both of us. > > So when I'm riding a vehicle, it can make my hands hold onto the > handlebars, without my having to change the animation based on the avatar > size. > > Automated puppetteering. > > _______________________________________________ > 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/20080605/d9225109/attachment.htm From kf6kjg at gmail.com Wed Jun 4 22:30:45 2008 From: kf6kjg at gmail.com (Ricky) Date: Wed Jun 4 22:30:49 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error Message-ID: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> Ok, I am trying to compile the latest from SVN in a 32 bit chroot on my 64 bit Gentoo desktop. I was able to compile the cmake-8 branch a while ago (with a patch I made to one of the files) so I think I have all the requirements in place... Maybe. This chroot is the first I have ever made! :D Here is the error thrown: Linking CXX executable linux-crash-logger /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Realloc' /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Alloc' /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ libpangoft2-1.0.so: undefined reference to `FT_Free' collect2: ld returned 1 exit status make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] Error 2 make: *** [all] Error 2 Any ideas on what I am missing? I looked through JIRA to see if anythign had been reported, and I've been monitoring this list and heard nothing, so it very well might just be me... :) If there is a missing dependency, could the cmake script check for it? Or would that be better done by the person/script doing the compiling? Thanks for the info! Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/45e01306/attachment.htm From danteferret at gmail.com Wed Jun 4 23:15:37 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Jun 4 23:15:45 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> Out of curiosity how is this client used? I compiled, went to the sim on aditi, and I see no aditional functionality from the standard client. (sorry for the double mail Brandon) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/dedcf07f/attachment.htm From kfa at gmx.net Wed Jun 4 23:18:01 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jun 4 23:20:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <48478519.2080106@gmx.net> Argent Stonecutter wrote: >> Anyway, to cut a long story short we (myself and Robla) thought about >> it and said "Well, if they can't, maybe the SLDev crew can do >> something with this" and with that we decided to publish the code to >> you guys. > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my hand > "track this prim". > Has anyone thought of this... well I'm sure many have before! Teaching in SL is already a big thing, and it could be much much bigger if we had better tools to simulate a real classroom situation. Better control of an avatar's hand would be a hinge for a ton of enhancements. I've taken some language courses in SL and it always was glaringly obvious that we missed a pointing device. A laser pointer or just a stick. It should be possible to translate the mouse position over a certain prim (the white/black board) into the target of a "look at" function to rotate the avatar's hand (or what it's holding) accordingly. More sophisticated, I'd like to use one of those graphics pads, capture what I'm drawing into a video stream (Gimp + CamStudio ?) and let that appear on the said white board, and together with the positional information from the same graphics pad (it's functionally the same as a mouse) simulate my avatar drawing it live there before everyone's eyes. Is that code going in a direction to enable such a thing? Felix PS: Actually, to me this sounds like a worthy project for a dedicated group even more than - forgive me - the NAV project. Immersion and realism would get a quantum leap forward and there is business in this. From robin.cornelius at gmail.com Wed Jun 4 23:22:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jun 4 23:22:37 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> Message-ID: <4847862B.7060509@gmail.com> Ricky wrote: > Linking CXX executable linux-crash-logger > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Realloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Alloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Free' > collect2: ld returned 1 exit status > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] > Error 2 > make: *** [all] Error 2 > > > Any ideas on what I am missing? I looked through JIRA to see if > anythign had been reported, and I've been monitoring this list and heard > nothing, so it very well might just be me... :) Free type library (libfreetype), There is a right mix of building methods being used so unless you are building the offical linden version in a chroot no one would spot this kind of thing. I only ever build standalone versions on linux so i have to supply my own libpango anyway which has a hard dependency of libfreetype, and many others probably have libfreetype-dev installed (or what ever you do on gentoo) so it just worked for them. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/19b53b3a/signature.pgp From kf6kjg at gmail.com Wed Jun 4 23:55:19 2008 From: kf6kjg at gmail.com (Ricky) Date: Wed Jun 4 23:55:21 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <4847862B.7060509@gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> Message-ID: <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> hmm... According to portage (the package management system for Gentoo) I already have freetype 2.3.5-r2 installed in the chroot. (For those who speak emerge:) # emerge -pv media-libs/freetype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/freetype-2.3.5-r2 USE="X -bindist -debug -doc -utils" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB On Wed, Jun 4, 2008 at 11:22 PM, Robin Cornelius wrote: > Ricky wrote: > > Linking CXX executable linux-crash-logger > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Realloc' > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Alloc' > > > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ > libpangoft2-1.0.so > > : undefined reference to `FT_Free' > > collect2: ld returned 1 exit status > > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > > make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] > > Error 2 > > make: *** [all] Error 2 > > > > > > Any ideas on what I am missing? I looked through JIRA to see if > > anythign had been reported, and I've been monitoring this list and heard > > nothing, so it very well might just be me... :) > > Free type library (libfreetype), > > There is a right mix of building methods being used so unless you are > building the offical linden version in a chroot no one would spot this > kind of thing. I only ever build standalone versions on linux so i have > to supply my own libpango anyway which has a hard dependency of > libfreetype, and many others probably have libfreetype-dev installed (or > what ever you do on gentoo) so it just worked for them. > > Robin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080604/da623854/attachment-0001.htm From sldev at bitparts.org Thu Jun 5 00:10:49 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Thu Jun 5 00:11:02 2008 Subject: [sldev] Error (misspelling) in lltexturefetch.cpp Message-ID: <48479179.6090309@bitparts.org> So after all this cache discussion, I decided to download the source and see if I could find some way to cache files decoded. Unfortunately, while I'm a C Guru, I'm yet again slapping my hands for not seriously learning C++. However, while I stumbled around, I came across this - lltexturefetch.cpp, line 228 (from slviewer-src-Branch_1-20-7-Viewer-r88152.zip): void relese() { --mActiveCount; } I searched the rest of the entire project, and found no other occurrences of "relese" - could this be a problem? Is something searching for "release" and not finding it, or has the function been deprecated? From danteferret at gmail.com Thu Jun 5 00:45:52 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 5 00:45:56 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> Message-ID: <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: puppetter.png Type: image/png Size: 502697 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080605/6fc8d045/puppetter-0001.png From robin.cornelius at gmail.com Thu Jun 5 00:54:45 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 00:54:49 2008 Subject: [sldev] Error (misspelling) in lltexturefetch.cpp In-Reply-To: <48479179.6090309@bitparts.org> References: <48479179.6090309@bitparts.org> Message-ID: > void relese() { --mActiveCount; } > > I searched the rest of the entire project, and found no other occurrences of > "relese" - could this be a problem? Is something searching for "release" and > not finding it, or has the function been deprecated? Looks like a dead function, certainly nothing is trying to call it or it would be a compile/link error. Greping through the code mActiveCount does not appear to do anything either, looks like it was trying to count the number of active texture worker threads, it may be part of the "enable multiple threads" plan which works to a point but some report deadlocks. As for the caching of decoded files, my inital gut feeling is that you can cache them in the WRITE_TO_CACHE state of the state machine, by swapping out the mFormattedImage->getData() to the buffer that was retrieved in DECODE_IMAGE and the reverse operation in LOAD_FROM_TEXTURE_CACHE needs to load them into the raw image buffer not the mFormattedImage, the recall will probably be a little harder as you need to ensure the buffers are big enough and you will have to rig the states so it can jump stright over to DONE after that and make sure there are no mFormattedImage memory allocations left around. Discard will just be ignored for a cache hit. I've started looking but as usual time is the limiting factor. Robin From robin.cornelius at gmail.com Thu Jun 5 01:10:30 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 01:10:33 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 7:55 AM, Ricky wrote: > hmm... According to portage (the package management system for Gentoo) I > already have freetype 2.3.5-r2 installed in the chroot. > And i am being stupid at the same time, its complaining of missing symbols not a missing library so its not even attempting to link against freetype. But it must have found the freetype headers. STANDALONE uses pkgconfig in indra/Freetype.cmake which will set the CFLAGS and LDFLAGS correctly, something is missing somewhere then in the standard build? Has it detected you are on 64bit and changed the library location to libraries/x86_64-linux which i presume there are no prebuild libs for? From evolutie at gmail.com Thu Jun 5 01:50:34 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 01:50:37 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <5fb4b1fa0806050150i628f9118v226c768be07ad6a1@mail.gmail.com> ohhh! i'm so happy about this!! thanks!! Evo On Thu, Jun 5, 2008 at 2:15 AM, Jake Simpson wrote: > Some of you may have noticed there's a new build package on S3 named > "Puppeteering". The link to it is here - > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset > urls is > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) > > I wanted to give you some background on what it is, why it's there and what > it can do. > > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one even > quit over it) but it was deemed necessary for focus on stability to be the > main issue. Also, using a mouse to actually generate animation is less > instinctual than we had originally imagined and that was another nail in the > coffin. > > The basic idea of the project was to enable real time animation of the > avatar, via mouse so that you can animate on the fly and other people can > see you doing it. Therefore there is (obviously) some simulator side code > that's not being released and which is not in our current simulator > releases, nor is there much intent to really make it so. However, the client > side code works fine without the simulator data passing code - it's just > that no one else logged in can see you when you do the puppeteering > animation. > > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this code > - basically we've given it to them, said "see if you can make something > compelling with it, and if you can, we may reconsider finishing up the > simulator code and pushing it through". > > Anyway, to cut a long story short we (myself and Robla) thought about it and > said "Well, if they can't, maybe the SLDev crew can do something with this" > and with that we decided to publish the code to you guys. > > The code itself is somewhat complete - there are definitely some things we > would do differently and there are still definitely bugs in there, but right > now it's pretty unlikely that we will return to this to complete it or > refactor that which we would want to change with the code and intent as it > stands. > > So, this is unsupported code, lets be clear, but it's out there and if you > guys can do cool things with it then we would definitely love to see it. > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > > Enjoy. > > Jake Simpson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- http://www.creativemachinery.org From secret.argent at gmail.com Thu Jun 5 04:12:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 5 04:11:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48476B56.6040004@signpostmarv.name> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <48476B56.6040004@signpostmarv.name> Message-ID: <318BF2E8-017D-4481-BF09-78D5BFED2ED4@gmail.com> On 2008-06-04, at 23:28, SignpostMarv Martin wrote: > something along those lines ? : > > http://jira.secondlife.com/browse/SVC-2478 > http://jira.secondlife.com/browse/SVC-2479 Except for being immensely simpler to specify and implement, yes. SL already has code to track prims with attachment points, your left hand uses them every time you edit an object. And by tracking a prim you're not restricted to tracking avatars, but you get that for free. From secret.argent at gmail.com Thu Jun 5 04:19:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 5 04:17:50 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> On 2008-06-04, at 23:53, Brandon Lockaby wrote: > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D I'm not sure how SLProxy would help... the important bit would be scripted. llTrackPrim(integer joint, key prim, integer distance, integer strictness, integer follow_rotation); While prim is in range of motion of joint, joint is constrained to remain in distance meters of the center of prim. Strictness indicates how quickly it would track the prim, and follow_rotation whether it should try and rotate the joint to match the angle of the prim. It would apply to the owner or the avatar for which the script has appropriate permissions. From blindwanderer at gmail.com Thu Jun 5 07:09:18 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Thu Jun 5 07:09:21 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <89ca6da00806050709v7f6e585ekf393bb9e51f86941@mail.gmail.com> Hey jake, just noticed a bug in SVN-616 (R88154). There is a collision in /indra/llmessage/llregionflags.h between REGION_FLAGS_BLOCK_PUPPETEERING and REGION_FLAGS_BLOCK_PARCEL_SEARCH. I've posted a patch on Jira. https://jira.secondlife.com/browse/VWR-7606 On Wed, Jun 4, 2008 at 8:15 PM, Jake Simpson wrote: > Some of you may have noticed there's a new build package on S3 named > "Puppeteering". The link to it is here - > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/. (asset > urls is > http://svn.secondlife.com/svn/linden/branches/Puppeteering080323/doc/asset_urls.txt) > > I wanted to give you some background on what it is, why it's there and what > it can do. > > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one even > quit over it) but it was deemed necessary for focus on stability to be the > main issue. Also, using a mouse to actually generate animation is less > instinctual than we had originally imagined and that was another nail in the > coffin. > > The basic idea of the project was to enable real time animation of the > avatar, via mouse so that you can animate on the fly and other people can > see you doing it. Therefore there is (obviously) some simulator side code > that's not being released and which is not in our current simulator > releases, nor is there much intent to really make it so. However, the client > side code works fine without the simulator data passing code - it's just > that no one else logged in can see you when you do the puppeteering > animation. > > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this code > - basically we've given it to them, said "see if you can make something > compelling with it, and if you can, we may reconsider finishing up the > simulator code and pushing it through". > > Anyway, to cut a long story short we (myself and Robla) thought about it and > said "Well, if they can't, maybe the SLDev crew can do something with this" > and with that we decided to publish the code to you guys. > > The code itself is somewhat complete - there are definitely some things we > would do differently and there are still definitely bugs in there, but right > now it's pretty unlikely that we will return to this to complete it or > refactor that which we would want to change with the code and intent as it > stands. > > So, this is unsupported code, lets be clear, but it's out there and if you > guys can do cool things with it then we would definitely love to see it. > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > > Enjoy. > > Jake Simpson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Thu Jun 5 08:09:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jun 5 08:09:24 2008 Subject: [sldev] Re: Open source meeting, call for items Thursday 2PM In-Reply-To: References: Message-ID: Open source meeting - Thursday, 2pm PT in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Last weeks minutes are at :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/2008-05-29 I've added a few issues that i think may be worth discussing, but please if you have anything better thats burning a hole, please add to the wiki page and replace some of my rubbish if it gets too full ;-) # Texture caching, follow up from SLDEV, can we store some kind of uncompressed data etc # VWR-7531 - Dynamic grid loading to the login panel # Puppettering - Jake gave us the source code to discuss and play.. so Discuss! (seriously, not sure if there is much if better items turn up last minute then please replace) # cmake - Hows everyone finding it, build issues, other issues etc From monkowsk at watson.ibm.com Thu Jun 5 08:35:59 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 08:37:46 2008 Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <484807DF.2070806@watson.ibm.com> Was voice moderation and morphing another of the projects that was dropped? (I did see the puppet master's name in the voice code ;-) ) If so, can we have the code for that too? If not, when do you think we might see it? Mike Jake Simpson wrote: > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one > even quit over it) but it was deemed necessary for focus on stability to > be the main issue. From sarah at aucreativegroup.com Thu Jun 5 08:37:46 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 08:37:51 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> Message-ID: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Hello all! Thank you so much for your feedback and comments on the Landmarks & Navigation project. My name is Kippie Friedkin and I'm a member of the Vectorform team. The team has been watching the threads and taking into consideration all of your input. We're excited that there has been so much interest in this project! Working on an open source project is a great learning experience for us, so we've been careful to respond with accuracy. Now we'll work on responding with a little more speed. As we have begun to define the design and functionality, we're better positioned to understand and discuss the technical issues. I thought I'd begin this note with an update on the project - where we've been, where we are, and where we're going. *Where we've been *The project began with a massive research phase that encompassed Office Hours discussions, interviews with Residents (both new and veteran), scouring Second Life blogs, researching resident-created tools, reviewing other Viewers and a host of web apps. During this phase, it was our goal to learn how Residents navigate in-world and how they create, use, and manage Landmarks. We solicited feedback on their pain points, ideas, and general comments that touched on Inventory, Landmarks, navigation, and User Picks. At the end of this research phase, we presented our finding to Linden Lab as well as some initial mockups and wireframes that would satisfy some of the project goals (as stated on the WIKI) as: - *To create a history of locations visited*, presented in some visual fashion, which may include: - Back & forward buttons for teleporting through location history - Prominent on-screen affordance for accessing/adding Landmarks - *To improve the existing, or create a new, system for managing Landmarks*, which should support the following: - Sorting, re-ordering - Organizing into folders or similar - Renaming - Sharing - Tagging - *To create a new navigation panel* (ie. the visual container for the new UI components) - To provide the ability to hide/show this panel. A few other things were investigated and discussed at the project's onset: 1. Removing Landmarks from Inventory, in favor of a new system for managing Landmarks. 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Discussions with Residents quickly removed these two items from the scope of this project. Removing Landmarks from the Inventory is an extremely difficult thing from to do from an implementation perspective. It also means that one of our project requirements - that of backwards compatibility - was broken. So it was determined that Landmarks were best left a part of the Inventory. As noted, there are many ways a Landmark can end up in one's Inventory, and the pros of Landmarks being left where they are, very quickly outweighed any cons that currently exist. With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is. *Where we are today *The Vectorform team has spent the past few weeks working on wireframes and designs for the newly proposed features. Based on our research, Resident feedback, and meetings with Linden Lab, we are building the following features in the Viewer: 1. *Navigation Panel* The Navigation panel will include forward, back, home and history buttons, as well as an address/location text box and 'go' button. The designs are being revised and updated to fit more into the new Dazzle style with insight and feedback from Residents and Lindens. The Navigation Panel can be able to be shown or hidden using both a small toggle at the top-left of the Viewer as well a keyboard shortcut - "/". (We are still determining if this will work as a shortcut key, but an initial review indicated it was not being used by another UI element - so this is TBD). In between the back and forward buttons will be a small, history button which will allow a Resident to view the list of places he/she has visited during that session. The number of places stored in this history and whether it persists between sessions can be set in ones User Preferences. The name of the parcel and region will be shown in the location history. Mousing over an item in the list will reveal additional info (SLURL? How long ago you were there?) Clicking the back or forward button will automatically teleport the Resident back/foward in their location history. Clicking the home button will teleport the Resident back to his/her home location. Address Bar - The address bar will display a SLURL by default. Users can enter a SLURL, or Region name in their Inventory. If the Resident types in a Region name that is not in their Inventory, we will go a global search to find the location. If the location cannot be found, the Search floater will open. 2. *User Preferences *We are introducing a new tab to the User Preferences floater that will providing users the ability to: - Set the number of days to store location history - Set the number of days to store address bar history - Clear the history of either of the above two items - Export Landmarks in HTML, TXT, or XML formats 3. *Create/Edit Landmarks UI* Residents will now be able to add a custom name and stores notes when creating or editing a Landmark. There will also be the option to select or create a folder when creating/editing Landmarks. All Landmarks and their folders will be will be placed into the Landmarks folder in the Inventory floater. To clear up any confusion, the following circumstances will still apply: - Landmarks received from purchased objects will remain with the object/folder as they are created. - Landmarks received view Inventory transfer will be placed into a Received Landmarks folder by default, but also allow for the Resident to edit and select a folder in which to place the Landmark. - Landmarks received via automatic givers will also be placed into the Received Landmarks folder, by default. Still TBD in terms of scoping, but we'd also like to include functionality that allows the Resident to edit and select a folder in which to place the Landmark. - Landmarks embedded in Notecards will not see any change in functionality. The landmark will remain embedded in the Notecard and not accessible except through Notecard access. 4. *Landmarks Menu* A new 'Landmarks' menu will be added to the top menu of the Viewer. The options for this menu are as follows: - Create Landmark - Manage Landmarks - Set Home to Current Location - Teleport Home - Received Landmarks - A sub-folder in the Landmarks folder in Inventory where all received Landmarks are stored by default. - Recent Places - Displays a list of Landmarks a Resident has recented used. - Access to Landmarks located in the Inventory Floater - Residents will now have access to Landmarks stored in the Landmarks folder of their Inventory via this menu. Any sub-folders of the main Landmarks folder will appear in this Landmarks menu and be navigable via this menu. 5. *Manage Landmarks UI* This new UI element is meant to allow residents a filtered via of the Inventory, in which to organize and manage (edit/delete) Landmarks. It consists of a small floater which will almost look like a filter viewed of the Inventory Floater. The Manage Landmarks floater will allow Residents to filter Landmarks, create/edit/delete folders easily, and provide a place (without having to weed through the rest of the Inventory) to edit Landmarks. If you've had a chance to look at the wireframe posted on NAV-28, there are two approaches to the Manage Landmarks UI. At present, we have been asked to proceed with the separated floaters approach (Solution 2). Also, an advanced feature proposed for the Manage Landmarks UI was a Data Sort View which would allow Residents to view, sort, and manage Landmarks from a column set approach (like iTunes). However, at this time, we have been asked to put that feature on hold since it's real benefit has not been clear for all project stakeholders. When editing a Landmarks, Residents will have the ability to specify a custom name, add their own notes to each Landmark. Residents will also have the ability to specify a picture they want to use for a particular Landmark. Our technical team is also reviewing the possibility of allowing a Resident the option of using/reverting back to the default image for this location (as specified by the Land Owner). It is as of yet undetermined if this feature will be in scope. The Edit Landmarks Floater will include small icons for 'Show on Map' and 'Copy SLURL' to provide additional functionality. Finally, we intend to display additional metadata about the Landmark from the Edit Landmark floater - date acquired, last teleport date, and last updated date. *Shared Landmarks & Tagging *One of our original ideas (and a common suggestion from Residents) has been to include tagging of Landmarks and other Inventory assets. We investigated a couple of ways to create a folksonomy use with Landmarks in Second Life during the first phase of our project. However, it became clear that tagging functionality would be useful for many other areas and could touch many other areas including search, the web, User Picks, and most Inventory items. Rather than build a small one-off tagging system just for Landmarks, it was decided that creating a true folksonomy that could be used throughout Second Life (For searching, sharing landmarks, creating more a social network, etc.) was a much bigger project than our timeline or project goals would allow for. So tagging functionality was deemed out of scope for this project. *Where we're going! Issues, Risks, Reviews, and Builds! * The design team is working closely with Linden Lab and soliciting Resident feedback on new designs revisions. We hope to have design approachs for the new Nav bar solidifed by the end of this week. In the meantime, our technical team have been working on laying the foundation for the new Navigation bar, as well as spending time researching the items which many of you have spoken about on this list. A few items for which we're actively researching: - Understanding more about SLURLs and their relation to the Agni grid and how they come into play with the beta grid(s). - How the introduction of a new top-left UI element will affect Resident-created HUDs. - How the introduction of forward/back button teleport functionality will affect grid stability. In addition to researching open issues, our tech team is also working on wrapping up a Viewer build (minus approved creative). We will be testing that and reviewing it with Linden Lab over the next week. I would encourage all of you to continue sharing your thoughts and feedback. As I stated at the beginning of this message, the Vectorform team will be much more actively engaged with this list moving forward. Best, Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/1ebaedab/attachment-0001.htm From missannotoole at yahoo.com Thu Jun 5 08:41:02 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 08:41:03 2008 Subject: [sldev] Voice moderation and morphing; was: Voice moderation and morphing; was: [sldev] Puppettering Branch Message-ID: <507402.50528.qm@web59108.mail.re1.yahoo.com> Please put [sldev] as a prefix so these messages won't so easily be flagged and deleted as spam. Thanks. ----- Original Message ---- From: Mike Monkowski To: Jake Simpson Cc: sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:35:59 AM Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch Was voice moderation and morphing another of the projects that was dropped? (I did see the puppet master's name in the voice code ;-) ) If so, can we have the code for that too? If not, when do you think we might see it? Mike Jake Simpson wrote: > Puppeteering is a project that we had going last year that we dropped in > order to focus on stability issues. Note, at the time this was a pretty > contentious move, some internal people were fairly upset about it (one > even quit over it) but it was deemed necessary for focus on stability to > be the main issue. _______________________________________________ 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/20080605/b047cb64/attachment.htm From missannotoole at yahoo.com Thu Jun 5 08:49:31 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 08:49:34 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <328748.69828.qm@web59112.mail.re1.yahoo.com> I previously requested someone look into how this project can impact search and there were no replies so I will reiterate: Profile Picks are part of the new search relevancy. Messing with this breaks search. An external non LL contracted team cannot be allowed to work on things that will result in devastation of the economy. How this can even happen is interesting. Great work and all but who decided to allow you to potentially erase the SL economy? Landmarks were initially listed in the SL blog as being a search relevance factor. The entire discussion of removing landmarks should have never happened without a discussion of this factor first. My recommendation is for the LL search related team to pay more attention to protecting their turf and communicating with this community to ensure everyone understands how this work will or will not impact the new search. ----- Original Message ---- From: Sarah Hutchinson To: sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:37:46 AM Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Hello all! Thank you so much for your feedback and comments on the Landmarks & Navigation project. My name is Kippie Friedkin and I'm a member of the Vectorform team. The team has been watching the threads and taking into consideration all of your input. We're excited that there has been so much interest in this project! Working on an open source project is a great learning experience for us, so we've been careful to respond with accuracy. Now we'll work on responding with a little more speed. As we have begun to define the design and functionality, we're better positioned to understand and discuss the technical issues. I thought I'd begin this note with an update on the project - where we've been, where we are, and where we're going. Where we've been The project began with a massive research phase that encompassed Office Hours discussions, interviews with Residents (both new and veteran), scouring Second Life blogs, researching resident-created tools, reviewing other Viewers and a host of web apps. During this phase, it was our goal to learn how Residents navigate in-world and how they create, use, and manage Landmarks. We solicited feedback on their pain points, ideas, and general comments that touched on Inventory, Landmarks, navigation, and User Picks. At the end of this research phase, we presented our finding to Linden Lab as well as some initial mockups and wireframes that would satisfy some of the project goals (as stated on the WIKI) as: * To create a history of locations visited, presented in some visual fashion, which may include: * Back & forward buttons for teleporting through location history * Prominent on-screen affordance for accessing/adding Landmarks * To improve the existing, or create a new, system for managing Landmarks, which should support the following: * Sorting, re-ordering * Organizing into folders or similar * Renaming * Sharing * Tagging * To create a new navigation panel (ie. the visual container for the new UI components) * To provide the ability to hide/show this panel. A few other things were investigated and discussed at the project's onset: 1. Removing Landmarks from Inventory, in favor of a new system for managing Landmarks. 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Discussions with Residents quickly removed these two items from the scope of this project. Removing Landmarks from the Inventory is an extremely difficult thing from to do from an implementation perspective. It also means that one of our project requirements - that of backwards compatibility - was broken. So it was determined that Landmarks were best left a part of the Inventory. As noted, there are many ways a Landmark can end up in one's Inventory, and the pros of Landmarks being left where they are, very quickly outweighed any cons that currently exist. With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is. Where we are today The Vectorform team has spent the past few weeks working on wireframes and designs for the newly proposed features. Based on our research, Resident feedback, and meetings with Linden Lab, we are building the following features in the Viewer: 1. Navigation Panel The Navigation panel will include forward, back, home and history buttons, as well as an address/location text box and 'go' button. The designs are being revised and updated to fit more into the new Dazzle style with insight and feedback from Residents and Lindens. The Navigation Panel can be able to be shown or hidden using both a small toggle at the top-left of the Viewer as well a keyboard shortcut - "/". (We are still determining if this will work as a shortcut key, but an initial review indicated it was not being used by another UI element - so this is TBD). In between the back and forward buttons will be a small, history button which will allow a Resident to view the list of places he/she has visited during that session. The number of places stored in this history and whether it persists between sessions can be set in ones User Preferences. The name of the parcel and region will be shown in the location history. Mousing over an item in the list will reveal additional info (SLURL? How long ago you were there?) Clicking the back or forward button will automatically teleport the Resident back/foward in their location history. Clicking the home button will teleport the Resident back to his/her home location. Address Bar - The address bar will display a SLURL by default. Users can enter a SLURL, or Region name in their Inventory. If the Resident types in a Region name that is not in their Inventory, we will go a global search to find the location. If the location cannot be found, the Search floater will open. 2. User Preferences We are introducing a new tab to the User Preferences floater that will providing users the ability to: * Set the number of days to store location history * Set the number of days to store address bar history * Clear the history of either of the above two items * Export Landmarks in HTML, TXT, or XML formats 3. Create/Edit Landmarks UI Residents will now be able to add a custom name and stores notes when creating or editing a Landmark. There will also be the option to select or create a folder when creating/editing Landmarks. All Landmarks and their folders will be will be placed into the Landmarks folder in the Inventory floater. To clear up any confusion, the following circumstances will still apply: * Landmarks received from purchased objects will remain with the object/folder as they are created. * Landmarks received view Inventory transfer will be placed into a Received Landmarks folder by default, but also allow for the Resident to edit and select a folder in which to place the Landmark. * Landmarks received via automatic givers will also be placed into the Received Landmarks folder, by default. Still TBD in terms of scoping, but we'd also like to include functionality that allows the Resident to edit and select a folder in which to place the Landmark. * Landmarks embedded in Notecards will not see any change in functionality. The landmark will remain embedded in the Notecard and not accessible except through Notecard access. 4. Landmarks Menu A new 'Landmarks' menu will be added to the top menu of the Viewer. The options for this menu are as follows: * Create Landmark * Manage Landmarks * Set Home to Current Location * Teleport Home * Received Landmarks - A sub-folder in the Landmarks folder in Inventory where all received Landmarks are stored by default. * Recent Places - Displays a list of Landmarks a Resident has recented used. * Access to Landmarks located in the Inventory Floater - Residents will now have access to Landmarks stored in the Landmarks folder of their Inventory via this menu. Any sub-folders of the main Landmarks folder will appear in this Landmarks menu and be navigable via this menu. 5. Manage Landmarks UI This new UI element is meant to allow residents a filtered via of the Inventory, in which to organize and manage (edit/delete) Landmarks. It consists of a small floater which will almost look like a filter viewed of the Inventory Floater. The Manage Landmarks floater will allow Residents to filter Landmarks, create/edit/delete folders easily, and provide a place (without having to weed through the rest of the Inventory) to edit Landmarks. If you've had a chance to look at the wireframe posted on NAV-28, there are two approaches to the Manage Landmarks UI. At present, we have been asked to proceed with the separated floaters approach (Solution 2). Also, an advanced feature proposed for the Manage Landmarks UI was a Data Sort View which would allow Residents to view, sort, and manage Landmarks from a column set approach (like iTunes). However, at this time, we have been asked to put that feature on hold since it's real benefit has not been clear for all project stakeholders. When editing a Landmarks, Residents will have the ability to specify a custom name, add their own notes to each Landmark. Residents will also have the ability to specify a picture they want to use for a particular Landmark. Our technical team is also reviewing the possibility of allowing a Resident the option of using/reverting back to the default image for this location (as specified by the Land Owner). It is as of yet undetermined if this feature will be in scope. The Edit Landmarks Floater will include small icons for 'Show on Map' and 'Copy SLURL' to provide additional functionality. Finally, we intend to display additional metadata about the Landmark from the Edit Landmark floater - date acquired, last teleport date, and last updated date. Shared Landmarks & Tagging One of our original ideas (and a common suggestion from Residents) has been to include tagging of Landmarks and other Inventory assets. We investigated a couple of ways to create a folksonomy use with Landmarks in Second Life during the first phase of our project. However, it became clear that tagging functionality would be useful for many other areas and could touch many other areas including search, the web, User Picks, and most Inventory items. Rather than build a small one-off tagging system just for Landmarks, it was decided that creating a true folksonomy that could be used throughout Second Life (For searching, sharing landmarks, creating more a social network, etc.) was a much bigger project than our timeline or project goals would allow for. So tagging functionality was deemed out of scope for this project. Where we're going! Issues, Risks, Reviews, and Builds! The design team is working closely with Linden Lab and soliciting Resident feedback on new designs revisions. We hope to have design approachs for the new Nav bar solidifed by the end of this week. In the meantime, our technical team have been working on laying the foundation for the new Navigation bar, as well as spending time researching the items which many of you have spoken about on this list. A few items for which we're actively researching: * Understanding more about SLURLs and their relation to the Agni grid and how they come into play with the beta grid(s). * How the introduction of a new top-left UI element will affect Resident-created HUDs. * How the introduction of forward/back button teleport functionality will affect grid stability.In addition to researching open issues, our tech team is also working on wrapping up a Viewer build (minus approved creative). We will be testing that and reviewing it with Linden Lab over the next week. I would encourage all of you to continue sharing your thoughts and feedback. As I stated at the beginning of this message, the Vectorform team will be much more actively engaged with this list moving forward. Best, Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/487b236b/attachment-0001.htm From dahliatrimble at gmail.com Thu Jun 5 09:01:40 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Jun 5 09:01:43 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: Does (or could) the puppeteering code implement inverse kinematics? On Thu, Jun 5, 2008 at 4:19 AM, Argent Stonecutter wrote: > On 2008-06-04, at 23:53, Brandon Lockaby wrote: > >> Assuming LL doesn't write a simulator for you, might I suggest the >> possiblity of using slproxy to emulate the server-side behaviors? :D >> > > I'm not sure how SLProxy would help... the important bit would be scripted. > > llTrackPrim(integer joint, key prim, integer distance, integer strictness, > integer follow_rotation); > > While prim is in range of motion of joint, joint is constrained to remain > in distance meters of the center of prim. Strictness indicates how quickly > it would track the prim, and follow_rotation whether it should try and > rotate the joint to match the angle of the prim. > > It would apply to the owner or the avatar for which the script has > appropriate permissions. > > > _______________________________________________ > 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/20080605/7a8ca6fb/attachment.htm From tateru.nino at gmail.com Thu Jun 5 09:04:31 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 09:05:15 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <328748.69828.qm@web59112.mail.re1.yahoo.com> References: <328748.69828.qm@web59112.mail.re1.yahoo.com> Message-ID: <48480E8F.2040805@weblogsinc.com> I thought they /were/ a contracted team. Ann Otoole wrote: > I previously requested someone look into how this project can impact > search and there were no replies so I will reiterate: > > Profile Picks are part of the new search relevancy. Messing with this > breaks search. An external non LL contracted team cannot be allowed to > work on things that will result in devastation of the economy. How > this can even happen is interesting. Great work and all but who > decided to allow you to potentially erase the SL economy? > > Landmarks were initially listed in the SL blog as being a search > relevance factor. The entire discussion of removing landmarks should > have never happened without a discussion of this factor first. > > My recommendation is for the LL search related team to pay more > attention to protecting their turf and communicating with this > community to ensure everyone understands how this work will or will > not impact the new search. > > > ----- Original Message ---- > From: Sarah Hutchinson > To: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:37:46 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking > into consideration all of your input. We're excited that there has > been so much interest in this project! Working on an open source > project is a great learning experience for us, so we've been careful > to respond with accuracy. Now we'll work on responding with a little > more speed. As we have begun to define the design and functionality, > we're better positioned to understand and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where > we've been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed > Office Hours discussions, interviews with Residents (both new and > veteran), scouring Second Life blogs, researching resident-created > tools, reviewing other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate > in-world and how they create, use, and manage Landmarks. We solicited > feedback on their pain points, ideas, and general comments that > touched on Inventory, Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden > Lab as well as some initial mockups and wireframes that would satisfy > some of the project goals (as stated on the WIKI) as: > > * > > *To create a history of locations visited*, presented in some > visual fashion, which may include: > > o > > Back & forward buttons for teleporting through location > history > > o > > Prominent on-screen affordance for accessing/adding Landmarks > > * > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > > o > > Sorting, re-ordering > > o > > Organizing into folders or similar > > o > > Renaming > > o > > Sharing > > o > > Tagging > > * > > *To create a new navigation panel* (ie. the visual container for > the new UI components) > > o > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > > 2. > > Deprecating Picks or finding some way to make sharing Landmarks > easier. > > Discussions with Residents quickly removed these two items from the > scope of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing > from to do from an implementation perspective. It also means that one > of our project requirements - that of backwards compatibility - was > broken. So it was determined that Landmarks were best left a part of > the Inventory. As noted, there are many ways a Landmark can end up in > one's Inventory, and the pros of Landmarks being left where they are, > very quickly outweighed any cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved > into, that it should be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on > wireframes and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden > Lab, we are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and > history buttons, as well as an address/location text box and > 'go' button. > > The designs are being revised and updated to fit more into the > new Dazzle style with insight and feedback from Residents and > Lindens. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > In between the back and forward buttons will be a small, history > button which will allow a Resident to view the list of places > he/she has visited during that session. The number of places > stored in this history and whether it persists between sessions > can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional > info (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport > the Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to > his/her home location. > > Address Bar - The address bar will display a SLURL by default. > Users can enter a SLURL, or Region name in their Inventory. If > the Resident types in a Region name that is not in their > Inventory, we will go a global search to find the location. If > the location cannot be found, the Search floater will open. > > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater > that will providing users the ability to: > > * > > Set the number of days to store location history > > * > > Set the number of days to store address bar history > > * > > Clear the history of either of the above two items > > * > > Export Landmarks in HTML, TXT, or XML formats > > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes > when creating or editing a Landmark. There will also be the > option to select or create a folder when creating/editing > Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will > still apply: > > * > > Landmarks received from purchased objects will remain with > the object/folder as they are created. > > * > > Landmarks received view Inventory transfer will be placed > into a Received Landmarks folder by default, but also > allow for the Resident to edit and select a folder in > which to place the Landmark. > > * > > Landmarks received via automatic givers will also be > placed into the Received Landmarks folder, by default. > Still TBD in terms of scoping, but we'd also like to > include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > > * > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the > Notecard and not accessible except through Notecard access. > > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the > Viewer. The options for this menu are as follows: > > * > > Create Landmark > > * > > Manage Landmarks > > * > > Set Home to Current Location > > * > > Teleport Home > > * > > Received Landmarks - A sub-folder in the Landmarks folder > in Inventory where all received Landmarks are stored by > default. > > * > > Recent Places - Displays a list of Landmarks a Resident > has recented used. > > * > > Access to Landmarks located in the Inventory Floater - > Residents will now have access to Landmarks stored in the > Landmarks folder of their Inventory via this menu. Any > sub-folders of the main Landmarks folder will appear in > this Landmarks menu and be navigable via this menu. > > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via > of the Inventory, in which to organize and manage (edit/delete) > Landmarks. It consists of a small floater which will almost look > like a filter viewed of the Inventory Floater. The Manage > Landmarks floater will allow Residents to filter Landmarks, > create/edit/delete folders easily, and provide a place (without > having to weed through the rest of the Inventory) to edit Landmarks. > > If you've had a chance to look at the wireframe posted on > NAV-28, there are two approaches to the Manage Landmarks UI. At > present, we have been asked to proceed with the separated > floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI > was a Data Sort View which would allow Residents to view, sort, > and manage Landmarks from a column set approach (like iTunes > ). However, at this time, we have > been asked to put that feature on hold since it's real benefit > has not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to > specify a custom name, add their own notes to each Landmark. > Residents will also have the ability to specify a picture they > want to use for a particular Landmark. Our technical team is > also reviewing the possibility of allowing a Resident the option > of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined > if this feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on > Map' and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the > Landmark from the Edit Landmark floater - date acquired, last > teleport date, and last updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) > has been to include tagging of Landmarks and other Inventory assets. > We investigated a couple of ways to create a folksonomy use with > Landmarks in Second Life during the first phase of our project. > However, it became clear that tagging functionality would be useful > for many other areas and could touch many other areas including > search, the web, User Picks, and most Inventory items. Rather than > build a small one-off tagging system just for Landmarks, it was > decided that creating a true folksonomy that could be used throughout > Second Life (For searching, sharing landmarks, creating more a social > network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of > scope for this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting > Resident feedback on new designs revisions. We hope to have design > approachs for the new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time > researching the items which many of you have spoken about on this > list. A few items for which we're actively researching: > > * > > Understanding more about SLURLs and their relation to the Agni > grid and how they come into play with the beta grid(s). > > * > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > > * > > How the introduction of forward/back button teleport > functionality will affect grid stability. > > In addition to researching open issues, our tech team is also working > on wrapping up a Viewer build (minus approved creative). We will be > testing that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform > team will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From evolutie at gmail.com Thu Jun 5 09:08:15 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 09:08:17 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> yes, that's what it does! this is so great! the UI actually works quite well, I think. But script functions would be very nice.. really would love to connect a mocap suit to it... chrz, evo On Thu, Jun 5, 2008 at 6:01 PM, Dahlia Trimble wrote: > Does (or could) the puppeteering code implement inverse kinematics? > > > On Thu, Jun 5, 2008 at 4:19 AM, Argent Stonecutter > wrote: >> >> On 2008-06-04, at 23:53, Brandon Lockaby wrote: >>> >>> Assuming LL doesn't write a simulator for you, might I suggest the >>> possiblity of using slproxy to emulate the server-side behaviors? :D >> >> I'm not sure how SLProxy would help... the important bit would be >> scripted. >> >> llTrackPrim(integer joint, key prim, integer distance, integer strictness, >> integer follow_rotation); >> >> While prim is in range of motion of joint, joint is constrained to remain >> in distance meters of the center of prim. Strictness indicates how quickly >> it would track the prim, and follow_rotation whether it should try and >> rotate the joint to match the angle of the prim. >> >> It would apply to the owner or the avatar for which the script has >> appropriate permissions. >> >> _______________________________________________ >> 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 > > -- http://www.creativemachinery.org From sean at lindenlab.com Thu Jun 5 09:09:13 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 09:09:15 2008 Subject: [sldev] Voice moderation and morphing; was: Voice moderation and morphing; was: [sldev] Puppettering Branch In-Reply-To: <507402.50528.qm@web59108.mail.re1.yahoo.com> References: <507402.50528.qm@web59108.mail.re1.yahoo.com> Message-ID: <3736d47a0806050909g2e270206mb1410576f11a83ad@mail.gmail.com> The reason [sldev] wasn't at the beginning of the subject is that mailman checks to see if [sldev] exists *anywhere* in the subject to make sure it doesn't have [sldev] more than once. You should be looking for [sldev] anywhere in the subject rather than just at the beginning. As it is, replies will regularly end up as Re: [sldev] blah blah blah. On Thu, Jun 5, 2008 at 8:41 AM, Ann Otoole wrote: > Please put [sldev] as a prefix so these messages won't so easily be flagged > and deleted as spam. > > Thanks. > > ----- Original Message ---- > From: Mike Monkowski > To: Jake Simpson > Cc: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:35:59 AM > Subject: Voice moderation and morphing; was: [sldev] Puppettering Branch > > Was voice moderation and morphing another of the projects that was > dropped? (I did see the puppet master's name in the voice code ;-) ) > If so, can we have the code for that too? If not, when do you think we > might see it? > > Mike > > Jake Simpson wrote: > > Puppeteering is a project that we had going last year that we dropped in > > order to focus on stability issues. Note, at the time this was a pretty > > contentious move, some internal people were fairly upset about it (one > > even quit over it) but it was deemed necessary for focus on stability to > > be the main issue. > _______________________________________________ > 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/20080605/d698bc74/attachment-0001.htm From missannotoole at yahoo.com Thu Jun 5 09:11:52 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Jun 5 09:11:56 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Message-ID: <193533.8360.qm@web59104.mail.re1.yahoo.com> My point is simple. This work can impact search and the impact on search needs to be explained. Or if it is going to negatively impact something then why use time discussing things that will not be allowed to happen? More communication is needed. And how this effort can enhance search would be a great thing. (I.e.; I suspect everything is converted to html urls for google appliance indexing anyway so how can this new navigation work help? will the history of teleports finally be counted as a form of real traffic into and out of a sim? etc. etc.) Don't confuse emotionless straight direct talk with negativism. Thanks. ----- Original Message ---- From: Drew Dwi To: Ann Otoole Cc: Sarah Hutchinson ; sldev@lists.secondlife.com Sent: Thursday, June 5, 2008 11:54:52 AM Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 Hi, Hate to poke my head in, but careful reading is required before harsh feedback. Per Kippie's post (you don't get your own email? the name says Sarah fyi): "With regards to User Picks, we learned that Picks are used for a lot more than just sharing of favorite places. It was decided that until Second Life offer the more social features that Picks have evolved into, that it should be left as is." I don't see how any of the changes listed below affect search. -Drew Ann Otoole wrote: > I previously requested someone look into how this project can impact > search and there were no replies so I will reiterate: > > Profile Picks are part of the new search relevancy. Messing with this > breaks search. An external non LL contracted team cannot be allowed to > work on things that will result in devastation of the economy. How > this can even happen is interesting. Great work and all but who > decided to allow you to potentially erase the SL economy? > > Landmarks were initially listed in the SL blog as being a search > relevance factor. The entire discussion of removing landmarks should > have never happened without a discussion of this factor first. > > My recommendation is for the LL search related team to pay more > attention to protecting their turf and communicating with this > community to ensure everyone understands how this work will or will > not impact the new search. > > > ----- Original Message ---- > From: Sarah Hutchinson > To: sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:37:46 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking > into consideration all of your input. We're excited that there has > been so much interest in this project! Working on an open source > project is a great learning experience for us, so we've been careful > to respond with accuracy. Now we'll work on responding with a little > more speed. As we have begun to define the design and functionality, > we're better positioned to understand and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where > we've been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed > Office Hours discussions, interviews with Residents (both new and > veteran), scouring Second Life blogs, researching resident-created > tools, reviewing other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate > in-world and how they create, use, and manage Landmarks. We solicited > feedback on their pain points, ideas, and general comments that > touched on Inventory, Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden > Lab as well as some initial mockups and wireframes that would satisfy > some of the project goals (as stated on the WIKI) as: > > * > > *To create a history of locations visited*, presented in some > visual fashion, which may include: > > o > > Back & forward buttons for teleporting through location > history > > o > > Prominent on-screen affordance for accessing/adding Landmarks > > * > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > > o > > Sorting, re-ordering > > o > > Organizing into folders or similar > > o > > Renaming > > o > > Sharing > > o > > Tagging > > * > > *To create a new navigation panel* (ie. the visual container for > the new UI components) > > o > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > > 2. > > Deprecating Picks or finding some way to make sharing Landmarks > easier. > > Discussions with Residents quickly removed these two items from the > scope of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing > from to do from an implementation perspective. It also means that one > of our project requirements - that of backwards compatibility - was > broken. So it was determined that Landmarks were best left a part of > the Inventory. As noted, there are many ways a Landmark can end up in > one's Inventory, and the pros of Landmarks being left where they are, > very quickly outweighed any cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved > into, that it should be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on > wireframes and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden > Lab, we are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and > history buttons, as well as an address/location text box and > 'go' button. > > The designs are being revised and updated to fit more into the > new Dazzle style with insight and feedback from Residents and > Lindens. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > In between the back and forward buttons will be a small, history > button which will allow a Resident to view the list of places > he/she has visited during that session. The number of places > stored in this history and whether it persists between sessions > can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional > info (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport > the Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to > his/her home location. > > Address Bar - The address bar will display a SLURL by default. > Users can enter a SLURL, or Region name in their Inventory. If > the Resident types in a Region name that is not in their > Inventory, we will go a global search to find the location. If > the location cannot be found, the Search floater will open. > > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater > that will providing users the ability to: > > * > > Set the number of days to store location history > > * > > Set the number of days to store address bar history > > * > > Clear the history of either of the above two items > > * > > Export Landmarks in HTML, TXT, or XML formats > > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes > when creating or editing a Landmark. There will also be the > option to select or create a folder when creating/editing > Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will > still apply: > > * > > Landmarks received from purchased objects will remain with > the object/folder as they are created. > > * > > Landmarks received view Inventory transfer will be placed > into a Received Landmarks folder by default, but also > allow for the Resident to edit and select a folder in > which to place the Landmark. > > * > > Landmarks received via automatic givers will also be > placed into the Received Landmarks folder, by default. > Still TBD in terms of scoping, but we'd also like to > include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > > * > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the > Notecard and not accessible except through Notecard access. > > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the > Viewer. The options for this menu are as follows: > > * > > Create Landmark > > * > > Manage Landmarks > > * > > Set Home to Current Location > > * > > Teleport Home > > * > > Received Landmarks - A sub-folder in the Landmarks folder > in Inventory where all received Landmarks are stored by > default. > > * > > Recent Places - Displays a list of Landmarks a Resident > has recented used. > > * > > Access to Landmarks located in the Inventory Floater - > Residents will now have access to Landmarks stored in the > Landmarks folder of their Inventory via this menu. Any > sub-folders of the main Landmarks folder will appear in > this Landmarks menu and be navigable via this menu. > > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via > of the Inventory, in which to organize and manage (edit/delete) > Landmarks. It consists of a small floater which will almost look > like a filter viewed of the Inventory Floater. The Manage > Landmarks floater will allow Residents to filter Landmarks, > create/edit/delete folders easily, and provide a place (without > having to weed through the rest of the Inventory) to edit Landmarks. > > If you've had a chance to look at the wireframe posted on > NAV-28, there are two approaches to the Manage Landmarks UI. At > present, we have been asked to proceed with the separated > floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI > was a Data Sort View which would allow Residents to view, sort, > and manage Landmarks from a column set approach (like iTunes > ). However, at this time, we have > been asked to put that feature on hold since it's real benefit > has not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to > specify a custom name, add their own notes to each Landmark. > Residents will also have the ability to specify a picture they > want to use for a particular Landmark. Our technical team is > also reviewing the possibility of allowing a Resident the option > of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined > if this feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on > Map' and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the > Landmark from the Edit Landmark floater - date acquired, last > teleport date, and last updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) > has been to include tagging of Landmarks and other Inventory assets. > We investigated a couple of ways to create a folksonomy use with > Landmarks in Second Life during the first phase of our project. > However, it became clear that tagging functionality would be useful > for many other areas and could touch many other areas including > search, the web, User Picks, and most Inventory items. Rather than > build a small one-off tagging system just for Landmarks, it was > decided that creating a true folksonomy that could be used throughout > Second Life (For searching, sharing landmarks, creating more a social > network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of > scope for this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting > Resident feedback on new designs revisions. We hope to have design > approachs for the new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time > researching the items which many of you have spoken about on this > list. A few items for which we're actively researching: > > * > > Understanding more about SLURLs and their relation to the Agni > grid and how they come into play with the beta grid(s). > > * > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > > * > > How the introduction of forward/back button teleport > functionality will affect grid stability. > > In addition to researching open issues, our tech team is also working > on wrapping up a Viewer build (minus approved creative). We will be > testing that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform > team will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20080605/968d705d/attachment-0001.htm From sean at lindenlab.com Thu Jun 5 09:16:12 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 09:16:15 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> Message-ID: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> For development purposes, why not just hold all the state in the viewer and send the state to other viewers in the region via some message that's routed directly to other viewers? Just be careful with this, since you should assume any such messages are from untrusted sources. On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby wrote: > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D > > > On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter < > secret.argent@gmail.com> wrote: > >> Anyway, to cut a long story short we (myself and Robla) thought about it >>> and said "Well, if they can't, maybe the SLDev crew can do something with >>> this" and with that we decided to publish the code to you guys. >>> >> >> What I'd like to do with this would require server-side access. >> >> I don't want to drag my hand with my mouse, I want to tell my hand "track >> this prim". >> >> And I want to do it from a script. >> >> Why? Well, how about so I can walk along holding someone's hand, because >> they're wearing the prim I'm tracking... not because we're both riding a >> vehicle that's animating walks for both of us. >> >> So when I'm riding a vehicle, it can make my hands hold onto the >> handlebars, without my having to change the animation based on the avatar >> size. >> >> Automated puppetteering. >> >> _______________________________________________ >> 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/20080605/b47cd258/attachment.htm From tateru.nino at gmail.com Thu Jun 5 09:18:00 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 09:18:42 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> Message-ID: <484811B8.1070308@gmail.com> Most viewers would be behind either firewalls or NAT layers, I should think - that would seem to preclude peer-to-peer communications in most cases, unless the receiver is competent and able to allow it. Sean Lynch wrote: > For development purposes, why not just hold all the state in the > viewer and send the state to other viewers in the region via some > message that's routed directly to other viewers? Just be careful with > this, since you should assume any such messages are from untrusted > sources. > > On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby > wrote: > > Assuming LL doesn't write a simulator for you, might I suggest the > possiblity of using slproxy to emulate the server-side behaviors? :D > > > On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter > > wrote: > > Anyway, to cut a long story short we (myself and Robla) > thought about it and said "Well, if they can't, maybe the > SLDev crew can do something with this" and with that we > decided to publish the code to you guys. > > > What I'd like to do with this would require server-side access. > > I don't want to drag my hand with my mouse, I want to tell my > hand "track this prim". > > And I want to do it from a script. > > Why? Well, how about so I can walk along holding someone's > hand, because they're wearing the prim I'm tracking... not > because we're both riding a vehicle that's animating walks for > both of us. > > So when I'm riding a vehicle, it can make my hands hold onto > the handlebars, without my having to change the animation > based on the avatar size. > > Automated puppetteering. > > _______________________________________________ > 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 monkowsk at watson.ibm.com Thu Jun 5 08:11:19 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 09:33:08 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <48480217.8080107@watson.ibm.com> Jake Simpson wrote: > Now we recently resurrected this code and have distributed it to various > partners who have items in the works that might well end up using this > code - basically we've given it to them, said "see if you can make > something compelling with it, and if you can, we may reconsider > finishing up the simulator code and pushing it through". Will this parther code become part of the open source distribution or is it being done under a different license agreement? > Anyway, to cut a long story short we (myself and Robla) thought about it > and said "Well, if they can't, maybe the SLDev crew can do something > with this" and with that we decided to publish the code to you guys. I don't imagine you'd have any documentation. Would you? > The code itself is somewhat complete - there are definitely some things > we would do differently and there are still definitely bugs in there, > but right now it's pretty unlikely that we will return to this to > complete it or refactor that which we would want to change with the code > and intent as it stands. What are the "some things we would do differently"? How would you want to refactor it? Mike From evolutie at gmail.com Thu Jun 5 09:38:28 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 09:38:31 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48480217.8080107@watson.ibm.com> References: <48473027.9090101@lindenlab.com> <48480217.8080107@watson.ibm.com> Message-ID: <5fb4b1fa0806050938x5cd21714ib2703d9c5455c23c@mail.gmail.com> this should be helpful for some of the documentation part... http://avatarpuppeteering.com/ chrz, evo On Thu, Jun 5, 2008 at 5:11 PM, Mike Monkowski wrote: > Jake Simpson wrote: >> >> Now we recently resurrected this code and have distributed it to various >> partners who have items in the works that might well end up using this code >> - basically we've given it to them, said "see if you can make something >> compelling with it, and if you can, we may reconsider finishing up the >> simulator code and pushing it through". > > Will this parther code become part of the open source distribution or is it > being done under a different license agreement? > >> Anyway, to cut a long story short we (myself and Robla) thought about it >> and said "Well, if they can't, maybe the SLDev crew can do something with >> this" and with that we decided to publish the code to you guys. > > I don't imagine you'd have any documentation. Would you? > >> The code itself is somewhat complete - there are definitely some things we >> would do differently and there are still definitely bugs in there, but right >> now it's pretty unlikely that we will return to this to complete it or >> refactor that which we would want to change with the code and intent as it >> stands. > > What are the "some things we would do differently"? How would you want to > refactor it? > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- http://www.creativemachinery.org From cenji.neutra at gmail.com Thu Jun 5 10:01:27 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Thu Jun 5 10:01:30 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 Message-ID: Thanks for the good overview Sarah. Just wanted to chime in to mention that the SL client is increasingly being used to login to 3rd-party grids in addition to SL - a trend that will continue to gain momentum, especially with work underway to make user selection of which 'grid' to connect to part of the UI (see VWR-7531 for example). While currently an avatar's identity and inventory (i.e. landmarks) and the grid they're logged into are tied together, in the new Architecture LL & the AWG is proposing, they are not (see http://wiki.secondlife.com/wiki/AWG). So it will be possible in future for an avatar (belonging to a particular 'agent domain') to login to a number of independent 'grids' (e.g. region domains). That obviously has implications for landmarks, since the landmark information would need to be associated with the region domain in which it was created. For example, if I created a landmark in SL to a region named "Island1" and then quit and reconnected to a different agent domain - say osgrid.org or centralgrid.com - *with my SL avatar and inventory* (which isn't yet technically possible, but will be), then when I select that landmark and click 'teleport' I would expect the SL client to know it isn't a location in the grid I'm currently in (even if that grid also has a region named "Island1".). Perhaps it should display an error, or maybe even re-connect me to SL to TP there. Just wanted this to be 'on your radar' so perhaps you can build-in appropriate 'grid identifiers' into your data design which will aid the transition to the new agent/region domain architecture in the future. Regards. -Cenji. From lenglish5 at cox.net Thu Jun 5 10:06:58 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:07:01 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> Message-ID: <48481D32.40604@cox.net> Dante Tucker wrote: > Aha, I got it nevermind. Though the interface is less then usable I > managed to get a feel for it. Only problem is the second you interact > with your characters skeleton it goes into crazy convulsions. > For the fun of it I have attached an image of two views of the > convulsions and one view of my attempt to put my avatar into a decent > standing pose. I think a mouse-only interface is not really an option. However, I could see this being used with suitable controls, as an in-viewer animation generator. With scripting, you could add custom animations in near-realtime. With suitable interfaces (and not just dual Wii controllers or 3D webcams, but hot keys, voice control MIDI keyboard, etc) you could certainly have realtime animation. Lawson From lenglish5 at cox.net Thu Jun 5 10:18:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:18:07 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> Message-ID: <48481FCC.2050408@cox.net> evolutie wrote: > yes, that's what it does! > this is so great! > the UI actually works quite well, I think. > But script functions would be very nice.. > > really would love to connect a mocap suit to it... > Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam controller for SL. I imagine his people have a copy to work with since his stuff is really prmitive mocap and the camera's resolution scales with extra modules added. Lawson From danteferret at gmail.com Thu Jun 5 10:18:42 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Jun 5 10:18:44 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481D32.40604@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> Message-ID: <4d211a610806051018o4492f2dfwa1b69be91e91be47@mail.gmail.com> Unfortunately I think the biggest downside of all the tools in sl at the moment is the lack of multiple views. Compare this to other programs that have multiple views from different angles at the same time. On Thu, Jun 5, 2008 at 1:06 PM, Lawson English wrote: > Dante Tucker wrote: > >> Aha, I got it nevermind. Though the interface is less then usable I >> managed to get a feel for it. Only problem is the second you interact with >> your characters skeleton it goes into crazy convulsions. >> For the fun of it I have attached an image of two views of the convulsions >> and one view of my attempt to put my avatar into a decent standing pose. >> > I think a mouse-only interface is not really an option. However, I could > see this being used with suitable controls, as an in-viewer animation > generator. With scripting, you could add custom animations in near-realtime. > With suitable interfaces (and not just dual Wii controllers or 3D webcams, > but hot keys, voice control MIDI keyboard, etc) you could certainly have > realtime animation. > > > Lawson > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/59f59ba8/attachment-0001.htm From lenglish5 at cox.net Thu Jun 5 10:20:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:20:45 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484811B8.1070308@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> Message-ID: <4848206A.4030804@cox.net> Tateru Nino wrote: > Most viewers would be behind either firewalls or NAT layers, I should > think - that would seem to preclude peer-to-peer communications in > most cases, unless the receiver is competent and able to allow it. Reverese http allows P2P for anyone if they want to bother with it. Lawson From lenglish5 at cox.net Thu Jun 5 10:19:48 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 10:31:28 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> Message-ID: <48482034.7030802@cox.net> Sean Lynch wrote: > For development purposes, why not just hold all the state in the > viewer and send the state to other viewers in the region via some > message that's routed directly to other viewers? Just be careful with > this, since you should assume any such messages are from untrusted > sources. > No provision in he LL design for P2P. AWG has discussed adding a protocol to announce that P2P is available in a given region domain (grid), but its not high on anyone's list. Lawson From sldev at bitparts.org Thu Jun 5 11:28:26 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Thu Jun 5 11:28:42 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <4848304A.1080402@bitparts.org> Sarah Hutchinson wrote: > > 1. > > The Navigation Panel can be able to be shown or hidden using > both a small toggle at the top-left of the Viewer as well a > keyboard shortcut - "/". (We are still determining if this will > work as a shortcut key, but an initial review indicated it was > not being used by another UI element - so this is TBD). > > So, minor thing compared with the whole "why bother" question - "/" will currently open the local chat entry line if it is closed. So, yeah - might want to double-check the work of whoever decided it wasn't in use already. From sarah77 at gmail.com Thu Jun 5 11:57:07 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Thu Jun 5 11:57:08 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4848304A.1080402@bitparts.org> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <4848304A.1080402@bitparts.org> Message-ID: <9010c35c0806051157m239ca5cbjfa6598d1471897bd@mail.gmail.com> My apologies. That was a typo on my part. The character should be "\". Unless I am mistaken, it is not currently in use for another Viewer shortcuts. Thanks for catching that! Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/51c24fc5/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 12:03:40 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 12:03:44 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: Message-ID: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Hi Cenji, I'll make sure our technical team is aware of this. I'm not as familiar with how the Viewer is used for other grids. I'll take a look at VWR-7531 right now and the sites you referenced. Thanks, Kippie On Thu, Jun 5, 2008 at 1:01 PM, Cenji Neutra wrote: > Thanks for the good overview Sarah. > Just wanted to chime in to mention that the SL client is increasingly > being used to login to 3rd-party grids in addition to SL - a trend > that will continue to gain momentum, especially with work underway to > make user selection of which 'grid' to connect to part of the UI (see > VWR-7531 for example). > > While currently an avatar's identity and inventory (i.e. landmarks) > and the grid they're logged into are tied together, in the new > Architecture LL & the AWG is proposing, they are not (see > http://wiki.secondlife.com/wiki/AWG). So it will be possible in > future for an avatar (belonging to a particular 'agent domain') to > login to a number of independent 'grids' (e.g. region domains). > > That obviously has implications for landmarks, since the landmark > information would need to be associated with the region domain in > which it was created. For example, if I created a landmark in SL to a > region named "Island1" and then quit and reconnected to a different > agent domain - say osgrid.org or centralgrid.com - *with my SL avatar > and inventory* (which isn't yet technically possible, but will be), > then when I select that landmark and click 'teleport' I would expect > the SL client to know it isn't a location in the grid I'm currently in > (even if that grid also has a region named "Island1".). Perhaps it > should display an error, or maybe even re-connect me to SL to TP > there. > > Just wanted this to be 'on your radar' so perhaps you can build-in > appropriate 'grid identifiers' into your data design which will aid > the transition to the new agent/region domain architecture in the > future. > Regards. > -Cenji. > _______________________________________________ > 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/20080605/12e78675/attachment.htm From labrat.hb at gmail.com Thu Jun 5 12:37:27 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jun 5 12:37:30 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Message-ID: I'm not sure I like this item: > 2. Deprecating Picks or finding some way to make sharing Landmarks easier. Picks have become much more then a "Hey I like this place come take a look. They are a social bookmark, used to show more information about who and what residents find, think and believe about the Second Life world. I would hate to lose this non-landmark / navigation functionality because the "Picks" were being deprecated. From evolutie at gmail.com Thu Jun 5 12:46:29 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jun 5 12:46:32 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481FCC.2050408@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> <48481FCC.2050408@cox.net> Message-ID: <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> > Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam > controller for SL. I imagine his people have a copy to work with since his > stuff is really prmitive mocap and the camera's resolution scales with extra > modules added. > > > Lawson > > oh! that sounds very interesting! Do you know where I could get more information on this? thnx, evo -- http://www.creativemachinery.org From kelly at lindenlab.com Thu Jun 5 12:47:31 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Thu Jun 5 12:47:34 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> Message-ID: <484842D3.6000406@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/5ef08d2d/attachment.htm From labrat.hb at gmail.com Thu Jun 5 12:53:55 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jun 5 12:53:57 2008 Subject: [sldev] Re: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <484842D3.6000406@lindenlab.com> References: <9010c35c0806051203w2ffc8e24r5191d340261cf803@mail.gmail.com> <484842D3.6000406@lindenlab.com> Message-ID: I caught that after I pressed send. *sweeps the previous reply under the rug and stomps it down nice and flat* On Thu, Jun 5, 2008 at 12:47 PM, Kelly Linden wrote: > > Please! Read what you reply to! The above quote, in context reads: From monkowsk at watson.ibm.com Thu Jun 5 12:34:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jun 5 13:00:00 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48481D32.40604@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> Message-ID: <48483FBE.8070206@watson.ibm.com> Here's an idea. The problem I see with gestures is that they have a fixed time sequence. They play exactly the same way every time. Not very cinematic. Now suppose there was a HUD that had at its disposal the puppeteering equivalents of these gestures and a way to gang them together (master - slave controls) so that you could select a gesture or gang of gestures and use the mouse to move a slider as if it were scrubbing the timeline for the animation. So, for example, if I had a hand-waving animation I could wave a little very slowly "Yes, I'm a princess." by slowly scrubbing the middle of the timeline or I could give a vigorous "Hey I'm over here! Pick me!" wave by scrubbing the entire timeline quickly. You'd have to plan ahead and gang gestures appropriately since you can only control one timeline, but switching between gestures might not be too difficult. Putting this in a HUD would mean that a lot of customization could be done quickly. But, I've never built a HUD in SL, so I really don't know how much is possible. Mike Lawson English wrote: > I think a mouse-only interface is not really an option. However, I could > see this being used with suitable controls, as an in-viewer animation > generator. With scripting, you could add custom animations in > near-realtime. With suitable interfaces (and not just dual Wii > controllers or 3D webcams, but hot keys, voice control MIDI keyboard, > etc) you could certainly have realtime animation. From lenglish5 at cox.net Thu Jun 5 13:36:51 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jun 5 13:36:53 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> <5fb4b1fa0806050908w793f240etbda2bcc3243435c8@mail.gmail.com> <48481FCC.2050408@cox.net> <5fb4b1fa0806051246q5135fa5anf53f15810a06da3f@mail.gmail.com> Message-ID: <48484E63.6050304@cox.net> evolutie wrote: >> Kaplan, former Chairman of LL and Chief Angel, is working on a 3D webcam >> controller for SL. I imagine his people have a copy to work with since his >> stuff is really prmitive mocap and the camera's resolution scales with extra >> modules added. >> >> >> Lawson >> >> >> > > oh! that sounds very interesting! > Do you know where I could get more information on this? > > Oops. Mitch Kapor, not Kaplan. http://news.cnet.com/8301-10784_3-9916946-7.html Lawson From gbrandon at gmail.com Thu Jun 5 14:05:18 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Jun 5 14:05:21 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: Would one be able to look through the location history and decide to bookmark any of the items? Also I want to put in a few words about back & forward buttons: remember, Second Life has teleport problems and much like the web you don't always know where the back button is going to take you. Can you imagine hitting the back button rapidly trying to find something? So, with a web browser, you have something like drop-down box buttons next to those back and forward buttons showing a quick history you can choose from, that comes in handy. Oh! What's the internal opinion on having the widget in the menu bar instead of a floater? Thanks, Brandon Lockaby On Thu, Jun 5, 2008 at 11:37 AM, Sarah Hutchinson wrote: > Hello all! > > Thank you so much for your feedback and comments on the Landmarks & > Navigation project. My name is Kippie Friedkin and I'm a member of the > Vectorform team. The team has been watching the threads and taking into > consideration all of your input. We're excited that there has been so much > interest in this project! Working on an open source project is a great > learning experience for us, so we've been careful to respond with accuracy. > Now we'll work on responding with a little more speed. As we have begun to > define the design and functionality, we're better positioned to understand > and discuss the technical issues. > > I thought I'd begin this note with an update on the project - where we've > been, where we are, and where we're going. > > *Where we've been > *The project began with a massive research phase that encompassed Office > Hours discussions, interviews with Residents (both new and veteran), > scouring Second Life blogs, researching resident-created tools, reviewing > other Viewers and a host of web apps. > > During this phase, it was our goal to learn how Residents navigate in-world > and how they create, use, and manage Landmarks. We solicited feedback on > their pain points, ideas, and general comments that touched on Inventory, > Landmarks, navigation, and User Picks. > > At the end of this research phase, we presented our finding to Linden Lab > as well as some initial mockups and wireframes that would satisfy some of > the project goals (as stated on the WIKI) as: > > - > > *To create a history of locations visited*, presented in some visual > fashion, which may include: > - > > Back & forward buttons for teleporting through location history > - > > Prominent on-screen affordance for accessing/adding Landmarks > - > > *To improve the existing, or create a new, system for managing > Landmarks*, which should support the following: > - > > Sorting, re-ordering > - > > Organizing into folders or similar > - > > Renaming > - > > Sharing > - > > Tagging > - > > *To create a new navigation panel* (ie. the visual container for the > new UI components) > - > > To provide the ability to hide/show this panel. > > A few other things were investigated and discussed at the project's onset: > > 1. > > Removing Landmarks from Inventory, in favor of a new system for > managing Landmarks. > 2. > > Deprecating Picks or finding some way to make sharing Landmarks easier. > > Discussions with Residents quickly removed these two items from the scope > of this project. > > Removing Landmarks from the Inventory is an extremely difficult thing from > to do from an implementation perspective. It also means that one of our > project requirements - that of backwards compatibility - was broken. So it > was determined that Landmarks were best left a part of the Inventory. As > noted, there are many ways a Landmark can end up in one's Inventory, and the > pros of Landmarks being left where they are, very quickly outweighed any > cons that currently exist. > > With regards to User Picks, we learned that Picks are used for a lot more > than just sharing of favorite places. It was decided that until Second Life > offer the more social features that Picks have evolved into, that it should > be left as is. > > *Where we are today > *The Vectorform team has spent the past few weeks working on wireframes > and designs for the newly proposed features. > > Based on our research, Resident feedback, and meetings with Linden Lab, we > are building the following features in the Viewer: > > 1. > > *Navigation Panel* > The Navigation panel will include forward, back, home and history > buttons, as well as an address/location text box and 'go' button. > > The designs are being revised and updated to fit more into the new > Dazzle style with insight and feedback from Residents and Lindens. > > The Navigation Panel can be able to be shown or hidden using both a > small toggle at the top-left of the Viewer as well a keyboard shortcut - > "/". (We are still determining if this will work as a shortcut key, but an > initial review indicated it was not being used by another UI element - so > this is TBD). > > In between the back and forward buttons will be a small, history button > which will allow a Resident to view the list of places he/she has visited > during that session. The number of places stored in this history and whether > it persists between sessions can be set in ones User Preferences. > > The name of the parcel and region will be shown in the location > history. Mousing over an item in the list will reveal additional info > (SLURL? How long ago you were there?) > > Clicking the back or forward button will automatically teleport the > Resident back/foward in their location history. > > Clicking the home button will teleport the Resident back to his/her > home location. > > Address Bar - The address bar will display a SLURL by default. Users > can enter a SLURL, or Region name in their Inventory. If the Resident types > in a Region name that is not in their Inventory, we will go a global search > to find the location. If the location cannot be found, the Search floater > will open. > 2. > > *User Preferences > *We are introducing a new tab to the User Preferences floater that will > providing users the ability to: > - > > Set the number of days to store location history > - > > Set the number of days to store address bar history > - > > Clear the history of either of the above two items > - > > Export Landmarks in HTML, TXT, or XML formats > 3. > > *Create/Edit Landmarks UI* > Residents will now be able to add a custom name and stores notes when > creating or editing a Landmark. There will also be the option to select or > create a folder when creating/editing Landmarks. > > All Landmarks and their folders will be will be placed into the > Landmarks folder in the Inventory floater. > > To clear up any confusion, the following circumstances will still > apply: > - > > Landmarks received from purchased objects will remain with the > object/folder as they are created. > - > > Landmarks received view Inventory transfer will be placed into a > Received Landmarks folder by default, but also allow for the Resident to > edit and select a folder in which to place the Landmark. > - > > Landmarks received via automatic givers will also be placed into the > Received Landmarks folder, by default. Still TBD in terms of scoping, but > we'd also like to include functionality that allows the Resident to edit and > select a folder in which to place the Landmark. > - > > Landmarks embedded in Notecards will not see any change in > functionality. The landmark will remain embedded in the Notecard and not > accessible except through Notecard access. > 4. > > *Landmarks Menu* > A new 'Landmarks' menu will be added to the top menu of the Viewer. The > options for this menu are as follows: > - > > Create Landmark > - > > Manage Landmarks > - > > Set Home to Current Location > - > > Teleport Home > - > > Received Landmarks - A sub-folder in the Landmarks folder in > Inventory where all received Landmarks are stored by default. > - > > Recent Places - Displays a list of Landmarks a Resident has recented > used. > - > > Access to Landmarks located in the Inventory Floater - Residents > will now have access to Landmarks stored in the Landmarks folder of their > Inventory via this menu. Any sub-folders of the main Landmarks folder will > appear in this Landmarks menu and be navigable via this menu. > 5. > > *Manage Landmarks UI* > This new UI element is meant to allow residents a filtered via of the > Inventory, in which to organize and manage (edit/delete) Landmarks. It > consists of a small floater which will almost look like a filter viewed of > the Inventory Floater. The Manage Landmarks floater will allow Residents to > filter Landmarks, create/edit/delete folders easily, and provide a place > (without having to weed through the rest of the Inventory) to edit > Landmarks. > > If you've had a chance to look at the wireframe posted on NAV-28, there > are two approaches to the Manage Landmarks UI. At present, we have been > asked to proceed with the separated floaters approach (Solution 2). > > Also, an advanced feature proposed for the Manage Landmarks UI was a > Data Sort View which would allow Residents to view, sort, and manage > Landmarks from a column set approach (like iTunes). However, at this time, > we have been asked to put that feature on hold since it's real benefit has > not been clear for all project stakeholders. > > When editing a Landmarks, Residents will have the ability to specify a > custom name, add their own notes to each Landmark. Residents will also have > the ability to specify a picture they want to use for a particular Landmark. > Our technical team is also reviewing the possibility of allowing a Resident > the option of using/reverting back to the default image for this location > (as specified by the Land Owner). It is as of yet undetermined if this > feature will be in scope. > > The Edit Landmarks Floater will include small icons for 'Show on Map' > and 'Copy SLURL' to provide additional functionality. > > Finally, we intend to display additional metadata about the Landmark > from the Edit Landmark floater - date acquired, last teleport date, and last > updated date. > > *Shared Landmarks & Tagging > *One of our original ideas (and a common suggestion from Residents) has > been to include tagging of Landmarks and other Inventory assets. We > investigated a couple of ways to create a folksonomy use with Landmarks in > Second Life during the first phase of our project. However, it became clear > that tagging functionality would be useful for many other areas and could > touch many other areas including search, the web, User Picks, and most > Inventory items. Rather than build a small one-off tagging system just for > Landmarks, it was decided that creating a true folksonomy that could be used > throughout Second Life (For searching, sharing landmarks, creating more a > social network, etc.) was a much bigger project than our timeline or project > goals would allow for. So tagging functionality was deemed out of scope for > this project. > > *Where we're going! Issues, Risks, Reviews, and Builds! > * > The design team is working closely with Linden Lab and soliciting Resident > feedback on new designs revisions. We hope to have design approachs for the > new Nav bar solidifed by the end of this week. > > In the meantime, our technical team have been working on laying the > foundation for the new Navigation bar, as well as spending time researching > the items which many of you have spoken about on this list. A few items for > which we're actively researching: > > - > > Understanding more about SLURLs and their relation to the Agni grid and > how they come into play with the beta grid(s). > - > > How the introduction of a new top-left UI element will affect > Resident-created HUDs. > - > > How the introduction of forward/back button teleport functionality will > affect grid stability. > > In addition to researching open issues, our tech team is also working on > wrapping up a Viewer build (minus approved creative). We will be testing > that and reviewing it with Linden Lab over the next week. > > I would encourage all of you to continue sharing your thoughts and > feedback. As I stated at the beginning of this message, the Vectorform team > will be much more actively engaged with this list moving forward. > > Best, > Kippie Friedkin > > _______________________________________________ > 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/20080605/6af6b8fb/attachment-0001.htm From sean at lindenlab.com Thu Jun 5 14:12:06 2008 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jun 5 14:12:10 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484811B8.1070308@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> Message-ID: <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> Sorry, I phrased that confusingly. By "routed directly to other viewers" I meant the message is routed by the simulator to any viewers that can see the agent. There are some messages that work this way, but I don't know what they are off the top of my head. On Thu, Jun 5, 2008 at 9:18 AM, Tateru Nino wrote: > Most viewers would be behind either firewalls or NAT layers, I should think > - that would seem to preclude peer-to-peer communications in most cases, > unless the receiver is competent and able to allow it. > > Sean Lynch wrote: > >> For development purposes, why not just hold all the state in the viewer >> and send the state to other viewers in the region via some message that's >> routed directly to other viewers? Just be careful with this, since you >> should assume any such messages are from untrusted sources. >> >> On Wed, Jun 4, 2008 at 9:53 PM, Brandon Lockaby > gbrandon@gmail.com>> wrote: >> >> Assuming LL doesn't write a simulator for you, might I suggest the >> possiblity of using slproxy to emulate the server-side behaviors? :D >> >> >> On Wed, Jun 4, 2008 at 10:29 PM, Argent Stonecutter >> > wrote: >> >> Anyway, to cut a long story short we (myself and Robla) >> thought about it and said "Well, if they can't, maybe the >> SLDev crew can do something with this" and with that we >> decided to publish the code to you guys. >> >> >> What I'd like to do with this would require server-side access. >> >> I don't want to drag my hand with my mouse, I want to tell my >> hand "track this prim". >> >> And I want to do it from a script. >> >> Why? Well, how about so I can walk along holding someone's >> hand, because they're wearing the prim I'm tracking... not >> because we're both riding a vehicle that's animating walks for >> both of us. >> >> So when I'm riding a vehicle, it can make my hands hold onto >> the handlebars, without my having to change the animation >> based on the avatar size. >> >> Automated puppetteering. >> >> _______________________________________________ >> 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/20080605/17f26a06/attachment.htm From sldev at catznip.com Thu Jun 5 14:53:17 2008 From: sldev at catznip.com (Kitty) Date: Thu Jun 5 14:50:42 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com><105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com><48432D25.7020300@lindenlab.com><32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com><7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> >* To create a history of locations visited, presented in some visual fashion I looked through the PDFs and the emails and I only found a reference to "teleport history" so it would seem that the history is populated only from point-to-point teleporting and nothing else? The analogy between SL and a web browser breaks down because you only really have one way of navigating the web which is to click links. In SL that translates to tp'ing, but you can also simply wander around without tp'ing. As an illustrative example: someone hears about the new Bay City sims and decides to go have a look. They use a landmark or the map to teleport over and some time (potentially hours) after that they tp away again. They could find a lot of places they might want to visit again and forgot to landmark - or didn't realize they wanted to visit again - in between those two tp's. Parcel-to-parcel tracking (probably would have to based on a "user definable time spent on that parcel" to avoid clutter) would seem a lot more useful than only tracking tp's. We already have a crude teleport history right now and I don't find it very useful since it offers no history of where I went, only the place I tp'ed away from. The web analogy would be browsing pictures on Flickr and instead of having a history of each picture you looked at, it would just tell you "you looked at the Flickr site" with nothing more specific than that. What I would love as a history would be a trajectory overlayed on a sim map, with points where I stopped for several minutes highlighted as potential reference points. Having only a SLURL to Bliss Gardens isn't that useful for instance since it's a dozen connected sims consisting of sim sized parcels and it would take forever to wander and find what you saw the day before; being able to literally retrace your steps visually would be invaluable in finding things again easily. >Clicking the back or forward button will automatically >teleport the Resident back/forward in their location history. We have a setting that determines whether double clicking a landmark automatically teleports you or whether it pops up a confirmation dialog. I personally like having the confirmation since misclicks do happen. >Address Bar - The address bar will display a SLURL by default. >Users can enter a SLURL, or Region name in their Inventory. Is "region name in inventory" a typo for "landmark name in inventory"? If the browser analogy has to be made, I would expect to be able to type "Shiny Things" there and have it fetch the location from the recent history or landmarks with an auto-complete drop down. --- I'm not sure if I missed it, but where is all the extra metadata stored? --- I don't mean to sound all negative :|. It's obvious a lot of work and effort went into planning this and working all of it out and creating prototypes and it'll undoubtably to useful to some people, but overall the new management UI seems rather complicated and clumsy to me compared to ordering landmarks in inventory which is something that everyone in SL already knows how to do and I hope it's something that can be turned off. From jacek.antonelli at gmail.com Thu Jun 5 14:59:08 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Jun 5 14:59:11 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <105c09f0806051459x21df0821qeaeaaafe212acc9b@mail.gmail.com> On Thu, Jun 5, 2008 at 4:05 PM, Brandon Lockaby wrote: > Would one be able to look through the location history and decide to > bookmark any of the items? Great idea! Maybe have a star icon (like on Twitter) or similar, that you can press to make a landmark out of it (which would put it in the menu and your inventory). > Also I want to put in a few words about back & forward buttons: remember, > Second Life has teleport problems and much like the web you don't always > know where the back button is going to take you. Can you imagine hitting > the back button rapidly trying to find something? So, with a web browser, > you have something like drop-down box buttons next to those back and forward > buttons showing a quick history you can choose from, that comes in handy. _Emphatically_ agreed. Teleports are costly -- they take a long time, they're not easily undo-able, and they can sometimes crash your client! There is a drop-down history planned (a little down arrow button near the back button), but I would argue that a better solution is to have pressing the back button pop up the menu, _not_ automatically teleport. The only cost of popping up the menu is that it takes one extra click to teleport. The cost of automatically teleporting is much higher: it's not hard to imagine accidently teleporting out of an important meeting because you made one stray click. From open at autistici.org Thu Jun 5 15:12:54 2008 From: open at autistici.org (Opensource Obscure) Date: Thu Jun 5 15:12:57 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <807cdf5117351cc6f7bf88c9685ed871@localhost> I can't build this on Linux (Ubuntu 8.04). (I understand this code is unsupported, so please stop me if asking help here about is unappropriate) I managed to work around three errors using these patches: https://jira.secondlife.com/browse/VWR-5414 https://jira.secondlife.com/browse/VWR-5412 https://jira.secondlife.com/browse/VWR-4456 but then I stumbled into LLPhysicalAvatar, and I couldn't find anything on google about it, so I didn't find any patch or PJIRA page. error output follows, slightly longer version here: http://www.pastebin.ca/raw/1039869 In file included from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatartool.h:44, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llvoavatar.h:61, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llfloatercustomize.h:43, from /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llagent.cpp:73: /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:192: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:193: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:207: error: ISO C++ forbids declaration of 'LLPhysicalAvatar' with no type /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:207: error: expected ';' before '*' token /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:222: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:223: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:229: error: 'LLPhysicalAvatar' has not been declared /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llphysicalavatar.h:230: error: expected `)' before '*' token cc1plus: warnings being treated as errors /tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llsky.h:45: warning: 'NIGHTTIME_ELEVATION_COS' defined but not used scons: *** [/tmp/puppeteer/linden/indra/i686-linux-client-releasefordownload/newview/llagent.o] Error 1 scons: building terminated because of errors. bye :) Opensource Obscure From jacek.antonelli at gmail.com Thu Jun 5 15:37:44 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Jun 5 15:37:46 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> On Thu, Jun 5, 2008 at 10:37 AM, Sarah Hutchinson wrote: > Address Bar - The address bar will display a SLURL by default. Users can > enter a SLURL, or Region name in their Inventory. Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont (152,166,46)" -- depending on how specific I feel like being. Why force people to type in all that needless boilerplate and punctuation? It would also be really useful to be able to type in a landmark, with name completion, just as it is in the Map floater. Type in "Ben's house" (the name of the landmark in my inventory), press Enter or click Go, and off I go to Ben's house. > If the Resident types in > a Region name that is not in their Inventory, we will go a global search to > find the location. If the location cannot be found, the Search floater will > open. I'm fond of the way Firefox's search bar will make suggestions if you type something in and pause for a little bit. It would be great to have region name suggestions pop up in a similar way, after a delay. (It might be tricky to integrate that with landmark name completion, though.) > Set the number of days to store location history > > Set the number of days to store address bar history Another suggestion: number of locations to store. So, store the last 10, 20, 50, etc. items, rather than days. This could be a number entry with a drop-down box or radio buttons next to it, e.g. "Remember the last [_10_] (_) days (o) items" > Received Landmarks - A sub-folder in the Landmarks folder in Inventory where > all received Landmarks are stored by default. I love this idea. Would especially love to see this generalized into an "Inbox" / "Received" folder for all inventory. I know I'm not alone in this wish. :-D But that is probably outside the scope of the project. From richard at lindenlab.com Thu Jun 5 16:12:48 2008 From: richard at lindenlab.com (Richard Nelson) Date: Thu Jun 5 16:12:50 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C@gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-431F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> Message-ID: On Sat, 31 May 2008 07:14:03 -0700, Argent Stonecutter wrote: > On 2008-05-30, at 09:10, Felix Duesenburg wrote: >> Argent Stonecutter wrote: >>> ... >>> I would rather the texture picker just be a filtered inventory view... >> > >> From what I can see in the source code, that's exactly what it already >> is... not? > > I mean, I want to be able to open the inventory and click on a texture > and have it previewed the way the texture picker does it, without having > to be in the texture picker. > Felix is right, the texture picker uses an embedded inventory panel with the filter rules set to only show textures. If I understand you correctly, you want the preview portion of the texture picker to be part of the inventory window as well. I think you might get something similar with the proposed inventory item thumbnail project. >>> That's why I want the "landmarks" dropdown in the world map to ONLY >>> show landmarks in my "Landmarks" folder. In fact I'd like to select >>> which subfolder of the Landmarks folder the map looks at. That way >>> landmarks in boxes and landmark givers don't clutter up the map view. >> > >> Then why not just preserve the folders as they are, just omitting those >> that don't contain any landmarks. That way you know exactly where to >> look. > > Clutter. When I'm on the map, I'm looking for my favorite landmarks. > I think the first step is to add the concept of selectable root folder(s) to the inventory item filter, which would allow you to only show contents of the specified folders. Once that is done, it would be much easier to show restricted views of your inventory items for special cases like these. > In SL, having the map view only pull down one folder's worth of > bookmarks instead of groveling through the whole inventory looking for > them should have an even bigger effect on improving performance. > There are several operations which require a full inventory search...I don't remember them all. The working assumption right now is that any time you run the client you will need your entire inventory contents in short order. I think we still have some bugs around inventory caching to fix, though. Richard From sarah at aucreativegroup.com Thu Jun 5 16:47:53 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 16:47:55 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> * **On Thu, Jun 5, 2008 at 5:05 PM, Brandon Lockaby wrote: * > > *Would one be able to look through the location history and decide to > bookmark any of the items? > * The ability to bookmark a location history item hasn't been scoped, but that's a cool idea. I've made a note of it and will share it with the team. If it's not a feature than can be integrated in the scope of this project, it's a great feature idea for a future enhancement. > Also I want to put in a few words about back & forward buttons: remember, > Second Life has teleport problems and much like the web you don't always > know where the back button is going to take you. Can you imagine hitting > the back button rapidly trying to find something? So, with a web browser, > you have something like drop-down box buttons next to those back and forward > buttons showing a quick history you can choose from, that comes in handy. > Our implementation of a nav bar also includes a history drop-down just like a web browser. If you take a look in NAV-28, there should be a few designs and wireframes that show this feature. > Oh! What's the internal opinion on having the widget in the menu bar > instead of a floater? > We discussed the idea of integrating the nav bar into the menu bar, but felt it made the menu bar far too cluttered. There's just so much happening in that area of the UI already. As long as you run Second Life in a full screen window on a large monitor, it can work out great - but for those running Second Life on a smaller display or window, it was just too crowded. - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/e9319624/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 16:56:34 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 16:56:36 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9D724747E0074EFDA92A17B3E570D3A0@devbits.intra> Message-ID: <9010c35c0806051656i46f403e9p10a81a1f839caf05@mail.gmail.com> On Thu, Jun 5, 2008 at 5:53 PM, Kitty wrote: > so it would seem that the history is populated only from > point-to-point teleporting and nothing else? > ... > Parcel-to-parcel tracking (probably would have to based on a "user > definable > time spent on that parcel" to avoid clutter) would seem a lot more useful > than only tracking tp's. This is great feedback. Due to time constraints in our specific project, the baseline functionality to be introduced is teleport history. However, the team is actively investigating a better heuristic for how the history is populated. In the research phase of the project, we talked with Residents about the qualifications for an item being added to history - and it seems to boil down down time spent within a given Parcel. I completely agree that this would make the history feature a lot more useful. I know the Development team at Vectorform is continuing to investigate the feasibility of this functionality and once I have more information, I'll certainly pass it along. > What I would love as a history would be a trajectory overlayed on a sim > map, > with points where I stopped for several minutes highlighted as potential > reference points. Great idea! I'll note this as a future enhancement idea. It ties into another idea we discussed which is that of a travelogue where you can record information about your travels in Second Life and post that information on the web. Being able to see a map overlay would be awesome. > We have a setting that determines whether double clicking a landmark > automatically teleports you or whether it pops up a confirmation dialog. I > personally like having the confirmation since misclicks do happen. I've made a note of this and will bring it up during our next status. It seems that a confirmation that the first time (that you may dismiss if you wish) is a very good idea in this case. > If the browser analogy has to be made, I would expect to be able to type > "Shiny Things" there and have it fetch the location from the recent history > or landmarks with an auto-complete drop down. > --- > I'm not sure if I missed it, but where is all the extra metadata stored? > I'll check in with the team on the auto-complete and extra metadata and get back to you! I want to make sure I don't misquote the developers! :) - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/c4de0c04/attachment.htm From sarah at aucreativegroup.com Thu Jun 5 17:01:30 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Thu Jun 5 17:01:34 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> Message-ID: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> On Thu, Jun 5, 2008 at 6:37 PM, Jacek Antonelli wrote: > Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing > "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just > be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont > (152,166,46)" -- depending on how specific I feel like being. Why > force people to type in all that needless boilerplate and punctuation? > I apologize for the confusion - while the SLURL has been discussed as the default, you will also be able to type a Region name. I'll check in with the development team to get some more specifics. It would also be really useful to be able to type in a landmark, with > name completion, just as it is in the Map floater. Type in "Ben's > house" (the name of the landmark in my inventory), press Enter or > click Go, and off I go to Ben's house. I agree. I'd like to have this functionality too. When I name a Landmark, 'My build hideaway', I'd like to be able to type that into the address bar. I will follow up on that as well. - Kippie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3fdb60cd/attachment.htm From gbrandon at gmail.com Thu Jun 5 17:21:31 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Jun 5 17:21:36 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: Attaching link to article about FireFox 3's "smart bar" since I keep thinking of it here http://ed.agadak.net/2007/11/smartbar-to-awesomebar On Thu, Jun 5, 2008 at 8:01 PM, Sarah Hutchinson wrote: > On Thu, Jun 5, 2008 at 6:37 PM, Jacek Antonelli > wrote: > >> Ick, ick ick. I don't want to read nor type nasty, ugly, cofusing >> "http://slurl.com/secondlife/Beaumont/152/166/46" when I should just >> be able to type "Beaumont", "Beaumont (152,166)", or "Beaumont >> (152,166,46)" -- depending on how specific I feel like being. Why >> force people to type in all that needless boilerplate and punctuation? >> > > I apologize for the confusion - while the SLURL has been discussed as the > default, you will also be able to type a Region name. I'll check in with the > development team to get some more specifics. > > It would also be really useful to be able to type in a landmark, with >> name completion, just as it is in the Map floater. Type in "Ben's >> house" (the name of the landmark in my inventory), press Enter or >> click Go, and off I go to Ben's house. > > > I agree. I'd like to have this functionality too. When I name a Landmark, > 'My build hideaway', I'd like to be able to type that into the address bar. > I will follow up on that as well. > > - Kippie > > > _______________________________________________ > 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/20080605/c1ce7192/attachment.htm From tongb at ohio.edu Thu Jun 5 17:47:18 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 5 17:47:23 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> Message-ID: <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> I attempted to build using cmake for the first time. I seem to have encountered something similar to what Michelle2 Zenovka mentioned in VWR-6794. I guess that's fitting since I was following her nice summary found at... http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake I was using the sources from... slviewer-src-maint-viewer-7-r88903 $ ./develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DUNATTENDED:BOOl=FALSE -DSTANDALONE:BO OL=FALSE "" "c:/ZZTong/SLDev/linden/indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works -- Building with FMOD audio support -- Building with FMOD audio support -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in '/cygdrive/c/ZZTong/SLDev/linden/i ndra' sh: toolsvstoolVSTool.exe: command not found Traceback (most recent call last): File "./develop.py", line 631, in main(sys.argv[1:]) File "./develop.py", line 604, in main setup.run_cmake() File "./develop.py", line 493, in run_cmake self.run(vstool_cmd) File "./develop.py", line 481, in run (name, ret)) __main__.CommandError: the command 'tools\\vstool\\VSTool.exe' exited with 32512 One thing I found that wasn't mentioned was this message from develop.py: The C compiler "c1" is not able to compile a simple test program. It fails with the following output: The requested operation requires elevation Generator: execution of make failed. Make command was: C:\PROGRA~1\MICROS~2\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debu g /project cmTryCompileExec I figured this was refering to ... C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VCExpress.exe ... and I resolved it by... Control Panel -> User Accounts Turn Account Control OFF ... I'm not used to developing on Windows, plus this is my first exposure to Windows Vista. I was expecting somebody to knock on the door and say "Hi, I'm a Mac", but that didn't happen. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Thu Jun 5 17:50:02 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 5 17:50:04 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> Message-ID: On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: > I attempted to build using cmake for the first time. I seem to have > encountered something similar to what Michelle2 Zenovka mentioned in > VWR-6794. I guess that's fitting since I was following her nice > summary found at... > > http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake > > I was using the sources from... slviewer-src-maint-viewer-7-r88903 > > $ ./develop.py -G VC80 >From the $ prompt, are you attempting this with cygwin? What happens if you try it from a command shell without cygwin in your path? From secret.argent at gmail.com Thu Jun 5 19:54:43 2008 From: secret.argent at gmail.com (Argent) Date: Thu Jun 5 19:54:45 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C@gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-431F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> Message-ID: <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> On Thu, Jun 5, 2008 at 6:12 PM, Richard Nelson wrote: > If I understand you correctly, you want the preview portion of the texture picker to > be part of the inventory window as well. Close. I want it available as a view of the inventory. > There are several operations which require a full inventory search...I don't remember > them all. I don't think pulling in landmarks is, because when I open a folder in the inventory it will open, but other folders in the inventory may still be in the downloading state... and teh landmarks folder is no exception. > The working assumption right now is that any time you run the client you will need > your entire inventory contents in short order. I don't know that's a safe assumption. Usually the first thing I do when I log in is look up a landmark to get to the first place I want to go to. I do this long before I hit the inventory for anything else. Bringing up the inventory menu in the map is MUCH slower than opening the inventory, opening landmarks, and working from there, but it's also more convenient. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/3d2eb10e/attachment.htm From kf6kjg at gmail.com Thu Jun 5 19:55:29 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Jun 5 19:55:32 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4847862B.7060509@gmail.com> <3bb9647e0806042355l1cf6fa3w3ff8fa24a70dac3a@mail.gmail.com> Message-ID: <3bb9647e0806051955s3f38273bm68db1bda4d7207c9@mail.gmail.com> I just did a reverse-dependency check for my installed programs thinking that I might have some problems there, and I did, but fixing those problems didn't fix the build. Still trying to figure it out. Anything I might want to look at? Here is what I do: $ cd ./linden/indra $ ./develop.py cmake $ cd viewer-linux-i686 $ make Cron On Thu, Jun 5, 2008 at 1:10 AM, Robin Cornelius wrote: > On Thu, Jun 5, 2008 at 7:55 AM, Ricky wrote: > > hmm... According to portage (the package management system for Gentoo) I > > already have freetype 2.3.5-r2 installed in the chroot. > > > > And i am being stupid at the same time, its complaining of missing > symbols not a missing library so its not even attempting to link > against freetype. But it must have found the freetype headers. > > STANDALONE uses pkgconfig in indra/Freetype.cmake which will set the > CFLAGS and LDFLAGS correctly, something is missing somewhere then in > the standard build? Has it detected you are on 64bit and changed the > library location to libraries/x86_64-linux which i presume there are > no prebuild libs for? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080605/c278db31/attachment.htm From tongb at ohio.edu Thu Jun 5 21:12:43 2008 From: tongb at ohio.edu (Bruce Tong) Date: Thu Jun 5 21:12:48 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> Message-ID: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Yes, I was running that within a bash shell from cygwin. I'm not sure why, now that I think about it. Some part of the process had me install it. I like bash and I guess it must have been wishful thinking on my part, or something. If I try it from a windows command prompt, I get... C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' -- Building with FMOD audio support -- Building with FMOD audio support -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' Opening solution: build-VC80\SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, now opening new VisualStudio instance... Reading .sln file version... Opening VS version: VC80... Value cannot be null. Parameter name: type Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl n On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: > On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >> I attempted to build using cmake for the first time. I seem to have >> encountered something similar to what Michelle2 Zenovka mentioned in >> VWR-6794. I guess that's fitting since I was following her nice >> summary found at... >> >> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >> >> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >> >> $ ./develop.py -G VC80 > > >From the $ prompt, are you attempting this with cygwin? What happens > if you try it from a command shell without cygwin in your path? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Bruce Tong Software Engineer Office of Information Technology Ohio University From soft at lindenlab.com Thu Jun 5 21:24:11 2008 From: soft at lindenlab.com (Soft) Date: Thu Jun 5 21:24:13 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Message-ID: Thanks, passing this straight to the cmake guys in case they're not reading On Thu, Jun 5, 2008 at 11:12 PM, Bruce Tong wrote: > Yes, I was running that within a bash shell from cygwin. I'm not sure > why, now that I think about it. Some part of the process had me > install it. I like bash and I guess it must have been wishful thinking > on my part, or something. > > If I try it from a windows command prompt, I get... > > C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 > Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' > -- Building with FMOD audio support > -- Building with FMOD audio support > -- Version of viewer is 1.20.6.0 > -- Configuring done > -- Generating done > -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 > Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi > g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' > > Opening solution: build-VC80\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC80... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl > n > > On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> I attempted to build using cmake for the first time. I seem to have >>> encountered something similar to what Michelle2 Zenovka mentioned in >>> VWR-6794. I guess that's fitting since I was following her nice >>> summary found at... >>> >>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>> >>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>> >>> $ ./develop.py -G VC80 >> >> >From the $ prompt, are you attempting this with cygwin? What happens >> if you try it from a command shell without cygwin in your path? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > From gigstaggart at gmail.com Thu Jun 5 22:46:28 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 5 22:46:31 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> Message-ID: <4848CF34.604@gmail.com> Argent Stonecutter wrote: > On 2008-06-04, at 00:04, Jason Giglio wrote: >> I'm all for metered bandwidth. > > I don't think "metered bandwidth" is a good term. Bandwidth is "how > much you can transmit per unit of time", and is metered in units of > bits-per-second. My bandwidth is capped to 256 kilobits per second, > for example. This is good enough to play SL, but not enough to stream > HD movies (or stream anything while I'm playing SL). > > What we're talking about here needs a different term. It's not a > bandwidth cap, it's a total traffic cap. I don't know what you are talking about, but what I'm talking about is metered bandwidth. I.e. 0.1 cents per meg + $5/month as an example. Like every other utility service known to man, in other words. Your water company does not turn off your water if you use over a certain amount, they just charge you more. Internet service should be no different. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/8fc901d1/smime-0001.bin From tateru.nino at gmail.com Thu Jun 5 22:51:35 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 5 22:52:19 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: <4848D067.5000704@gmail.com> Jason Giglio wrote: > Argent Stonecutter wrote: > >> On 2008-06-04, at 00:04, Jason Giglio wrote: >> >>> I'm all for metered bandwidth. >>> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. >> > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. > > I.e. 0.1 cents per meg + $5/month as an example. Like every other > utility service known to man, in other words. > > Your water company does not turn off your water if you use over a > certain amount, they just charge you more. Internet service should be > no different. > > Most countries either cut it off - or charge you extra. US$0.115 is a common amount to charge per million bytes (not per meg). From lcc1967 at gmail.com Thu Jun 5 23:37:54 2008 From: lcc1967 at gmail.com (laurent cezanne) Date: Thu Jun 5 23:37:57 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> Message-ID: about LM navigation: Is there a way to show a LM has changed like a sim owner change or coordonate ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/33a51086/attachment.htm From ordinal.malaprop at fastmail.fm Fri Jun 6 02:01:28 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Jun 6 02:01:33 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: On 6 Jun 2008, at 06:46, Jason Giglio wrote: > Argent Stonecutter wrote: >> On 2008-06-04, at 00:04, Jason Giglio wrote: >>> I'm all for metered bandwidth. >> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. > > I.e. 0.1 cents per meg + $5/month as an example. Like every other > utility service known to man, in other words. > > Your water company does not turn off your water if you use over a > certain amount, they just charge you more. Internet service should be > no different. I think that what he is talking about is that what is being referred to here and elsewhere as "bandwidth" is not bandwidth, but quantity of data transferred. (Incidentally my water is not metered, but that's by the by.) From kfa at gmx.net Fri Jun 6 02:32:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 02:32:16 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> Message-ID: <48490413.8050708@gmx.net> laurent cezanne wrote: > about LM navigation: Is there a way to show a LM has changed like a sim > owner change or coordonate ? > > Great point! No, currently not. When taking a landmark, you only conserve a piece of information from that time which afterwards has no more connection with its source. Having a way to poll for an update would constitute a significant improvement in the value of landmarks. This would be a great item for the NAV project, if someone with the permission to post there felt inclined to include it. Also, it involves doing something on the server side, so it's not something that the OS crowd currently could take up. Not sure if Vectorform is granted access beyond the viewer? Cheers, Felix From robin.cornelius at gmail.com Fri Jun 6 02:38:12 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jun 6 02:38:19 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed Message-ID: Hi everyone, We had some more discussion at Rob's hours yesterday and the basic problem is there are multiple issues here and we seem to be going over the same topics in circles without really achieving very much. (In fact Rob believes this sounds like the March 2007 discussion all over again). Rob proposed we create a bof[1] Working Group, and to me this sounds like it needs some wiki pages to lay out the issues. I am happy to try to pull some stuff together, but without sounding like a complete moron, where should we put these pages on the wiki? What i propose is that we firstly try to subdivide these issues and although they are related there seems to be some funtimental top level categories that are :- * Performance * Amount of downloaded data May be more and sub issues of those too. The original discussion was purely a performance due to decoding of cached j2k textures. But other very valid sub points have cropped up including issues of the amount of downloaded data. Various suggestions have been made about storing more data, uncompressed data etc all of which many have consequences .Other things include not using the separate texture headers and files, storing in alternative formats We could also do with defining what we could do and methods of measuring its effects in quantitative terms NOT qualitative for performance/data download amounts etc. But we also have to factor in to account political views (the angry villagers with pitchforks analogy). So what i would like to do is :- * Define issues with the texture caching system (with the scope also including download amounts due to textures) * Define and discuss possible solutions, alternatives etc. * Get some linden input on what they are doing internally, is the texture cache being rewritten? or planning to be as part of the new texture pipeline, is this worth wile and will it provide decent feedback to the lindens? * If anyone has time, play with some possible solutions and measure performance. * if we are to measure performance, define how on earth to do this. Regards Robin [1] http://en.wikipedia.org/wiki/Birds_of_a_Feather_(computing) From kfa at gmx.net Fri Jun 6 02:49:33 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 02:49:47 2008 Subject: [sldev] More ideas for NAV - was: Re: SLDev Digest, Vol 18, Issue 32 In-Reply-To: <48490413.8050708@gmx.net> References: <20080605153754.A2EE441B3B6@stupor.lindenlab.com> <48490413.8050708@gmx.net> Message-ID: <4849082D.5010701@gmx.net> Felix Duesenburg wrote: > laurent cezanne wrote: >> about LM navigation: Is there a way to show a LM has changed like a >> sim owner change or coordonate ? >> >> > > Great point! No, currently not. When taking a landmark, you only > conserve a piece of information from that time which afterwards has no > more connection with its source. Having a way to poll for an update > would constitute a significant improvement in the value of landmarks. > > This would be a great item for the NAV project, if someone with the > permission to post there felt inclined to include it. Also, it involves > doing something on the server side, so it's not something that the OS > crowd currently could take up. ... Maybe I spoke too quickly... why could we not? It should be possible to do a search for the geocoordinates of a landmark and retrieve current information about its owner, name, even parcel content when I look at how the places search recently works. This could be run as a background task when inventory is refreshed. Only thing, I'm not sure what that would do to the database load if it was a standard feature... Another idea for NAV: The landmark preview floater could include all the information that you find with the places search. Maybe vendors would like the idea that this way the list of objects for sale at that location would be visible to the client just by a double click. Does that make sense? Felix From robin.cornelius at gmail.com Fri Jun 6 04:17:26 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jun 6 04:17:30 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: On Fri, Jun 6, 2008 at 11:57 AM, Dale Mahalko wrote: > Is there some particular reason the caching is limited to just > textures? It appears that most everything else also has the potential > to also be cached. Sounds, primitive shapes, notecards, linksets, and > the terrain shape should also apparently be locally cachable. No technical reason, that i know of anyway for things like animations and sounds, even notecards and things that have an asset server LLUID. The current system does cache sounds, animations etc for a single session but they are deleted when the viewer closes. This is something i will be changing on my private viewer just for the reason "why the **** am i downloading the same sound/animation etc again and again" Now objects shapes and things that are not static are more troublesome as i suppose you need a way of re synchronizing. I don't know the message handshakes in enough detail to know how well this could work. I think some is done now? But i would have thought that the basic object position/details is fairly low bandwidth information compared to textures/sounds and the like and the additional overhead may outweigh the simple waiting for the object update packets, i don't know. Robin From dmahalko at gmail.com Fri Jun 6 03:57:29 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 6 04:22:03 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: Is there some particular reason the caching is limited to just textures? It appears that most everything else also has the potential to also be cached. Sounds, primitive shapes, notecards, linksets, and the terrain shape should also apparently be locally cachable. Regarding the angry pitchforks, I suppose you could do something fast and stupid like (rot13 + some offset) on everything, and then slap the DMCA against anyone who "decodes" that "encryption" system. Other than that, it has been stated over and over that nothing can done to absolutely protect any asset data from copying, other than server-side compiled scripts. I fully accept that there may be strong political views against developing a robust and comprehensive local cache because that make it easy to "rip" the sounds, images, and objects created by other people. I see this as no defense against doing good local caching because those with the programming skill to do so are already ripping content from asset system using the client source code and wrappers. And even if there is strong resistance to having a large and easily rippable cache on the local user's machine, this should not stop the development of a "commercial grade" proxy cache for use by an ISP, school, or business which must support many users all trying to access the same super-high bandwidth SL system. The likelihood of someone at an ISP or university ripping someone's skirt texture from their local 10 TB SL asset-proxy/cache is pretty darn low, compared to the massive benefits of being able to taking the asset download strain off their Internet bandwidth. - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 4:38 AM, Robin Cornelius wrote: > What i propose is that we firstly try to subdivide these issues and > although they are related there seems to be some funtimental top level > categories that are :- > > * Performance > * Amount of downloaded data From tateru.nino at gmail.com Fri Jun 6 04:21:45 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 04:22:30 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: <48491DC9.3000908@gmail.com> ordinal.malaprop@fastmail.fm wrote: > > On 6 Jun 2008, at 06:46, Jason Giglio wrote: > >> Argent Stonecutter wrote: >>> On 2008-06-04, at 00:04, Jason Giglio wrote: >>>> I'm all for metered bandwidth. >>> >>> I don't think "metered bandwidth" is a good term. Bandwidth is "how >>> much you can transmit per unit of time", and is metered in units of >>> bits-per-second. My bandwidth is capped to 256 kilobits per second, >>> for example. This is good enough to play SL, but not enough to stream >>> HD movies (or stream anything while I'm playing SL). >>> >>> What we're talking about here needs a different term. It's not a >>> bandwidth cap, it's a total traffic cap. >> >> >> I don't know what you are talking about, but what I'm talking about is >> metered bandwidth. >> >> I.e. 0.1 cents per meg + $5/month as an example. Like every other >> utility service known to man, in other words. >> >> Your water company does not turn off your water if you use over a >> certain amount, they just charge you more. Internet service should be >> no different. > > I think that what he is talking about is that what is being referred > to here and elsewhere as "bandwidth" is not bandwidth, but quantity of > data transferred. > "Bandwidth" is confusingly used to mean "bandwidth consumption" which, I believe, is what is actually being referred to in this discussion. From tateru.nino at gmail.com Fri Jun 6 04:25:12 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 04:25:58 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <48491E98.3@gmail.com> Robin Cornelius wrote: > On Fri, Jun 6, 2008 at 11:57 AM, Dale Mahalko wrote: > >> Is there some particular reason the caching is limited to just >> textures? It appears that most everything else also has the potential >> to also be cached. Sounds, primitive shapes, notecards, linksets, and >> the terrain shape should also apparently be locally cachable. >> > > No technical reason, that i know of anyway for things like animations > and sounds, even notecards and things that have an asset server LLUID. > > The current system does cache sounds, animations etc for a single > session but they are deleted when the viewer closes. This is > something i will be changing on my private viewer just for the reason > "why the **** am i downloading the same sound/animation etc again and > again" > Animations sometimes seem to get corrupted. I've certainly seen broken animations get cached, where they annoy you for the rest of a session. I've heard anecdotal accounts of the viewer caching silences when it comes to sounds, but I'm less certain of that. From secret.argent at gmail.com Fri Jun 6 04:40:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:39:24 2008 Subject: [sldev] Puppettering Branch In-Reply-To: References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <5B5D7CC9-82D8-48DF-B66F-DA7706688565@gmail.com> Message-ID: <6E97248F-39D3-457F-B1B9-19FC91EEE117@gmail.com> Added SVC-2482. From me at signpostmarv.name Fri Jun 6 04:41:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jun 6 04:41:13 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <48492253.9050308@signpostmarv.name> Dale Mahalko wrote: > Is there some particular reason the caching is limited to just > textures? It appears that most everything else also has the potential > to also be cached. Sounds, primitive shapes, notecards, linksets, and > the terrain shape should also apparently be locally cachable. > > Regarding the angry pitchforks, I suppose you could do something fast > and stupid like (rot13 + some offset) on everything, and then slap the > DMCA against anyone who "decodes" that "encryption" system. Other than > that, it has been stated over and over that nothing can done to > absolutely protect any asset data from copying, other than server-side > compiled scripts. > > > I fully accept that there may be strong political views against > developing a robust and comprehensive local cache because that make it > easy to "rip" the sounds, images, and objects created by other people. > I see this as no defense against doing good local caching because > those with the programming skill to do so are already ripping content > from asset system using the client source code and wrappers. In order to get appease the pitchfork carrying mob, since textures are being fetched over HTTP (and one assumes other assets may be sent over HTTP ?), why not just have the remote tool that spits out the asset examine permissions and send appropriate caching headers ? I'd not advocate borking the existing permissions system to figure out which headers to send, I'd prefer adding an additional "allow client caching" flag, where it sends appropriate Cache-Control headers ? http://www.mnot.net/cache_docs/#CACHE-CONTROL ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/5aebb865/smime.bin From gigstaggart at gmail.com Fri Jun 6 04:48:13 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 04:48:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <3736d47a0806051412w2df8adb1p35b2f5416b48d819@mail.gmail.com> Message-ID: <484923FD.2020807@gmail.com> Sean Lynch wrote: > Sorry, I phrased that confusingly. By "routed directly to other viewers" I > meant the message is routed by the simulator to any viewers that can see the > agent. There are some messages that work this way, but I don't know what > they are off the top of my head. LookAt, Typing Animation, maybe fidgits? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/1b014e5d/smime.bin From secret.argent at gmail.com Fri Jun 6 04:50:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:48:53 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4848206A.4030804@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> Message-ID: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> I don't think P2P is an option from a privacy perspective anyway. From gigstaggart at gmail.com Fri Jun 6 04:52:06 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 04:52:11 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> Message-ID: <484924E6.8080607@gmail.com> Argent Stonecutter wrote: > I don't think P2P is an option from a privacy perspective anyway. What do you mean, 70-140-36-186.lightspeed.hstntx.sbcglobal.net? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/ca3e100f/smime-0001.bin From secret.argent at gmail.com Fri Jun 6 04:59:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 04:58:38 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48483FBE.8070206@watson.ibm.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <4d211a610806042315k1ae439a8ve189ed4583ba7d15@mail.gmail.com> <4d211a610806050045i18efbf5cp9fdc533a6e70429b@mail.gmail.com> <48481D32.40604@cox.net> <48483FBE.8070206@watson.ibm.com> Message-ID: On 2008-06-05, at 14:34, Mike Monkowski wrote: > The problem I see with gestures is that they have a fixed time > sequence. They play exactly the same way every time. Not very > cinematic. I have wanted an extended llStartAnimation() with a few extra options: llStartAnimationExt(string anim, float rate, vector offset, integer priority, integer bonemask, ...); Alas, scrubbing in a HUD would require fixing a number of JIRAs regarding llDetectedGrab() and similar. From secret.argent at gmail.com Fri Jun 6 05:06:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:05:37 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> Message-ID: On 2008-06-05, at 18:47, Sarah Hutchinson wrote: > We discussed the idea of integrating the nav bar into the menu bar, > but felt it made the menu bar far too cluttered. There's just so > much happening in that area of the UI already. What about making the region name in the menu bar, something that's already there, into a menu dropdown? The existing action (land properties) would be in the menu, along with navigation options... From secret.argent at gmail.com Fri Jun 6 05:11:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:09:53 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: <95DD712A-52D3-456D-8123-9F040D56BA6C@gmail.com> On 2008-06-05, at 19:01, Sarah Hutchinson wrote: > I apologize for the confusion - while the SLURL has been discussed > as the default, you will also be able to type a Region name. I'll > check in with the development team to get some more specifics. I don't want to see the SLURL displayed, either. What is wrong with "secondlife://region/x/y/z" by the way? Why the switch to the external SLURLs inside the game? It seems inconsistent, plus it makes it hard to pass someone an extern link on the slurl site... From secret.argent at gmail.com Fri Jun 6 05:24:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:23:04 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4848CF34.604@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> Message-ID: On 2008-06-06, at 00:46, Jason Giglio wrote: > Argent Stonecutter wrote: >> On 2008-06-04, at 00:04, Jason Giglio wrote: >>> I'm all for metered bandwidth. >> >> I don't think "metered bandwidth" is a good term. Bandwidth is "how >> much you can transmit per unit of time", and is metered in units of >> bits-per-second. My bandwidth is capped to 256 kilobits per second, >> for example. This is good enough to play SL, but not enough to stream >> HD movies (or stream anything while I'm playing SL). >> >> What we're talking about here needs a different term. It's not a >> bandwidth cap, it's a total traffic cap. > > > I don't know what you are talking about, but what I'm talking about is > metered bandwidth. I know what you're talking about. I'm saying that it's the wrong term. Your bandwidth (the amount of data you can transfer per second) is not metered in the scheme you are talking about, the total traffic (the total amount of data you are allowed to transfer) is. I have actual metered bandwidth at home. If I want higher transfer speeds, I pay more. I currently have it set to 256k per second. 256k per second is a *bandwidth* measurement. 5GB per month isn't... that 5GB can be a small number of high bandwidth transfers, or a long period with much lower bandwidth. From secret.argent at gmail.com Fri Jun 6 05:29:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:27:41 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48491DC9.3000908@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> Message-ID: <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> On 2008-06-06, at 06:21, Tateru Nino wrote: > "Bandwidth" is confusingly used to mean "bandwidth consumption" > which, I believe, is what is actually being referred to in this > discussion. I have no idea what "bandwidth consumption" means. Bandwidth isn't consumed, like power or water. It's a speed limit. What would "speed limit consumption" mean? From secret.argent at gmail.com Fri Jun 6 05:32:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 6 05:32:31 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484924E6.8080607@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> Message-ID: <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> On 2008-06-06, at 06:52, Jason Giglio wrote: > Argent Stonecutter wrote: >> I don't think P2P is an option from a privacy perspective anyway. > > What do you mean, 70-140-36-186.lightspeed.hstntx.sbcglobal.net? Email doesn't happen inside SL. There is currently no way for you to get that information about me *within second life* and use it to determine that any member of my family is using SL from the same IP address and figure out who they are in SL. None. Zippo. Zero. That SHOULD NOT change. From bboomslang at googlemail.com Fri Jun 6 05:45:25 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Fri Jun 6 05:45:29 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: References: <48456D49.5020105@bitparts.org> <4d211a610806031003o5be81b34p39761a8b8c597b65@mail.gmail.com> <48457A9B.1010704@weblogsinc.com> <4845A31D.10002@bitparts.org> <4845DDD0.70305@gmx.net> <79e704e0806031811p4e08416au32c96cd8d3e510d3@mail.gmail.com> Message-ID: <347b550f0806060545m6ef5389bk16232e6463254ca5@mail.gmail.com> Hey, yep, I run that option enabled for as long as I know about it's existance - and yep, it does help definitely. I have a dual-core machine, so it actually enhances FPS since part of the code is offloaded to the other core. And I never had any problems that were linked to that option - or to put differently, everytime I had problems I thought might be related to it, they didn't improve by switching it off and usually where solved by one of Nicholaz' patches ;) bye, Barney On 6/4/08, Nexeus Fatale wrote: > I wonder if anyone has tested the run multiple threads and have found > any improvements > > > - Nexeus > > > On Tue, Jun 3, 2008 at 9:11 PM, Matthew Underwood wrote: > > On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble wrote: > >> If the goal were to improve seek time in a cache, how about keeping the > >> cache on one of those readyboost-capable usb flash drives? They can have > >> seek times as low as 1 ms or better, although the transfer rate and write > >> times arent all that fast. > >> > >> Then again it's probably moot if the bottleneck is the decoding :/ > >> > >> On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg wrote: > >>> > >>> Dale Mahalko wrote: > >>>> > >>>> ... > >>>> Windows isn't good at dealing with directories containing tens of > >>>> thousands of files. Ever tried opening a folder containing 20,000 > >>>> files? There is a delay of several seconds trying to do this in > >>>> Windows. Also the hidden MFT and directory structures can become > >>>> ridiculously fragmented, also leading to slowdowns. > >>>> > >>> > >>> Reiser4 is excellent with exactly these requirements. It's not mature > >>> enough to be considered reliable for critical systems, but for a cache? It > >>> doesn't help that Reiser himself is removed from the development process, > >>> but it's still there and the source available. Shouldn't that be possible to > >>> be included as a virtual filesystem even under Windows? > >>> > >>> I also always thought it must be a good way to boost performance if the > >>> cache lived on its own partition, like a Linux swap partition. For the Linux > >>> version of SL this would even sound like the most natural way to do it. > >>> Setting such a thing up on an existing Windows machine has a slight fear > >>> factor attached and is not for everyone, but if a savvy user can handle it, > >>> why not offer. I'm speculating, but the difference could be dramatic, > >>> especially if we had a better file system than NTFS on that partition. > >>> > >>> > > >>> > A proper local database engine would likely deal with these huge > >>> > numbers of tiny files more efficiently than the local operating > >>> > system. > >>> > >>> Yes, but the usual architecture with the database running as a localhost > >>> server is not ideal for our situation since everything is squeezed back and > >>> forth through the network system, plus SQL parsing, unnecessarily. With > >>> MySQL you could build directly on top of the storage engine though, even > >>> bypassing the parsing with direct API calls. It would just serve as a > >>> virtual file system the same way as suggested above. I still believe that > >>> Reiser4 would be even faster. And according to the description on its (now > >>> defunct) website, they claimed reaching 94% package density with small > >>> files. > >>> > >>> Felix > > > > SQLite in a single user environment is incredibly fast so long as you > > don't let the database grow too large. Of course you have to figure > > out how efficiently textures can be stored and retrieved in SQL > > compared to the current caching system. > > > > On a side note: Does anyone know where it defines the polygon meshes > > for rendering cubes. I really want to try forcing untwisted, un-holed > > cubes down to 1-2 polygons per side and see if that will help out with > > the frame rate. I tried looking through the source but it is lacking > > in [helpful] comments. > > _______________________________________________ > > 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 me at signpostmarv.name Fri Jun 6 05:54:29 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jun 6 05:54:33 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> Message-ID: <48493385.4050008@signpostmarv.name> Aside from llParcelMediaCommandList() with the PARCEL_MEDIA_COMMAND_AGENT flag set. Argent Stonecutter wrote: > Email doesn't happen inside SL. There is currently no way for you to > get that information about me *within second life* and use it to > determine that any member of my family is using SL from the same IP > address and figure out who they are in SL. None. Zippo. Zero. That > SHOULD NOT change. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/aa114734/smime.bin From gigstaggart at gmail.com Fri Jun 6 06:39:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 6 06:39:11 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> Message-ID: <48493DF8.4040003@gmail.com> Argent Stonecutter wrote: > On 2008-06-06, at 06:21, Tateru Nino wrote: >> "Bandwidth" is confusingly used to mean "bandwidth consumption" >> which, I believe, is what is actually being referred to in this >> discussion. > > I have no idea what "bandwidth consumption" means. Bandwidth isn't > consumed, like power or water. It's a speed limit. What would "speed > limit consumption" mean? Don't get all nitpicky. The use of the term "bandwidth" to mean "speed limit" is already an abuse of an engineering term that had a specific, mostly unrelated meaning. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080606/4ea979b4/smime.bin From alissa_sabre at yahoo.co.jp Thu Jun 5 21:11:08 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jun 6 06:48:15 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <4846FA40.4010102@gmail.com> References: <4846FA40.4010102@gmail.com> Message-ID: <1L2cG27ei4facewdds4mhwkw.alissa_sabre@yahoo.co.jp> > Well for the 1st digit there is a 1/16 chance of a hit, for 2 digits its > 1/256 chance for the Nth digit its a 1/(16^N) chance, so for your > specific question its 1/4294967296 (1 in about 4.2 billion). No. It is the probability of one particuar UUID hits with another. Since you have a lot of UUIDs in your cache, the probability that you find two (or more) having the same prefix in your cache is much larger than that. Search for "birthday paradox" with your favorite search engine for details. Alissa Sabre -------------------------------------- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ From kfa at gmx.net Fri Jun 6 06:49:44 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 06:49:54 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> Message-ID: <48494078.5090801@gmx.net> Sarah Hutchinson wrote: > > > We discussed the idea of integrating the nav bar into the menu bar, but > felt it made the menu bar far too cluttered. There's just so much > happening in that area of the UI already. As long as you run Second Life > in a full screen window on a large monitor, it can work out great - but > for those running Second Life on a smaller display or window, it was > just too crowded. > > - Kippie > > We'll probably find that there are different tastes, habits and opinions here. I usually run SL not in fullscreen mode, but in a window that is maximized. That way I still have all functionality available, be it SL or outside, but maximum viewing angle. I like my 3D view into the world uncluttered and unfettered, and everything else pushed out of the way, marginalized. I even use HUD's only sparingly. For me, the big main menu is where these things should go and stay. I wonder, what speaks against leaving it that way since we can tear off submenus? I'd say all it takes is preserving the state and position of a torn off menu across sessions to accomodate different usage patterns. Felix From danteferret at gmail.com Fri Jun 6 07:27:24 2008 From: danteferret at gmail.com (Dante Tucker) Date: Fri Jun 6 07:27:25 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <48494078.5090801@gmx.net> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> Message-ID: <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> Really, my main personal concern when this project is over is "Can I hide it? Can I make it go away?" It's not negativity against this project, It's just how I like my UI. There should be nothing more then the bottom bar, menu bar and the world. Actualy this is a major concern for many people here. So, can we hide these new navigation features if we don't want them? On Fri, Jun 6, 2008 at 9:49 AM, Felix Duesenburg wrote: > >> > We'll probably find that there are different tastes, habits and opinions > here. I usually run SL not in fullscreen mode, but in a window that is > maximized. That way I still have all functionality available, be it SL or > outside, but maximum viewing angle. I like my 3D view into the world > uncluttered and unfettered, and everything else pushed out of the way, > marginalized. I even use HUD's only sparingly. For me, the big main menu is > where these things should go and stay. I wonder, what speaks against leaving > it that way since we can tear off submenus? I'd say all it takes is > preserving the state and position of a torn off menu across sessions to > accomodate different usage patterns. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/3fde6bf1/attachment.htm From sarah at aucreativegroup.com Fri Jun 6 08:25:31 2008 From: sarah at aucreativegroup.com (Sarah Hutchinson) Date: Fri Jun 6 08:25:37 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> Message-ID: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> There is a tiny toggle that will be in the top left of the Viewer which will allow you to show and hide the nav bar as you want. Likewise, with the Landmarks Management UI, if you don't want to use it, you won't have to. You'll see be able to see and work with your Landmarks via the Inventory floater. I believe the latest creative posted to NAV-28 ( https://jira.secondlife.com/browse/NAV-28). That should show the toggle and the different states. So in the event that you have the nav bar hidden, you'd just have a small little toggle button at the top left. Does that help? Best, Kippie/Sarah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080606/fd7ca04b/attachment-0001.htm From kfa at gmx.net Fri Jun 6 09:26:19 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 09:26:27 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <4849652B.608@gmx.net> Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer which > will allow you to show and hide the nav bar as you want. > > Likewise, with the Landmarks Management UI, if you don't want to use it, > you won't have to. You'll see be able to see and work with your > Landmarks via the Inventory floater. > > I believe the latest creative posted to NAV-28 > (https://jira.secondlife.com/browse/NAV-28). That should show the toggle > and the different states. So in the event that you have the nav bar > hidden, you'd just have a small little toggle button at the top left. > Does that help? > > Best, > Kippie/Sarah > > Why not a menu item for the toggle thingy, possibly connected with a keyboard shortcut. Resistance is futile ;) From phoenix at secondlife.com Fri Jun 6 09:28:04 2008 From: phoenix at secondlife.com (Phoenix) Date: Fri Jun 6 09:28:22 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com><61a5f47b10aafc4ff71eb929813bd563@localhost>< 4f335a50806051747m21283315i92991e1d278bc217@mail.gmail.com> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> Message-ID: <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> The attached patch appears to solve the vstool problem, but I don't think microsoft tools like to be run from cygwin. VC71 usually worked under cygwin but: * /cyg/path/to/Program Files/CMake 2.4/bin must be in your path * vstool occasionally crashed -- deleting the generated directory and trying again always worked. * VC80 was unable to load the generated project file * I did not try VC90. I'm sneaking this patch into trunk, but you can try it out now. Index: develop.py =================================================================== --- develop.py (revision 89110) +++ develop.py (working copy) @@ -485,10 +485,11 @@ PlatformSetup.run_cmake(self, args) if self.unattended == 'FALSE': for build_dir in self.build_dirs(): - vstool_cmd = ('tools\\vstool\\VSTool.exe' - ' --solution %s\\SecondLife.sln' - ' --config RelWithDebInfo' - ' --startup secondlife-bin' % build_dir) + vstool_cmd = os.path.join ('tools','vstool','VSTool.exe') \ + + ' --solution ' \ + + os.path.join (build_dir,'SecondLife.sln') \ + + ' --config RelWithDebInfo' \ + + ' --startup secondlife-bin' print 'Running %r in %r' % (vstool_cmd, os.getcwd()) self.run(vstool_cmd) @@ -619,7 +620,7 @@ raise CommandError('clean takes no arguments') setup.cleanup() else: - print >> sys.stderr, 'Error: unknown command', repr(arg) + print >> sys.stderr, 'Error: unknown command', repr(cmd) print >> sys.stderr, "(run 'develop.py --help' for help)" sys.exit(1) except CommandError, err: On 2008-06-05, at 21:12, Bruce Tong wrote: > Yes, I was running that within a bash shell from cygwin. I'm not sure > why, now that I think about it. Some part of the process had me > install it. I like bash and I guess it must have been wishful thinking > on my part, or something. > > If I try it from a windows command prompt, I get... > > C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 > Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' > -- Building with FMOD audio support > -- Building with FMOD audio support > -- Version of viewer is 1.20.6.0 > -- Configuring done > -- Generating done > -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/ > build-VC80 > Running 'tools\\vstool\\VSTool.exe --solution build-VC80\ > \SecondLife.sln --confi > g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\ > \linden\\indra' > > Opening solution: build-VC80\SecondLife.sln > Looking for existing VisualStudio instance... > Didn't find open solution, now opening new VisualStudio instance... > Reading .sln file version... > Opening VS version: VC80... > Value cannot be null. > Parameter name: type > Quitting do error opening: C:\ZZTong\SLDev\linden\indra\build-VC80 > \SecondLife.sl > n > > On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> I attempted to build using cmake for the first time. I seem to have >>> encountered something similar to what Michelle2 Zenovka mentioned in >>> VWR-6794. I guess that's fitting since I was following her nice >>> summary found at... >>> >>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>> >>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>> >>> $ ./develop.py -G VC80 >> >>> From the $ prompt, are you attempting this with cygwin? What happens >> if you try it from a command shell without cygwin in your path? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > _______________________________________________ > 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: 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/20080606/e6f59446/PGP.pgp From richard at lindenlab.com Fri Jun 6 09:31:50 2008 From: richard at lindenlab.com (Richard Nelson) Date: Fri Jun 6 09:31:53 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> Message-ID: On Thu, 05 Jun 2008 19:54:43 -0700, Argent wrote: > On Thu, Jun 5, 2008 at 6:12 PM, Richard Nelson > wrote: >> There are several operations which require a full inventory search...I > don't remember >> them all. > > I don't think pulling in landmarks is, because when I open a folder in > the > inventory it will open, but other folders in the inventory may still be > in > the downloading state... and teh landmarks folder is no exception. > The inventory fetch is scheduled one folder at a time. Any time you explicitly open a folder, the request for the contents of that folder are put at the top of the queue, so you should see the contents appear quickly. But as long as you see the number of fetched items being reported at the top of the inventory window, then the entire thing is being downloaded. >> The working assumption right now is that any time you run the client you > will need >> your entire inventory contents in short order. > > I don't know that's a safe assumption. Usually the first thing I do when > I > log in is > look up a landmark to get to the first place I want to go to. I do this > long > before I > hit the inventory for anything else. Bringing up the inventory menu in > the > map is > MUCH slower than opening the inventory, opening landmarks, and working > from > there, but > it's also more convenient. I'm not saying that the fetch occurs immediately, or even for everyone. Just that, with average usage, you will generally end up fetching your entire inventory whenever you log in. It puts too many constraints on our feature set if we have to delicately step around having your inventory available. Richard From mrallen1 at yahoo.com Fri Jun 6 11:02:13 2008 From: mrallen1 at yahoo.com (Mark Allen) Date: Fri Jun 6 11:02:16 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: Message-ID: <711493.29841.qm@web34303.mail.mud.yahoo.com> --- On Fri, 6/6/08, Dale Mahalko wrote: [...] > the development of a "commercial grade" proxy cache for use by an ISP, > school, or business which must support many users all trying to access > the same super-high bandwidth SL system. +1 Love this idea. It's like squid for Second Life content... Would SLProxy be a starting point for construction? Mark Allen http://www.linkedin.com/in/markrallen From aimee at ama-zing.co.uk Fri Jun 6 11:09:26 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jun 6 11:09:30 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> On Jun 6, 2008, at 16:25, Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer > which will allow you to show and hide the nav bar as you want. When not in use there should be _nothing_ visible in the main content area. I don't want to sound defeatist, but that looks far more like unnecessary clutter than simply making the information that's _already_ in the menu bar active. Yes, we already have a cluttered UI, but adding more clutter doesn't seem like an answer to me, it's just side stepping the problem. Did it get as far as mock-ups of an active menu bar? Maybe overflow the navigation into a hideable second line of the menu area (similar to what's being proposed for the nav bar) if the window is too small; that could be the best of both worlds? The main world view is what SL is all about, and it needs to be protected. For any new fixed UI element to be allowed as a permanent intrusion into that, no matter how small, there has to an absolutely compelling reason, and I just don't see it when there's a perfectly good menu bar. I know complaining about one tiny little toggle might seem a bit over the top, but these things have a habit of setting precedents which then allow other things to creep in in the future by eroding the boundary. Living in dreamland for a minute, ideally I'd like to to see the UI made up of dockable (and closeable) toolbar sections, so the user can decide the arrangement that best fits their window size, workflow, interest priority etc. and lose the bits they don't need. Think Adobe Photoshop CS3 etc., with saveable workspaces. Though I know that's way outside the scope of what's being discussed here, and there's an awful lot of work that would have to take place to make it possible, I'd like to see that as a long term aim for the UI. Something to work towards, even in baby steps. To me the Nav project should be seized as an opportunity to start the ground work for that. Rather than just adding another disjointed mismatched UI element, create the generic framework in code using this as a prototype, for a more versatile well structured system, for other parts of the UI to migrate to in future. Aimee. From kfa at gmx.net Fri Jun 6 11:23:32 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 11:23:47 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> Message-ID: <484980A4.1020708@gmx.net> Aimee Walton wrote: > ... > Though I know that's way outside the scope of what's being discussed > here, and there's an awful lot of work that would have to take place to > make it possible, I'd like to see that as a long term aim for the UI. > Something to work towards, even in baby steps. To me the Nav project > should be seized as an opportunity to start the ground work for that. > Rather than just adding another disjointed mismatched UI element, create > the generic framework in code using this as a prototype, for a more > versatile well structured system, for other parts of the UI to migrate > to in future. > That may be just a matter of interpretation whether it's outside the scope or not... what if one sees 'navigation' as navigation of the user interface as a whole. A holistic approach, yes. That sounds better for a project with its own JIRA namespace, doesn't it? Did anyone take a closer look at Blender's UI beyond an initial "Hoooo!" and shying away? Fully ingenious, fully customizable, and fully OpenGL. Takes a while to learn, but so does SL. Felix From jacek.antonelli at gmail.com Fri Jun 6 11:35:20 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Fri Jun 6 11:35:23 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> Message-ID: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> On Fri, Jun 6, 2008 at 1:09 PM, Aimee Walton wrote: > When not in use there should be _nothing_ visible in the main content area. > I don't want to sound defeatist, but that looks far more like unnecessary > clutter than simply making the information that's _already_ in the menu bar > active. Yes, we already have a cluttered UI, but adding more clutter doesn't > seem like an answer to me, it's just side stepping the problem. I think having the small button visible by default is important from a usability standpoint. I'm thinking particularly of "discoverability" -- users see the button, click it to find out what it does, and thus discover that the functionality exists. Otherwise, the majority of users wouldn't even know about it, which dampens the usefulness of the project. That said, I think there definitely should be a toggle item in the View menu to turn it off or on, just like there is for the bottom button bar (Fly, Snapshot, etc.). It would only take about 10 minutes to add such a thing, and it would soothe the nay-sayers. ;-) > Living in dreamland for a minute, ideally I'd like to to see the UI made up > of dockable (and closeable) toolbar sections, so the user can decide the > arrangement that best fits their window size, workflow, interest priority > etc. and lose the bits they don't need. Think Adobe Photoshop CS3 etc., with > saveable workspaces. Happily, that's a long term UI goal. :-) http://wiki.secondlife.com/wiki/User_Interface_Improvements From lenglish5 at cox.net Fri Jun 6 11:53:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jun 6 11:53:22 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> Message-ID: <4849879D.5000602@cox.net> Argent Stonecutter wrote: > I don't think P2P is an option from a privacy perspective anyway. > _______________________________________________ Sure, not for most purposes, but there could be use-cases where P2P was useful, hence the long-standing proposal that the protocol support informing the viewer that P2P is available in a given sim/grid and *how* to establish contact with other participating viewers. This is obviously not a SL-specific thing, but a private OpenSim grid might be running all sorts of simulation software, or collaboration software, etc., where P2P makes sense. Lawson From jhurliman at jhurliman.org Fri Jun 6 12:00:43 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri Jun 6 12:00:50 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> Message-ID: I had to change: + os.path.join(build_dir,'SecondLife.sln') \ to: + 'SecondLife.sln' \ to get this working. Before I would get "Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln ..." so I hacked it to get "Running 'tools\\vstool\\VSTool.exe --solution SecondLife.sln ..." and everything worked after that. John On Fri, Jun 6, 2008 at 9:28 AM, Phoenix wrote: > The attached patch appears to solve the vstool problem, but I don't think > microsoft tools like to be run from cygwin. VC71 usually worked under cygwin > but: > * /cyg/path/to/Program Files/CMake 2.4/bin must be in your path > * vstool occasionally crashed -- deleting the generated directory and > trying again always worked. > * VC80 was unable to load the generated project file > * I did not try VC90. > > I'm sneaking this patch into trunk, but you can try it out now. > > > Index: develop.py > =================================================================== > --- develop.py (revision 89110) > +++ develop.py (working copy) > @@ -485,10 +485,11 @@ > PlatformSetup.run_cmake(self, args) > if self.unattended == 'FALSE': > for build_dir in self.build_dirs(): > - vstool_cmd = ('tools\\vstool\\VSTool.exe' > - ' --solution %s\\SecondLife.sln' > - ' --config RelWithDebInfo' > - ' --startup secondlife-bin' % build_dir) > + vstool_cmd = os.path.join('tools','vstool','VSTool.exe') \ > + + ' --solution ' \ > + + os.path.join(build_dir,'SecondLife.sln') \ > + + ' --config RelWithDebInfo' \ > + + ' --startup secondlife-bin' > print 'Running %r in %r' % (vstool_cmd, os.getcwd()) > self.run(vstool_cmd) > > @@ -619,7 +620,7 @@ > raise CommandError('clean takes no arguments') > setup.cleanup() > else: > - print >> sys.stderr, 'Error: unknown command', repr(arg) > + print >> sys.stderr, 'Error: unknown command', repr(cmd) > print >> sys.stderr, "(run 'develop.py --help' for help)" > sys.exit(1) > except CommandError, err: > > > > > On 2008-06-05, at 21:12, Bruce Tong wrote: > >> Yes, I was running that within a bash shell from cygwin. I'm not sure >> why, now that I think about it. Some part of the process had me >> install it. I like bash and I guess it must have been wishful thinking >> on my part, or something. >> >> If I try it from a windows command prompt, I get... >> >> C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 >> Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' >> -- Building with FMOD audio support >> -- Building with FMOD audio support >> -- Version of viewer is 1.20.6.0 >> -- Configuring done >> -- Generating done >> -- Build files have been written to: >> C:/ZZTong/SLDev/linden/indra/build-VC80 >> Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln >> --confi >> g RelWithDebInfo --startup secondlife-bin' in >> 'C:\\ZZTong\\SLDev\\linden\\indra' >> >> Opening solution: build-VC80\SecondLife.sln >> Looking for existing VisualStudio instance... >> Didn't find open solution, now opening new VisualStudio instance... >> Reading .sln file version... >> Opening VS version: VC80... >> Value cannot be null. >> Parameter name: type >> Quitting do error opening: >> C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife.sl >> n >> >> On Thu, Jun 5, 2008 at 8:50 PM, Soft wrote: >> >>> On Thu, Jun 5, 2008 at 7:47 PM, Bruce Tong wrote: >>> >>>> I attempted to build using cmake for the first time. I seem to have >>>> encountered something similar to what Michelle2 Zenovka mentioned in >>>> VWR-6794. I guess that's fitting since I was following her nice >>>> summary found at... >>>> >>>> http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake >>>> >>>> I was using the sources from... slviewer-src-maint-viewer-7-r88903 >>>> >>>> $ ./develop.py -G VC80 >>>> >>> >>> From the $ prompt, are you attempting this with cygwin? What happens >>>> >>> if you try it from a command shell without cygwin in your path? >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> >> >> -- >> Bruce Tong >> Software Engineer >> Office of Information Technology >> Ohio University >> _______________________________________________ >> 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/20080606/97273e0c/attachment.htm From dmahalko at gmail.com Fri Jun 6 12:04:18 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jun 6 12:04:20 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <711493.29841.qm@web34303.mail.mud.yahoo.com> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: It does not look like anyone has ever tried modifying the client to allow the local cache to just grow indefinitely. If unlimited growth of a user's local cache could be tracked, I generally expect that the cache grows in small spurts when a new area is visited, but then growth is either flat or slowly linear once the "hangouts" in the world are established. These growth spurts will be the largest for a new cache just beginning to grow...... but for an established user visiting a new area, the "spurt" might only be a tiny blip since the difference between the new place and all others will be small. While LL must store the entire world, the user only needs to store those very few areas that they visit frequently, plus occasional trips off into new and unusual areas. So even if unlimited cache growth is permitted for testing purposes, the local user's asset storage is only ever going to be a minuscule fraction of LL's asset storage. Also, generally I would expect the client performance to improve by disabling the size limiting and garbage collection. If the only task is inserting new objects into the cache without limit, there is no need to be doing histograms and so forth to try to find the "oldest" content to remove. But of course, I just don't know at what size this local leveling-off will occur, because no one has tried testing any of this yet. This all appears to be trivially easy to start testing, since it just comes down to a few file-delete commands here and there in the source, plus some size limiter tests. So comment out all the deletion and garbage collection procedures, and force the limiters to always permit caching, and we shall see just how big the local cache can grow. Alas I am not a programmer by trade, so I don't have Visual Studio installed, nor am I familiar with subversion. But it looks very easy to do this cache hacking and testing using the existing code, so I may just have to suffer the steep learning curve of compiling to try it myself. I have a brand-new 750 gig SATA drive sitting here, still in the antistatic bag, that has no particular purpose right now (it'll be a backup drive eventually). I suppose I could set it up as my unlimited SL test cache.. :-) - Scalar Tardis / Dale Mahalko From evolutie at gmail.com Fri Jun 6 12:26:46 2008 From: evolutie at gmail.com (evolutie) Date: Fri Jun 6 12:26:50 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4849879D.5000602@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> Message-ID: <5fb4b1fa0806061226j407e6b9bn2b265b99f56d8fab@mail.gmail.com> I would love to see the verse protocol supported somehow... Though I really don't know enough of it to see the implications.. but would be wonderful to work on a texture in gimp or a model in blender and see it updated in SL.. "Verse is a network protocol that lets multiple applications act together as one large application by sharing data over a network. If one application makes a change to shared data, the change is distributed instantly to all the other interested clients. The protocol and associated data format are both heavily optimized for sharing data suitable for 3D graphics. " http://verse.blender.org/ evo On Fri, Jun 6, 2008 at 8:53 PM, Lawson English wrote: > Argent Stonecutter wrote: >> >> I don't think P2P is an option from a privacy perspective anyway. >> _______________________________________________ > > Sure, not for most purposes, but there could be use-cases where P2P was > useful, hence the long-standing proposal that the protocol support informing > the viewer that P2P is available in a given sim/grid and *how* to establish > contact with other participating viewers. This is obviously not a > SL-specific thing, but a private OpenSim grid might be running all sorts of > simulation software, or collaboration software, etc., where P2P makes sense. > From soft at lindenlab.com Fri Jun 6 12:40:23 2008 From: soft at lindenlab.com (Soft) Date: Fri Jun 6 12:40:25 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: > It does not look like anyone has ever tried modifying the client to > allow the local cache to just grow indefinitely. > [...] > > This all appears to be trivially easy to start testing, since it just > comes down to a few file-delete commands here and there in the source, > plus some size limiter tests. So comment out all the deletion and > garbage collection procedures, and force the limiters to always permit > caching, and we shall see just how big the local cache can grow. You may be overthinking this. Simply raising the limit from 1 gig to a much larger number would be sufficient. I wouldn't be surprised if that number were in the xml for the network preferences panel, not the viewer source, even. From Celierra at gmail.com Fri Jun 6 13:05:27 2008 From: Celierra at gmail.com (Celierra Darling) Date: Fri Jun 6 13:05:32 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: > It does not look like anyone has ever tried modifying the client to > allow the local cache to just grow indefinitely. > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the release notes said that that was found to be counterproductive and it was reduced to 1 GB. I can't find that specific release note, but the 1.14 notes do say "unlimited texture cache size". ~Alex and Cel From kfa at gmx.net Fri Jun 6 13:22:59 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jun 6 13:23:08 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <48499CA3.203@gmx.net> Celierra Darling wrote: > On Fri, Jun 6, 2008 at 2:04 PM, Dale Mahalko wrote: >> It does not look like anyone has ever tried modifying the client to >> allow the local cache to just grow indefinitely. >> > > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the > release notes said that that was found to be counterproductive and it > was reduced to 1 GB. I can't find that specific release note, but the > 1.14 notes do say "unlimited texture cache size". > > ~Alex and Cel > Counterproductive... hm, we don't know what the poet wanted to tell us with that line. But before there's more speculation, here is where to strike it out (as Soft hinted): panel_preferences_network.xml line 32 - between ' References: <193533.8360.qm@web59104.mail.re1.yahoo.com> Message-ID: <4849ADD8.6010202@lindenlab.com> Hi everyone, I'm sorry I couldn't reply sooner to this thread. I am a member of the search team at LL. The landmarks project will not affect search (technically) at all. This is because landmarks are stored as assets (and not in the database) and because asset storage does not touch the Google Search Appliances (GSAs). The GSAs are physically separate from where assets live. It's possible that the proposed landmarks changes could, for example, affect residents' willingness to use Top Picks. Top Picks is, at present, the most important vote for a place and traffic is a strong second. If residents were to stop or change their usage behavior of Top Picks, for example, then the change in behavior would by extension change search results. This would be true even if the landmarks project weren't happening, of course - it's just that landmarks changes could inspire some residents to change behavior. Down the road, I think landmarks *could* serve as a potential new resource for search - but, to be clear, in the current project they are NOT designed to do this. Later on, though, let's say we have some sort of "favorites designation." We *could possibly* mine that data as a high-quality designation of what residents think is interesting and use it for search results. Again, this is NOT part of the current project plan. We do NOT think this project will lead to different or better search results. Cheers, Stephany Ann Otoole wrote: > My point is simple. > > This work can impact search and the impact on search needs to be > explained. > Or if it is going to negatively impact something then why use time > discussing things that will not be allowed to happen? > > More communication is needed. And how this effort can enhance search > would be a great thing. (I.e.; I suspect everything is converted to > html urls for google appliance indexing anyway so how can this new > navigation work help? will the history of teleports finally be counted > as a form of real traffic into and out of a sim? etc. etc.) > > Don't confuse emotionless straight direct talk with negativism. > > Thanks. > > ----- Original Message ---- > From: Drew Dwi > To: Ann Otoole > Cc: Sarah Hutchinson ; > sldev@lists.secondlife.com > Sent: Thursday, June 5, 2008 11:54:52 AM > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > Hi, > > Hate to poke my head in, but careful reading is required before harsh > feedback. > > Per Kippie's post (you don't get your own email? the name says Sarah fyi): > > "With regards to User Picks, we learned that Picks are used for a lot > more than just sharing of favorite places. It was decided that until > Second Life offer the more social features that Picks have evolved into, > that it should be left as is." > > I don't see how any of the changes listed below affect search. > > -Drew > > Ann Otoole wrote: > > I previously requested someone look into how this project can impact > > search and there were no replies so I will reiterate: > > > > Profile Picks are part of the new search relevancy. Messing with this > > breaks search. An external non LL contracted team cannot be allowed to > > work on things that will result in devastation of the economy. How > > this can even happen is interesting. Great work and all but who > > decided to allow you to potentially erase the SL economy? > > > > Landmarks were initially listed in the SL blog as being a search > > relevance factor. The entire discussion of removing landmarks should > > have never happened without a discussion of this factor first. > > > > My recommendation is for the LL search related team to pay more > > attention to protecting their turf and communicating with this > > community to ensure everyone understands how this work will or will > > not impact the new search. > > > > > > ----- Original Message ---- > > From: Sarah Hutchinson > > > To: sldev@lists.secondlife.com > > Sent: Thursday, June 5, 2008 11:37:46 AM > > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 > > > > Hello all! > > > > Thank you so much for your feedback and comments on the Landmarks & > > Navigation project. My name is Kippie Friedkin and I'm a member of the > > Vectorform team. The team has been watching the threads and taking > > into consideration all of your input. We're excited that there has > > been so much interest in this project! Working on an open source > > project is a great learning experience for us, so we've been careful > > to respond with accuracy. Now we'll work on responding with a little > > more speed. As we have begun to define the design and functionality, > > we're better positioned to understand and discuss the technical issues. > > > > I thought I'd begin this note with an update on the project - where > > we've been, where we are, and where we're going. > > > > *Where we've been > > *The project began with a massive research phase that encompassed > > Office Hours discussions, interviews with Residents (both new and > > veteran), scouring Second Life blogs, researching resident-created > > tools, reviewing other Viewers and a host of web apps. > > > > During this phase, it was our goal to learn how Residents navigate > > in-world and how they create, use, and manage Landmarks. We solicited > > feedback on their pain points, ideas, and general comments that > > touched on Inventory, Landmarks, navigation, and User Picks. > > > > At the end of this research phase, we presented our finding to Linden > > Lab as well as some initial mockups and wireframes that would satisfy > > some of the project goals (as stated on the WIKI) as: > > > > * > > > > *To create a history of locations visited*, presented in some > > visual fashion, which may include: > > > > o > > > > Back & forward buttons for teleporting through location > > history > > > > o > > > > Prominent on-screen affordance for accessing/adding Landmarks > > > > * > > > > *To improve the existing, or create a new, system for managing > > Landmarks*, which should support the following: > > > > o > > > > Sorting, re-ordering > > > > o > > > > Organizing into folders or similar > > > > o > > > > Renaming > > > > o > > > > Sharing > > > > o > > > > Tagging > > > > * > > > > *To create a new navigation panel* (ie. the visual container for > > the new UI components) > > > > o > > > > To provide the ability to hide/show this panel. > > > > A few other things were investigated and discussed at the project's > onset: > > > > 1. > > > > Removing Landmarks from Inventory, in favor of a new system for > > managing Landmarks. > > > > 2. > > > > Deprecating Picks or finding some way to make sharing Landmarks > > easier. > > > > Discussions with Residents quickly removed these two items from the > > scope of this project. > > > > Removing Landmarks from the Inventory is an extremely difficult thing > > from to do from an implementation perspective. It also means that one > > of our project requirements - that of backwards compatibility - was > > broken. So it was determined that Landmarks were best left a part of > > the Inventory. As noted, there are many ways a Landmark can end up in > > one's Inventory, and the pros of Landmarks being left where they are, > > very quickly outweighed any cons that currently exist. > > > > With regards to User Picks, we learned that Picks are used for a lot > > more than just sharing of favorite places. It was decided that until > > Second Life offer the more social features that Picks have evolved > > into, that it should be left as is. > > > > *Where we are today > > *The Vectorform team has spent the past few weeks working on > > wireframes and designs for the newly proposed features. > > > > Based on our research, Resident feedback, and meetings with Linden > > Lab, we are building the following features in the Viewer: > > > > 1. > > > > *Navigation Panel* > > The Navigation panel will include forward, back, home and > > history buttons, as well as an address/location text box and > > 'go' button. > > > > The designs are being revised and updated to fit more into the > > new Dazzle style with insight and feedback from Residents and > > Lindens. > > > > The Navigation Panel can be able to be shown or hidden using > > both a small toggle at the top-left of the Viewer as well a > > keyboard shortcut - "/". (We are still determining if this will > > work as a shortcut key, but an initial review indicated it was > > not being used by another UI element - so this is TBD). > > > > In between the back and forward buttons will be a small, history > > button which will allow a Resident to view the list of places > > he/she has visited during that session. The number of places > > stored in this history and whether it persists between sessions > > can be set in ones User Preferences. > > > > The name of the parcel and region will be shown in the location > > history. Mousing over an item in the list will reveal additional > > info (SLURL? How long ago you were there?) > > > > Clicking the back or forward button will automatically teleport > > the Resident back/foward in their location history. > > > > Clicking the home button will teleport the Resident back to > > his/her home location. > > > > Address Bar - The address bar will display a SLURL by default. > > Users can enter a SLURL, or Region name in their Inventory. If > > the Resident types in a Region name that is not in their > > Inventory, we will go a global search to find the location. If > > the location cannot be found, the Search floater will open. > > > > 2. > > > > *User Preferences > > *We are introducing a new tab to the User Preferences floater > > that will providing users the ability to: > > > > * > > > > Set the number of days to store location history > > > > * > > > > Set the number of days to store address bar history > > > > * > > > > Clear the history of either of the above two items > > > > * > > > > Export Landmarks in HTML, TXT, or XML formats > > > > 3. > > > > *Create/Edit Landmarks UI* > > Residents will now be able to add a custom name and stores notes > > when creating or editing a Landmark. There will also be the > > option to select or create a folder when creating/editing > > Landmarks. > > > > All Landmarks and their folders will be will be placed into the > > Landmarks folder in the Inventory floater. > > > > To clear up any confusion, the following circumstances will > > still apply: > > > > * > > > > Landmarks received from purchased objects will remain with > > the object/folder as they are created. > > > > * > > > > Landmarks received view Inventory transfer will be placed > > into a Received Landmarks folder by default, but also > > allow for the Resident to edit and select a folder in > > which to place the Landmark. > > > > * > > > > Landmarks received via automatic givers will also be > > placed into the Received Landmarks folder, by default. > > Still TBD in terms of scoping, but we'd also like to > > include functionality that allows the Resident to edit and > > select a folder in which to place the Landmark. > > > > * > > > > Landmarks embedded in Notecards will not see any change in > > functionality. The landmark will remain embedded in the > > Notecard and not accessible except through Notecard access. > > > > 4. > > > > *Landmarks Menu* > > A new 'Landmarks' menu will be added to the top menu of the > > Viewer. The options for this menu are as follows: > > > > * > > > > Create Landmark > > > > * > > > > Manage Landmarks > > > > * > > > > Set Home to Current Location > > > > * > > > > Teleport Home > > > > * > > > > Received Landmarks - A sub-folder in the Landmarks folder > > in Inventory where all received Landmarks are stored by > > default. > > > > * > > > > Recent Places - Displays a list of Landmarks a Resident > > has recented used. > > > > * > > > > Access to Landmarks located in the Inventory Floater - > > Residents will now have access to Landmarks stored in the > > Landmarks folder of their Inventory via this menu. Any > > sub-folders of the main Landmarks folder will appear in > > this Landmarks menu and be navigable via this menu. > > > > 5. > > > > *Manage Landmarks UI* > > This new UI element is meant to allow residents a filtered via > > of the Inventory, in which to organize and manage (edit/delete) > > Landmarks. It consists of a small floater which will almost look > > like a filter viewed of the Inventory Floater. The Manage > > Landmarks floater will allow Residents to filter Landmarks, > > create/edit/delete folders easily, and provide a place (without > > having to weed through the rest of the Inventory) to edit > Landmarks. > > > > If you've had a chance to look at the wireframe posted on > > NAV-28, there are two approaches to the Manage Landmarks UI. At > > present, we have been asked to proceed with the separated > > floaters approach (Solution 2). > > > > Also, an advanced feature proposed for the Manage Landmarks UI > > was a Data Sort View which would allow Residents to view, sort, > > and manage Landmarks from a column set approach (like iTunes > > > ). However, at this time, we have > > been asked to put that feature on hold since it's real benefit > > has not been clear for all project stakeholders. > > > > When editing a Landmarks, Residents will have the ability to > > specify a custom name, add their own notes to each Landmark. > > Residents will also have the ability to specify a picture they > > want to use for a particular Landmark. Our technical team is > > also reviewing the possibility of allowing a Resident the option > > of using/reverting back to the default image for this location > > (as specified by the Land Owner). It is as of yet undetermined > > if this feature will be in scope. > > > > The Edit Landmarks Floater will include small icons for 'Show on > > Map' and 'Copy SLURL' to provide additional functionality. > > > > Finally, we intend to display additional metadata about the > > Landmark from the Edit Landmark floater - date acquired, last > > teleport date, and last updated date. > > > > *Shared Landmarks & Tagging > > *One of our original ideas (and a common suggestion from Residents) > > has been to include tagging of Landmarks and other Inventory assets. > > We investigated a couple of ways to create a folksonomy use with > > Landmarks in Second Life during the first phase of our project. > > However, it became clear that tagging functionality would be useful > > for many other areas and could touch many other areas including > > search, the web, User Picks, and most Inventory items. Rather than > > build a small one-off tagging system just for Landmarks, it was > > decided that creating a true folksonomy that could be used throughout > > Second Life (For searching, sharing landmarks, creating more a social > > network, etc.) was a much bigger project than our timeline or project > > goals would allow for. So tagging functionality was deemed out of > > scope for this project. > > > > *Where we're going! Issues, Risks, Reviews, and Builds! > > * > > The design team is working closely with Linden Lab and soliciting > > Resident feedback on new designs revisions. We hope to have design > > approachs for the new Nav bar solidifed by the end of this week. > > > > In the meantime, our technical team have been working on laying the > > foundation for the new Navigation bar, as well as spending time > > researching the items which many of you have spoken about on this > > list. A few items for which we're actively researching: > > > > * > > > > Understanding more about SLURLs and their relation to the Agni > > grid and how they come into play with the beta grid(s). > > > > * > > > > How the introduction of a new top-left UI element will affect > > Resident-created HUDs. > > > > * > > > > How the introduction of forward/back button teleport > > functionality will affect grid stability. > > > > In addition to researching open issues, our tech team is also working > > on wrapping up a Viewer build (minus approved creative). We will be > > testing that and reviewing it with Linden Lab over the next week. > > > > I would encourage all of you to continue sharing your thoughts and > > feedback. As I stated at the beginning of this message, the Vectorform > > team will be much more actively engaged with this list moving forward. > > > > Best, > > Kippie Friedkin > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20080606/b1984e7a/attachment-0001.htm From sldev at bitparts.org Fri Jun 6 16:35:57 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Fri Jun 6 16:35:58 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: Message-ID: <4849C9DD.9090904@bitparts.org> I really regret missing this meeting - had planned on it, went early & got a LM, and then got too busy at RL work to attend. Further thoughts, after trapesing my way through the source - it /appears/ as though the cache code already supports reading TGA files from the cache - am I correct? Does the cache writing code support writing in TGA? If so, it's just a matter of telling the image fetching code to write out the decompressed version - although I get the feeling that this could be done much more gracefully with a larger rewrite. Alas, I lack the C++ skills for it. Damn LL for not coding in plain C (*snort). Right now, I've bumped the limit on my texture cache size (a la the xml hack posted on another thread), but we're still dealing with the decode delay. I think that's the thing that really needs to be addressed, before further discussion about discard algorithms etc. -Buckaroo From teravus at gmail.com Fri Jun 6 17:24:34 2008 From: teravus at gmail.com (Teravus Ovares) Date: Fri Jun 6 17:24:36 2008 Subject: [sldev] Cache speed experiment & results.. In-Reply-To: <617974.16404.qm@web59110.mail.re1.yahoo.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> Message-ID: <34cc66250806061724h4d275d2n5c20033ba0e6d619@mail.gmail.com> Does anyone remember AT&T Worldnet? No? (tried to go back to metered dialup connections back in the day) Best Regards Teravus On 6/3/08, Ann Otoole wrote: > > Time Warner is going to try forcing metered bandwith on the cable modem > community they serve. > So the ugly head of the end of unlimited bandwith use raises it's head once > again. > (Presumably because of those few horrid torrent/movie downloaders messing > everything up for the rest of the planet. Yes thats right, instead of > closing off the pipes used by the abusers they choose to make more money by > harming the community in general. Typical Time Warner choice as opposed to > upgrading their antiquated copper wire infrastructure eh? anyway i worry > that heavy SL users (such as content creators) may be about to lose any > further incentive for bothering with virtual worlds...) > > Has anyone measured actual bandwith utilization to the point people can > predict their usage per month before they get slapped with killer bills? > > The reason I mention this is because, although I am also a fan of reduced > compression overhead, there will no doubt be trade offs required. Perhaps > there is a way to make compression/decompression more efficient? > > > ----- Original Message ---- > From: Tateru Nino > To: Dante Tucker > Cc: Second Life Developer Mailing List > Sent: Tuesday, June 3, 2008 1:08:43 PM > Subject: Re: [sldev] Cache speed experiment & results... > > Compromise? A lighterweight compressed cache format? Admittedly, yes, > the textures would still be coming down as jpeg2000 - which means they > would have to be decoded and recompressed before they went in the cache > - which is wasteful. But it's wasteful once per texture transfer, not > once per texture fetched from the cache. > > Use a PNG or vanilla jpg compressor to save space on disk (and let the > user set the compression quality with a slider to let them decide how > much bang-for-the-buck they want out of their chosen megabytes of > storage), then you've got far less work to do decoding than the jpeg2000 > decompressor -- or so I presume. If I got all that fatally wrong, just > whack me with a rolled up man page. > > Dante Tucker wrote: > > I definatly second this as an option. Provided there is no technical > > reason this can't be done :) > > > > On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu > > wrote: > > > > > > > > Given the dirt-cheap price of HD space these days, why bother > > compressing the cache, given that the decode is so expensive > > time-wise? Enlarge the cache maximum size, and toss out the > > compression - at least give us an option to try it, and see. A > > simple checkbox or debug option "UseCompressedCache" or somesuch > > defaulted to yes - then those of us with plenty of space can try > > it out. People are screaming about texture load times - I can't > > imagine they wouldn't sacrifice some disk space for a large boost > > in performance. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > 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/20080606/495cc05d/attachment.htm From kerdezixe at gmail.com Fri Jun 6 18:05:38 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jun 6 18:05:41 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <48499CA3.203@gmx.net> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <48499CA3.203@gmx.net> Message-ID: <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> 2008/6/6 Felix Duesenburg : > > panel_preferences_network.xml line 32 > - between ' - there is 'max_val="1000"' > which is the maximum by the slider settable cache size in MB. > i found : Advanced->Debug Setting->CacheSize There is an option "CacheValidateCounter" too but i have no idea of the meaning so i won't touch it :) used in void LLTextureCache::purgeTextures(bool validate) Since ... a long time ago ... i cry for texture saved as TGA (see the wiki about texture cache) and the ability to store texture cache on a separated and optimized server using squid or similar. Overkill for "random user", awesome for company, cybercafe and technonerdogeeky. -- F4FQM Kerunix Flan Laurent Laborde From tateru.nino at gmail.com Fri Jun 6 20:06:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 6 20:07:25 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4849ADD8.6010202@lindenlab.com> References: <193533.8360.qm@web59104.mail.re1.yahoo.com> <4849ADD8.6010202@lindenlab.com> Message-ID: <4849FB3F.3070604@weblogsinc.com> Was it not said that the landmarks and navigation project would deprecate, then eliminate Top Picks? Stephany Filimon wrote: > Hi everyone, > > I'm sorry I couldn't reply sooner to this thread. > > I am a member of the search team at LL. The landmarks project will > not affect search (technically) at all. This is because landmarks are > stored as assets (and not in the database) and because asset storage > does not touch the Google Search Appliances (GSAs). The GSAs are > physically separate from where assets live. > > It's possible that the proposed landmarks changes could, for example, > affect residents' willingness to use Top Picks. Top Picks is, at > present, the most important vote for a place and traffic is a strong > second. If residents were to stop or change their usage behavior of > Top Picks, for example, then the change in behavior would by extension > change search results. This would be true even if the landmarks > project weren't happening, of course - it's just that landmarks > changes could inspire some residents to change behavior. > > Down the road, I think landmarks *could* serve as a potential new > resource for search - but, to be clear, in the current project they > are NOT designed to do this. Later on, though, let's say we have some > sort of "favorites designation." We *could possibly* mine that data > as a high-quality designation of what residents think is interesting > and use it for search results. > Again, this is NOT part of the current project plan. We do NOT think > this project will lead to different or better search results. > > Cheers, > > Stephany > > Ann Otoole wrote: >> My point is simple. >> >> This work can impact search and the impact on search needs to be >> explained. >> Or if it is going to negatively impact something then why use time >> discussing things that will not be allowed to happen? >> >> More communication is needed. And how this effort can enhance search >> would be a great thing. (I.e.; I suspect everything is converted to >> html urls for google appliance indexing anyway so how can this new >> navigation work help? will the history of teleports finally be >> counted as a form of real traffic into and out of a sim? etc. etc.) >> >> Don't confuse emotionless straight direct talk with negativism. >> >> Thanks. >> >> ----- Original Message ---- >> From: Drew Dwi >> To: Ann Otoole >> Cc: Sarah Hutchinson ; >> sldev@lists.secondlife.com >> Sent: Thursday, June 5, 2008 11:54:52 AM >> Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 >> >> Hi, >> >> Hate to poke my head in, but careful reading is required before harsh >> feedback. >> >> Per Kippie's post (you don't get your own email? the name says Sarah >> fyi): >> >> "With regards to User Picks, we learned that Picks are used for a lot >> more than just sharing of favorite places. It was decided that until >> Second Life offer the more social features that Picks have evolved into, >> that it should be left as is." >> >> I don't see how any of the changes listed below affect search. >> >> -Drew >> >> Ann Otoole wrote: >> > I previously requested someone look into how this project can impact >> > search and there were no replies so I will reiterate: >> > >> > Profile Picks are part of the new search relevancy. Messing with this >> > breaks search. An external non LL contracted team cannot be allowed to >> > work on things that will result in devastation of the economy. How >> > this can even happen is interesting. Great work and all but who >> > decided to allow you to potentially erase the SL economy? >> > >> > Landmarks were initially listed in the SL blog as being a search >> > relevance factor. The entire discussion of removing landmarks should >> > have never happened without a discussion of this factor first. >> > >> > My recommendation is for the LL search related team to pay more >> > attention to protecting their turf and communicating with this >> > community to ensure everyone understands how this work will or will >> > not impact the new search. >> > >> > >> > ----- Original Message ---- >> > From: Sarah Hutchinson > > >> > To: sldev@lists.secondlife.com >> > Sent: Thursday, June 5, 2008 11:37:46 AM >> > Subject: Re: [sldev] RE: Landmarks and Navigation Update 2008-05-29 >> > >> > Hello all! >> > >> > Thank you so much for your feedback and comments on the Landmarks & >> > Navigation project. My name is Kippie Friedkin and I'm a member of the >> > Vectorform team. The team has been watching the threads and taking >> > into consideration all of your input. We're excited that there has >> > been so much interest in this project! Working on an open source >> > project is a great learning experience for us, so we've been careful >> > to respond with accuracy. Now we'll work on responding with a little >> > more speed. As we have begun to define the design and functionality, >> > we're better positioned to understand and discuss the technical issues. >> > >> > I thought I'd begin this note with an update on the project - where >> > we've been, where we are, and where we're going. >> > >> > *Where we've been >> > *The project began with a massive research phase that encompassed >> > Office Hours discussions, interviews with Residents (both new and >> > veteran), scouring Second Life blogs, researching resident-created >> > tools, reviewing other Viewers and a host of web apps. >> > >> > During this phase, it was our goal to learn how Residents navigate >> > in-world and how they create, use, and manage Landmarks. We solicited >> > feedback on their pain points, ideas, and general comments that >> > touched on Inventory, Landmarks, navigation, and User Picks. >> > >> > At the end of this research phase, we presented our finding to Linden >> > Lab as well as some initial mockups and wireframes that would satisfy >> > some of the project goals (as stated on the WIKI) as: >> > >> > * >> > >> > *To create a history of locations visited*, presented in some >> > visual fashion, which may include: >> > >> > o >> > >> > Back & forward buttons for teleporting through location >> > history >> > >> > o >> > >> > Prominent on-screen affordance for accessing/adding >> Landmarks >> > >> > * >> > >> > *To improve the existing, or create a new, system for managing >> > Landmarks*, which should support the following: >> > >> > o >> > >> > Sorting, re-ordering >> > >> > o >> > >> > Organizing into folders or similar >> > >> > o >> > >> > Renaming >> > >> > o >> > >> > Sharing >> > >> > o >> > >> > Tagging >> > >> > * >> > >> > *To create a new navigation panel* (ie. the visual container for >> > the new UI components) >> > >> > o >> > >> > To provide the ability to hide/show this panel. >> > >> > A few other things were investigated and discussed at the project's >> onset: >> > >> > 1. >> > >> > Removing Landmarks from Inventory, in favor of a new system for >> > managing Landmarks. >> > >> > 2. >> > >> > Deprecating Picks or finding some way to make sharing Landmarks >> > easier. >> > >> > Discussions with Residents quickly removed these two items from the >> > scope of this project. >> > >> > Removing Landmarks from the Inventory is an extremely difficult thing >> > from to do from an implementation perspective. It also means that one >> > of our project requirements - that of backwards compatibility - was >> > broken. So it was determined that Landmarks were best left a part of >> > the Inventory. As noted, there are many ways a Landmark can end up in >> > one's Inventory, and the pros of Landmarks being left where they are, >> > very quickly outweighed any cons that currently exist. >> > >> > With regards to User Picks, we learned that Picks are used for a lot >> > more than just sharing of favorite places. It was decided that until >> > Second Life offer the more social features that Picks have evolved >> > into, that it should be left as is. >> > >> > *Where we are today >> > *The Vectorform team has spent the past few weeks working on >> > wireframes and designs for the newly proposed features. >> > >> > Based on our research, Resident feedback, and meetings with Linden >> > Lab, we are building the following features in the Viewer: >> > >> > 1. >> > >> > *Navigation Panel* >> > The Navigation panel will include forward, back, home and >> > history buttons, as well as an address/location text box and >> > 'go' button. >> > >> > The designs are being revised and updated to fit more into the >> > new Dazzle style with insight and feedback from Residents and >> > Lindens. >> > >> > The Navigation Panel can be able to be shown or hidden using >> > both a small toggle at the top-left of the Viewer as well a >> > keyboard shortcut - "/". (We are still determining if this will >> > work as a shortcut key, but an initial review indicated it was >> > not being used by another UI element - so this is TBD). >> > >> > In between the back and forward buttons will be a small, history >> > button which will allow a Resident to view the list of places >> > he/she has visited during that session. The number of places >> > stored in this history and whether it persists between sessions >> > can be set in ones User Preferences. >> > >> > The name of the parcel and region will be shown in the location >> > history. Mousing over an item in the list will reveal additional >> > info (SLURL? How long ago you were there?) >> > >> > Clicking the back or forward button will automatically teleport >> > the Resident back/foward in their location history. >> > >> > Clicking the home button will teleport the Resident back to >> > his/her home location. >> > >> > Address Bar - The address bar will display a SLURL by default. >> > Users can enter a SLURL, or Region name in their Inventory. If >> > the Resident types in a Region name that is not in their >> > Inventory, we will go a global search to find the location. If >> > the location cannot be found, the Search floater will open. >> > >> > 2. >> > >> > *User Preferences >> > *We are introducing a new tab to the User Preferences floater >> > that will providing users the ability to: >> > >> > * >> > >> > Set the number of days to store location history >> > >> > * >> > >> > Set the number of days to store address bar history >> > >> > * >> > >> > Clear the history of either of the above two items >> > >> > * >> > >> > Export Landmarks in HTML, TXT, or XML formats >> > >> > 3. >> > >> > *Create/Edit Landmarks UI* >> > Residents will now be able to add a custom name and stores notes >> > when creating or editing a Landmark. There will also be the >> > option to select or create a folder when creating/editing >> > Landmarks. >> > >> > All Landmarks and their folders will be will be placed into the >> > Landmarks folder in the Inventory floater. >> > >> > To clear up any confusion, the following circumstances will >> > still apply: >> > >> > * >> > >> > Landmarks received from purchased objects will remain with >> > the object/folder as they are created. >> > >> > * >> > >> > Landmarks received view Inventory transfer will be placed >> > into a Received Landmarks folder by default, but also >> > allow for the Resident to edit and select a folder in >> > which to place the Landmark. >> > >> > * >> > >> > Landmarks received via automatic givers will also be >> > placed into the Received Landmarks folder, by default. >> > Still TBD in terms of scoping, but we'd also like to >> > include functionality that allows the Resident to edit and >> > select a folder in which to place the Landmark. >> > >> > * >> > >> > Landmarks embedded in Notecards will not see any change in >> > functionality. The landmark will remain embedded in the >> > Notecard and not accessible except through Notecard access. >> > >> > 4. >> > >> > *Landmarks Menu* >> > A new 'Landmarks' menu will be added to the top menu of the >> > Viewer. The options for this menu are as follows: >> > >> > * >> > >> > Create Landmark >> > >> > * >> > >> > Manage Landmarks >> > >> > * >> > >> > Set Home to Current Location >> > >> > * >> > >> > Teleport Home >> > >> > * >> > >> > Received Landmarks - A sub-folder in the Landmarks folder >> > in Inventory where all received Landmarks are stored by >> > default. >> > >> > * >> > >> > Recent Places - Displays a list of Landmarks a Resident >> > has recented used. >> > >> > * >> > >> > Access to Landmarks located in the Inventory Floater - >> > Residents will now have access to Landmarks stored in the >> > Landmarks folder of their Inventory via this menu. Any >> > sub-folders of the main Landmarks folder will appear in >> > this Landmarks menu and be navigable via this menu. >> > >> > 5. >> > >> > *Manage Landmarks UI* >> > This new UI element is meant to allow residents a filtered via >> > of the Inventory, in which to organize and manage (edit/delete) >> > Landmarks. It consists of a small floater which will almost look >> > like a filter viewed of the Inventory Floater. The Manage >> > Landmarks floater will allow Residents to filter Landmarks, >> > create/edit/delete folders easily, and provide a place (without >> > having to weed through the rest of the Inventory) to edit >> Landmarks. >> > >> > If you've had a chance to look at the wireframe posted on >> > NAV-28, there are two approaches to the Manage Landmarks UI. At >> > present, we have been asked to proceed with the separated >> > floaters approach (Solution 2). >> > >> > Also, an advanced feature proposed for the Manage Landmarks UI >> > was a Data Sort View which would allow Residents to view, sort, >> > and manage Landmarks from a column set approach (like iTunes >> >> > ). However, at this time, we have >> > been asked to put that feature on hold since it's real benefit >> > has not been clear for all project stakeholders. >> > >> > When editing a Landmarks, Residents will have the ability to >> > specify a custom name, add their own notes to each Landmark. >> > Residents will also have the ability to specify a picture they >> > want to use for a particular Landmark. Our technical team is >> > also reviewing the possibility of allowing a Resident the option >> > of using/reverting back to the default image for this location >> > (as specified by the Land Owner). It is as of yet undetermined >> > if this feature will be in scope. >> > >> > The Edit Landmarks Floater will include small icons for 'Show on >> > Map' and 'Copy SLURL' to provide additional functionality. >> > >> > Finally, we intend to display additional metadata about the >> > Landmark from the Edit Landmark floater - date acquired, last >> > teleport date, and last updated date. >> > >> > *Shared Landmarks & Tagging >> > *One of our original ideas (and a common suggestion from Residents) >> > has been to include tagging of Landmarks and other Inventory assets. >> > We investigated a couple of ways to create a folksonomy use with >> > Landmarks in Second Life during the first phase of our project. >> > However, it became clear that tagging functionality would be useful >> > for many other areas and could touch many other areas including >> > search, the web, User Picks, and most Inventory items. Rather than >> > build a small one-off tagging system just for Landmarks, it was >> > decided that creating a true folksonomy that could be used throughout >> > Second Life (For searching, sharing landmarks, creating more a social >> > network, etc.) was a much bigger project than our timeline or project >> > goals would allow for. So tagging functionality was deemed out of >> > scope for this project. >> > >> > *Where we're going! Issues, Risks, Reviews, and Builds! >> > * >> > The design team is working closely with Linden Lab and soliciting >> > Resident feedback on new designs revisions. We hope to have design >> > approachs for the new Nav bar solidifed by the end of this week. >> > >> > In the meantime, our technical team have been working on laying the >> > foundation for the new Navigation bar, as well as spending time >> > researching the items which many of you have spoken about on this >> > list. A few items for which we're actively researching: >> > >> > * >> > >> > Understanding more about SLURLs and their relation to the Agni >> > grid and how they come into play with the beta grid(s). >> > >> > * >> > >> > How the introduction of a new top-left UI element will affect >> > Resident-created HUDs. >> > >> > * >> > >> > How the introduction of forward/back button teleport >> > functionality will affect grid stability. >> > >> > In addition to researching open issues, our tech team is also working >> > on wrapping up a Viewer build (minus approved creative). We will be >> > testing that and reviewing it with Linden Lab over the next week. >> > >> > I would encourage all of you to continue sharing your thoughts and >> > feedback. As I stated at the beginning of this message, the Vectorform >> > team will be much more actively engaged with this list moving forward. >> > >> > Best, >> > Kippie Friedkin >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > 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 > -- Tateru Nino http://www.massively.com/ From robin.cornelius at gmail.com Sat Jun 7 00:20:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jun 7 00:20:23 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <48499CA3.203@gmx.net> <8a1bfe660806061805p3154e210i1a4afe83be394313@mail.gmail.com> Message-ID: <484A36B5.6040803@gmail.com> Laurent Laborde wrote: > i found : > Advanced->Debug Setting->CacheSize > > There is an option "CacheValidateCounter" too but i have no idea of > the meaning so i won't touch it :) > used in void LLTextureCache::purgeTextures(bool validate) > > Since ... a long time ago ... i cry for texture saved as TGA (see the > wiki about texture cache) > and the ability to store texture cache on a separated and optimized > server using squid or similar. > > Overkill for "random user", awesome for company, cybercafe and technonerdogeeky. > With the current fetch system squid is not really direct useful, without miss-appropriating it some what, if we go http textures via caps then may be it would be useful but would need an slproxy instance as well. I was going to do a mysql cache, i've already done some mods so it should be a trivial next step for me. I greatly expect for a single client the performance to be worse but as the number of local clients increase and if the db server is thrown a lot of memory it may level out and could help reduce total data download. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080607/de86436b/signature.pgp From dmahalko at gmail.com Sat Jun 7 00:27:41 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 7 00:27:42 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: There is performance value in disabling (some) file deletion procedures in the client. For example, I know what a DSF temporary cache file is. There is currently no wiki article about DSF's. Should I create such an article? Should I explain in perfectly clear terms to anyone who cares to read it what can be done with a DSF? Or does LL prefer this remain a "don't ask, don't tell" sort of topic? Do you (LL staff in general) want security through obscurity, or are we going to be honest and open about file/data formats in the \cache folder? I see a very nice specific client performance improvement by no longer deleting DSFs, even if they are a space hog. The client kills them on exit, normally, which is rather annoying: http://svn.secondlife.com/trac/linden/browser/release/indra/newview/llappviewer.cpp 1184 // delete some of the files left around in the cache. 1185 removeCacheFiles("*.wav"); 1186 removeCacheFiles("*.tmp"); 1187 removeCacheFiles("*.lso"); 1188 removeCacheFiles("*.out"); 1189 removeCacheFiles("*.dsf"); 1190 removeCacheFiles("*.bodypart"); 1191 removeCacheFiles("*.clothing"); Fortunately I found a way to prevent DSF deletion, even without recompiling the source, thanks to special NTFS permissions: http://img528.imageshack.us/my.php?image=shotclientinthefootcu0.png Too bad these DSFs don't get their own folder alongside the \textures folder. - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 2:40 PM, Soft wrote: > You may be overthinking this. Simply raising the limit from 1 gig to a > much larger number would be sufficient. I wouldn't be surprised if > that number were in the xml for the network preferences panel, not the > viewer source, even. > From robin.cornelius at gmail.com Sat Jun 7 00:37:52 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jun 7 00:37:55 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <484A3AD0.3040409@gmail.com> Dale Mahalko wrote: > For example, I know what a DSF temporary cache file is. There is > currently no wiki article about DSF's. Should I create such an > article? Should I explain in perfectly clear terms to anyone who cares > to read it what can be done with a DSF? Or does LL prefer this remain > a "don't ask, don't tell" sort of topic? Do you (LL staff in general) > want security through obscurity, or are we going to be honest and open > about file/data formats in the \cache folder? This is a whole topic on its own. We really need some general Linden input on this. I'm not currently prepare to release any patches that open these formats up to casual picking of files nor do my releases have such patches even though its a trivial patch. > > I see a very nice specific client performance improvement by no longer > deleting DSFs, even if they are a space hog. The client kills them on > exit, normally, which is rather annoying: Yes, i am about to start testing this aspect too but someone reported that some things can get cached corrupt which is annoying and we would have no way to remove them at present. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080607/d44aba49/signature.pgp From sarah77 at gmail.com Sat Jun 7 04:55:46 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Sat Jun 7 04:55:49 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <4849FB3F.3070604@weblogsinc.com> References: <193533.8360.qm@web59104.mail.re1.yahoo.com> <4849ADD8.6010202@lindenlab.com> <4849FB3F.3070604@weblogsinc.com> Message-ID: <9010c35c0806070455j1adb57bbn4e22f5eb0e04256e@mail.gmail.com> On Fri, Jun 6, 2008 at 11:06 PM, Tateru Nino wrote: > Was it not said that the landmarks and navigation project would deprecate, > then eliminate Top Picks? > The idea to remove Profile Picks was introduced as an area for discussion at the beginning of the project. However, almost immediately after the first or second Office Hour during which we discussed how Residents use Profile Picks, we learned that Profile Picks are used not just to share a favorite place, but to mark friends, memorials, favorite quotes, tutorials, help, classifieds for stores, and more. It was decided that it does not make sense to remove Profile Picks at this time because Residents have changed their intended use into a social networking-like tool. Until more social features could be introduced in the Viewer, Residents made it clear they didn't want to lose Profile Picks. So removing/deprecating/eliminating Profile Picks was removed as a project goal. - Kippie Friedkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080607/d1fa9349/attachment.htm From aimee at ama-zing.co.uk Sat Jun 7 07:07:06 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Jun 7 07:07:11 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> Message-ID: <172A0D95-5CCC-4F28-BCC5-420085EE3A15@ama-zing.co.uk> On Jun 6, 2008, at 19:35, Jacek Antonelli wrote: > I think having the small button visible by default is important from a > usability standpoint. I'm thinking particularly of "discoverability" > -- users see the button, click it to find out what it does, and thus > discover that the functionality exists. Otherwise, the majority of > users wouldn't even know about it, which dampens the usefulness of the > project. Very true I guess, I think I was meaning more that it needs to be incorporated into the menu bar in some way rather than being out in the main window. Along the lines of the button in the top right of the title bar on Mac application windows that toggles all the toolbars. > Happily, that's a long term UI goal. :-) > > http://wiki.secondlife.com/wiki/User_Interface_Improvements Oh yes, I'd forgotten that, I remember looking at that screen shot and getting my hopes up before ^^ interestingly, having held up Adobe as a random icon of UI design yesterday, the first thing I read today is http://blogs.adobe.com/ jnack/2008/06/future_photoshop_ui.html ... defending the reasoning behind some of their upcoming changes in CS4 :) Aimee. From secret.argent at gmail.com Sat Jun 7 08:54:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 08:53:02 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> Message-ID: <5C84BA56-605D-4FF8-AD2A-33D72CD9B4E0@gmail.com> Apologies for the lateness of this response, we have been very busy at work this week and I have not been able to get in world, let alone catch up on my mail, for some time. On 2008-06-05, at 10:37, Sarah Hutchinson wrote: > A new 'Landmarks' menu will be added to the top menu of the Viewer. > The options for this menu are as follows: > Create Landmark > > Manage Landmarks > > Set Home to Current Location > > Teleport Home > > Received Landmarks > > Recent Places > > Access to Landmarks located in the Inventory Floater - Residents > will now have access to Landmarks stored in the Landmarks folder of > their Inventory via this menu. Any sub-folders of the main > Landmarks folder will appear in this Landmarks menu and be > navigable via this menu. > This all looks good. I would like to have an additional menu item here: "Landmarks Floater", instead of having a permanent tab on the screen. > Also, an advanced feature proposed for the Manage Landmarks UI was > a Data Sort View which would allow Residents to view, sort, and > manage Landmarks from a column set approach (like iTunes). However, > at this time, we have been asked to put that feature on hold since > it's real benefit has not been clear for all project stakeholders. > I like this view, I would just like to have it available for all asset types. Will the additional information in a landmark be part of the landmark and transferred with the landmark if it is given to a third party? Would it be possible to make the picture display on the landmark floater optional, to save screen space? > How the introduction of a new top-left UI element will affect > Resident-created HUDs. This is why I would rather the landmark floater be activated from the menu, like the other floaters, and be located anywhere, like the other floaters. From secret.argent at gmail.com Sat Jun 7 08:56:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 08:55:18 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <105c09f0806051537n27832cf6n90e2e08b5a8545d8@mail.gmail.com> <9010c35c0806051701i6a7a0579rfae9611ae324a629@mail.gmail.com> Message-ID: <0246F3B5-FE0E-4A74-A774-CEEF1E91ED74@gmail.com> On Thu, Jun 5, 2008 at 8:01 PM, Sarah Hutchinson wrote: > I apologize for the confusion - while the SLURL has been discussed > as the default, you will also be able to type a Region name. How about having it *display* the region name? Possibly because the region name is at the top of the screen anyway? What about making the region name in the title bar editable, instead? From secret.argent at gmail.com Sat Jun 7 09:06:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:05:03 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48493385.4050008@signpostmarv.name> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <484924E6.8080607@gmail.com> <39C20DFB-7943-4805-AFBF-E81CEE4FAD1F@gmail.com> <48493385.4050008@signpostmarv.name> Message-ID: <5D0D3D39-2C29-4B3C-8881-2A783007C830@gmail.com> On 2008-06-06, at 07:54, SignpostMarv Martin wrote: > Aside from llParcelMediaCommandList() with the > PARCEL_MEDIA_COMMAND_AGENT flag set. You can't get information _about me_ that way, because I don't have streaming media turned on. Nor do an increasing number of other people who are aware that streaming media can reveal that information. > Argent Stonecutter wrote: >> Email doesn't happen inside SL. There is currently no way for you >> to get that information about me *within second life* and use it >> to determine that any member of my family is using SL from the >> same IP address and figure out who they are in SL. None. Zippo. >> Zero. That SHOULD NOT change. From secret.argent at gmail.com Sat Jun 7 09:10:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:09:03 2008 Subject: [sldev] Cache speed experiment & results... In-Reply-To: <48493DF8.4040003@gmail.com> References: <617974.16404.qm@web59110.mail.re1.yahoo.com> <48462277.30708@gmail.com> <4848CF34.604@gmail.com> <48491DC9.3000908@gmail.com> <2CDB7179-27D6-48BE-812A-696E6843F5E7@gmail.com> <48493DF8.4040003@gmail.com> Message-ID: <144FC2CF-B027-4A1F-910B-0CD5436EC83E@gmail.com> On 2008-06-06, at 08:39, Jason Giglio wrote: > Don't get all nitpicky. The use of the term "bandwidth" to mean > "speed > limit" is already an abuse of an engineering term that had a specific, > mostly unrelated meaning. I would not have any compunctions about using "speed limit" as an analogy for bandwidth when talking to a non-technical person, any more than I would have compunctions about referring to the speed of light that way, even though it's not precisely correct either way. Using "bandwidth" to refer to a quantity of data, rather than a rate of data flow, is more than merely imprecise, it's inaccurate. From secret.argent at gmail.com Sat Jun 7 09:16:11 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:14:48 2008 Subject: [sldev] RE: Landmarks and Navigation Update 2008-05-29 In-Reply-To: <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> Message-ID: <18E99479-EA5B-43C9-B801-9F0A006B6C18@gmail.com> On 2008-06-06, at 10:25, Sarah Hutchinson wrote: > There is a tiny toggle that will be in the top left of the Viewer > which will allow you to show and hide the nav bar as you want. Can I drag the nav bar? If I drag the nav bar, will the toggle move? Or can I drag the toggle? If the answer in either case is "no", wouldn't that be a fairly obvious enhancement that would avoid many of the issues with HUD conflicts? Speaking of which, how about applying the same technology to the location of minimized floaters? Have a tab at the edge of the area where minimized floaters are. Click it, and the minimized floaters are hidden, and the tab gets a number showing how many minimized floaters it holds. Drag it, and you can change where the minimized floaters show up. From secret.argent at gmail.com Sat Jun 7 09:24:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:23:21 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> Message-ID: <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> On 2008-06-06, at 11:31, Richard Nelson wrote: > The inventory fetch is scheduled one folder at a time. Any time > you explicitly open a folder, the request for the contents of that > folder are put at the top of the queue, so you should see the > contents appear quickly. But as long as you see the number of > fetched items being reported at the top of the inventory window, > then the entire thing is being downloaded. That means that only pulling in the landmarks folder for the map would have the following advantages: 1. It would reduce clutter in the pulldown from the map. 2. It could be fetched quicker, showing a complete view sooner. I'm not asking you to "delicately step around having my inventory available". I'm suggesting an additional advantage of restricting the map pulldown to the Landmarks folder, beyond the primary goal of reducing clutter. :) From secret.argent at gmail.com Sat Jun 7 09:49:48 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:48:26 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <484980A4.1020708@gmx.net> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <105c09f0806011324t11c80221ya5ad8010f63f97d6@mail.gmail.com> <48432D25.7020300@lindenlab.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <484980A4.1020708@gmx.net> Message-ID: On 2008-06-06, at 13:23, Felix Duesenburg wrote: > Did anyone take a closer look at Blender's UI beyond an initial > "Hoooo!" and shying away? I spent a week and change working with it before shying away. From secret.argent at gmail.com Sat Jun 7 09:55:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:53:37 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-29 In-Reply-To: <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> References: <9788aeb10806010524x2bf2a385k2627a0f042de3fe2@mail.gmail.com> <32FFDBA2-DE30-4025-BEA9-1DDC7F09BE23@gmail.com> <7765f2c60806021240w67ae2e1bg573f8b315ccdf32f@mail.gmail.com> <9010c35c0806050837lbac24es6dd47e8bbcc610d3@mail.gmail.com> <9010c35c0806051647y4c38dd06hdb40e755e4a58d35@mail.gmail.com> <48494078.5090801@gmx.net> <4d211a610806060727w4e75197dsa44ea2652190b7d7@mail.gmail.com> <9010c35c0806060825h3d2a9a6eh352c7b365370877@mail.gmail.com> <3D21BD41-BB1D-4DC9-A275-7CF7F99A3F4C@ama-zing.co.uk> <105c09f0806061135yfb96542p16d5bfa309992a27@mail.gmail.com> Message-ID: On 2008-06-06, at 13:35, Jacek Antonelli wrote: > I think having the small button visible by default is important from a > usability standpoint. I'm thinking particularly of "discoverability" > -- users see the button, click it to find out what it does, and thus > discover that the functionality exists. Otherwise, the majority of > users wouldn't even know about it, which dampens the usefulness of the > project. This is the same logic that led to the search box in the menu bar, when there was already a search button on the screen. The usefulness of a project shouldn't be just based on "how many people use this particular feature" but also "how well does this fit into the rest of the system", because there's always going to be SOME feature set that you don't use, whoever you are, and if you can't get it out of your face it's annoying. They eventually made the search box optional. Nothing should sit between the chat bar and the menu bar that isn't optional. Anything between the chat bar and the menu bar should be movable. From secret.argent at gmail.com Sat Jun 7 09:58:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 09:57:19 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <4849879D.5000602@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> Message-ID: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> On 2008-06-06, at 13:53, Lawson English wrote: > Sure, not for most purposes, but there could be use-cases where P2P > was useful, hence the long-standing proposal that the protocol > support informing the viewer that P2P is available in a given sim/ > grid and *how* to establish contact with other participating viewers. One thing to keep in mind: there's not that many viewers in a sim anyway. We need an inter-viewer "data bus" for low volume data sharing between viewers in range, that's mediated through the sim. I think puppeteering info is small enough to count as "low volume". For higher volume data transfer, let the viewers share P2P contact information through this bus, subject to user request and approval. From secret.argent at gmail.com Sat Jun 7 10:02:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 10:01:24 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: On 2008-06-06, at 15:05, Celierra Darling wrote: > IIRC, at some point the old (GUI) maximum was a 10 GB cache, but the > release notes said that that was found to be counterproductive and it > was reduced to 1 GB. On the other hand there has been a switch to a new texture cache format since then. From kfa at gmx.net Sat Jun 7 10:19:05 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Jun 7 10:19:18 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> Message-ID: <484AC309.1010803@gmx.net> Argent Stonecutter wrote: > ... > > For higher volume data transfer, let the viewers share P2P contact > information through this bus, subject to user request and approval. > Sounds good from a technical viewpoint, but couldn't this open another can of worms? I could imagine that in SL, to a higher degree even than on the www, people are icky about privacy and wouldn't want to reveal their IP addresses to untrusted parties. If you use P2P networks then you (ought to) know what you're doing, but with SL you didn't bargain for that actually. Even with explicit approval - if declining means you can't use some functionality, then this is a double-edged sword. From sldev at bitparts.org Sat Jun 7 10:31:01 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 10:31:02 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: <484AC5D5.4060608@bitparts.org> I've done some more testing, and I don't like what I see. I set my texture cache to 50GB (using the xml hack posted earlier). I went home, moved around and fetched all of the textures around my home - got up to about 39MB. TPed to a shopping sim, wandered around letting lots of stuff fetch, and saw it increase to about 300MB. Good, good. TPed home, let everything rez... checked my cache... and it's back down to 50MB. Stuff is getting discarded from the disk cache even when it's nowhere near full. Is this intended? If so, why? -Jim From sldev at bitparts.org Sat Jun 7 10:34:20 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 10:34:20 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <484AC5D5.4060608@bitparts.org> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <484AC5D5.4060608@bitparts.org> Message-ID: <484AC69C.8040305@bitparts.org> Buckaroo Mu wrote: > I've done some more testing, and I don't like what I see. I set my > texture cache to 50GB (using the xml hack posted earlier). I went > home, moved around and fetched all of the textures around my home - > got up to about 39MB. TPed to a shopping sim, wandered around letting > lots of stuff fetch, and saw it increase to about 300MB. Good, good. > TPed home, let everything rez... checked my cache... and it's back > down to 50MB. Stuff is getting discarded from the disk cache even when > it's nowhere near full. Is this intended? If so, why? > I should clarify - I'm checking the "textures" folder of my cache folder, not the total "cache" folder. From secret.argent at gmail.com Sat Jun 7 10:41:10 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 10:40:12 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484AC309.1010803@gmx.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484AC309.1010803@gmx.net> Message-ID: <6647DE62-2129-406D-87A0-C381A2BA4844@gmail.com> On 2008-06-07, at 12:19, Felix Duesenburg wrote: > Argent Stonecutter wrote: >> For higher volume data transfer, let the viewers share P2P contact >> information through this bus, subject to user request and approval. > > Sounds good from a technical viewpoint, but couldn't this open > another can of worms? I could imagine that in SL, to a higher > degree even than on the www, people are icky about privacy and > wouldn't want to reveal their IP addresses to untrusted parties. That's why "subject to user request and approval". You would have to turn on "P2P support" the way you have to turn on "streaming media" now. You would have to click some icon to approve each new P2P request. Of course a plugin or custom viewer might decide not to cooperate with this, but plugins can already decide not to cooperate with any of the restrictions in SL, so I don't see that as being a new problem. > If you use P2P networks then you (ought to) know what you're doing, > but with SL you didn't bargain for that actually. Even with > explicit approval - if declining means you can't use some > functionality, then this is a double-edged sword. That's true, and that's already an issue with streaming media and external HTTP requests (which I routinely deny). I'm proposing this because it provides the required functionality for the more common case of synchronizing actions between viewers without opening up the P2P can of worms for the easy case. From kerdezixe at gmail.com Sat Jun 7 10:45:52 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Jun 7 10:45:53 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache Message-ID: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> I'm playing with 010 Editor, which is a powerfull Hex editor. (but not free, not opensource, and 100% Windows). i use it as a toy, but can be used to read/edit/write/parse/whatever (it have a script engine) binary file, disk, and process heap. (kinda the ultimate hacker's tool, but it's not my purpose here). I'll use it to make some... statitics about the cache. And maybe create an "offline cache cleaning tool". (MANY people clean their cache at startup, maybe they won't do that anymore if they have some kind of "Cache Defragmenter Super+ Gold Edition Bundle pack") Anyway... it's for my own pleasure to do some geeky stuff. Here is the template file : Nothing less, nothing more, it display all the texture.entries data, uncluding a shiny reformating to display the texture UUID : //-------------------------------------- //--- 010 Editor v3.0 Binary Template // // File: ReadTextureEntries.bt // Author: kerunix Flan // Revision: r1 // Purpose: Playing with texture.entries SL Texture Cache //-------------------------------------- typedef ubyte LLUUID[16]; typedef struct { float mVersion; // Version of ... something ? uint32 mEntries; // Number of entries. } EntriesHeader ; typedef struct { LLUUID mID; // 128 bits int32 mSize; // total size of image if known (NOT size cached), or -1 if unknown time_t mTime; // seconds since 1/1/1970 } EntriesBody ; string ReadEntriesBody( EntriesBody &body) { string s; SPrintf(s,"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",body.mID[0],body.mID[1],body.mID[2],body.mID[3],body.mID[4],body.mID[5],body.mID[6],body.mID[7],body.mID[8],body.mID[9],body.mID[10],body.mID[11],body.mID[12],body.mID[13],body.mID[14],body.mID[15]); return s; } string ReadEntriesHeader (EntriesHeader &head) { string s; SPrintf(s,"Version = %f, Entries = %u", head.mVersion, head.mEntries); return s; } EntriesHeader header; EntriesBody body[header.mEntries]; //------------------------ Note : It doesn't help at all to "steal" cached texture and i'll never release that kind of tool. Note2 : what's the purpose of separating headers from bodies ? Secure-obscurity ? Note3 : what is the mVersion ? Version of the file structure ? Note4 : BareRose HQ is a wonderfull place to stresstest the texture cache. Bigger-note : What about storing cache *per sim* ? Most peoples always go in the same dozen of sim 99% of time and a lot of texture are unique to the sim. When you enter in a sim, just load the *entire* cache related to this sim and discard later the unused texture. Could it save time ? (pre-decoding ?) That's all... have fun :) -- F4FQM Kerunix Flan Laurent Laborde From dmahalko at gmail.com Sat Jun 7 13:36:27 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jun 7 13:36:30 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: References: <711493.29841.qm@web34303.mail.mud.yahoo.com> Message-ID: It looks like the setting in XML is forced down to 1 gigabyte: http://svn.secondlife.com/trac/linden/browser/release/indra/newview/llappviewer.cpp 2624 LLSplashScreen::update("Initializing Texture Cache..."); 2625 2626 // Init the texture cache 2627 // Allocate 80% of the cache size for textures 2628 BOOL read_only = mSecondInstance ? true : false; 2629 const S32 MB = 1024*1024; 2630 S64 cache_size = (S64)(gSavedSettings.getU32("CacheSize")) * MB; 2631 const S64 MAX_CACHE_SIZE = 1024*MB; 2632 cache_size = llmin(cache_size, MAX_CACHE_SIZE); 2633 S64 texture_cache_size = ((cache_size * 8)/10); 2634 S64 extra = LLAppViewer::getTextureCache()->initCache(LL_PATH_CACHE, texture_cache_size, read_only); 2635 texture_cache_size -= extra; 2636 2637 LLSplashScreen::update("Initializing VFS..."); 2638 2639 // Init the VFS 2640 S64 vfs_size = cache_size - texture_cache_size; 2641 const S64 MAX_VFS_SIZE = 1024 * MB; // 1 GB 2642 vfs_size = llmin(vfs_size, MAX_VFS_SIZE); So, max cache size = 1024 * 1024 * 1024 = 1 gigabyte Texture cache size = 80% VFS cache size = 20% - Scalar Tardis / Dale Mahalko On Fri, Jun 6, 2008 at 2:40 PM, Soft wrote: > You may be overthinking this. Simply raising the limit from 1 gig to a > much larger number would be sufficient. I wouldn't be surprised if > that number were in the xml for the network preferences panel, not the > viewer source, even. > From richard at lindenlab.com Sat Jun 7 14:50:57 2008 From: richard at lindenlab.com (Richard Nelson) Date: Sat Jun 7 14:51:01 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> Message-ID: On Sat, 07 Jun 2008 09:24:44 -0700, Argent Stonecutter wrote: > > That means that only pulling in the landmarks folder for the map would > have the following advantages: > > 1. It would reduce clutter in the pulldown from the map. > 2. It could be fetched quicker, showing a complete view sooner. > > I'm not asking you to "delicately step around having my inventory > available". I'm suggesting an additional advantage of restricting the > map pulldown to the Landmarks folder, beyond the primary goal of > reducing clutter. :) Ok, my apologies. It seems we agree in principle then. I was speaking to the overall behavior of inventory fetching, not to the specific behavior of the landmarks dropdown in the map. I agree that the current implementation is not terribly usable, and your suggestion sounds reasonable to me, personally. Off the wall idea here...how about a hybrid inventory view/dropdown? What you see at first is a text entry box with an arrow next to it. But what you type in the text field doesn't just perform a match against the first characters of each entry, like a typical combo box, but instead performs a filter operation against all landmarks in your inventory. And instead of popping up a flat list of landmarks, we pop up a filtered inventory view? This would provide a better search mechanism using the existing inventory behavior, and allow you to scan by folder, etc. Under the hood, we could let you change the filter rules for that dropdown to only scan a certain folder, and so on. Just a thought. R. From secret.argent at gmail.com Sat Jun 7 15:14:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 15:13:32 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> Message-ID: <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> On 2008-06-07, at 16:50, Richard Nelson wrote: > Ok, my apologies. It seems we agree in principle then. I was > speaking to the overall behavior of inventory fetching, not to the > specific behavior of the landmarks dropdown in the map. I agree > that the current implementation is not terribly usable, and your > suggestion sounds reasonable to me, personally. I understand, it's easy to get off on a tangent in email, and I was kind of getting off on one. > Off the wall idea here...how about a hybrid inventory view/ > dropdown? What you see at first is a text entry box with an arrow > next to it. But what you type in the text field doesn't just > perform a match against the first characters of each entry, like a > typical combo box, but instead performs a filter operation against > all landmarks in your inventory. Hmmm, so when you pull down the inventory you get your Landmarks folder, but when you search it searched all your inventory? That would give you the best of both worlds, perhaps. I don't think I'd really care about where the landmarks were in my inventory in that case, so having it go into a folder view pulldown is probably unnecessary yak shaving. Leave the more complex view for the inventory folder or the landmarks floater. ... You know, though, this does give me an idea... What about making the landmarks navigation bar associated with the map somehow? Move the region search entry to the top, like a search box, and put forward/back buttons next to it, and let it accept slurls or Region Name (X,Y,Z) or secondlife: urls. Then you don't have to worry about forward/back teleporting and stuff, all it would do would be move the destination dot around on the map until you hit teleport. Like, at the top of the map you'd have a navigation bar like this: +----------------- | (<) (>) [ Region (X, Y, Z) _____________________ ] (Search) (Copy) (Teleport) [Landmarks _____ |v] [Friends ________ |v] Layout not precise, but you get the idea, yesno? From sldev at bitparts.org Sat Jun 7 15:24:32 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 15:24:32 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <484AC69C.8040305@bitparts.org> References: <711493.29841.qm@web34303.mail.mud.yahoo.com> <484AC5D5.4060608@bitparts.org> <484AC69C.8040305@bitparts.org> Message-ID: <484B0AA0.3010402@bitparts.org> >> I've done some more testing, and I don't like what I see. I set my >> texture cache to 50GB (using the xml hack posted earlier). I went >> home, moved around and fetched all of the textures around my home - >> got up to about 39MB. TPed to a shopping sim, wandered around letting >> lots of stuff fetch, and saw it increase to about 300MB. Good, good. >> TPed home, let everything rez... checked my cache... and it's back >> down to 50MB. Stuff is getting discarded from the disk cache even >> when it's nowhere near full. Is this intended? If so, why? >> > I should clarify - I'm checking the "textures" folder of my cache > folder, not the total "cache" folder. > Further testing. When I log in, my cache... goes away. All of those textures are wiped. Or at least most of them - I'm down to a few megabytes, when I stand at my login spot. The discard algorithm is DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded (apparently, as disclosed in another thread) limit. From evolutie at gmail.com Sat Jun 7 15:27:08 2008 From: evolutie at gmail.com (evolutie) Date: Sat Jun 7 15:27:10 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <48473027.9090101@lindenlab.com> References: <48473027.9090101@lindenlab.com> Message-ID: <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> I finally got around to test with multiple clients logged on to aditi puppeteering, and unfortunetely the simulation doesn't seem to work. Seems like instead of simulating the movement of the joints, the direction in which the avatar looks is simulated. To illustrate: http://www.evolutie.org/movies/puppet1.mov shows me moving my hand http://www.evolutie.org/movies/puppet2.mov shows what this looks like to another client evo . > It's based off 1.19.1 by the way, and we do actually have a region on aditi > that is running the simulator code (note, again, this code is relatively > incomplete and the simulator could well crash) named Puppeteering (You may > well need to log directly into it by they way). > From missannotoole at yahoo.com Sat Jun 7 15:53:58 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat Jun 7 15:54:01 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed Message-ID: <26449.37698.qm@web59103.mail.re1.yahoo.com> Sounds like a defect in need of a pjira entry because there is no shortage of people noticing constant texture reloading. This eats bytes transferred and SL needs to tighten these bolts up before Time Warner deploys that dumb so-called "bandwith cap" (bytes transferred cap". Good catch. Optimally speaking, I should not have to reload textures from the same sim I am in almost exclusively. (I don't get out much lol) On a side note and in respect to textures and size impact... Anyone ever look at the math for a "sub optimal" sim with 15,000 textures at max size? That would be the worst case scenario for cache size per sim. Even 15,000 512*512 textures is a whole lot. And thats not counting avatars. So yea cache needs to be much larger and very efficient. Otherwise everyone on time warner will be switching to DSL lol. Probably will be switching to DSL anyway as a matter of principal if the upper limit is too restrictive. ----- Original Message ---- From: Buckaroo Mu >Further testing. When I log in, my cache... goes away. All of those >textures are wiped. Or at least most of them - I'm down to a few >megabytes, when I stand at my login spot. The discard algorithm is >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded >(apparently, as disclosed in another thread) limit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080607/f8ca679b/attachment.htm From lenglish5 at cox.net Sat Jun 7 16:47:13 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 7 16:47:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> Message-ID: <484B1E01.1010800@cox.net> Argent Stonecutter wrote: > On 2008-06-06, at 13:53, Lawson English wrote: >> Sure, not for most purposes, but there could be use-cases where P2P >> was useful, hence the long-standing proposal that the protocol >> support informing the viewer that P2P is available in a given >> sim/grid and *how* to establish contact with other participating >> viewers. > > One thing to keep in mind: there's not that many viewers in a sim anyway. > > We need an inter-viewer "data bus" for low volume data sharing between > viewers in range, that's mediated through the sim. > > I think puppeteering info is small enough to count as "low volume". With reverse http, the normal data requests via the GetEvent CAP should be plenty fast for "low volume." The server will simply POST each new event as it gets it to the veiwer's faux-POST/GET server. > > For higher volume data transfer, let the viewers share P2P contact > information through this bus, subject to user request and approval. > > _ Doable, I'm sure, but as Felix points out, opting out of it will cripple functionality in a given region/sim/grid and opting in, would provide some loss of privacy. Lawson From secret.argent at gmail.com Sat Jun 7 17:13:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 7 17:12:14 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484B1E01.1010800@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> Message-ID: <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> On 2008-06-07, at 18:47, Lawson English wrote: > Doable, I'm sure, but as Felix points out, opting out of it will > cripple functionality in a given region/sim/grid Why? All that will mean is that whatever optional feature that uses P2P can't be used. That's hardly crippling. From richard at lindenlab.com Sat Jun 7 17:30:05 2008 From: richard at lindenlab.com (Richard Nelson) Date: Sat Jun 7 17:30:08 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-05-22 In-Reply-To: <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> References: <48360C0C.4070107@lindenlab.com> <84710F48-5504-4F89-90AB-52BB77421C0C @gmail.com> <483E5203.3020904@gmx.net> <483FE354.4010808@gmx.net> <04A6E965-7093-4 31F-B3E5-3DD9DC1FEF5C@gmail.com> <48400ABD.80102@gmx.net> <6A2013CE-4835-44EE-98E4-921F58F9F448@gmail.com> <16309a040806051954x39e31ad9r506be347a886478@mail.gmail.com> <2788C862-29D6-40F5-A653-7598C0177D0B@gmail.com> <18003C8B-5E3D-4E09-984F-14D424B1C871@gmail.com> Message-ID: On Sat, 07 Jun 2008 15:14:44 -0700, Argent Stonecutter wrote: > Hmmm, so when you pull down the inventory you get your Landmarks folder, > but when you search it searched all your inventory? That would give you > the best of both worlds, perhaps. I don't think I'd really care about > where the landmarks were in my inventory in that case, so having it go > into a folder view pulldown is probably unnecessary yak shaving. Sorry, let me clarify. I was thinking that *whatever* was decided (by tweaking the XUI or settings files) to be relevant for the dropdown, whether that is just your Landmarks folder or all landmarks in your inventory, the text you type in the entry field would filter/search just those contents. This is better than the current dropdown because you get substring searching instead of just prefix (which, IMO, is more usable), and you get to see your folders (based on your filter rules) if, like me, you can't be bothered to maintain a single Landmarks folder that has everything you may want to search for in the map window. Anyway, just an idea. Richard From sldev at bitparts.org Sat Jun 7 17:39:33 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sat Jun 7 17:39:34 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed In-Reply-To: <26449.37698.qm@web59103.mail.re1.yahoo.com> References: <26449.37698.qm@web59103.mail.re1.yahoo.com> Message-ID: <484B2A45.4050805@bitparts.org> Filed as VWR-7659 (https://jira.secondlife.com/browse/VWR-7659) Ann Otoole wrote: > Sounds like a defect in need of a pjira entry because > there is no shortage of people noticing constant texture reloading. > This eats bytes transferred and SL needs to tighten these bolts up > before Time Warner deploys that dumb so-called > "bandwith cap" (bytes transferred cap". > > Good catch. > > Optimally speaking, I should not have to reload textures from > the same sim I am in almost exclusively. (I don't get out much lol) > > On a side note and in respect to textures and size impact... > Anyone ever look at the math for a "sub optimal" sim > with 15,000 textures at max size? > That would be the worst case scenario for cache size per sim. > Even 15,000 512*512 textures is a whole lot. > And thats not counting avatars. > > So yea cache needs to be much larger and very efficient. > > Otherwise everyone on time warner will be switching to DSL lol. > Probably will be switching to DSL anyway as a matter of > principal if the upper limit is too restrictive. > > ----- Original Message ---- > From: Buckaroo Mu > >Further testing. When I log in, my cache... goes away. All of those > >textures are wiped. Or at least most of them - I'm down to a few > >megabytes, when I stand at my login spot. The discard algorithm is > >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded > >(apparently, as disclosed in another thread) limit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From darien_caldwell at comcast.net Sat Jun 7 23:26:22 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Sat Jun 7 23:26:22 2008 Subject: [sldev] Texture caching/bandwidth/performance how to proceed References: <26449.37698.qm@web59103.mail.re1.yahoo.com> <484B2A45.4050805@bitparts.org> Message-ID: Sorry, i tried this, and don't see the issue you're describing. All the textures I had cached at my last logoff were still cached after logging on (1.20 RC9). are you sure you haven't flipped some wierd setting or something? ----- Original Message ----- From: "Buckaroo Mu" To: "Second Life Developer Mailing List" Sent: Saturday, June 07, 2008 5:39 PM Subject: Re: [sldev] Texture caching/bandwidth/performance how to proceed > Filed as VWR-7659 (https://jira.secondlife.com/browse/VWR-7659) > > Ann Otoole wrote: >> Sounds like a defect in need of a pjira entry because >> there is no shortage of people noticing constant texture reloading. >> This eats bytes transferred and SL needs to tighten these bolts up >> before Time Warner deploys that dumb so-called >> "bandwith cap" (bytes transferred cap". >> >> Good catch. >> >> Optimally speaking, I should not have to reload textures from >> the same sim I am in almost exclusively. (I don't get out much lol) >> >> On a side note and in respect to textures and size impact... >> Anyone ever look at the math for a "sub optimal" sim >> with 15,000 textures at max size? >> That would be the worst case scenario for cache size per sim. >> Even 15,000 512*512 textures is a whole lot. >> And thats not counting avatars. >> >> So yea cache needs to be much larger and very efficient. >> >> Otherwise everyone on time warner will be switching to DSL lol. >> Probably will be switching to DSL anyway as a matter of >> principal if the upper limit is too restrictive. >> >> ----- Original Message ---- >> From: Buckaroo Mu >> >Further testing. When I log in, my cache... goes away. All of those >> >textures are wiped. Or at least most of them - I'm down to a few >> >megabytes, when I stand at my login spot. The discard algorithm is >> >DEFINITELY too aggressive. I'm not even getting NEAR the .8GB hardcoded >> >(apparently, as disclosed in another thread) limit. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Sat Jun 7 23:35:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jun 7 23:35:51 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> Message-ID: <484B7DC5.7000900@cox.net> Argent Stonecutter wrote: > On 2008-06-07, at 18:47, Lawson English wrote: >> Doable, I'm sure, but as Felix points out, opting out of it will >> cripple functionality in a given region/sim/grid > > Why? > > All that will mean is that whatever optional feature that uses P2P > can't be used. That's hardly crippling. > > > Well, if its important enough to provide for, its probably exceedingly important. OTOH, if you really wanted to participate, you'd make sure you had the plugin or whatever so you could. Lawson From secret.argent at gmail.com Sun Jun 8 07:11:36 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 07:10:16 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484B7DC5.7000900@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> Message-ID: <441F5696-2366-4FC2-BB68-DF9600F5C232@gmail.com> On 2008-06-08, at 01:35, Lawson English wrote: > Well, if its important enough to provide for, its probably > exceedingly important. Well, first, streaming audio and video is "provided for", but it's hardly important. I don't even have Quicktime installed on my Wintendo any more. Voice is provided for but it's got negative value as far as I'm concerned: the only times I've used voice have been times I've been more or less forced to by other players if I wanted to participate in something, and the experience was entirely unpleasant. I'm not suggesting it as something "provided for" at all. What I suggested as a sim-level data bus to *avoid* having to use it, and the suggestion that IF that proved insufficient for some third-party plugin or viewer THEN you could negotiate some kind of P2P arrangement over it for users that chose to use it. I'm simply saying that using P2P needs to be explicitly requested by the user and explicitly approved by the user when it's required, just like streaming video is. > OTOH, if you really wanted to participate, you'd make sure you had > the plugin or whatever so you could. From secret.argent at gmail.com Sun Jun 8 12:06:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 12:05:29 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484B7DC5.7000900@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> Message-ID: <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> http://jira.secondlife.com/browse/SVC-2509 http://jira.secondlife.com/browse/SVC-2508 From lenglish5 at cox.net Sun Jun 8 12:18:18 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Jun 8 12:18:21 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> Message-ID: <484C307A.7020004@cox.net> Argent Stonecutter wrote: > http://jira.secondlife.com/browse/SVC-2509 > http://jira.secondlife.com/browse/SVC-2508 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > One issue to keep in mind is that LL is committed currently to using http or some variation for virtually all of its communications needs between client and server. Because of the http/1.1 recommendation for having at most only 2 http connections between client and server, their first response will be to point to the preceding requirement and any suggestion about communications will have to fit into that 2-socket requirement in some way. Lawson From dahliatrimble at gmail.com Sun Jun 8 16:47:28 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun Jun 8 16:47:30 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: Seems to me that the existing channels between the viewer and the server could support this already without additional sockets by adding an additional packet type or instant message filter, at least for the object->viewer pathway. Perhaps a more robust XML-RPC implementation for objects could support the rest? On Sun, Jun 8, 2008 at 12:18 PM, Lawson English wrote: > Argent Stonecutter wrote: > >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> One issue to keep in mind is that LL is committed currently to using http > or some variation for virtually all of its communications needs between > client and server. Because of the http/1.1 recommendation for having at most > only 2 http connections between client and server, their first response will > be to point to the preceding requirement and any suggestion about > communications will have to fit into that 2-socket requirement in some way. > > Lawson > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080608/b724b40b/attachment.htm From secret.argent at gmail.com Sun Jun 8 18:59:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jun 8 18:58:16 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <03A9114E-C798-4625-AEDB-2D6EFB000731@gmail.com> On 2008-06-08, at 14:18, Lawson English wrote: > One issue to keep in mind is that LL is committed currently to > using http or some variation for virtually all of its > communications needs between client and server. I don't see what that has to so with it. This is not a new connection, it's a new message type. Whether messages between the client and the server are using UDP, TCP, HTTP, or SMTP is an implementation detail. From tateru.nino at gmail.com Sun Jun 8 19:03:21 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jun 8 19:04:07 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <484C8F69.6080505@gmail.com> Lawson English wrote: > Argent Stonecutter wrote: >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > One issue to keep in mind is that LL is committed currently to using > http or some variation for virtually all of its communications needs > between client and server. Because of the http/1.1 recommendation for > having at most only 2 http connections between client and server, > their first response will be to point to the preceding requirement and > any suggestion about communications will have to fit into that > 2-socket requirement in some way. > The two-socket recommendation is an RFC2616 advisory, intended to encourage a specific behavior pattern based on the size, quantity, request pattern and so forth of entities on the Web. It is not unreasonable for non-Web-based applications to have more (or fewer) simultaneous HTTP transports (persistent and non-), because they're never going to experience the conditions and circumstances that the two-socket recommendation was intended to address. From tateru.nino at gmail.com Sun Jun 8 19:07:06 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jun 8 19:07:52 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C307A.7020004@cox.net> References: <48473027.9090101@lindenlab.com> <55FE7119-9885-4512-927B-8D46EF8B59CB@gmail.com> <3736d47a0806050916g26994521g9a11c86acc4b7d00@mail.gmail.com> <484811B8.1070308@gmail.com> <4848206A.4030804@cox.net> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> Message-ID: <484C904A.1070205@gmail.com> I should have added - there may be *other* reasons that a two-socket maximum may be sensible, but the recommendation in the specification isn't it :) Lawson English wrote: > Argent Stonecutter wrote: >> http://jira.secondlife.com/browse/SVC-2509 >> http://jira.secondlife.com/browse/SVC-2508 >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > One issue to keep in mind is that LL is committed currently to using > http or some variation for virtually all of its communications needs > between client and server. Because of the http/1.1 recommendation for > having at most only 2 http connections between client and server, > their first response will be to point to the preceding requirement and > any suggestion about communications will have to fit into that > 2-socket requirement in some way. > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dmahalko at gmail.com Mon Jun 9 00:22:15 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jun 9 00:22:17 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: >From the mention of pitchforks and politics in Robin's other thread, I am getting the impression that some people don't really want to improve the local caching performance as much as possible. The best possible caching performance would require storing raw data in ways that would make it all so much easier to "rip" and reuse copyrighted assets without the creator's permission. This whole secondary decoded image cache discussion... will LL's senior developers allow this project to exist in the release viewer? JPEG2000 seems to have two purposes. Not only does it allow high compression, but it isn't a widely accepted image standard, so the texture cache as designed now is somewhat protected and obfuscated by locally caching bitmaps that way. Decompressing JPEG2000 straight to video memory helps to hide the raw data from casual ripping. This is easily defeated with that OpenGL wrapper, but the wrapper also generates a ton of garbage that must be sifted to find the desired texture to steal, so it isn't easy to use for ripping by any means. A raw decompressed texture cache would be ridiculously easy to rip. Can you imagine casually browsing to the SL cache folders with Windows and having it auto-create thumbnails of every single cached image? Or having the texture cache folders imported into Picasa's catalog? There are people selling high-value avatar skins and sculpties who would probably have an apoplectic fit if they saw this. The VFS is another obfuscatory layer. As designed it is a RAM-disk, read into memory only when the client starts up, and it isn't written to the disk at all while the client is running. It consumes precious limited system memory at all times, but it also helps to hide downloaded assets in a storage system that cannot be easily snooped with file-access monitoring tools. As a RAM-disk, the VFS absolutely does not scale, and trying to improve network caching performance by making the VFS several gigabytes in size just invites virtual-memory page swapping and poor overall system performance. I think we'd be much better off to use the new folder-based texture caching system to store all asset types, and completely cease the use of the VFS and its totally-held-in-RAM design. BUT this would remove all obfuscatory layers of the VFS and would make it easier to directly examine and potentially rip downloaded assets of any type. Non-texture assets are probably all in their raw file data formats, and they would be laid bare and helpless in a folder-based cache, so LL may not be willing to allow this. A move to a local MySQL database may be needed not only to merely make the asset cache scalable and more efficient, but more importantly, to preserve the local asset storage obfuscation layers. The developers on this list appear to understand that ultimately nothing sent to the client can be protected from copying and unauthorized reuse, and this is just the facts of life. It sounds to me like some people at LL don't want to force the rest of the userbase to accept this reality. We may have to continue to live with lousy local caching performance just to help assuage the fears of the angry and irrational pitchfork-waving masses that are still running "anti-copybot" scripts. - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Mon Jun 9 01:55:25 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 01:55:28 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <484CEFFD.4060408@gmail.com> Dale Mahalko wrote: > The best possible caching performance would require storing raw data > in ways that would make it all so much easier to "rip" and reuse > copyrighted assets without the creator's permission. It is not difficult now. > This whole secondary decoded image cache discussion... will LL's > senior developers allow this project to exist in the release viewer? Linden Lab is not accepting *any* outside contributions currently. That said, if it really does perform better, I don't foresee them not taking it because of some concern about the perception of easier ripping. > JPEG2000 seems to have two purposes. Not only does it allow high > compression, but it isn't a widely accepted image standard, so the > texture cache as designed now is somewhat protected and obfuscated by > locally caching bitmaps that way. JPEG2000 has wide support in many applications. It is in no way security through obscurity. > Decompressing JPEG2000 straight to video memory helps to hide the raw > data from casual ripping. This is easily defeated with that OpenGL That is not the reason it is done that way. > A raw decompressed texture cache would be ridiculously easy to rip. The current cache is just as easy. > Can you imagine casually browsing to the SL cache folders with Windows > and having it auto-create thumbnails of every single cached image? Or Who cares? A small utility anyone can write in a few hours can do this today. > having the texture cache folders imported into Picasa's catalog? There > are people selling high-value avatar skins and sculpties who would > probably have an apoplectic fit if they saw this. I doubt it. People that make a living selling these sorts of items are well aware by now that they will always be easily copied. > The VFS is another obfuscatory layer. As designed it is a RAM-disk, > read into memory only when the client starts up, and it isn't written > to the disk at all while the client is running. It consumes precious This was never the intention of the VFS. The VFS was created due to a perception at Linden Lab that filesystems were not good enough to store cache files. It was kind of strange logic, but I guess at a time when FAT32 was still common, it might have made sense. > I think we'd be much better off to use the new folder-based texture > caching system to store all asset types, and completely cease the use > of the VFS and its totally-held-in-RAM design. It is already mostly this way. > A move to a local MySQL database may be needed not only to merely make > the asset cache scalable and more efficient, but more importantly, to > preserve the local asset storage obfuscation layers. This is probably the stupidest thing I've ever seen you type. :) Such a solution is very much not scalable. Databases store structured relational data, not files. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/5182c2bd/smime.bin From danteferret at gmail.com Mon Jun 9 03:23:23 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 03:23:26 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> Lets all just stop pretending anyone who wants to steal textures can't with the current system. Anyone who wants them can already get them. The only thing storing data raw would do is make them more accesable to people who don't want them and have no knoledge of how to get them currently. And if they don't want them then whats the harm? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/befade52/attachment.htm From tom at streamsense.net Mon Jun 9 03:34:10 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Jun 9 03:35:08 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D070A.1050705@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> Message-ID: <484D0722.3020701@streamsense.net> Dante Tucker wrote: > Lets all just stop pretending anyone who wants to steal textures can't > with the current system. Anyone who wants them can already get them. > The only thing storing data raw would do is make them more accesable > to people who don't want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? Agreed. I tire of people moaning about IP security. Your stuff is already stolen, deal with it. ~Tom From robin.cornelius at gmail.com Mon Jun 9 03:49:59 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 03:50:03 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D0722.3020701@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: On Mon, Jun 9, 2008 at 11:34 AM, Thomas Grimshaw wrote: > Dante Tucker wrote: >> >> Lets all just stop pretending anyone who wants to steal textures can't >> with the current system. Anyone who wants them can already get them. The >> only thing storing data raw would do is make them more accesable to people >> who don't want them and have no knoledge of how to get them currently. And >> if they don't want them then whats the harm? > > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > It wasn't ip security i started this about but the general SL populations "perception". We know here the texture cache might just as well not mess about and save in a direct format. We know its trivial to rip a texture now with a 101 methods but ignorance like :- http://jira.secondlife.com/browse/VWR-4614 http://jira.secondlife.com/browse/VWR-6798 http://jira.secondlife.com/browse/VWR-4503 just to pick a few, not the example i was looking for, there is/was one somewhere with a pile of votes saying remove the texture console. And this noise is heard so often and often gets associated with anti-opensource. There are no real usable technical solutions to content theft, nothing technical really works anywhere. As far as i see the only solution is the social one, where people have the respect not to just rip stuff off and thats a whole bigger issue than just SL. May be i just should not care. The libsl guys do not, and they got blamed for copybot. Closed source or open source, copying is inevitable, i just don't want open source to get the blame. Robin From secret.argent at gmail.com Mon Jun 9 04:40:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 04:39:26 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> On 2008-06-09, at 02:22, Dale Mahalko wrote: > A move to a local MySQL database God no. sqlite, please. Without all the MySQL "I'm pretending to be a real database engine" overhead. But preserving the local obfuscation would still be easy, simply by storing the raw bitmaps rather than any encoded form, and storing caching metadata in binary at the beginning of the file instead of in filesystem datestamps and extensions. Plus there's no reason to use the raw UUID. XORING it with "Please don't steal Mac OS X"... I mean "Please don't steal this asset"... would do. From tateru.nino at gmail.com Mon Jun 9 05:03:01 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 05:03:49 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: Message-ID: <484D1BF5.4060807@weblogsinc.com> Dale Mahalko wrote: > A raw decompressed texture cache would be ridiculously easy to rip. > Can you imagine casually browsing to the SL cache folders with Windows > and having it auto-create thumbnails of every single cached image? Or > having the texture cache folders imported into Picasa's catalog? > Umm. Actually, this can already be done. -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Mon Jun 9 05:04:45 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 05:05:41 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> Message-ID: <484D1C5D.40805@gmail.com> Actually, the raw, decoded textures would be *slightly* more complicated to rip than the current JPG2K textures are. You'd have to at least convert the image formats first to something that other tools could understand. Dante Tucker wrote: > Lets all just stop pretending anyone who wants to steal textures can't > with the current system. Anyone who wants them can already get them. > The only thing storing data raw would do is make them more accesable > to people who don't want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From teravus at gmail.com Mon Jun 9 05:21:49 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 05:21:51 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C904A.1070205@gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> Message-ID: <34cc66250806090521q3c1cf2fsf9086a11ca47829b@mail.gmail.com> Unfortunately, Operating systems like Microsoft windows has the '2' limitation buried in the registry, and some ubiquitous libraries honor that limitation (can you say wininet?). In fact, for server applications using wininet, it's recommended by Microsoft to dig into the registry and change that value. Best Regards Teravus On 6/8/08, Tateru Nino wrote: > > I should have added - there may be *other* reasons that a two-socket > maximum may be sensible, but the recommendation in the specification isn't > it :) > > Lawson English wrote: > >> Argent Stonecutter wrote: >> >>> http://jira.secondlife.com/browse/SVC-2509 >>> http://jira.secondlife.com/browse/SVC-2508 >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> One issue to keep in mind is that LL is committed currently to using http >> or some variation for virtually all of its communications needs between >> client and server. Because of the http/1.1 recommendation for having at most >> only 2 http connections between client and server, their first response will >> be to point to the preceding requirement and any suggestion about >> communications will have to fit into that 2-socket requirement in some way. >> >> Lawson >> _______________________________________________ >> 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/20080609/22712868/attachment.htm From zak.escher at gmail.com Mon Jun 9 05:32:02 2008 From: zak.escher at gmail.com (Zak Escher) Date: Mon Jun 9 05:32:09 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> Message-ID: <484D22C2.1090403@gmail.com> I keep getting the following when trying to run develop.py. This is from within Windows Vista Ultimate 64-Bit. (Note: I have replaced my user id with ) c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BO OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- broken CMake Error at C:/Program Files (x86)/CMake 2.6/share/cmake-2.6/Modules/CMakeTes tCCompiler.cmake:32 (MESSAGE): The C compiler "cl" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/ CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~2\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual Studio Version 8.0.50727.867. Copyright (C) Microsoft Corp 1984-2005. All rights reserved. 1>------ Build started: Project: cmTryCompileExec, Configuration: Debug Win32 ------ 1>Compiling... 1>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 1>Copyright (C) Microsoft Corporation. All rights reserved. 1>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTC1 /MDd /Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/CMakeTmp/ Debug/cmTryCompileExec.pdb" /W3 /c /Zi /TC /Zm1000 1> ".\testCCompiler.c" 1>testCCompiler.c 1>Compiling manifest to resources... 1>Linking... 1>link: extra operand `/ERRORREPORT:QUEUE' 1>Try `link --help' for more information. 1>Project : error PRJ0002 : Error result 1 returned from 'C:\cygwin\bin\link.exe'. 1>Build log was saved at "file://c:\Users\\sl_1_19_1_14\linden\indra\build-VC80\CMakeFiles\CMake Tmp\cmTryCompileExec.dir\Debug\BuildLog.htm" 1>cmTryCompileExec - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) -- Configuring done Cleaning 'build-VC80' Traceback (most recent call last): File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 654, in ? main(sys.argv[1:]) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 627, in mai n setup.run_cmake() File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 509, in run _cmake PlatformSetup.run_cmake(self, args) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 155, in run _cmake self.run(cmd, 'cmake') File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 504, in run raise CommandError('the command %r exited with %s' % __main__.CommandError: the command 'cmake' exited with 1 From teravus at gmail.com Mon Jun 9 05:35:29 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 05:35:33 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484C904A.1070205@gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> Message-ID: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> I also note, that according to Microsoft's kb article: "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. The four-connection limit for HTTP 1.0 is a self-imposed restriction that coincides with the standard that is used by a number of popular Web browsers." You can read the article here: http://support.microsoft.com/kb/183110 You can read the RFC here: http://www.faqs.org/rfcs/rfc2616.html Best Regards Teravus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/084c762c/attachment.htm From robin.cornelius at gmail.com Mon Jun 9 05:40:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 05:40:25 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D22C2.1090403@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: On Mon, Jun 9, 2008 at 1:32 PM, Zak Escher wrote: > I keep getting the following when trying to run develop.py. This is from > within Windows Vista Ultimate 64-Bit. > > (Note: I have replaced my user id with ) > > c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 > Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE > -DUNATTENDED:BO > OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in > 'build-VC80' > -- Check for working C compiler: cl > -- Check for working C compiler: cl -- broken > CMake Error at C:/Program Files (x86)/CMake > 2.6/share/cmake-2.6/Modules/CMakeTes > tCCompiler.cmake:32 (MESSAGE): > The C compiler "cl" is not able to compile a simple test program. try running from the console the vcvars.bat (or vsvars.bat) that is found in c:\program files\visual studio 2005\VC\bin\ or a path very like that and try again. Looks like your visual studio is not correctly setup for out of IDE compiling. Robin From Celierra at gmail.com Mon Jun 9 08:50:38 2008 From: Celierra at gmail.com (Celierra Darling) Date: Mon Jun 9 08:50:40 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> Message-ID: On Mon, Jun 9, 2008 at 8:35 AM, Teravus Ovares wrote: > I also note, that according to Microsoft's kb article: > > "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. The > four-connection limit for HTTP 1.0 is a self-imposed restriction that > coincides with the standard that is used by a number of popular Web > browsers." > > You can read the article here: > http://support.microsoft.com/kb/183110 > > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > The relevant text in the RFC seems to be in 8.1.4, "Practical Considerations". The relevant paragraph quoted: " Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion. " They are all "SHOULD" guidelines, not mandates as the Microsoft quote claims. There are several browsers which break the recommendation already, as the Firefox people seem to have noticed. Microsoft (apparently) is also going to break the 2-connection guideline starting with IE8. According to http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/5eebb8c65c34c3c6/323b25cfd9211fa0?fwc=1 , here are the numbers for some major browsers: Firefox 2: 2 Firefox 3: 2 (now 6) Opera 9.26: 4 Opera 9.5 beta: 4 Safari 3.0.4 Mac/Windows: 4 IE 7: 2 IE 8: 6 See also https://bugzilla.mozilla.org/show_bug.cgi?id=423377 , where this discussion appears to have already happened once before. ~Cel From tateru.nino at gmail.com Mon Jun 9 09:03:32 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 09:04:22 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D22C2.1090403@gmail.com> References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: <484D5454.6040207@weblogsinc.com> Cmake2.6 is not supported at present, is it? I thought the build only supported (I think it was 2.4.8) Zak Escher wrote: > I keep getting the following when trying to run develop.py. This is > from within Windows Vista Ultimate 64-Bit. > > (Note: I have replaced my user id with ) > > c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 > Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE > -DUNATTENDED:BO > OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in > 'build-VC80' > -- Check for working C compiler: cl > -- Check for working C compiler: cl -- broken > CMake Error at C:/Program Files (x86)/CMake > 2.6/share/cmake-2.6/Modules/CMakeTes > tCCompiler.cmake:32 (MESSAGE): > The C compiler "cl" is not able to compile a simple test program. > > It fails with the following output: > > Change Dir: > C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/ > CMakeTmp > > > > Run Build Command:C:\PROGRA~2\MICROS~2\Common7\IDE\devenv.com > CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec > > > > Microsoft (R) Visual Studio Version 8.0.50727.867. > > Copyright (C) Microsoft Corp 1984-2005. All rights reserved. > > 1>------ Build started: Project: cmTryCompileExec, Configuration: Debug > Win32 ------ > > 1>Compiling... > > 1>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version > 14.00.50727.762 > for 80x86 > > 1>Copyright (C) Microsoft Corporation. All rights reserved. > > 1>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D > "CMAKE_INTDIR=\"Debug\"" > /D "_MBCS" /FD /RTC1 /MDd /Fo"cmTryCompileExec.dir\Debug\\" > > /Fd"C:/Users//sl_1_19_1_14/linden/indra/build-VC80/CMakeFiles/CMakeTmp/ > > Debug/cmTryCompileExec.pdb" > /W3 /c /Zi /TC /Zm1000 > > 1> ".\testCCompiler.c" > > 1>testCCompiler.c > > 1>Compiling manifest to resources... > > 1>Linking... > > 1>link: extra operand `/ERRORREPORT:QUEUE' > > 1>Try `link --help' for more information. > > 1>Project : error PRJ0002 : Error result 1 returned from > 'C:\cygwin\bin\link.exe'. > > 1>Build log was saved at > > "file://c:\Users\\sl_1_19_1_14\linden\indra\build-VC80\CMakeFiles\CMake > > Tmp\cmTryCompileExec.dir\Debug\BuildLog.htm" > > > 1>cmTryCompileExec - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped > ========== > > > > > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:3 (project) > > > -- Configuring done > Cleaning 'build-VC80' > Traceback (most recent call last): > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 654, in ? > main(sys.argv[1:]) > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 627, in mai > n > setup.run_cmake() > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 509, in run > _cmake > PlatformSetup.run_cmake(self, args) > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 155, in run > _cmake > self.run(cmd, 'cmake') > File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", > line 504, in run > > raise CommandError('the command %r exited with %s' % > __main__.CommandError: the command 'cmake' exited with 1 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Mon Jun 9 09:12:39 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 9 09:13:38 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <992DA8EA-06E7-478A-9A6A-29C17097C6BF@gmail.com> <4849879D.5000602@cox.net> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> Message-ID: <484D5677.80300@gmail.com> Actually it is not a mandate. A mandate would be a MUST NOT. This is a SHOULD NOT, specifically: "A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users." I've got personal knowledge that the author did not intend the above to apply to situations like this. For the substrate to MSIE, however, it is entirely appropriate. Also, the above only applies to persistent connections, not non-persistent connections (applying the same guideline to non-persistent connections would cause problems that this guideline is intended to avoid). Just because you're doing HTTP, doesn't make you a part of the Web, and connection considerations in Web architecture over HTTP are different to other architectures over HTTP. Teravus Ovares wrote: > I also note, that according to Microsoft's kb article: > > "The HTTP 1.1 specification (RFC2616) mandates the two-connection > limit. The four-connection limit for HTTP 1.0 is a self-imposed > restriction that coincides with the standard that is used by a number > of popular Web browsers." > > You can read the article here: > http://support.microsoft.com/kb/183110 > > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > > Best Regards > > Teravus From robla at lindenlab.com Mon Jun 9 10:13:40 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 9 10:13:46 2008 Subject: [sldev] Linden Lab is accepting outside contribution (Re: Cache politics: performance vs obfuscation) In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <484D64C4.8070507@lindenlab.com> On 6/9/08 1:55 AM, Jason Giglio wrote: > Linden Lab is not accepting *any* outside contributions currently. This is false. We are accepting outside contribution. We are trying to stay focused on stability issues right now, so that's where you're most likely to see us quickly take your patches. I can see where earlier statements on this list might lead one to believe that we're not taking contribution, but such statements do not represent the consensus view. Rob From tongb at ohio.edu Mon Jun 9 10:20:16 2008 From: tongb at ohio.edu (Bruce Tong) Date: Mon Jun 9 10:20:19 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <484D5454.6040207@weblogsinc.com> References: <48448135.6090805@lindenlab.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> <484D5454.6040207@weblogsinc.com> Message-ID: <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> Trying to build with CMake against slviewer-src-maint-viewer-7-r89229... C:\ZZTong\SLDev\linden\indra>develop.py -G VC80 Running 'cmake "" "C:\\ZZTong\\SLDev\\linden\\indra"' in 'build-VC80' -- Version of viewer is 1.20.6.0 -- Configuring done -- Generating done -- Build files have been written to: C:/ZZTong/SLDev/linden/indra/build-VC80 Running 'tools\\vstool\\VSTool.exe --solution build-VC80\\SecondLife.sln --confi g RelWithDebInfo --startup secondlife-bin' in 'C:\\ZZTong\\SLDev\\linden\\indra' Opening solution: build-VC80\SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, now opening new VisualStudio instance... Reading .sln file version... Opening VS version: VC80... Value cannot be null. Parameter name: type Quitting do to error opening: C:\ZZTong\SLDev\linden\indra\build-VC80\SecondLife .sln Error getting property: "SolutionBuild" Object reference not set to an instance of an object. Object reference not set to an instance of an object. Error getting property: "Projects" Object reference not set to an instance of an object. Object reference not set to an instance of an object. Finished! I tried to track down the source of this failure. In main.cpp of VSTool, starting at line 315: Type objType = Type.GetTypeFromProgID(progid); dte = System.Activator.CreateInstance(objType); It looks like GettypeFromProgID() returns null. The progid value is being set in GetVSProgID(), based on "VC80" it is being set to "VisualStudio.DTE.8.0". >From this point I'm speculating since I've not done any development for Windows since 1994. I assumed null was the result when the type could not be found. I further assumed since I have an express edition of 2005, that "VisualStudio.DTE.8.0" might not be the right string. So I read a bunch of web pages, poked around in the registry, and for the .sln extension the ProgID on this computer might be "VisualStudio.Launcher.sln", but I also see things like "VCExpress.cpp.8.0". I'm not really certain if I'm on the right track here, or not. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From jake at lindenlab.com Mon Jun 9 10:35:50 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 10:36:02 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> Message-ID: <484D69F6.3040802@lindenlab.com> evolutie wrote: > I finally got around to test with multiple clients logged on to aditi > puppeteering, and unfortunetely the simulation doesn't seem to work. > Seems like instead of simulating the movement of the joints, the > direction in which the avatar looks is simulated. > To illustrate: > http://www.evolutie.org/movies/puppet1.mov shows me moving my hand > http://www.evolutie.org/movies/puppet2.mov shows what this looks like > to another client > > evo > . > > >> It's based off 1.19.1 by the way, and we do actually have a region on aditi >> that is running the simulator code (note, again, this code is relatively >> incomplete and the simulator could well crash) named Puppeteering (You may >> well need to log directly into it by they way). >> >> I'll be honest and say I'm not the least bit surprised. The reason LL let this code branch go was because of issues like this and the fact that mouse-generated real time animation manipulation (which is mostly a client side thing) just wasn't as compelling as had been thought. From teravus at gmail.com Mon Jun 9 10:39:42 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 10:39:45 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484D5677.80300@gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> Message-ID: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Can anyone confirm that the client does not use a library that respects this 2 connection limitation? So far in testing, it appears that it does. When two threads get stuck, it fails to do anything else via http. We've tried to use HTTP CAPS for inventory, and consistently, when the inventory service runs slow, the client stops making *any* further http requests. Best Regards Teravus On 6/9/08, Tateru Nino wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This is a > SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections with any > server or proxy. A proxy SHOULD use up to 2*N connections to another server > or proxy, where N is the number of simultaneously active users." > > I've got personal knowledge that the author did not intend the above to > apply to situations like this. For the substrate to MSIE, however, it is > entirely appropriate. Also, the above only applies to persistent > connections, not non-persistent connections (applying the same guideline to > non-persistent connections would cause problems that this guideline is > intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the Web, and > connection considerations in Web architecture over HTTP are different to > other architectures over HTTP. > > > > > Teravus Ovares wrote: > >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >> coincides with the standard that is used by a number of popular Web >> browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3199c322/attachment.htm From teravus at gmail.com Mon Jun 9 10:47:56 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jun 9 10:47:59 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484D5677.80300@gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> Message-ID: <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> I note that we can argue exactly what the RFC means until we're blue in the face. Ultimately what matters is how the libraries the client uses handle it. >From the referenced definition of the words: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) So, given this, the word 'MAY' is optional. SHOULD is almost always. SHOULD NOT is almost never. Best Regards Teravus On 6/9/08, Tateru Nino wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This is a > SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections with any > server or proxy. A proxy SHOULD use up to 2*N connections to another server > or proxy, where N is the number of simultaneously active users." > > I've got personal knowledge that the author did not intend the above to > apply to situations like this. For the substrate to MSIE, however, it is > entirely appropriate. Also, the above only applies to persistent > connections, not non-persistent connections (applying the same guideline to > non-persistent connections would cause problems that this guideline is > intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the Web, and > connection considerations in Web architecture over HTTP are different to > other architectures over HTTP. > > > > > Teravus Ovares wrote: > >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >> coincides with the standard that is used by a number of popular Web >> browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/265eab98/attachment-0001.htm From dahliatrimble at gmail.com Mon Jun 9 11:11:26 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon Jun 9 11:11:31 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> Message-ID: I dont see why the requested functionality couldn't work with existing channels, or am I missing something here? On Mon, Jun 9, 2008 at 10:47 AM, Teravus Ovares wrote: > I note that we can argue exactly what the RFC means until we're blue in the > face. Ultimately what matters is how the libraries the client uses handle > it. > > From the referenced definition of the words: > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > > So, given this, the word 'MAY' is optional. SHOULD is almost always. > SHOULD NOT is almost never. > > Best Regards > > Teravus > > > On 6/9/08, Tateru Nino wrote: > >> Actually it is not a mandate. A mandate would be a MUST NOT. This is a >> SHOULD NOT, specifically: >> "A single-user client SHOULD NOT maintain more than 2 connections with any >> server or proxy. A proxy SHOULD use up to 2*N connections to another server >> or proxy, where N is the number of simultaneously active users." >> >> I've got personal knowledge that the author did not intend the above to >> apply to situations like this. For the substrate to MSIE, however, it is >> entirely appropriate. Also, the above only applies to persistent >> connections, not non-persistent connections (applying the same guideline to >> non-persistent connections would cause problems that this guideline is >> intended to avoid). >> >> Just because you're doing HTTP, doesn't make you a part of the Web, and >> connection considerations in Web architecture over HTTP are different to >> other architectures over HTTP. >> >> >> >> >> Teravus Ovares wrote: >> >>> I also note, that according to Microsoft's kb article: >>> "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit. >>> The four-connection limit for HTTP 1.0 is a self-imposed restriction that >>> coincides with the standard that is used by a number of popular Web >>> browsers." >>> You can read the article here: >>> http://support.microsoft.com/kb/183110 >>> You can read the RFC here: >>> http://www.faqs.org/rfcs/rfc2616.html >>> Best Regards >>> Teravus >>> >> > > _______________________________________________ > 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/20080609/9c2a20da/attachment.htm From robin.cornelius at gmail.com Mon Jun 9 11:20:50 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jun 9 11:20:53 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> References: <48448135.6090805@lindenlab.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> <484D5454.6040207@weblogsinc.com> <4f335a50806091020p6ff31f3bte2ad0a43800ea026@mail.gmail.com> Message-ID: <484D7482.3080506@gmail.com> Bruce Tong wrote: > > I tried to track down the source of this failure. > > In main.cpp of VSTool, starting at line 315: > > Type objType = Type.GetTypeFromProgID(progid); > dte = System.Activator.CreateInstance(objType); > > It looks like GettypeFromProgID() returns null. The progid value is > being set in GetVSProgID(), based on "VC80" it is being set to > "VisualStudio.DTE.8.0". > >>From this point I'm speculating since I've not done any development > for Windows since 1994. > > I assumed null was the result when the type could not be found. I > further assumed since I have an express edition of 2005, that > "VisualStudio.DTE.8.0" might not be the right string. So I read a > bunch of web pages, poked around in the registry, and for the .sln > extension the ProgID on this computer might be > "VisualStudio.Launcher.sln", but I also see things like > "VCExpress.cpp.8.0". I'm not really certain if I'm on the right track > here, or not. > http://jira.secondlife.com/browse/VWR-7680 Yea we were on this today on #opensl It appears that the express editions do not register themselves the same way as the Standard or better editions. Its the DTE's you are looking for For express there is reference to VCExpress.DTE which links to VCExpress.DTE.9.0 (on my system) but the CLSID this then contains is not a registered com objectm if i look at my Standard installed VC 2003 .NET i have a VisualStudio.DTE.7.1 and the com objects are registered correctly. (And VSTool.exe works perfectly on my 2003.NET (standard edition) but not on my 2008 Express. I think its a limitation of express versions Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/cd55658c/signature.pgp From me at signpostmarv.name Mon Jun 9 12:35:33 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Jun 9 12:35:43 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> Message-ID: <484D8605.4090200@signpostmarv.name> referenced by name or sim UUID ? ~ Marv. > Bigger-note : > What about storing cache *per sim* ? Most peoples always go in the > same dozen of sim 99% of time and a lot of texture are unique to the > sim. > When you enter in a sim, just load the *entire* cache related to this > sim and discard later the unused texture. > Could it save time ? (pre-decoding ?) > > That's all... have fun :) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/49cfd2a2/smime.bin From rdw at lindenlab.com Mon Jun 9 12:43:17 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jun 9 12:43:18 2008 Subject: Improved viewer and script communications (Re: [sldev]Puppettering Branch) In-Reply-To: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> References: <48473027.9090101@lindenlab.com><6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com><484B1E01.1010800@cox.net><3DC4D675-A 662-4217-AF6D-FEF08586E946@gmail.com><484B7DC5.7000900@cox.net><299591AF-E75A-4757-825F-9F0350A59377@gmail.com><484C307A.702000 4@cox.net> <484C904A.1070205@gmail.com><34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com><484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Message-ID: <484D87D5.3050609@lindenlab.com> Teravus Ovares wrote: > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it appears > that it does. When two threads get stuck, it fails to do anything > else via http. We've tried to use HTTP CAPS for inventory, and > consistently, when the inventory service runs slow, the client stops > making *any* further http requests. The client uses libcurl. I wasn't able to dig up information either confirming or denying that libcurl has such a restriction, but maybe you can! -RYaN From zak.escher at gmail.com Mon Jun 9 13:03:22 2008 From: zak.escher at gmail.com (Zak Escher) Date: Mon Jun 9 13:03:27 2008 Subject: [sldev] CMake project merged to release branch! In-Reply-To: References: <48448135.6090805@lindenlab.com> <4844F1D3.1090301@gmail.com> <61a5f47b10aafc4ff71eb929813bd563@localhost> <4f335a50806052112n58912972r74a16b96d33e57c2@mail.gmail.com> <0D2C9F7D-8E83-4B85-89B8-96769A901339@secondlife.com> <484D22C2.1090403@gmail.com> Message-ID: <484D8C8A.2080604@gmail.com> I ran the batch file. Now I am getting the following: C:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BO OL=FALSE "" "C:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in 'build-VC80' CMake Error: Could not create named generator Visual Studio 8 2005 Cleaning 'build-VC80' Traceback (most recent call last): File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 654, in ? main(sys.argv[1:]) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 627, in mai n setup.run_cmake() File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 509, in run _cmake PlatformSetup.run_cmake(self, args) File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 155, in run _cmake self.run(cmd, 'cmake') File "C:\Users\\sl_1_19_1_14\linden\indra\develop.py", line 504, in run raise CommandError('the command %r exited with %s' % __main__.CommandError: the command 'cmake' exited with 1 Robin Cornelius wrote: > On Mon, Jun 9, 2008 at 1:32 PM, Zak Escher wrote: > >> I keep getting the following when trying to run develop.py. This is from >> within Windows Vista Ultimate 64-Bit. >> >> (Note: I have replaced my user id with) >> >> c:\Users\\sl_1_19_1_14\linden\indra>develop.py -G VC80 >> Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=FALSE >> -DUNATTENDED:BO >> OL=FALSE "" "c:\\Users\\\\sl_1_19_1_14\\linden\\indra"' in >> 'build-VC80' >> -- Check for working C compiler: cl >> -- Check for working C compiler: cl -- broken >> CMake Error at C:/Program Files (x86)/CMake >> 2.6/share/cmake-2.6/Modules/CMakeTes >> tCCompiler.cmake:32 (MESSAGE): >> The C compiler "cl" is not able to compile a simple test program. >> > > try running from the console the vcvars.bat (or vsvars.bat) that is > found in c:\program files\visual studio 2005\VC\bin\ > > or a path very like that and try again. Looks like your visual studio > is not correctly setup for out of IDE compiling. > > Robin > From timothyhorrigan at mac.com Mon Jun 9 13:36:04 2008 From: timothyhorrigan at mac.com (Timothy Horrigan) Date: Mon Jun 9 13:36:16 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <484D9434.4090409@mac.com> Robin Cornelius wrote: > > > just to pick a few, not the example i was looking for, there is/was > one somewhere with a pile of votes saying remove the texture console. > And this noise is heard so often and often gets associated with > anti-opensource. > > There are no real usable technical solutions to content theft, nothing > technical really works anywhere. As far as i see the only solution is > the social one, where people have the respect not to just rip stuff > off and thats a whole bigger issue than just SL. > > Anytime you make content visible to the public, you are running the risk of them "stealing" it. Even if you make direct copying, they can just reverse-engineer it. In the case of SL, the textures are "stealing" space on my hard drive, so I should be able to look at the cache files :-) I liked the people who wanted to eliminate the texture console. even though they were unable to explain how the texture console would actually enable a user to rip a specific console. -------------- next part -------------- A non-text attachment was scrubbed... Name: timothyhorrigan.vcf Type: text/x-vcard Size: 224 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/6afd74c9/timothyhorrigan.vcf From timothyhorrigan at mac.com Mon Jun 9 13:36:28 2008 From: timothyhorrigan at mac.com (Timothy Horrigan) Date: Mon Jun 9 13:36:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <484D944C.9010009@mac.com> Robin Cornelius wrote: > > > just to pick a few, not the example i was looking for, there is/was > one somewhere with a pile of votes saying remove the texture console. > And this noise is heard so often and often gets associated with > anti-opensource. > > There are no real usable technical solutions to content theft, nothing > technical really works anywhere. As far as i see the only solution is > the social one, where people have the respect not to just rip stuff > off and thats a whole bigger issue than just SL. > > Anytime you make content visible to the public, you are running the risk of them "stealing" it. Even if you make direct copying impossible, they can just reverse-engineer it. In the case of SL, the textures are "stealing" space on my hard drive, so I should be able to look at the cache files :-) I liked the people who wanted to eliminate the texture console. even though they were unable to explain how the texture console would actually enable a user to rip a specific console. -------------- next part -------------- A non-text attachment was scrubbed... Name: timothyhorrigan.vcf Type: text/x-vcard Size: 224 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/92ad078b/timothyhorrigan.vcf From evolutie at gmail.com Mon Jun 9 13:56:48 2008 From: evolutie at gmail.com (evolutie) Date: Mon Jun 9 13:57:07 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484D69F6.3040802@lindenlab.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> Message-ID: <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: > evolutie wrote: >> >> I finally got around to test with multiple clients logged on to aditi >> puppeteering, and unfortunetely the simulation doesn't seem to work. >> Seems like instead of simulating the movement of the joints, the >> direction in which the avatar looks is simulated. >> To illustrate: >> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >> to another client >> >> evo >> . >> >> >>> >>> It's based off 1.19.1 by the way, and we do actually have a region on >>> aditi >>> that is running the simulator code (note, again, this code is relatively >>> incomplete and the simulator could well crash) named Puppeteering (You >>> may >>> well need to log directly into it by they way). >>> >>> > > I'll be honest and say I'm not the least bit surprised. The reason LL let > this code branch go was because of issues like this and the fact that > mouse-generated real time animation manipulation (which is mostly a client > side thing) just wasn't as compelling as had been thought. > hmmmm. I realize the code is unsupported.. and therefor i'm not that surprised either. But it looks more like either the wrong simulation code is being executed on the serverside of things or the puppeteering client is sending or receiving (or interpreting) wrong data.. Somewhere in the communication someone isn't aware of the avatar being a "physical avatar". I think that the current UI being mousebased is useful, but yes, I would love to have other input for it like script functions and physical interfaces like mocap suits etc. But the ability for realtime animation of avatars is a wonderful exciting thing!!! It offers a lot of possibilities that right now are just not possible in SL, and well.. really.. it's totally compelling :-) With things on the clientside already working really well, I don't see too much trouble technically to make it work 'globally'. An array of joint positions/rotations isn't that heavy... Am I overlooking something? Apologies for putting these issues on unsupported features up.. I would just love to see this going to the next level, but can't do anything when it comes to the serverside of things.. And maybe this is just a matter of the wrong code running on the puppeteering SIM ? thnx and regards, Evo From blindwanderer at gmail.com Mon Jun 9 14:04:31 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Mon Jun 9 14:04:36 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <89ca6da00806091402j2b614bc2t4df2f5f10374c06f@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <484D944C.9010009@mac.com> <89ca6da00806091402j2b614bc2t4df2f5f10374c06f@mail.gmail.com> Message-ID: <89ca6da00806091404u63911c62p8085f4a4f69b7f71@mail.gmail.com> I've been playing with the client cache for years. Yes I said years. Three years ago I wrote a tool that converted the VFS to a tar archive. It then became trivial to open it in WinZip (which handles large archives really well). It was during this time that I reverse engineered the asset formats. At the time I opened a dialog with LL on the issues of asset security, and so I was asked the question: "No matter what we do, people can still steal assets, so why bother doing anything?" The problem is, to render an asset it needs to be in raw form. Even if you encrypt the data stream and caches, the weak link is the end of the chain where it gets rendered. There is no point in hardening the front door when the back door is hanging off it's hinges. LL will do what ever is easy and will provide good performance. The question I have is this: Is it faster to read a decoded image from disk or read a JPEG2000 encoded image from disk and decode it? With the steady increase of the number of CPU cores in a system, allowing for more simultaneous threads, is it really important? On Mon, Jun 9, 2008 at 4:36 PM, Timothy Horrigan wrote: > Robin Cornelius wrote: >> >> >> just to pick a few, not the example i was looking for, there is/was >> one somewhere with a pile of votes saying remove the texture console. >> And this noise is heard so often and often gets associated with >> anti-opensource. >> >> There are no real usable technical solutions to content theft, nothing >> technical really works anywhere. As far as i see the only solution is >> the social one, where people have the respect not to just rip stuff >> off and thats a whole bigger issue than just SL. >> >> > > Anytime you make content visible to the public, you are running the risk of > them "stealing" it. Even if you make direct copying impossible, they can > just reverse-engineer it. > > In the case of SL, the textures are "stealing" space on my hard drive, so I > should be able to look at the cache files :-) > > I liked the people who wanted to eliminate the texture console. even though > they were unable to explain how the texture console would actually enable a > user to rip a specific console. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From ordinal.malaprop at fastmail.fm Mon Jun 9 14:22:10 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Mon Jun 9 14:22:15 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484D0722.3020701@streamsense.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > Dante Tucker wrote: >> Lets all just stop pretending anyone who wants to steal textures >> can't with the current system. Anyone who wants them can already >> get them. The only thing storing data raw would do is make them >> more accesable to people who don't want them and have no knoledge >> of how to get them currently. And if they don't want them then >> whats the harm? > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > > ~Tom Not to pick on Tom particularly here, but this is the sort of m message that reinforces my opinion that: (a) the people involved in discussing assets don't understand what those _creating_ the assets want or think; (b) they don't care. The level of snobbery applied here is breathtaking, endless references to pitchforks ho ho, you know, they're all irrational peasants. But even in the current situation, textures not being instantly obtainable by just going to the right directory and dragging to somewhere else is a disincentive to pirates. YES, we do all know about glintercept and all the other ways to get hold of textures. YES, we know that there is an intrinsic problem here, that displaying the damn assets implies that they are received by the client. YES, we've all heard these teenage extropian "information wants to be free" tropes, thanks all the same. Amazingly enough, people appreciate the practical issues. What they don't like is the idea that they are being treated as idiots and rubes by LL and assorted geeky types because they dare to get worried about the reason that they are there and building the world for you lot to play about with in the first place. Because, you know, if it wasn't for people who make content, you and I would not be here discussing this stuff, as I've said before. If you can't offer anything to content creators apart from "ha ha your stuff has already been stolen stupid n00bs" then you might as well close the whole company down right now. From jake at lindenlab.com Mon Jun 9 14:23:29 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 14:23:41 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> Message-ID: <484D9F51.4010209@lindenlab.com> Comments at the bottom evolutie wrote: > On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: > >> evolutie wrote: >> >>> I finally got around to test with multiple clients logged on to aditi >>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>> Seems like instead of simulating the movement of the joints, the >>> direction in which the avatar looks is simulated. >>> To illustrate: >>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>> to another client >>> >>> evo >>> . >>> >>> >>> >>>> It's based off 1.19.1 by the way, and we do actually have a region on >>>> aditi >>>> that is running the simulator code (note, again, this code is relatively >>>> incomplete and the simulator could well crash) named Puppeteering (You >>>> may >>>> well need to log directly into it by they way). >>>> >>>> >>>> >> I'll be honest and say I'm not the least bit surprised. The reason LL let >> this code branch go was because of issues like this and the fact that >> mouse-generated real time animation manipulation (which is mostly a client >> side thing) just wasn't as compelling as had been thought. >> >> > > hmmmm. I realize the code is unsupported.. and therefor i'm not that > surprised either. > But it looks more like either the wrong simulation code is being > executed on the serverside of things or the puppeteering client is > sending or receiving (or interpreting) wrong data.. Somewhere in the > communication someone isn't aware of the avatar being a "physical > avatar". > I think that the current UI being mousebased is useful, but yes, I > would love to have other input for it like script functions and > physical interfaces like mocap suits etc. > But the ability for realtime animation of avatars is a wonderful > exciting thing!!! It offers a lot of possibilities that right now are > just not possible in SL, and well.. really.. it's totally compelling > :-) > With things on the clientside already working really well, I don't see > too much trouble technically to make it work 'globally'. An array of > joint positions/rotations isn't that heavy... Am I overlooking > something? > Apologies for putting these issues on unsupported features up.. I > would just love to see this going to the next level, but can't do > anything when it comes to the serverside of things.. And maybe this > is just a matter of the wrong code running on the puppeteering SIM ? > > thnx and regards, > Evo > I haven't actually looked, I just asked Ops to build and put up the code. I'll go ping them and talk to the relevant people. In terms of finishing the code and pushing it out, well, that's partly why we released it to you guys. If someone here came up with a compelling instance of usage then yeah, it's possible we would revisit it. Internally, as an LL driven project it's unlikely - we just don't have the internal resources free to do large R&D on this particularly item right now - but we figure that's all the more reason to see what you guys can do with it. Never say never. Jake From evolutie at gmail.com Mon Jun 9 14:31:32 2008 From: evolutie at gmail.com (evolutie) Date: Mon Jun 9 14:31:35 2008 Subject: [sldev] Puppettering Branch In-Reply-To: <484D9F51.4010209@lindenlab.com> References: <48473027.9090101@lindenlab.com> <5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com> <484D69F6.3040802@lindenlab.com> <5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com> <484D9F51.4010209@lindenlab.com> Message-ID: <5fb4b1fa0806091431q78b23e99s5e86e3fec815f172@mail.gmail.com> Thanks Jake! It's very appreciated! evo On Mon, Jun 9, 2008 at 11:23 PM, Jake Simpson wrote: > Comments at the bottom > > evolutie wrote: >> >> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: >> >>> >>> evolutie wrote: >>> >>>> >>>> I finally got around to test with multiple clients logged on to aditi >>>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>>> Seems like instead of simulating the movement of the joints, the >>>> direction in which the avatar looks is simulated. >>>> To illustrate: >>>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>>> to another client >>>> >>>> evo >>>> . >>>> >>>> >>>> >>>>> >>>>> It's based off 1.19.1 by the way, and we do actually have a region on >>>>> aditi >>>>> that is running the simulator code (note, again, this code is >>>>> relatively >>>>> incomplete and the simulator could well crash) named Puppeteering (You >>>>> may >>>>> well need to log directly into it by they way). >>>>> >>>>> >>>>> >>> >>> I'll be honest and say I'm not the least bit surprised. The reason LL let >>> this code branch go was because of issues like this and the fact that >>> mouse-generated real time animation manipulation (which is mostly a >>> client >>> side thing) just wasn't as compelling as had been thought. >>> >>> >> >> hmmmm. I realize the code is unsupported.. and therefor i'm not that >> surprised either. >> But it looks more like either the wrong simulation code is being >> executed on the serverside of things or the puppeteering client is >> sending or receiving (or interpreting) wrong data.. Somewhere in the >> communication someone isn't aware of the avatar being a "physical >> avatar". >> I think that the current UI being mousebased is useful, but yes, I >> would love to have other input for it like script functions and >> physical interfaces like mocap suits etc. >> But the ability for realtime animation of avatars is a wonderful >> exciting thing!!! It offers a lot of possibilities that right now are >> just not possible in SL, and well.. really.. it's totally compelling >> :-) >> With things on the clientside already working really well, I don't see >> too much trouble technically to make it work 'globally'. An array of >> joint positions/rotations isn't that heavy... Am I overlooking >> something? >> Apologies for putting these issues on unsupported features up.. I >> would just love to see this going to the next level, but can't do >> anything when it comes to the serverside of things.. And maybe this >> is just a matter of the wrong code running on the puppeteering SIM ? >> >> thnx and regards, >> Evo >> > > I haven't actually looked, I just asked Ops to build and put up the code. > I'll go ping them and talk to the relevant people. > > In terms of finishing the code and pushing it out, well, that's partly why > we released it to you guys. If someone here came up with a compelling > instance of usage then yeah, it's possible we would revisit it. Internally, > as an LL driven project it's unlikely - we just don't have the internal > resources free to do large R&D on this particularly item right now - but we > figure that's all the more reason to see what you guys can do with it. > > Never say never. > > Jake > -- http://www.creativemachinery.org From xotmid at gmail.com Mon Jun 9 14:34:31 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Jun 9 14:34:33 2008 Subject: [sldev] Shadow Patch? Message-ID: http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html Is this going to make it into rc10? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/a9d95ad8/attachment.htm From q at lindenlab.com Mon Jun 9 14:36:07 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon Jun 9 14:36:11 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> On Jun 9, 2008, at 5:22 PM, ordinal.malaprop@fastmail.fm wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > >> Dante Tucker wrote: >>> Lets all just stop pretending anyone who wants to steal textures >>> can't with the current system. Anyone who wants them can already >>> get them. The only thing storing data raw would do is make them >>> more accesable to people who don't want them and have no knoledge >>> of how to get them currently. And if they don't want them then >>> whats the harm? >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom > > Not to pick on Tom particularly here, but this is the sort of m > message that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what > those _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless > references to pitchforks ho ho, you know, they're all irrational > peasants. But even in the current situation, textures not being > instantly obtainable by just going to the right directory and > dragging to somewhere else is a disincentive to pirates. > > YES, we do all know about glintercept and all the other ways to get > hold of textures. YES, we know that there is an intrinsic problem > here, that displaying the damn assets implies that they are received > by the client. YES, we've all heard these teenage extropian > "information wants to be free" tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they > don't like is the idea that they are being treated as idiots and > rubes by LL and assorted geeky types because they dare to get > worried about the reason that they are there and building the world > for you lot to play about with in the first place. Because, you > know, if it wasn't for people who make content, you and I would not > be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. > Boy, I can totally see both sides of this argument. It's true -- if we're displaying it, it can be copied with a relatively small amount of work for a motivated individual with technical skill. It's *also* true that if it's trivially easy to copy it, it will be copied much more frequently than if it's slightly harder. This is why "security by obscurity" is popular. The extra step makes it obvious that you're taking some measure -- no matter how simple -- to break a protection scheme, and that sense of an explicit violation does deter a lot of people. So while I completely agree that there's no way we can provide true protection, I also agree that simply stuffing the files into a directory using standard formats is kind of like leaving your bike unlocked in the street -- someone will ride off with it who might not have bothered if you used even a cheap bike lock. Personally (I'm not speaking for Linden here), I think that if we want to change the way we do caching, we should make it slightly complicated to grab items out of the cache by NOT storing them in standard formats. Q From bboomslang at googlemail.com Mon Jun 9 14:36:26 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Jun 9 14:36:32 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <347b550f0806091436t3cafddf3m463de8a6afa3e903@mail.gmail.com> I have to agree with Ordinal here. Yes, obviously, data sent to the client is decodeable by the client and not possible to protect perfectly. That's a given. But that does not say at the same time that you should make things so simple that taking textures is obvious. We still don't put bars on our windows, even though we absolutely know that breaking glas is easy. We still put paper envelopes around our letters despite everybody knowing that paper envelopes don't protect their content. Yes, the professional thieve won't have a problem with breaking your doorlocks - but that doesn't say you rip out your door and let anybody walk in unhindered. The very same reasoning works for software, too. Right, there is no perfect protection. It's pointless to flog that dead horse all the time - but it's at least as pointless to throw all limitations out the window just because of that argument. There are ways to give content at least a token protection that will prevent the most stupid ways of content to spread. No, that won't keep professional thieves out. And yes, it would be ridiculous to go to the lengths the music industry tried to do with DRM, because that will actually harm the users more than the thieves. Practical example: watermarking images in SL and checking those watermarks on re-upload would be an easy way for said token protection against too simple copying. And would add ways to claim ownership. No, definitely not perfect protection, but doable without adding harm for users or degrading performance (as the check is done on upload only and the watermarking right after upload). Would that solve texture-theft? Nope. But it would at least keep some of it onder control. Don't underestimate the results of the proverbial slap-on-the-wrist with most people. bye, Barney On Mon, Jun 9, 2008 at 11:22 PM, wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: >> >>> Lets all just stop pretending anyone who wants to steal textures can't >>> with the current system. Anyone who wants them can already get them. The >>> only thing storing data raw would do is make them more accesable to people >>> who don't want them and have no knoledge of how to get them currently. And >>> if they don't want them then whats the harm? >>> >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom >> > > Not to pick on Tom particularly here, but this is the sort of m message > that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what those > _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless references to > pitchforks ho ho, you know, they're all irrational peasants. But even in the > current situation, textures not being instantly obtainable by just going to > the right directory and dragging to somewhere else is a disincentive to > pirates. > > YES, we do all know about glintercept and all the other ways to get hold of > textures. YES, we know that there is an intrinsic problem here, that > displaying the damn assets implies that they are received by the client. > YES, we've all heard these teenage extropian "information wants to be free" > tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they don't > like is the idea that they are being treated as idiots and rubes by LL and > assorted geeky types because they dare to get worried about the reason that > they are there and building the world for you lot to play about with in the > first place. Because, you know, if it wasn't for people who make content, > you and I would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha your > stuff has already been stolen stupid n00bs" then you might as well close the > whole company down right now. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/01281b0f/attachment-0001.htm From danteferret at gmail.com Mon Jun 9 14:38:57 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 14:38:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> Now don't forget everything here is just opinion. The ultimate decision of what happens with the client is up to Linden Labs. My point is they will listen to everyone before making a decision, not just the few that rant here in this list. We look at things from a technical perspective, others will argue a different perspective. And in the end LL will take all into account. It's a balance really, no reason to get mad. On Mon, Jun 9, 2008 at 5:22 PM, wrote: > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: >> >>> Lets all just stop pretending anyone who wants to steal textures can't >>> with the current system. Anyone who wants them can already get them. The >>> only thing storing data raw would do is make them more accesable to people >>> who don't want them and have no knoledge of how to get them currently. And >>> if they don't want them then whats the harm? >>> >> Agreed. >> >> I tire of people moaning about IP security. >> >> Your stuff is already stolen, deal with it. >> >> ~Tom >> > > Not to pick on Tom particularly here, but this is the sort of m message > that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what those > _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless references to > pitchforks ho ho, you know, they're all irrational peasants. But even in the > current situation, textures not being instantly obtainable by just going to > the right directory and dragging to somewhere else is a disincentive to > pirates. > > YES, we do all know about glintercept and all the other ways to get hold of > textures. YES, we know that there is an intrinsic problem here, that > displaying the damn assets implies that they are received by the client. > YES, we've all heard these teenage extropian "information wants to be free" > tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What they don't > like is the idea that they are being treated as idiots and rubes by LL and > assorted geeky types because they dare to get worried about the reason that > they are there and building the world for you lot to play about with in the > first place. Because, you know, if it wasn't for people who make content, > you and I would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha your > stuff has already been stolen stupid n00bs" then you might as well close the > whole company down right now. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/185c279c/attachment.htm From overtake at keynet.com.br Mon Jun 9 14:46:42 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Mon Jun 9 14:47:45 2008 Subject: [sldev] Puppettering Branch References: <48473027.9090101@lindenlab.com><5fb4b1fa0806071527y37dc0ce6idcf5d02252e6afb0@mail.gmail.com><484D69F6.3040802@lindenlab.com><5fb4b1fa0806091356s2af1f140m607854c6efa35f00@mail.gmail.com><484D9F51.4010209@lindenlab.com> <5fb4b1fa0806091431q78b23e99s5e86e3fec815f172@mail.gmail.com> Message-ID: <004901c8ca7a$6c69c0f0$6e00a8c0@eaurouge> Thats great! I?m one of the machinima people waiting anxiously for it ((: {}Overtake ----- Original Message ----- From: "evolutie" To: "Jake Simpson" Cc: Sent: Monday, June 09, 2008 6:31 PM Subject: Re: [sldev] Puppettering Branch > Thanks Jake! It's very appreciated! > > evo > > On Mon, Jun 9, 2008 at 11:23 PM, Jake Simpson wrote: >> Comments at the bottom >> >> evolutie wrote: >>> >>> On Mon, Jun 9, 2008 at 7:35 PM, Jake Simpson wrote: >>> >>>> >>>> evolutie wrote: >>>> >>>>> >>>>> I finally got around to test with multiple clients logged on to aditi >>>>> puppeteering, and unfortunetely the simulation doesn't seem to work. >>>>> Seems like instead of simulating the movement of the joints, the >>>>> direction in which the avatar looks is simulated. >>>>> To illustrate: >>>>> http://www.evolutie.org/movies/puppet1.mov shows me moving my hand >>>>> http://www.evolutie.org/movies/puppet2.mov shows what this looks like >>>>> to another client >>>>> >>>>> evo >>>>> . >>>>> >>>>> >>>>> >>>>>> >>>>>> It's based off 1.19.1 by the way, and we do actually have a region >>>>>> on >>>>>> aditi >>>>>> that is running the simulator code (note, again, this code is >>>>>> relatively >>>>>> incomplete and the simulator could well crash) named Puppeteering >>>>>> (You >>>>>> may >>>>>> well need to log directly into it by they way). >>>>>> >>>>>> >>>>>> >>>> >>>> I'll be honest and say I'm not the least bit surprised. The reason LL >>>> let >>>> this code branch go was because of issues like this and the fact that >>>> mouse-generated real time animation manipulation (which is mostly a >>>> client >>>> side thing) just wasn't as compelling as had been thought. >>>> >>>> >>> >>> hmmmm. I realize the code is unsupported.. and therefor i'm not that >>> surprised either. >>> But it looks more like either the wrong simulation code is being >>> executed on the serverside of things or the puppeteering client is >>> sending or receiving (or interpreting) wrong data.. Somewhere in the >>> communication someone isn't aware of the avatar being a "physical >>> avatar". >>> I think that the current UI being mousebased is useful, but yes, I >>> would love to have other input for it like script functions and >>> physical interfaces like mocap suits etc. >>> But the ability for realtime animation of avatars is a wonderful >>> exciting thing!!! It offers a lot of possibilities that right now are >>> just not possible in SL, and well.. really.. it's totally compelling >>> :-) >>> With things on the clientside already working really well, I don't see >>> too much trouble technically to make it work 'globally'. An array of >>> joint positions/rotations isn't that heavy... Am I overlooking >>> something? >>> Apologies for putting these issues on unsupported features up.. I >>> would just love to see this going to the next level, but can't do >>> anything when it comes to the serverside of things.. And maybe this >>> is just a matter of the wrong code running on the puppeteering SIM ? >>> >>> thnx and regards, >>> Evo >>> >> >> I haven't actually looked, I just asked Ops to build and put up the code. >> I'll go ping them and talk to the relevant people. >> >> In terms of finishing the code and pushing it out, well, that's partly >> why >> we released it to you guys. If someone here came up with a compelling >> instance of usage then yeah, it's possible we would revisit it. >> Internally, >> as an LL driven project it's unlikely - we just don't have the internal >> resources free to do large R&D on this particularly item right now - but >> we >> figure that's all the more reason to see what you guys can do with it. >> >> Never say never. >> >> Jake >> > > > > -- > http://www.creativemachinery.org > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From missannotoole at yahoo.com Mon Jun 9 15:03:57 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 9 15:03:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Message-ID: <186182.74892.qm@web59109.mail.re1.yahoo.com> I'm aware of the challenge/opportunity. Thus why I don't have much to say about it in negative unproductive terms (anymore :P ). My interest is in finding a way to increase both the storage capacity and efficiency of storing/loading while increasing protection against unauthorized access. My gut feeling is what I want will require better personal computer hardware. I do not think it is simple. This will require some creative thinking and hard work. If everyone had a powerful 64 bit pc/os with 4gb ram and high end video card then maybe an in memory database might be an interesting concept. But everyone doesn't have enough memory and processing power yet. Oracle is moving in this direction for heavy transaction systems to get hundreds of thousands of transactions per second with resiliency between network disconnects. Is the mysql effort doing anything similar? I doubt a lot of low hanging fruit is available The number and size factor of an entire sim's textures is large. The more you store the longer to find it to reload. etc etc. Doesn't mean we can't plan ahead. And try. ----- Original Message ---- From: Dante Tucker To: ordinal.malaprop@fastmail.fm Cc: Second Life Developer Mailing List Sent: Monday, June 9, 2008 5:38:57 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Now don't forget everything here is just opinion. The ultimate decision of what happens with the client is up to Linden Labs. My point is they will listen to everyone before making a decision, not just the few that rant here in this list. We look at things from a technical perspective, others will argue a different perspective. And in the end LL will take all into account. It's a balance really, no reason to get mad. On Mon, Jun 9, 2008 at 5:22 PM, wrote: On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: Dante Tucker wrote: Lets all just stop pretending anyone who wants to steal textures can't with the current system. Anyone who wants them can already get them. The only thing storing data raw would do is make them more accesable to people who don't want them and have no knoledge of how to get them currently. And if they don't want them then whats the harm? Agreed. I tire of people moaning about IP security. Your stuff is already stolen, deal with it. ~Tom Not to pick on Tom particularly here, but this is the sort of m message that reinforces my opinion that: (a) the people involved in discussing assets don't understand what those _creating_ the assets want or think; (b) they don't care. The level of snobbery applied here is breathtaking, endless references to pitchforks ho ho, you know, they're all irrational peasants. But even in the current situation, textures not being instantly obtainable by just going to the right directory and dragging to somewhere else is a disincentive to pirates. YES, we do all know about glintercept and all the other ways to get hold of textures. YES, we know that there is an intrinsic problem here, that displaying the damn assets implies that they are received by the client. YES, we've all heard these teenage extropian "information wants to be free" tropes, thanks all the same. Amazingly enough, people appreciate the practical issues. What they don't like is the idea that they are being treated as idiots and rubes by LL and assorted geeky types because they dare to get worried about the reason that they are there and building the world for you lot to play about with in the first place. Because, you know, if it wasn't for people who make content, you and I would not be here discussing this stuff, as I've said before. If you can't offer anything to content creators apart from "ha ha your stuff has already been stolen stupid n00bs" then you might as well close the whole company down right now. _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/648defe7/attachment.htm From jake at lindenlab.com Mon Jun 9 15:34:01 2008 From: jake at lindenlab.com (Jake Simpson) Date: Mon Jun 9 15:34:15 2008 Subject: [sldev] How Far For Security? In-Reply-To: <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> Message-ID: <484DAFD9.6030009@lindenlab.com> I'd just like to make the point that a lot of LL reads these threads and we have lots of internal discussions about exactly stuff like this. We have one currently going regarding a feature we are talking about adding thats very much along these lines. "How far do we go to obstrufacate the data stream?" is the question. Bear in mind that some of the economy of Second Life is built upon people being able to build and have some degree of confidence that what they build won't get ripped off immediately by those who can, so they can be sure of getting some return on their investment of time. I'm sure you can understand how many in LL will be sympathetic to this thinking. Sure, technically anything can be reversed engineered (save scripts since they don't come to the client in any way) so the question becomes "how hard do we make it?" (or even "how hard CAN we make it?") - which is basically paraphrasing what's already been said in this thread. Stating "Well, because it's possible, don't even bother trying to stop it" doesn't (unfortunately) solve the issue of "how can I protect what I make" which is the root cry of anyone who spends time building things; it just undermines the Second Life economy to the point where it might potentially not be viable, obviously something people within in LL are keen to avoid. Please understand we are having the same discussions internally and what is said here is taken on board by those making the internal decisions, so keep at it. I'd like to rename this thread since it's quote a contentious name. Cheers Jake Dante Tucker wrote: > Now don't forget everything here is just opinion. The ultimate > decision of what happens with the client is up to Linden Labs. My > point is they will listen to everyone before making a decision, not > just the few that rant here in this list. We look at things from a > technical perspective, others will argue a different perspective. And > in the end LL will take all into account. It's a balance really, no > reason to get mad. > > On Mon, Jun 9, 2008 at 5:22 PM, > wrote: > > > On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: > > Dante Tucker wrote: > > Lets all just stop pretending anyone who wants to steal > textures can't with the current system. Anyone who wants > them can already get them. The only thing storing data raw > would do is make them more accesable to people who don't > want them and have no knoledge of how to get them > currently. And if they don't want them then whats the harm? > > Agreed. > > I tire of people moaning about IP security. > > Your stuff is already stolen, deal with it. > > ~Tom > > > Not to pick on Tom particularly here, but this is the sort of m > message that reinforces my opinion that: > > (a) the people involved in discussing assets don't understand what > those _creating_ the assets want or think; > (b) they don't care. > > The level of snobbery applied here is breathtaking, endless > references to pitchforks ho ho, you know, they're all irrational > peasants. But even in the current situation, textures not being > instantly obtainable by just going to the right directory and > dragging to somewhere else is a disincentive to pirates. > > YES, we do all know about glintercept and all the other ways to > get hold of textures. YES, we know that there is an intrinsic > problem here, that displaying the damn assets implies that they > are received by the client. YES, we've all heard these teenage > extropian "information wants to be free" tropes, thanks all the same. > > Amazingly enough, people appreciate the practical issues. What > they don't like is the idea that they are being treated as idiots > and rubes by LL and assorted geeky types because they dare to get > worried about the reason that they are there and building the > world for you lot to play about with in the first place. Because, > you know, if it wasn't for people who make content, you and I > would not be here discussing this stuff, as I've said before. > > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. > _______________________________________________ > 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 danteferret at gmail.com Mon Jun 9 15:51:17 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jun 9 15:51:19 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> Could you give a quick description of that file? For some downloading it is not a possibility. On Mon, Jun 9, 2008 at 5:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > > _______________________________________________ > 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/20080609/480a09ea/attachment.htm From lenglish5 at cox.net Mon Jun 9 16:21:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 16:21:29 2008 Subject: [sldev] iphone 3D client possible? Message-ID: <484DBAF7.9000308@cox.net> I don't know the difference between OpenGL and OpenGL ES, but Apple claims hardware OpenGL ES acceleration for the new iPhone. Does this mean that some subset of the 3D viewer code will be implementable on the iPhone? Lawson From me at signpostmarv.name Mon Jun 9 16:23:51 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Jun 9 16:23:53 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> References: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> Message-ID: <484DBB87.90604@signpostmarv.name> I believe it refers to http://www.massively.com/2008/05/29/high-end-graphics-features-planned-for-second-life/ Dante Tucker wrote: > Could you give a quick description of that file? For some downloading > it is not a possibility. > > On Mon, Jun 9, 2008 at 5:34 PM, Brandon Husbands > wrote: > > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/30d2e260/smime.bin From gigstaggart at gmail.com Mon Jun 9 16:34:50 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 16:34:59 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> Message-ID: <484DBE1A.8040008@gmail.com> Kent Quirk (Q Linden) wrote: > Personally (I'm not speaking for Linden here), I think that if we want > to change the way we do caching, we should make it slightly > complicated to grab items out of the cache by NOT storing them in > standard formats. Do you use "right click protection" javascript on web pages you design, to prevent people from "stealing" your images? It's the same thing. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/19f0a405/smime.bin From daveh at lindenlab.com Mon Jun 9 16:38:18 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Mon Jun 9 16:38:21 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484DBAF7.9000308@cox.net> References: <484DBAF7.9000308@cox.net> Message-ID: OpenGL ES is a subset of OpenGL. Its basically had all the intermediate calls removed in favour of vertex arrays. There's been some cool stuff done with the iphone: someone ported quake 3! http://www.youtube.com/watch?v=kvci1vTXyUo Unfortunately I doubt its got enough power to run SL. On 10 Jun 2008, at 00:21, Lawson English wrote: > I don't know the difference between OpenGL and OpenGL ES, but Apple > claims hardware OpenGL ES acceleration for the new iPhone. Does this > mean that some subset of the 3D viewer code will be implementable on > the iPhone? > > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d4ed8ee6/attachment.htm From sldev at bitparts.org Mon Jun 9 16:41:38 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Mon Jun 9 16:41:44 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484DBFB2.4070801@bitparts.org> How about this, then - to the same thing we do now, storing the header in the binary cache, and the bulk of the data in a raw file - just change it from a (CPU-intensive) JPG2000 decode to a (CPU-cheap) TGA or whatever raw format the client uses inside the code? Or even if you just stored the first (arbitrary-number) of bytes in the textures.cache file, with the rest coming from the existant UUID-named file? The bottleneck, as I have demonstrated through the use of a RAMdisk cache folder, is definitely the decoding. -Buckaroo ps - 'scuse my top-posting, I know it's frowned on, but damnit, it just makes it easier to read. -b Jake Simpson wrote: > I'd just like to make the point that a lot of LL reads these threads > and we have lots of internal discussions about exactly stuff like > this. We have one currently going regarding a feature we are talking > about adding thats very much along these lines. > > "How far do we go to obstrufacate the data stream?" is the question. > > Bear in mind that some of the economy of Second Life is built upon > people being able to build and have some degree of confidence that > what they build won't get ripped off immediately by those who can, so > they can be sure of getting some return on their investment of time. > I'm sure you can understand how many in LL will be sympathetic to this > thinking. Sure, technically anything can be reversed engineered (save > scripts since they don't come to the client in any way) so the > question becomes "how hard do we make it?" (or even "how hard CAN we > make it?") - which is basically paraphrasing what's already been said > in this thread. Stating "Well, because it's possible, don't even > bother trying to stop it" doesn't (unfortunately) solve the issue of > "how can I protect what I make" which is the root cry of anyone who > spends time building things; it just undermines the Second Life > economy to the point where it might potentially not be viable, > obviously something people within in LL are keen to avoid. > > Please understand we are having the same discussions internally and > what is said here is taken on board by those making the internal > decisions, so keep at it. > > I'd like to rename this thread since it's quote a contentious name. > > Cheers > > Jake > From gbrandon at gmail.com Mon Jun 9 17:18:32 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Jun 9 17:18:35 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: On Mon, Jun 9, 2008 at 6:34 PM, Jake Simpson wrote: > Stating "Well, because it's possible, don't even bother trying to stop it" > doesn't (unfortunately) solve the issue of "how can I protect what I make" > which is the root cry of anyone who spends time building things; it just > undermines the Second Life economy to the point where it might potentially > not be viable, obviously something people within in LL are keen to avoid. The thing I worry about is people having the wrong idea. Which would you prefer: a. Go ahead and be like the web where people know they have to protect their own assets or b. Make people think it's LL's job to protect their assets, and make them angry at you when it turns out it doesn't work the way they thought? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/529fe54a/attachment-0001.htm From gigstaggart at gmail.com Mon Jun 9 17:23:31 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 17:23:34 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DBFB2.4070801@bitparts.org> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484DBFB2.4070801@bitparts.org> Message-ID: <484DC983.9030301@gmail.com> Buckaroo Mu wrote: > How about this, then - to the same thing we do now, storing the header > in the binary cache, and the bulk of the data in a raw file - just > change it from a (CPU-intensive) JPG2000 decode to a (CPU-cheap) TGA or It's definitely a possibility. The thing is, recompressing into another lossy format will lose some quality. If we are going to do that though, S3TC is probably the way to go, that's video card native. I've experimented with some rough patches to enable S3TC recompression, the loss in quality is noticeable, but not terrible. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/ffe10d89/smime.bin From lenglish5 at cox.net Mon Jun 9 17:28:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 17:28:42 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: References: <484DBAF7.9000308@cox.net> Message-ID: <484DCAB8.80100@cox.net> Dave Hillier wrote: > OpenGL ES is a subset of OpenGL. Its basically had all the > intermediate calls removed in favour of vertex arrays. > > There's been some cool stuff done with the iphone: someone ported > quake 3! http://www.youtube.com/watch?v=kvci1vTXyUo > Unfortunately I doubt its got enough power to run SL. > Maybe the old iPhone couldn't do it, but the new one? I'm pretty sure some reasonably robust subset of the current SL 3D graphcis will run at acceptable framerates. http://events.apple.com.edgesuite.net/0806wdt546x/event/index.html This kills, well, slaughters, a LOT of platforms, I think. $200 for the base model. Lawson From GordonWendt at gmail.com Mon Jun 9 18:08:32 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 18:08:35 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> Message-ID: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> With all due respect if you have linden after your name (Q Linden in this case) then you are going to be assumed to be speaking for LL every time you post anywhere, is it fair? no but that's life on a mailing list that the company you works for runs. On the topic of obscurity through obscurity it doesn't work, period. People can easily figure out that glintercept is at glintercept.nutty.org, anytime I post on the forums people see that since I link to it from my signature. To discourge piracy either go full out or leave it out in the open and make the platform allow people to implement their own solutions to this. -G.W. On Mon, Jun 9, 2008 at 5:36 PM, Kent Quirk (Q Linden) wrote: > > On Jun 9, 2008, at 5:22 PM, ordinal.malaprop@fastmail.fm wrote: > > >> On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote: >> >> Dante Tucker wrote: >>> >>>> Lets all just stop pretending anyone who wants to steal textures can't >>>> with the current system. Anyone who wants them can already get them. The >>>> only thing storing data raw would do is make them more accesable to people >>>> who don't want them and have no knoledge of how to get them currently. And >>>> if they don't want them then whats the harm? >>>> >>> Agreed. >>> >>> I tire of people moaning about IP security. >>> >>> Your stuff is already stolen, deal with it. >>> >>> ~Tom >>> >> >> Not to pick on Tom particularly here, but this is the sort of m message >> that reinforces my opinion that: >> >> (a) the people involved in discussing assets don't understand what those >> _creating_ the assets want or think; >> (b) they don't care. >> >> The level of snobbery applied here is breathtaking, endless references to >> pitchforks ho ho, you know, they're all irrational peasants. But even in the >> current situation, textures not being instantly obtainable by just going to >> the right directory and dragging to somewhere else is a disincentive to >> pirates. >> >> YES, we do all know about glintercept and all the other ways to get hold >> of textures. YES, we know that there is an intrinsic problem here, that >> displaying the damn assets implies that they are received by the client. >> YES, we've all heard these teenage extropian "information wants to be free" >> tropes, thanks all the same. >> >> Amazingly enough, people appreciate the practical issues. What they don't >> like is the idea that they are being treated as idiots and rubes by LL and >> assorted geeky types because they dare to get worried about the reason that >> they are there and building the world for you lot to play about with in the >> first place. Because, you know, if it wasn't for people who make content, >> you and I would not be here discussing this stuff, as I've said before. >> >> If you can't offer anything to content creators apart from "ha ha your >> stuff has already been stolen stupid n00bs" then you might as well close the >> whole company down right now. >> >> > Boy, I can totally see both sides of this argument. > > It's true -- if we're displaying it, it can be copied with a relatively > small amount of work for a motivated individual with technical skill. > > It's *also* true that if it's trivially easy to copy it, it will be copied > much more frequently than if it's slightly harder. This is why "security by > obscurity" is popular. The extra step makes it obvious that you're taking > some measure -- no matter how simple -- to break a protection scheme, and > that sense of an explicit violation does deter a lot of people. > > So while I completely agree that there's no way we can provide true > protection, I also agree that simply stuffing the files into a directory > using standard formats is kind of like leaving your bike unlocked in the > street -- someone will ride off with it who might not have bothered if you > used even a cheap bike lock. > > Personally (I'm not speaking for Linden here), I think that if we want to > change the way we do caching, we should make it slightly complicated to grab > items out of the cache by NOT storing them in standard formats. > > > Q > > _______________________________________________ > 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/20080609/05c72485/attachment.htm From secret.argent at gmail.com Mon Jun 9 18:16:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:14:48 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> Message-ID: <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> On 2008-06-09, at 13:11, Dahlia Trimble wrote: > I dont see why the requested functionality couldn't work with > existing channels, or am I missing something here? The intent was that the requested functionality would, in fact, use existing channels... not new connections. I'm not sure why the issue is even being brought up, to tell the truth. From GordonWendt at gmail.com Mon Jun 9 18:16:38 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 18:16:41 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <493033a70806091816v338d4565mcfb85a62537f9e07@mail.gmail.com> @Kent, to correct my phrasing slightly on the above post you may not be speaking as LL however by definition as an employee your statements still carry certain weight coming from someone from LL although I'll admit that's a very tricky distinction. @Jason, javascript protection of course is quite pointless since even a ten year old can bypass it, as is the same here if your sending data to somebody's computer it's impossible to protect unless you A) don't send it at all which defeats the purose, or B) have total control of the end system and the entire path from the beginning to the end, which is quite frankly impossible due to the nature of the internet, computing, not to mention that nobody will give up total control of their system and you'd need a different system run by each company that you have software from. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/151edc2a/attachment-0001.htm From secret.argent at gmail.com Mon Jun 9 18:19:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:17:48 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484D8605.4090200@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> Message-ID: On 2008-06-09, at 14:35, SignpostMarv Martin wrote, regarding Laurent's suggestion for a sim cache: > referenced by name or sim UUID ? I would think that since it's a cache it doesn't really matter. If the UUID is well distributed it could use it directly, or the sim name, or a hash of the sim name. It probably doesn't even matter much if there's sim name collisions. From secret.argent at gmail.com Mon Jun 9 18:22:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:21:01 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> Message-ID: <410A9BDF-B4EF-4BD3-87FD-4BD8AFBA6320@gmail.com> On 2008-06-09, at 16:22, ordinal.malaprop@fastmail.fm wrote: > If you can't offer anything to content creators apart from "ha ha > your stuff has already been stolen stupid n00bs" then you might as > well close the whole company down right now. I don't think I've seen that attitude from LL. From certain people, yes, but generally not the Lindens. And as I suggested in a previous message, an efficient cache with enough obfuscation to keep the honest honest is entirely possible. From secret.argent at gmail.com Mon Jun 9 18:30:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:29:12 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484DAFD9.6030009@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: If you use a raw format that's efficiently decoded by the client, with a header containing metadata, in an undocumented format with an undocumented size, then you'll have as much obscurity as you have now in a format that is perhaps bulkier but certainly will consume less CPU time to extract. And if you store the data by UUID or by a simple collision-free permutation of the UUID rather than going through VFS it should be possible to expand the texture cache on disk significantly. How far to go for obscurity? Only so far as it makes it easier to use GLintercept than to hack the cache. :) From secret.argent at gmail.com Mon Jun 9 18:46:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:45:03 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: On 2008-06-09, at 19:18, Brandon Lockaby wrote: > a. Go ahead and be like the web where people know they have to > protect their own assets The failure of so many web ventures, and the "dot bomb", suggests that the internet is not automatically the best model to follow. People do better work when they get rewarded. People are not capable of "protecting their own assets". The corollary of (a) is "eliminate a huge portion of the SL economy, and possibly go out of business". > b. Make people think it's LL's job to protect their assets, and > make them angry at you when it turns out it doesn't work the way > they thought? The corollary of (b) is "you always have angry customers, you have to learn to deal with them and where possible prevent the problems that they're angry about... it's part of the cost of staying in business." I've taken the opposite side of many of LL's decisions, and I still think they made a mistake removing large portions of the simulated economy in SL... it's caused a lot of problems, and led to a lot of bad behavior. I also don't approve of some changes in the fine details of the rights system, like enabling the creation of objects that can neither be copied or transferred. But I certainly can't complain about them being cautious about making changes that might remove the rest of the economic simulation by making everything too obviously free. Can you see a way to retain the Linden economy without people buying things in SL? From secret.argent at gmail.com Mon Jun 9 18:49:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 18:48:32 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> On 2008-06-09, at 20:08, Gordon Wendt wrote: > On the topic of obscurity through obscurity it doesn't work, period. Depends on what you mean by "working". It works well enough to make honest people treat a purchased object as having value. Does it need to work any better than that? All DRM schemes are no better than "honor system" deep. They work because most people don't need any more incentive than that. From robla at lindenlab.com Mon Jun 9 18:48:44 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 9 18:48:47 2008 Subject: [sldev] [POLICY] Devise better way to discuss hotbutton issues on sldev Message-ID: <484DDD7C.9090606@lindenlab.com> We have a tendency on the sldev mailing lists to have long threads that extend for a very long time, which seem irreconcilable. The current sldev posting guidelines aren't helping either (though perhaps that's only because people haven't been reminded, see: https://wiki.secondlife.com/wiki/SLDev ) Common hotbuttons: * IP address privacy. ** Discussed in JIRA here: SVC-241 ** Currently being replayed on sldev in the "Re: [sldev] Puppettering Branch" * What level of protection to put on in-world textures. ** Discussed in JIRA here: VWR-2909 ** Currently being replayed on sldev as "Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation" At a minimum, we have to do better at documenting the debate, perhaps with FAQs for each side of the discussion, so that at least we can pick up where we left off rather than starting from the beginning. I've filed this issue to discuss this problem: https://jira.secondlife.com/browse/MISC-1267 Please direct replies there rather than on-list. Thanks Rob From lenglish5 at cox.net Mon Jun 9 18:57:18 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jun 9 18:57:22 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <484DDF7E.9090306@cox.net> Gordon Wendt wrote: > With all due respect if you have linden after your name (Q Linden in > this case) then you are going to be assumed to be speaking for LL > every time you post anywhere, is it fair? no but that's life on a > mailing list that the company you works for runs. > > On the topic of obscurity through obscurity it doesn't work, period. > People can easily figure out that glintercept is at > glintercept.nutty.org , anytime I post > on the forums people see that since I link to it from my signature. > To discourge piracy either go full out or leave it out in the open and > make the platform allow people to implement their own solutions to this. > Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson From gbrandon at gmail.com Mon Jun 9 19:12:12 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Jun 9 19:12:15 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484DDF7E.9090306@cox.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <484DDF7E.9090306@cox.net> Message-ID: I think in the end we're just gonna see more tools that make it as easy to copy things as people want it to be. In that case it won't matter what kind of cache this viewer uses. I think if that doesn't happen it would be a result of SL falling out of favor as the world wide VW platform, or remaining what it is until a more robust one comes along. In summary, I believe if SL is successful, we will see tools come along that make these cache security decisions pointless. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/eea227d4/attachment-0001.htm From secret.argent at gmail.com Mon Jun 9 19:16:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 9 19:15:42 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484DBB87.90604@signpostmarv.name> References: <4d211a610806091551o74ea7208kb0ce0825d35d04da@mail.gmail.com> <484DBB87.90604@signpostmarv.name> Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > I believe it refers to http://www.massively.com/2008/05/29/high-end- > graphics-features-planned-for-second-life/ I don't think that will make it into RC10, or 1.21, or 1.22, ... From GordonWendt at gmail.com Mon Jun 9 19:16:55 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 19:16:58 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484DDF7E.9090306@cox.net> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <484DDF7E.9090306@cox.net> Message-ID: <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment.htm From soft at lindenlab.com Mon Jun 9 19:22:42 2008 From: soft at lindenlab.com (Soft) Date: Mon Jun 9 19:22:45 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? That's a long-term feature. No. The intent of the RC branch is that subsequent RCs at a given version number contain bug fixes only. From missannotoole at yahoo.com Mon Jun 9 20:08:01 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jun 9 20:08:04 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> Here is what some of the people on this list come across like: Let's say you have a town full of people worried about terrorists making home made bombs. Here comes a resident yelling obscenities at them, calling them stupid, yelling that there is nothing that can be done about it, and handing out flyers with instructions on how to make fertilizer bombs. Doesn't matter if it is right or wrong the behavior is antisocial and unacceptable. Thats the mentality I see going on. The professional nature of this list has vanished. I think LL needs to clean this list up and deal with it. The number of people causing problems is small and finite and I don't see much code or ideas coming from them. This list is an LL list and as such should fall under the TOS/CS and abusive behavior should be rewarded with suspensions from Secondlife and if it continues then the SL accounts be revoked. IMHO anyway. If obfuscation happens to be part of a new way to manage cache so more can be stored and the performance be improved then I'm all for it. However, the cache performance is what counts. The number of bytes being transferred is becoming critical. And may soon become very expensive. Can we return to finding ways to improve the cache now? ----- Original Message ---- From: Gordon Wendt To: Second Life Developer Mailing List Sent: Monday, June 9, 2008 10:16:55 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment.htm From GordonWendt at gmail.com Mon Jun 9 20:22:32 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Jun 9 20:22:35 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <988916.32450.qm@web59107.mail.re1.yahoo.com> References: <988916.32450.qm@web59107.mail.re1.yahoo.com> Message-ID: <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> Apologies to Ann for the double post since gmail at least automatically wants to send it directly to whoever sent the original message to the list. If you would like to skip to my ontopic comments on this conversation please skip to the second paragraph. @Ann Ironically you just displayed the same behavior you said should be banned and I take great offense at you comparing people who disagree with you on the topic of obsfucating information to terrorists. Other than your post here attacking other resident's directly I don't see any personal attacks just attacks on each other's arguments which is the nature of such discourse when not everybody agrees. Incidentally it seems so far that LL knows that off topic conversations and arguments go on in the list and as long as the main conversation goes along and as long as they are quick and not overly disruptive these arguments seem to be overlooked... this is just from my experience so far and Rob and the other list admins take action as they see fit without much regard to precedent. On the topic of the issue though since this really is getting off topic I'm sure there is some middleground in terms of performance but it seems like high performance would require changing the fundamental way that images are sent, recieved, and dealt with by the server and client respectively although I'd be interested if LL or anyone else has data on where the slowest parts of the process are since I'm not sure we know for sure that encoding is where the bottleneck is although that is unfortunately the only part that can really be directly seen except by LL since we don't know what goes on serverside. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment.htm From schlenk at uni-oldenburg.de Mon Jun 9 23:00:48 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Mon Jun 9 23:00:43 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> References: <58B57F91-EB8C-4B05-AAD4-3235759A0083@gmail.com> Message-ID: <484E1890.1080604@uni-oldenburg.de> Argent Stonecutter schrieb: > On 2008-06-09, at 02:22, Dale Mahalko wrote: >> A move to a local MySQL database > > God no. > > sqlite, please. Without all the MySQL "I'm pretending to be a real > database engine" overhead. SQLites pretty good for some stuff, but caching blob data is not one of it due to the required frequent fsync() calls needed to maintain transactions. (just see the current discussion around Firefox 3 being very slow on Ubuntu). But MySQL is an even worse idea... I had to write a heavily parallel (targeting some 1000 parallel writing threads) blob storage system for a different application and using SQLite, even only for storing the metadata leads to heavy lock contention and made the system far less scalable. Current filesystems like NTFS or ext3 are pretty okay for storing files and metadata, they are made for that kind of usecase..., its even faster to do a stat() on disk than to lookup stuff in sqlite in most cases. Michael From gigstaggart at gmail.com Mon Jun 9 23:34:11 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 23:34:15 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484E2063.20806@gmail.com> Argent Stonecutter wrote: > The corollary of (a) is "eliminate a huge portion of the SL economy, > and possibly go out of business". Yes, because the entire economy collapsed the day after copybot came out. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/62bc0b25/smime.bin From gigstaggart at gmail.com Mon Jun 9 23:37:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 9 23:37:12 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> Message-ID: <484E2114.5000902@gmail.com> Argent Stonecutter wrote: > All DRM schemes are no better than "honor system" deep. They work > because most people don't need any more incentive than that. Yes, exactly. Which is why we do not need to add additional complexity and bugs, and inconvenience for legitimate users by adding them at all. Most people are honest, and most people will remain honest. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/6e4a9aa9/smime.bin From tateru.nino at gmail.com Tue Jun 10 00:29:15 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 00:30:03 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <6CB1EC62-3B8A-47E1-B8D6-44D85D5ADD98@gmail.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> Message-ID: <484E2D4B.2010407@gmail.com> I've just checked 3 WinXP systems (two with SP2 and one with SP3) and the registry settings for wininet for HTTP/1.0 and HTTP/1.1 connections are set to 0xa (10) on all of them. That's HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. Teravus Ovares wrote: > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it appears > that it does. When two threads get stuck, it fails to do anything > else via http. We've tried to use HTTP CAPS for inventory, and > consistently, when the inventory service runs slow, the client stops > making *any* further http requests. > > Best Regards > > Teravus > > > On 6/9/08, *Tateru Nino* > wrote: > > Actually it is not a mandate. A mandate would be a MUST NOT. This > is a SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 connections > with any server or proxy. A proxy SHOULD use up to 2*N connections > to another server or proxy, where N is the number of > simultaneously active users." > > I've got personal knowledge that the author did not intend the > above to apply to situations like this. For the substrate to MSIE, > however, it is entirely appropriate. Also, the above only applies > to persistent connections, not non-persistent connections > (applying the same guideline to non-persistent connections would > cause problems that this guideline is intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the > Web, and connection considerations in Web architecture over HTTP > are different to other architectures over HTTP. > > > > > > Teravus Ovares wrote: > > I also note, that according to Microsoft's kb article: > "The HTTP 1.1 specification (RFC2616) mandates the > two-connection limit. The four-connection limit for HTTP 1.0 > is a self-imposed restriction that coincides with the standard > that is used by a number of popular Web browsers." > You can read the article here: > http://support.microsoft.com/kb/183110 > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > Best Regards > Teravus > > From secret.argent at gmail.com Tue Jun 10 00:46:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 00:45:17 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484E2063.20806@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: On 2008-06-10, at 01:34, Jason Giglio wrote: > Argent Stonecutter wrote: >> The corollary of (a) is "eliminate a huge portion of the SL economy, >> and possibly go out of business". > > Yes, because the entire economy collapsed the day after copybot > came out. Don't be silly. If copybot had not been broken, incomplete, and horribly inconvenient, if it been built into the standard client, with right click "show source" and "save as" that worked like "show source" and "save as" in a browser (because that IS what "treat it like the web" implies) in a browser and let you trivially grab all prims and assets in a convenient form for uploading as your own product, then... yes... it likely would have. From secret.argent at gmail.com Tue Jun 10 00:50:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 00:49:19 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484E2114.5000902@gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <4CF8FAB0-0F79-4F98-A230-D0DE44C2CC17@gmail.com> <484E2114.5000902@gmail.com> Message-ID: On 2008-06-10, at 01:37, Jason Giglio wrote: > Argent Stonecutter wrote: >> All DRM schemes are no better than "honor system" deep. They work >> because most people don't need any more incentive than that. > > Yes, exactly. Which is why we do not need to add additional > complexity > and bugs, Which is not what I'm suggesting. > Most people are honest, and most people will remain honest. Most people are pretty honest. Most people will remain pretty honest as long as that's the easy way. But when I drive the speed limit pretty much everyone passes me, and most people don't bother donating to the building fund but will buy a ticket to the museum, so long as there's someone at the door taking tickets. From lenglish5 at cox.net Tue Jun 10 00:53:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 00:53:21 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> References: <48473027.9090101@lindenlab.com> <484B1E01.1010800@cox.net> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091047k3ffa5fb6g397fc39146c83a9a@mail.gmail.com> <3C0C54B3-98F0-4986-B761-DC8B6870375F@gmail.com> Message-ID: <484E32ED.2080605@cox.net> Argent Stonecutter wrote: > On 2008-06-09, at 13:11, Dahlia Trimble wrote: >> I dont see why the requested functionality couldn't work with >> existing channels, or am I missing something here? > > The intent was that the requested functionality would, in fact, use > existing channels... not new connections. I'm not sure why the issue > is even being brought up, to tell the truth. > > _ Cause I'm an ijit? Lawson From lenglish5 at cox.net Tue Jun 10 01:02:44 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:02:48 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: <484E3524.6040008@cox.net> Argent Stonecutter wrote: > On 2008-06-10, at 01:34, Jason Giglio wrote: >> Argent Stonecutter wrote: >>> The corollary of (a) is "eliminate a huge portion of the SL economy, >>> and possibly go out of business". >> > >> Yes, because the entire economy collapsed the day after copybot came >> out. > > Don't be silly. If copybot had not been broken, incomplete, and > horribly inconvenient, if it been built into the standard client, with > right click "show source" and "save as" that worked like "show source" > and "save as" in a browser (because that IS what "treat it like the > web" implies) in a browser and let you trivially grab all prims and > assets in a convenient form for uploading as your own product, then... > yes... it likely would have. > > _ There's no provision in the average browser for extracting and then republishing content on the same website you extracted it from in the first place. Certainly not with the possibility of getting paid right then and there if you do it. Many of the technical details of SL fit or can be made to fit the web, but the social/interaction details are quite different, IMHO. Lawson From gbrandon at gmail.com Tue Jun 10 01:20:05 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Tue Jun 10 01:20:08 2008 Subject: [sldev] Security issues/Thank you/Congratulations Message-ID: When I first started digging into the SL protocol, it seemed like just about everything I tried to do uncovered a security issue. For awhile I thought we were just doomed, I mean it :D Alot of you who work with the protocol surely know the sort of thing I'm talking about! But right now I'm breathing a sigh of relief because from my point of view, things have been changing fast! Granted, there are still issues, and I'm sure they won't dry up just yet as I see an increasing number of people deciding to work with the protocol lately, but as of now I can honestly say I don't know a way to crash the official viewer or ruin someone's business just by using the intended client/server protocols on LL's grid. So I want to thank Linden Lab for responding so well to security issues, and say congratulations! As far as I'm concerned the response to these issues is stellar. And I want to extend thanks to everyone who makes an effort to report security issues. I know many of these people are probably nervous about talking publically about the things they've seen but they deserve some recognition. Well here is a huge THANK YOU to EVERYONE involved in helping improve Second Life in this very important way! :D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cd567181/attachment.htm From lenglish5 at cox.net Tue Jun 10 01:22:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:22:28 2008 Subject: [sldev] [AWG] AW Groupies meeting Tuesday. Topic: Dawn of the virtual worlds internet Message-ID: <484E39BC.8010405@cox.net> Tuesday, 10 June 2008, 9:30 AM AW Groupies meeting. Topics for discussion will likely include: * last week's successful login using the Second Life development server to rez an avatar in an OpenSim region. This is relatively minor technical step away from TP between SL and OpenSim (after that comes the hard part: trying to get the social/economic stuff right). http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ * possibly more info on the new Python-based test-harness based on the new protocols used above. http://wiki.secondlife.com/wiki/AWG_Test_Harness As always, IM Zha Ewry, Tree Kyomoon or Saijanai Kuhn in-world for a group invite to get to the AW Groupies meeting. AW Groupies is the [generally very techno-geek] in-world discussion group for the Architecture Working Group, a collaboration between Linden Lab, IBM, libsecondlife, OpenSim, and others, to create system of virtual worlds that can inter-operate with each other using an open system of internet protocols. http://wiki.secondlife.com/wiki/Architecture_Working_Group http://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs Lawson (Saijanai Kuhn) From lenglish5 at cox.net Tue Jun 10 01:39:00 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 01:39:03 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <484E3DA4.7020801@cox.net> Soft wrote: > On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > >> http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html >> >> Is this going to make it into rc10? >> > > That's a long-term feature. No. > > The intent of the RC branch is that subsequent RCs at a given version > number contain bug fixes only. > _______________________________________________ > Intent yes, reality? ;-) Lawson From me at signpostmarv.name Tue Jun 10 02:43:27 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:43:30 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> Message-ID: <484E4CBF.5060203@signpostmarv.name> Q Linden wrote: > Personally (I'm not speaking for Linden here), I think that if we want > to change the way we do caching, we should make it slightly > complicated to grab items out of the cache by NOT storing them in > standard formats. Jason Giglio wrote: > It's definitely a possibility. The thing is, recompressing into another > lossy format will lose some quality. > > If we are going to do that though, S3TC is probably the way to go, > that's video card native. Argent Stonecutter wrote: > If you use a raw format that's efficiently decoded by the client, with > a header containing metadata, in an undocumented format with an > undocumented size, then you'll have as much obscurity as you have now > in a format that is perhaps bulkier but certainly will consume less > CPU time to extract. If a non-standard format is used, it'll only be useful in the short term. 1) Code gets released 2) Code is either documented or becomes documented 3) Wide adoption of Second Life makes said non-standard format become de-facto standard for virtual worlds. A standard image codec that is "native" to OpenGL encapsulated in a container format which allows metadata to be embedded that is either standardised but traditionally unrelated to 3D software assets (Ogg ?) or a proprietary non-standard format would seem preferable to using a non-standard image format. Not that I am likely to develop software that would use such a system, but I would think that using unrelated standardised container/codec formats would still have a security-through-obscurity edge, since although all the tools for working with the individual formats are out there, people would have to scratch their heads while they figure out how to glue them together (unless working directly with the SL source code, which would be intended for loading assets into a 3D environment, not viewing/editing said assets via an image editor) ~ Marv -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/1eaa6cc2/smime.bin From me at signpostmarv.name Tue Jun 10 02:55:15 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:55:16 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484DCAB8.80100@cox.net> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> Message-ID: <484E4F83.7000402@signpostmarv.name> Lawson English wrote: > Maybe the old iPhone couldn't do it, but the new one? I'm pretty sure > some reasonably robust subset of the current SL 3D graphcis will run > at acceptable framerates. Is having the exact same experience necessary at "acceptable" framerates even necessary ? Why not go a different route with an iPhone client, and just have a cut-down IM client that has a 3D background ? Taking a cue from SLeek's interface, only give iPhone users the option to "move avatar to landing point" "touch objects with touch_events or left-click configs" and "sit on object with sit target or left-click config for sitting". At least initially, trying to do *everything* you do in SL on a desktop/laptop computer on a portable device would just seem rather..... stupid ? While it's conceivable you could build something via an iPhone (multi-touch rescale & rotate anyone ? ), I'd imagine that content-creators are likely to prefer desktop/laptop computing environments, and that portable devices such as the iPhone would be best suited to the content-consumer crowd. Since the frame rate on the iPhone may be low till the view can be optimised, rather than try to mirror the experience on a portable device, why not just give the option to (focus on object/avatar) with basic pan/rotate/zoom controls ? Exploring an environment in the traditional way (e.g. walking/flying around) may be too cumbersome to do on a portable device (either due to confined interface space or low-framerates), so why not have portable device viewers focus on how people explore when under heavy lag- move the camera, not the avatar ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d64efb03/smime-0001.bin From me at signpostmarv.name Tue Jun 10 02:57:32 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 02:57:35 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484E3DA4.7020801@cox.net> References: <484E3DA4.7020801@cox.net> Message-ID: <484E500C.4060400@signpostmarv.name> Since the Shadow branch is restricted to GeForce 8 GPUs only, it would make more sense to release it as a First Look viewer, not an RC. ~ Marv. Lawson English wrote: > Soft wrote: >> On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands >> wrote: >> >>> Is this going to make it into rc10? >> That's a long-term feature. No. >> >> The intent of the RC branch is that subsequent RCs at a given version >> number contain bug fixes only. >> _______________________________________________ >> > Intent yes, reality? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/7107d6a6/smime.bin From lenglish5 at cox.net Tue Jun 10 03:08:01 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 03:08:03 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <484E5281.8050102@cox.net> SignpostMarv Martin wrote: > > Lawson English wrote: >> Maybe the old iPhone couldn't do it, but the new one? I'm pretty >> sure some reasonably robust subset of the current SL 3D graphcis will >> run at acceptable framerates. > > Is having the exact same experience necessary at "acceptable" > framerates even necessary ? > > Why not go a different route with an iPhone client, and just have a > cut-down IM client that has a 3D background ? > > Taking a cue from SLeek's interface, only give iPhone users the option > to "move avatar to landing point" "touch objects with touch_events or > left-click configs" and "sit on object with sit target or left-click > config for sitting". > > At least initially, trying to do *everything* you do in SL on a > desktop/laptop computer on a portable device would just seem > rather..... stupid ? > While it's conceivable you could build something via an iPhone > (multi-touch rescale & rotate anyone ? ), I'd imagine that > content-creators are likely to prefer desktop/laptop computing > environments, and that portable devices such as the iPhone would be > best suited to the content-consumer crowd. > > Since the frame rate on the iPhone may be low till the view can be > optimised, rather than try to mirror the experience on a portable > device, why not just give the option to (focus on object/avatar) with > basic pan/rotate/zoom controls ? Exploring an environment in the > traditional way (e.g. walking/flying around) may be too cumbersome to > do on a portable device (either due to confined interface space or > low-framerates), so why not have portable device viewers focus on how > people explore when under heavy lag- move the camera, not the avatar ? > Its a thought, and I don't know how the iPhone 2 will perform, but looking at the console games demos, I wouldn't be surprised if a properly designed SL client couldn't be usable even in 3D. Certainly, the [eventual] Python test harness library could be adapted for use on the iPhone and give Sleek-like capabilities. Would need to be rewritten in ObjC of course. Lawson From me at signpostmarv.name Tue Jun 10 03:42:54 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 03:42:55 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> Message-ID: <484E5AAE.5030507@signpostmarv.name> Argent Stonecutter wrote: > On 2008-06-09, at 14:35, SignpostMarv Martin wrote, regarding > Laurent's suggestion for a sim cache: >> referenced by name or sim UUID ? > > I would think that since it's a cache it doesn't really matter. If the > UUID is well distributed it could use it directly, or the sim name, or > a hash of the sim name. It probably doesn't even matter much if > there's sim name collisions. Clarification: VFS references, or LLSD list of assets UUIDs ? Problem 1) Sim gets renamed. Does the UUID stay the same ? Use case: metaverse development company X gets hired to develop a sim for company Y. company X owns the sim while the work is being done (with an inconspicuous name so as to avoid PR issues), company X then transfers ownership of sim to company Y. Company Y has name of sim changed. No assets within the sim are changed. Problem 2) beta grid vs main grid (and LL's SL vs OpenSim). Use case: aside from visitors, region A is identical on both grids. region B has a few differences (one or two buildings weren't yet erected at the time the beta grid snapshot was made). region C is completely different- few if none identical assets. Problem 3) region being withdrawn. Use case: short term events, like Burning Life/ SL Birthday With problem 1, if the cache is references by name, then you just duplicated your effort. if the cache references by UUID, then the region UUID should remain the same, lest the same duplicated effort issue crops up. With problem 2, in case C, you'll have the cache reference bloat to twice the size it needs to be. Garbage collection: Problem 2) If regions have the same identifier, when the viewer connects to one grid then the other, you'll either have twice the amount of assets loaded than is needed, or you'll have half of the assets going missing and needing to re-download. If identical sims on seperate grids have the same content, but different UUIDs, should such region-based caching make allowances for that ? Also, because of case C in problem 2, such a region-based referencing mechanism should probably have the grid the region is attached to as a root reference. Problem 3) Assuming the grid-based root reference is in place, I shall illustrate a conversation between the viewer and server that solves problem 3: Viewer) (upon login) "Does region x exist within the grid ?" Server) "Yes" (load/fetch referenced assets). "No" (remove region reference files) The server's response of "Yes"/"No" should not be based upon credentials (e.g. whether or not a Resident can access the given region should not be taken into account). ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/caef6888/smime.bin From aimee at ama-zing.co.uk Tue Jun 10 03:57:47 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jun 10 03:57:53 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <82890598-11BF-4F3D-8FCA-861AE11E6443@ama-zing.co.uk> Vollee has a vaguely usable SL client "running" (I think they're cheating and just streaming the video from elsewhere) on various phones including the iPhone. It's not perfect, but the couple of times I've tried it on my N95 it wasn't _too_ painful, it at least served the purpose of getting in world, moving around a bit and talking to people. http://rblog.rezmagazine.co.uk/2008/06/second-life-on-move.html Aimee, On Jun 10, 2008, at 10:55, SignpostMarv Martin wrote: > > Lawson English wrote: >> Maybe the old iPhone couldn't do it, but the new one? I'm pretty >> sure some reasonably robust subset of the current SL 3D graphcis >> will run at acceptable framerates. > > Is having the exact same experience necessary at "acceptable" > framerates even necessary ? > > Why not go a different route with an iPhone client, and just have a > cut-down IM client that has a 3D background ? From secret.argent at gmail.com Tue Jun 10 04:27:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 04:25:50 2008 Subject: [sldev] How Far For Security? In-Reply-To: <484E4CBF.5060203@signpostmarv.name> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E4CBF.5060203@signpostmarv.name> Message-ID: <6DB48EB5-E112-4838-A65F-FFA73A06A3C0@gmail.com> On 2008-06-10, at 04:43, SignpostMarv Martin wrote: > If a non-standard format is used, it'll only be useful in the short > term. An effectively non-standard format is all that's "protecting" the cache now, and it's been useful for some years. And there's no reason to standardize the local on-disk cache format, or for any third part software to use the same format. It's completely internal. From secret.argent at gmail.com Tue Jun 10 04:37:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 10 04:36:33 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484E5AAE.5030507@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> <484E5AAE.5030507@signpostmarv.name> Message-ID: <556FCFBD-F18E-4141-AF13-825BBD9DBA66@gmail.com> On 2008-06-10, at 05:42, SignpostMarv Martin wrote: > Clarification: VFS references, or LLSD list of assets UUIDs ? I don't think VFS should even be in the loop for textures. The texture cache would be simply /xx/yy/zz/xxyyzzaabbccddee... where xxyyzzaabbccddee is a UUID or a unique permutation of a UUID. > Problem 1) Sim gets renamed. Does the UUID stay the same ?\ Who cares? It's a cache. For a few minutes you'll have preloaded the wrong textures, *once*, before throwing them away. At worst you'll be no worse off than you are now. The situations you're describing are rare, and at worst simply cause some wasted local copies, once, or you'll throw away some cached data you might want to keep, once. In all these cases you're If it turns out that grid matters, then you add an additional level for the grid. It doesn't matter if it invalidates existing cache when you add the extra level, it's a cache. From teravus at gmail.com Tue Jun 10 04:39:05 2008 From: teravus at gmail.com (Teravus Ovares) Date: Tue Jun 10 04:39:06 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <484E2D4B.2010407@gmail.com> References: <48473027.9090101@lindenlab.com> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> <484E2D4B.2010407@gmail.com> Message-ID: <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> *Tateru Nino* Interesting, because I have four fully patched WinXP systems that don't have the registry values at all. There's a discrepancy there, do you regularly apply registry hacks? Best Regards Teravus On 6/10/08, Tateru Nino wrote: > > I've just checked 3 WinXP systems (two with SP2 and one with SP3) and the > registry settings for wininet for HTTP/1.0 and HTTP/1.1 connections are set > to 0xa (10) on all of them. > That's HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet > Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. > > Teravus Ovares wrote: > >> Can anyone confirm that the client does not use a library that respects >> this 2 connection limitation? So far in testing, it appears that it does. >> When two threads get stuck, it fails to do anything else via http. >> We've tried to use HTTP CAPS for inventory, and consistently, when the >> inventory service runs slow, the client stops making *any* further http >> requests. >> Best Regards >> Teravus >> >> On 6/9/08, *Tateru Nino* > tateru.nino@gmail.com>> wrote: >> >> Actually it is not a mandate. A mandate would be a MUST NOT. This >> is a SHOULD NOT, specifically: >> "A single-user client SHOULD NOT maintain more than 2 connections >> with any server or proxy. A proxy SHOULD use up to 2*N connections >> to another server or proxy, where N is the number of >> simultaneously active users." >> >> I've got personal knowledge that the author did not intend the >> above to apply to situations like this. For the substrate to MSIE, >> however, it is entirely appropriate. Also, the above only applies >> to persistent connections, not non-persistent connections >> (applying the same guideline to non-persistent connections would >> cause problems that this guideline is intended to avoid). >> >> Just because you're doing HTTP, doesn't make you a part of the >> Web, and connection considerations in Web architecture over HTTP >> are different to other architectures over HTTP. >> >> >> >> >> >> Teravus Ovares wrote: >> >> I also note, that according to Microsoft's kb article: >> "The HTTP 1.1 specification (RFC2616) mandates the >> two-connection limit. The four-connection limit for HTTP 1.0 >> is a self-imposed restriction that coincides with the standard >> that is used by a number of popular Web browsers." >> You can read the article here: >> http://support.microsoft.com/kb/183110 >> You can read the RFC here: >> http://www.faqs.org/rfcs/rfc2616.html >> Best Regards >> Teravus >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/938f5e1e/attachment.htm From ravenglassrentals at yahoo.com Tue Jun 10 05:11:38 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Jun 10 05:11:42 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <20080610060041.C849741B41B@stupor.lindenlab.com> Message-ID: <827605.10646.qm@web55601.mail.re4.yahoo.com> Second Life is not a web browser. It is a world. It is a world with an economy based on intellectual property and real property rights. If you want a web browser, go outside to the Internet; if you want a world with people in it, and not merely a abstract platformist sandbox, you will have to accommodate the needs of non-scripters and non-coders who make up the business people supporting the costs of this platform and making a profit for the platform providers. The concept that right-clicking thereby enables stealing of proprietary images and codes everywhere else on the Internet is false, and a tendentious reading along the extremist Stallmanite lines. Any discussion of obfuscation should be reviewed on its merits, in good faith, both to determine whether it assists in the matter of copyright theft and preserving the integrity of the original permissions system, and also with a view to functionality and scaling. sldev-request@lists.secondlife.com wrote: Send SLDev mailing list submissions to sldev@lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request@lists.secondlife.com You can reach the person managing the list at sldev-owner@lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. Re: Shadow Patch? (Argent Stonecutter) 2. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Gordon Wendt) 3. Re: Shadow Patch? (Soft) 4. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Ann Otoole) 5. Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation (Gordon Wendt) 6. Re: Cache politics: performance vs obfuscation (Michael Schlenker) ---------------------------------------------------------------------- Message: 1 Date: Mon, 9 Jun 2008 21:16:52 -0500 From: Argent Stonecutter Subject: Re: [sldev] Shadow Patch? To: Second Life Developer Mailing List Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > I believe it refers to http://www.massively.com/2008/05/29/high-end- > graphics-features-planned-for-second-life/ I don't think that will make it into RC10, or 1.21, or 1.22, ... ------------------------------ Message: 2 Date: Mon, 9 Jun 2008 22:16:55 -0400 From: "Gordon Wendt" Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: "Second Life Developer Mailing List" Message-ID: <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment-0001.htm ------------------------------ Message: 3 Date: Mon, 9 Jun 2008 21:22:42 -0500 From: Soft Subject: Re: [sldev] Shadow Patch? To: "Brandon Husbands" Cc: Second Life Developer Mailing List Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? That's a long-term feature. No. The intent of the RC branch is that subsequent RCs at a given version number contain bug fixes only. ------------------------------ Message: 4 Date: Mon, 9 Jun 2008 20:08:01 -0700 (PDT) From: Ann Otoole Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: Second Life Developer Mailing List Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Here is what some of the people on this list come across like: Let's say you have a town full of people worried about terrorists making home made bombs. Here comes a resident yelling obscenities at them, calling them stupid, yelling that there is nothing that can be done about it, and handing out flyers with instructions on how to make fertilizer bombs. Doesn't matter if it is right or wrong the behavior is antisocial and unacceptable. Thats the mentality I see going on. The professional nature of this list has vanished. I think LL needs to clean this list up and deal with it. The number of people causing problems is small and finite and I don't see much code or ideas coming from them. This list is an LL list and as such should fall under the TOS/CS and abusive behavior should be rewarded with suspensions from Secondlife and if it continues then the SL accounts be revoked. IMHO anyway. If obfuscation happens to be part of a new way to manage cache so more can be stored and the performance be improved then I'm all for it. However, the cache performance is what counts. The number of bytes being transferred is becoming critical. And may soon become very expensive. Can we return to finding ways to improve the cache now? ----- Original Message ---- From: Gordon Wendt To: Second Life Developer Mailing List Sent: Monday, June 9, 2008 10:16:55 PM Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone. That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source. You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled. -G.W. On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: Eh, the middle way is best, I think. Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not. In my non-legal view, of course. Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment-0001.htm ------------------------------ Message: 5 Date: Mon, 9 Jun 2008 23:22:32 -0400 From: "Gordon Wendt" Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation To: "Second Life Developer Mailing List" Message-ID: <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Apologies to Ann for the double post since gmail at least automatically wants to send it directly to whoever sent the original message to the list. If you would like to skip to my ontopic comments on this conversation please skip to the second paragraph. @Ann Ironically you just displayed the same behavior you said should be banned and I take great offense at you comparing people who disagree with you on the topic of obsfucating information to terrorists. Other than your post here attacking other resident's directly I don't see any personal attacks just attacks on each other's arguments which is the nature of such discourse when not everybody agrees. Incidentally it seems so far that LL knows that off topic conversations and arguments go on in the list and as long as the main conversation goes along and as long as they are quick and not overly disruptive these arguments seem to be overlooked... this is just from my experience so far and Rob and the other list admins take action as they see fit without much regard to precedent. On the topic of the issue though since this really is getting off topic I'm sure there is some middleground in terms of performance but it seems like high performance would require changing the fundamental way that images are sent, recieved, and dealt with by the server and client respectively although I'd be interested if LL or anyone else has data on where the slowest parts of the process are since I'm not sure we know for sure that encoding is where the bottleneck is although that is unfortunately the only part that can really be directly seen except by LL since we don't know what goes on serverside. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment-0001.htm ------------------------------ Message: 6 Date: Tue, 10 Jun 2008 08:00:48 +0200 From: Michael Schlenker Subject: Re: [sldev] Cache politics: performance vs obfuscation To: Argent Stonecutter Cc: Second Life Developer Mailing List Message-ID: <484E1890.1080604@uni-oldenburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Argent Stonecutter schrieb: > On 2008-06-09, at 02:22, Dale Mahalko wrote: >> A move to a local MySQL database > > God no. > > sqlite, please. Without all the MySQL "I'm pretending to be a real > database engine" overhead. SQLites pretty good for some stuff, but caching blob data is not one of it due to the required frequent fsync() calls needed to maintain transactions. (just see the current discussion around Firefox 3 being very slow on Ubuntu). But MySQL is an even worse idea... I had to write a heavily parallel (targeting some 1000 parallel writing threads) blob storage system for a different application and using SQLite, even only for storing the metadata leads to heavy lock contention and made the system far less scalable. Current filesystems like NTFS or ext3 are pretty okay for storing files and metadata, they are made for that kind of usecase..., its even faster to do a stat() on disk than to lookup stuff in sqlite in most cases. Michael ------------------------------ _______________________________________________ SLDev mailing list SLDev@lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 18, Issue 66 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/ba904ff2/attachment-0001.htm From q at lindenlab.com Tue Jun 10 06:07:40 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue Jun 10 06:07:46 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> Message-ID: <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> On Jun 9, 2008, at 9:08 PM, Gordon Wendt wrote: > With all due respect if you have linden after your name (Q Linden in > this case) then you are going to be assumed to be speaking for LL > every time you post anywhere, is it fair? no but that's life on a > mailing list that the company you works for runs. Yes, sure. All I meant (and it was badly phrased, I admit) was that I'm not trying to say that what I think is what LL as a whole thinks or will do. I'm trying to have a conversation here, and I didn't want my evolving thinking to be perceived as any firm indication of what LL will necessarily do. I'm only one of many. Q From kwerks.sl at gmail.com Tue Jun 10 07:38:19 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 07:38:23 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <827605.10646.qm@web55601.mail.re4.yahoo.com> References: <20080610060041.C849741B41B@stupor.lindenlab.com> <827605.10646.qm@web55601.mail.re4.yahoo.com> Message-ID: <7b61e3970806100738p7b2f1dbcncf2d14bd06928fa7@mail.gmail.com> On Tue, Jun 10, 2008 at 8:11 AM, Random Unsung wrote: > Second Life is not a web browser. It is a world. It is a world with an > economy based on intellectual property and real property rights. If you want > a web browser, go outside to the Internet; if you want a world with people > in it, and not merely a abstract platformist sandbox, you will have to > accommodate the needs of non-scripters and non-coders who make up the > business people supporting the costs of this platform and making a profit > for the platform providers. > > The concept that right-clicking thereby enables stealing of proprietary > images and codes everywhere else on the Internet is false, and a tendentious > reading along the extremist Stallmanite lines. > > Any discussion of obfuscation should be reviewed on its merits, in good > faith, both to determine whether it assists in the matter of copyright theft > and preserving the integrity of the original permissions system, and also > with a view to functionality and scaling. > > *sldev-request@lists.secondlife.com* wrote: > > Send SLDev mailing list submissions to > sldev@lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > or, via email, send a message with subject or body 'help' to > sldev-request@lists.secondlife.com > > You can reach the person managing the list at > sldev-owner@lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SLDev digest..." > > > Today's Topics: > > 1. Re: Shadow Patch? (Argent Stonecutter) > 2. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Gordon Wendt) > 3. Re: Shadow Patch? (Soft) > 4. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Ann Otoole) > 5. Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation (Gordon Wendt) > 6. Re: Cache politics: performance vs obfuscation (Michael Schlenker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Jun 2008 21:16:52 -0500 > From: Argent Stonecutter > Subject: Re: [sldev] Shadow Patch? > To: Second Life Developer Mailing List > Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901@gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > On 2008-06-09, at 18:23, SignpostMarv Martin wrote: > > I believe it refers to http://www.massively.com/2008/05/29/high-end- > > graphics-features-planned-for-second-life/ > > I don't think that will make it into RC10, or 1.21, or 1.22, ... > > > > > ------------------------------ > > Message: 2 > Date: Mon, 9 Jun 2008 22:16:55 -0400 > From: "Gordon Wendt" > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: "Second Life Developer Mailing List" > Message-ID: > <493033a70806091916i6715e064kfd0efdd2045be2d2@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Irrational statements like what I keep seeing on this list are exactly why > an idiotic proposal like SVC-1919 was passed to remove UUID information > from > the viewer, just because things like showing a texture UUID in the GUI can > be used for nefarious purposes wasn't and isn't a reason to cripple the > client, doubly so when it can be easily undone. That's why there are no > copies of Mozilla Firefox (an open source web browser for those who don't > know) without right shift save image functionality or without the option to > view web page source. You don't see people whining and moaning about their > web page source being publicly available yet people want SL to be crippled > in the same way they'd want a web browser to be crippled. > > -G.W. > > On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > > > > Eh, the middle way is best, I think. > > > > Don't support things against the TOS via the SL viewer GUI, at the very > > least. Beyond that, minor obfuscation that requires a potential thief to > > have more technical understanding of what is going on than merely > accessing > > things via the standard MacOS/WIndows file GUI should be sufficient to > offer > > legal protection to content creators. Any protection BEOND that, will > > require more work on the content creator. A 3rd party solution to grab > > textures as they are uploaded and run them through signature/watermarking > > before forwarding them to LL, might be an option. No doubt there are > others, > > but for content creators, even slight obfuscation should offer legal > > protection. No obfuscation whatsoever, might not. > > > > In my non-legal view, of course. > > > > > > Lawson > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Mon, 9 Jun 2008 21:22:42 -0500 > From: Soft > Subject: Re: [sldev] Shadow Patch? > To: "Brandon Husbands" > Cc: Second Life Developer Mailing List > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands wrote: > > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > > > Is this going to make it into rc10? > > That's a long-term feature. No. > > The intent of the RC branch is that subsequent RCs at a given version > number contain bug fixes only. > > > ------------------------------ > > Message: 4 > Date: Mon, 9 Jun 2008 20:08:01 -0700 (PDT) > From: Ann Otoole > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: Second Life Developer Mailing List > Message-ID: <988916.32450.qm@web59107.mail.re1.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > Here is what some of the people on this list come across like: > > Let's say you have a town full of people worried about terrorists making > home made bombs. > Here comes a resident yelling obscenities at them, calling them stupid, > yelling that there is nothing that can be done about it, and handing out > flyers with instructions on how to make fertilizer bombs. > Doesn't matter if it is right or wrong the behavior is antisocial and > unacceptable. > > Thats the mentality I see going on. The professional nature of this list > has vanished. I think LL needs to clean this list up and deal with it. > The number of people causing problems is small and finite and I don't see > much code or ideas coming from them. > > This list is an LL list and as such should fall under the TOS/CS and > abusive behavior should be rewarded with suspensions from Secondlife and if > it continues then the SL accounts be revoked. > IMHO anyway. > > If obfuscation happens to be part of a new way to manage cache so more can > be stored and the performance be improved then I'm all for it. > However, the cache performance is what counts. > The number of bytes being transferred is becoming critical. > And may soon become very expensive. > > Can we return to finding ways to improve the cache now? > > > ----- Original Message ---- > From: Gordon Wendt > To: Second Life Developer Mailing List > Sent: Monday, June 9, 2008 10:16:55 PM > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > > Irrational statements like what I keep seeing on this list are exactly why > an idiotic proposal like SVC-1919 was passed to remove UUID information from > the viewer, just because things like showing a texture UUID in the GUI can > be used for nefarious purposes wasn't and isn't a reason to cripple the > client, doubly so when it can be easily undone. That's why there are no > copies of Mozilla Firefox (an open source web browser for those who don't > know) without right shift save image functionality or without the option to > view web page source. You don't see people whining and moaning about their > web page source being publicly available yet people want SL to be crippled > in the same way they'd want a web browser to be crippled. > > -G.W. > > > On Mon, Jun 9, 2008 at 9:57 PM, Lawson English wrote: > > > Eh, the middle way is best, I think. > > Don't support things against the TOS via the SL viewer GUI, at the very > least. Beyond that, minor obfuscation that requires a potential thief to > have more technical understanding of what is going on than merely accessing > things via the standard MacOS/WIndows file GUI should be sufficient to offer > legal protection to content creators. Any protection BEOND that, will > require more work on the content creator. A 3rd party solution to grab > textures as they are uploaded and run them through signature/watermarking > before forwarding them to LL, might be an option. No doubt there are others, > but for content creators, even slight obfuscation should offer legal > protection. No obfuscation whatsoever, might not. > > In my non-legal view, of course. > > > Lawson > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/85048a26/attachment-0001.htm > > ------------------------------ > > Message: 5 > Date: Mon, 9 Jun 2008 23:22:32 -0400 > From: "Gordon Wendt" > Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs > obfuscation > To: "Second Life Developer Mailing List" > Message-ID: > <493033a70806092022x6fd8aca1ie241ea72a6d4e72@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Apologies to Ann for the double post since gmail at least automatically > wants to send it directly to whoever sent the original message to the list. > > > If you would like to skip to my ontopic comments on this conversation > please > skip to the second paragraph. > > @Ann Ironically you just displayed the same behavior you said should be > banned and I take great offense at you comparing people who disagree with > you on the topic of obsfucating information to terrorists. Other than your > post here attacking other resident's directly I don't see any personal > attacks just attacks on each other's arguments which is the nature of such > discourse when not everybody agrees. Incidentally it seems so far that LL > knows that off topic conversations and arguments go on in the list and as > long as the main conversation goes along and as long as they are quick and > not overly disruptive these arguments seem to be overlooked... this is just > from my experience so far and Rob and the other list admins take action as > they see fit without much regard to precedent. > > On the topic of the issue though since this really is getting off topic I'm > sure there is some middleground in terms of performance but it seems like > high performance would require changing the fundamental way that images are > sent, recieved, and dealt with by the server and client respectively > although I'd be interested if LL or anyone else has data on where the > slowest parts of the process are since I'm not sure we know for sure that > encoding is where the bottleneck is although that is unfortunately the only > part that can really be directly seen except by LL since we don't know what > goes on serverside. > > -G.W. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment-0001.htm > > ------------------------------ > > Message: 6 > Date: Tue, 10 Jun 2008 08:00:48 +0200 > From: Michael Schlenker > Subject: Re: [sldev] Cache politics: performance vs obfuscation > To: Argent Stonecutter > Cc: Second Life Developer Mailing List > Message-ID: <484E1890.1080604@uni-oldenburg.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Argent Stonecutter schrieb: > > On 2008-06-09, at 02:22, Dale Mahalko wrote: > >> A move to a local MySQL database > > > > God no. > > > > sqlite, please. Without all the MySQL "I'm pretending to be a real > > database engine" overhead. > > SQLites pretty good for some stuff, but caching blob data is not one of > it due to the required frequent fsync() calls needed to maintain > transactions. (just see the current discussion around Firefox 3 being > very slow on Ubuntu). > > But MySQL is an even worse idea... > > I had to write a heavily parallel (targeting some 1000 parallel writing > threads) blob storage system for a different application and using > SQLite, even only for storing the metadata leads to heavy lock > contention and made the system far less scalable. Current filesystems > like NTFS or ext3 are pretty okay for storing files and metadata, they > are made for that kind of usecase..., its even faster to do a stat() on > disk than to lookup stuff in sqlite in most cases. > > Michael > > > > > ------------------------------ > > _______________________________________________ > SLDev mailing list > SLDev@lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > End of SLDev Digest, Vol 18, Issue 66 > ************************************* > > > > _______________________________________________ > 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/20080610/3caa0ca8/attachment-0001.htm From xotmid at gmail.com Tue Jun 10 07:51:59 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Tue Jun 10 07:52:01 2008 Subject: [sldev] Shadow Patch? In-Reply-To: <484E500C.4060400@signpostmarv.name> References: <484E3DA4.7020801@cox.net> <484E500C.4060400@signpostmarv.name> Message-ID: I installed it and it was really nice looking... Made second life look rocking... The down side everyones FAKE Shadows... made it look wierd. I know it was not optimized but it still ran good.. Would love to see it as an option w/o having to dl a 3rd party patch. On Tue, Jun 10, 2008 at 4:57 AM, SignpostMarv Martin wrote: > Since the Shadow branch is restricted to GeForce 8 GPUs only, it would make > more sense to release it as a First Look viewer, not an RC. > > ~ Marv. > > Lawson English wrote: > >> Soft wrote: >> >>> On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands >>> wrote: >>> >>> >>>> Is this going to make it into rc10? >>>> >>> That's a long-term feature. No. >>> >>> The intent of the RC branch is that subsequent RCs at a given version >>> number contain bug fixes only. >>> _______________________________________________ >>> >>> >> Intent yes, reality? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/362ed1ee/attachment.htm From kwerks.sl at gmail.com Tue Jun 10 08:12:30 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 08:12:34 2008 Subject: [sldev] Re: SLDev Digest, Vol 18, Issue 66 In-Reply-To: <827605.10646.qm@web55601.mail.re4.yahoo.com> References: <20080610060041.C849741B41B@stupor.lindenlab.com> <827605.10646.qm@web55601.mail.re4.yahoo.com> Message-ID: <7b61e3970806100812r460753c4gee46c3ef71e73354@mail.gmail.com> SL is certainly not a web browser, or more precisely, should not be approached with that metaphor, I agree. As to digital IP, to a lawyer the notion of copyright, be it a digital asset or an equity asset is the same thing. To a programmer a digital asset is most certainly not the same thing as an entry in a ledger. Computers do two things and that is all they do; they they copy information and they make mathematical calculations based on those copies. That is all they do in the end and they do those things very well and they must do both of them to be useful. The gap in the dialog of IP regarding computers will never be bridged I think becuase lawyers seek to make copying difficult or impossible and the only way to do that is to curtail, even cripple somehow the computers ablity to copy and thus take away the one of the intrinsic things that makes computers useful. It just can't happen. The programmer will always simply see the thing as a "right-click away" because, well, it is. I think a far better way to approach the problem of digital IP to is quit trying to apply a legal model that does not fit. Realize that computers make things inifinitly copiable becuase they need to and therefore the path is to find ways to bend legal concepts to fit that reality rather then trying to bend the computer to fit existing legal concepts. I think, in this case, it's the lawyers that need to be flexible and creative, not the programmers per se. As a professional musician I have a very personal and economic interest in digital IP. Every time I see one of my discs on someones iPod or hear it in a bar, I wonder where that money went. However, as a professional programmer I realize the approach taken by the RIAA, for example, and others is completely futile. I believe what is needed to bridge this gap and address the issue properly is a different legal model and discourse and metaphor, and to quit talking so much about different programming model and metaphor. Just my 2 cents. Apologies for my last empty post. Mouse mis-cue. JB On Tue, Jun 10, 2008 at 8:11 AM, Random Unsung wrote: > Second Life is not a web browser. It is a world. It is a world with an > economy based on intellectual property and real property rights. If you want > a web browser, go outside to the Internet; if you want a world with people > in it, and not merely a abstract platformist sandbox, you will have to > accommodate the needs of non-scripters and non-coders who make up the > business people supporting the costs of this platform and making a profit > for the platform providers. > > The concept that right-clicking thereby enables stealing of proprietary > images and codes everywhere else on the Internet is false, and a tendentious > reading along the extremist Stallmanite lines. > > Any discussion of obfuscation should be reviewed on its merits, in good > faith, both to determine whether it assists in the matter of copyright theft > and preserving the integrity of the original permissions system, and also > with a view to functionality and scaling. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/a44b765c/attachment.htm From cenji.neutra at gmail.com Tue Jun 10 08:48:08 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 08:48:11 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal Message-ID: Open Grid Identifier Notation - Proposal draft 1 As part of some internal software development, we've had a need for a generic identification scheme for 'grids' and their major components. Rather than invent something behind closed-doors with high probability that something similar will be needed and re-invented by the VW community in the near future, we decided to come up with a proposal for open discussion. The 'grid identifier' notation proposed is fairly simple and takes into consideration the work of the AWG, the SLGOGP draft and 'current practice'. http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec In short, we're proposing using a domain-name-like system for identifiers, but with the components reversed so as not to have them confused with DNS domain names. For example, "com.secondlife.agni" could be the identifier for the SL main grid. There are also specific identifier types for VW components, such as SLGOGP's "agent domains" and "region domains". The proposal doesn't dictate how identifiers might be used or how/where they're managed. It would be up to other parties to build lookup, discovery and other services utilizing them (which can be the subject of future independent proposals). Feedback and criticism welcomed and appreciated. -Cenji Neutra Apez Corp (http://www.apez.biz ) From tateru.nino at gmail.com Tue Jun 10 08:50:14 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 10 08:51:02 2008 Subject: Improved viewer and script communications (Re: [sldev] Puppettering Branch) In-Reply-To: <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> References: <48473027.9090101@lindenlab.com> <3DC4D675-A662-4217-AF6D-FEF08586E946@gmail.com> <484B7DC5.7000900@cox.net> <299591AF-E75A-4757-825F-9F0350A59377@gmail.com> <484C307A.7020004@cox.net> <484C904A.1070205@gmail.com> <34cc66250806090535t3a655b20p58641848f4ca2522@mail.gmail.com> <484D5677.80300@gmail.com> <34cc66250806091039y3c3ad103m20e361f311c73da8@mail.gmail.com> <484E2D4B.2010407@gmail.com> <34cc66250806100439i7dc12889y262a5206f85e4d4f@mail.gmail.com> Message-ID: <484EA2B6.5010505@gmail.com> Me? pretty much never. Something must have set those values, but I couldn't tell you what it was. Teravus Ovares wrote: > *Tateru Nino* > > Interesting, because I have four fully patched WinXP systems that > don't have the registry values at all. There's a discrepancy there, > do you regularly apply registry hacks? > > Best Regards > > Teravus > > > On 6/10/08, *Tateru Nino* > wrote: > > I've just checked 3 WinXP systems (two with SP2 and one with SP3) > and the registry settings for wininet for HTTP/1.0 and HTTP/1.1 > connections are set to 0xa (10) on all of them. > That's > HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet > Settings MaxConnectionsPerServer and MaxConnectionsPer1_0Server. > > Teravus Ovares wrote: > > Can anyone confirm that the client does not use a library that > respects this 2 connection limitation? So far in testing, it > appears that it does. When two threads get stuck, it fails > to do anything else via http. We've tried to use HTTP CAPS > for inventory, and consistently, when the inventory service > runs slow, the client stops making *any* further http requests. > Best Regards > Teravus > > On 6/9/08, *Tateru Nino* >> wrote: > > Actually it is not a mandate. A mandate would be a MUST > NOT. This > is a SHOULD NOT, specifically: > "A single-user client SHOULD NOT maintain more than 2 > connections > with any server or proxy. A proxy SHOULD use up to 2*N > connections > to another server or proxy, where N is the number of > simultaneously active users." > > I've got personal knowledge that the author did not intend the > above to apply to situations like this. For the substrate > to MSIE, > however, it is entirely appropriate. Also, the above only > applies > to persistent connections, not non-persistent connections > (applying the same guideline to non-persistent connections > would > cause problems that this guideline is intended to avoid). > > Just because you're doing HTTP, doesn't make you a part of the > Web, and connection considerations in Web architecture over > HTTP > are different to other architectures over HTTP. > > > > > > Teravus Ovares wrote: > > I also note, that according to Microsoft's kb article: > "The HTTP 1.1 specification (RFC2616) mandates the > two-connection limit. The four-connection limit for > HTTP 1.0 > is a self-imposed restriction that coincides with the > standard > that is used by a number of popular Web browsers." > You can read the article here: > http://support.microsoft.com/kb/183110 > You can read the RFC here: > http://www.faqs.org/rfcs/rfc2616.html > Best Regards > Teravus > > > From me at signpostmarv.name Tue Jun 10 08:55:06 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 08:55:10 2008 Subject: [sldev] Shadow Patch? In-Reply-To: References: Message-ID: <484EA3DA.6020202@signpostmarv.name> See http://signpsotmarv.blip.tv/file/979660/ and http://signpostmarv.blip.tv/file/979736 - both made with the viewer Brandon linked. Visit my office in Hippotropolis to view the build used in the videos :-P ~ Marv. Brandon Husbands wrote: > http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html > > Is this going to make it into rc10? > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/d30fe81b/smime-0001.bin From gigstaggart at gmail.com Tue Jun 10 09:04:26 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 10 09:04:29 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <484EA60A.4050909@gmail.com> Cenji Neutra wrote: > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to have them > confused with DNS domain names. For example, "com.secondlife.agni" > could be the identifier for the SL main grid. There are also specific > identifier types for VW components, such as SLGOGP's "agent domains" > and "region domains". Why? What's the point in reversing them? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cbe8a6dc/smime.bin From kwerks.sl at gmail.com Tue Jun 10 09:12:29 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 09:12:33 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> Excellent notion. Is this discussion to take place here or elsewhere? Apologies if this is out of place here but... Has the notion of a prefix or transport been discussed rather then a name reversal? Is is not clear to me the benefit of the name reversal. Given the convention of the prefix 'www' indicating the world wide web, and in the spirit of that naming convention attempting to look forward to other network notions, has a prefix of 'grid' or 'mv' (metaverse) or something like that been considered? 'grid.angi.secondlife.com' or 'mv.agni.secondlife.com' or even more simply the transport mechanism? 'grid://agni.secondlife.com' or 'mv://agni.secondlife.com' It seems to me that the current push to utilize HTTP for services, the plethora of software that understands this domain ordering and the ability to capitalize on existing DNS services would make this much easier then re-writing those things to accomodate this convention. Please let me know if this is out of place here and where previous discussion might be reviewed and future discourse might be taken up. regards JB On Tue, Jun 10, 2008 at 11:48 AM, Cenji Neutra wrote: > Open Grid Identifier Notation - Proposal draft 1 > > As part of some internal software development, we've had a need for a > generic identification scheme for 'grids' and their major components. > Rather than invent something behind closed-doors with high probability > that something similar will be needed and re-invented by the VW > community in the near future, we decided to come up with a proposal > for open discussion. > The 'grid identifier' notation proposed is fairly simple and takes > into consideration the work of the AWG, the SLGOGP draft and 'current > practice'. > > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to have them > confused with DNS domain names. For example, "com.secondlife.agni" > could be the identifier for the SL main grid. There are also specific > identifier types for VW components, such as SLGOGP's "agent domains" > and "region domains". > > The proposal doesn't dictate how identifiers might be used or > how/where they're managed. It would be up to other parties to build > lookup, discovery and other services utilizing them (which can be the > subject of future independent proposals). > > Feedback and criticism welcomed and appreciated. > > -Cenji Neutra > > Apez Corp (http://www.apez.biz ) > _______________________________________________ > 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/20080610/ba93a07e/attachment.htm From kfa at gmx.net Tue Jun 10 09:20:30 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 09:20:40 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA60A.4050909@gmail.com> References: <484EA60A.4050909@gmail.com> Message-ID: <484EA9CE.9070901@gmx.net> Jason Giglio wrote: > Cenji Neutra wrote: >> http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec >> >> In short, we're proposing using a domain-name-like system for >> identifiers, but with the components reversed so as not to have them >> confused with DNS domain names. For example, "com.secondlife.agni" >> could be the identifier for the SL main grid. There are also specific >> identifier types for VW components, such as SLGOGP's "agent domains" >> and "region domains". > > Why? What's the point in reversing them? > > Java does it the same way. The point is that it creates a top-down ordered folder structure. From kwerks.sl at gmail.com Tue Jun 10 09:34:18 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 09:34:19 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EA9CE.9070901@gmx.net> References: <484EA60A.4050909@gmail.com> <484EA9CE.9070901@gmx.net> Message-ID: <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> Hmm, please forgive my thickness, but how does java's convention of organizing name space and a folder structure for source code apply to the existing convention of network discovery and DNS? Solid tools are already out there to utilize the other approach for this exact application. JB On Tue, Jun 10, 2008 at 12:20 PM, Felix Duesenburg wrote: > Jason Giglio wrote: > >> Cenji Neutra wrote: >> >>> http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec >>> >>> In short, we're proposing using a domain-name-like system for >>> identifiers, but with the components reversed so as not to have them >>> confused with DNS domain names. For example, "com.secondlife.agni" >>> could be the identifier for the SL main grid. There are also specific >>> identifier types for VW components, such as SLGOGP's "agent domains" >>> and "region domains". >>> >> >> Why? What's the point in reversing them? >> >> >> > Java does it the same way. The point is that it creates a top-down ordered > folder structure. > > _______________________________________________ > 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/20080610/24bf867a/attachment.htm From jhurliman at jhurliman.org Tue Jun 10 09:35:30 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jun 10 09:35:36 2008 Subject: [sldev] How Far For Security? In-Reply-To: References: <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <4d211a610806091438i6ef3c358l16c5022f9b1bb82f@mail.gmail.com> <484DAFD9.6030009@lindenlab.com> <484E2063.20806@gmail.com> Message-ID: On Tue, Jun 10, 2008 at 12:46 AM, Argent Stonecutter < secret.argent@gmail.com> wrote: > On 2008-06-10, at 01:34, Jason Giglio wrote: > >> Argent Stonecutter wrote: >> >>> The corollary of (a) is "eliminate a huge portion of the SL economy, >>> and possibly go out of business". >>> >> >> > Yes, because the entire economy collapsed the day after copybot came out. >> > > Don't be silly. If copybot had not been broken, incomplete, and horribly > inconvenient, if it been built into the standard client, with right click > "show source" and "save as" that worked like "show source" and "save as" in > a browser (because that IS what "treat it like the web" implies) in a > browser and let you trivially grab all prims and assets in a convenient form > for uploading as your own product, then... yes... it likely would have. > > Then why hasn't primpreview killed the SL economy? http://www.youtube.com/watch?v=LfMNygcceAs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/cf6d12a9/attachment-0001.htm From vexstreeter at gmail.com Tue Jun 10 09:37:05 2008 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue Jun 10 09:37:10 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: Message-ID: <484EADB1.1050105@gmail.com> Cenji Neutra wrote: > Open Grid Identifier Notation - Proposal draft 1 > > As part of some internal software development, we've had a need for a > generic identification scheme for 'grids' and their major components. > I think you need to explain why a novel naming syntax is required. For instance, I'd think that a URI would be a better start, perhaps drawing on XML namespace URLs pointing to RDDL or some such, or a URN with types called out as components. From cenji.neutra at gmail.com Tue Jun 10 09:40:59 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 09:41:01 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> References: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> Message-ID: On Tue, Jun 10, 2008 at 12:04 PM, Jason Giglio wrote: >> confused with DNS domain names. For example, "com.secondlife.agni" >> could be the identifier for the SL main grid. > Why? What's the point in reversing them? The idea was to avoid confusion with domain names. On Tue, Jun 10, 2008 at 12:12 PM, JB Kraft wrote: > Excellent notion. Is this discussion to take place here or elsewhere? I guess it is related to SL development. There is also a Discussion/Talk page were comments can be posted. > Has the notion of a prefix or transport been discussed rather then a name > reversal? Is is not clear to me the benefit of the name reversal. No, it hasn't. This is the kind of feedback we were after :) > Given the convention of the prefix 'www' indicating the world wide web, and > in the spirit of that naming convention attempting to look forward to other > network notions, has a prefix of 'grid' or 'mv' (metaverse) or something > like that been considered? > > 'grid.angi.secondlife.com' or 'mv.agni.secondlife.com' > > or even more simply the transport mechanism? > > 'grid://agni.secondlife.com' or 'mv://agni.secondlife.com' > > It seems to me that the current push to utilize HTTP for services, the > plethora of software that understands this domain ordering and the ability > to capitalize on existing DNS services would make this much easier then > re-writing those things to accomodate this convention. The intention was to keep the abstract identifiers independent from any service end-points or resource locators. While a scheme like that may be useful as a standard way to connect to a service implementing a known interface, we're after a more abstract way to refer to them without any implication as to where the service might be located or what APIs it might support. Obviously, there is a need for a way to get to a service end-point from an identifier, but we don't want to dictate that at this stage. To give an example of how you might achieve something like that. Consider a hypothetical standard that specifies how an identifier can be used to obtain a service end-point in the following way: - map the identifier to a DNS host name by reversing the components and then appending a standard 'root' domain, such as virtualworld.id, for example to yield "agni.secondlife.com.virtualworld.id". - perform a DNS lookup on that domain for the SRV record - perhaps the SVC record can provide an SLGOGP login URL directly for an agent domain, or perhaps the host is identifies is required to support a simple rest GET request that returns some standard piece of XML that includes information such as login URLs and the like. Just one possibility of many and something that is outside of the scope of just specifying an identifier notation. -Cenji. From me at signpostmarv.name Tue Jun 10 10:06:10 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 10:06:13 2008 Subject: [sldev] iphone 3D client possible? In-Reply-To: <484E4F83.7000402@signpostmarv.name> References: <484DBAF7.9000308@cox.net> <484DCAB8.80100@cox.net> <484E4F83.7000402@signpostmarv.name> Message-ID: <484EB482.2050407@signpostmarv.name> John Hurliman wrote: > Then why hasn't primpreview killed the SL economy? > http://www.youtube.com/watch?v=LfMNygcceAs ^this is the kind of interface I was referring to for the iPhone. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/aecd76e7/smime.bin From waseemzhr at gmail.com Tue Jun 10 10:31:27 2008 From: waseemzhr at gmail.com (Waseem Azhar) Date: Tue Jun 10 10:31:29 2008 Subject: [sldev] Login SL Using Java Client Message-ID: Hi, I am writing java SL client. Currently I am stuck with login-to-simulator case. Using xml-rpc I am able to get authenticated with xml response from server. But when I send UseCircuitCode packet to simulator on UDP connection, I get no response from the Simulator. Can anyone help ? Thanks, -Azhar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/e31893e7/attachment.htm From kfa at gmx.net Tue Jun 10 07:04:25 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 10:52:31 2008 Subject: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> References: <484CEFFD.4060408@gmail.com> <4d211a610806090323s4294624amb97ee110b769343c@mail.gmail.com> <484D070A.1050705@streamsense.net> <484D0722.3020701@streamsense.net> <547146C8-97BB-4783-8146-0F1E3DC30415@lindenlab.com> <493033a70806091808r5089e4b5rb4d835f0d321fd@mail.gmail.com> <7AB9D36C-B563-4917-AE8A-C02E0B1503C5@lindenlab.com> Message-ID: <484E89E9.8060805@gmx.net> Kent Quirk (Q Linden) wrote: > > On Jun 9, 2008, at 9:08 PM, Gordon Wendt wrote: > >> With all due respect if you have linden after your name (Q Linden in >> this case) then you are going to be assumed to be speaking for LL >> every time you post anywhere, is it fair? no but that's life on a >> mailing list that the company you works for runs. > > Yes, sure. All I meant (and it was badly phrased, I admit) was that I'm > not trying to say that what I think is what LL as a whole thinks or will > do. I'm trying to have a conversation here, and I didn't want my > evolving thinking to be perceived as any firm indication of what LL will > necessarily do. I'm only one of many. > > Q > With all due respect as well, I do NOT think that the assumption Gordon expressed is a fair one, no matter how many would like to beat into the same kerf. Quite often things would be easier if we stopped assuming or trying to second-guess our counterparts and just took their words as they are. If there is a need to clarify, one can always ask back whether there's a person speaking or the company. We should be grateful that Lindens are engaging in discussion here, participate in developing ideas, and feel free to speak off the top of their heads just like everybody else. This shows they're not sitting in an ivory tower like so many others who seemingly can only communicate in carefully crafted legalese statements, always scared shitless the whole company could be pinned down for something they casually said. Cheers, Felix From ravenglassrentals at yahoo.com Tue Jun 10 10:58:31 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Jun 10 10:58:33 2008 Subject: [sldev] Re: "It's Just Not Possible" In-Reply-To: <20080610155510.66D1F41B34A@stupor.lindenlab.com> Message-ID: <425146.67076.qm@web55605.mail.re4.yahoo.com> JB, I'm glad you concede that SL is not a mere web browser, but your other statement about IP and lawyers is merely one ideological take, one common to programmers, and not even one all programmers, especially moderates, agree on. Number one, just because you can break into a house or steal the silver from the knife drawer technically doesn't mean this is morally and legally allowed. It isn't. And it's this decoupling of coders from the moral and legal suasion of real life that makes them continually morally and legally suspect. Locksmiths, architects, and doormen don't constantly inform their customers that their work is all hackable and pointless; they work to close the gaps. Software programmers should restore their accountability in the spirit of those real life professions. I don't think you can call yourself scientific, as in the science of computing, by claiming something "can never be done". By that logic, you would never stream a virtual world in 3-D across 20,000 servers because "it can't be done". Most people do not say their theft of a silver spoon in someone else's drawer is legitimate merely because it is always a drawer-pull away, because, well it is. Civilization is based on such scruples. I would urge you to restore them to your own field. The RIAA is not futile. It's not perfect; perhaps it is not the final say. But it works to secure many people's IP, despite the constant claims that it is futile by such as yourself. The existing legal and moral structures of thousands of years are perfectly adequate in their bare essentials to address the issue of creativity and theft and property. It is only in modern times that the progress was made in fact to establish property rights in the face of the tribe, the leader, the king. No need to go backwards to pre-Enlightenment eras just because we're on the Internet. No one who has a stake in SL can be directed to "quit talking about programming metaphors". The making of metaphors, and indeed the entire debate about programming the world of Second Life, is not the solve provence of coders. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/df0db000/attachment.htm From kfa at gmx.net Tue Jun 10 10:58:47 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Jun 10 10:58:55 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> References: <484EA60A.4050909@gmail.com> <484EA9CE.9070901@gmx.net> <7b61e3970806100934t45889f5ufd55bb2f781702df@mail.gmail.com> Message-ID: <484EC0D7.9060904@gmx.net> Hm, I'm not sure how this relates to our topic, I'm lacking some specific knowledge in that field. I took the question for "why on earth are the domain parts reversed there" which keeps popping up in Java related forums or lists. Maybe I misunderstood it, then please just scratch it. JB Kraft wrote: > Hmm, please forgive my thickness, but how does java's convention of > organizing name space and a folder structure for source code apply to > the existing convention of network discovery and DNS? Solid tools are > already out there to utilize the other approach for this exact application. > > JB > > On Tue, Jun 10, 2008 at 12:20 PM, Felix Duesenburg > wrote: > > Jason Giglio wrote: > > Cenji Neutra wrote: > > http://wiki.secondlife.com/wiki/Grid_Identifiers_Spec > > In short, we're proposing using a domain-name-like system for > identifiers, but with the components reversed so as not to > have them > confused with DNS domain names. For example, > "com.secondlife.agni" > could be the identifier for the SL main grid. There are > also specific > identifier types for VW components, such as SLGOGP's "agent > domains" > and "region domains". > > > Why? What's the point in reversing them? > > > > Java does it the same way. The point is that it creates a top-down > ordered folder structure. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From kwerks.sl at gmail.com Tue Jun 10 11:05:04 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 11:05:06 2008 Subject: [sldev] Re: "It's Just Not Possible" In-Reply-To: <425146.67076.qm@web55605.mail.re4.yahoo.com> References: <20080610155510.66D1F41B34A@stupor.lindenlab.com> <425146.67076.qm@web55605.mail.re4.yahoo.com> Message-ID: <7b61e3970806101105t455a21acv9c5ad7a0a5d4c0ee@mail.gmail.com> Thank you for responding. As I mentioned, this particular issue is a personal one for me as, as a musician, I am directly affected financially by the problem. My other hat, as a programmer, does leave me with somewhat of a paradox in this regard however, as I can see behind the curtain. To the resolution of that, I very much appreciate other views and would like to state, for the record, that my scruples are most certainly intact. I very much endeavour to protect the artist in every way as I feel the dimishing of the value of art directly, as we all do. My stance to date indeed is an ideological one, but I think that is where the solutions lie frankly. Perhaps I am not eloquent enough to put that properly forth. As a programmer, I do see the moving of bits around as essential and essentially the same thing, be that 20,000 machines and a 3D world or a Commodore-64 pulling data off a tape drive and poking it into ram. The difference is simply scale. I see the browser, and SL for that matter, simply as a fancy dumb terminal, a VT-100, that some server sends data to to render, whether that data lands on the screen as green globby text or windlight is semantic to me. The difficulty is to see that data as something that belongs to someone, though indeed it does, and how to protect that. Frankly I am not sure you can given the way computers work without making them not work or not work well. To use your example, the data is simply not the same thing as the spoon in a drawer and therefore needs to be dealt with differently from an ideological perspective and not only from a programmers perspective. The forging of a silver spoon takes a great deal of human effort, the copying of an image or song takes none. Should the protection of theft of those things not be approached differently? I don't know, but at this point, I think they should. Perhaps I don't spend enough time in the company of lawyers to speak to what discussions land on their lists but from where I do sit, I hear very little coming from them on ways to approach the problem differently. The lawyers I do hear from, from my record company for instance, are all trying to talk about ways to apply the conventional model of the spoon to the very different problem of the mp3 and I suppose I am just trying to put forth that we may find even better ways to address the problem if we try to come at it from that ideological direction as well. Making the programmer the locksmith fits the spoon metaphor, but I propose that we at least entertain the notion that a digital asset may not actually be the metaphorical spoon. Mp3's may be something that the makers of laws and copyrights did not even conceive of or account for when they built the model and it is the model too, that needs adjusting. I apologize to the list if this particular discussion is somewhat too philosophical and out of bounds to its purpose but I feel strongly about it as both a programmer and a musician and think it bears the consideration of other approaches from both the the litigators asking the programmer to be locksmiths and the programmers somewhat naively seeing information as something that "wants to be free". Knowledge may want to be free but I'd rather you gave me a few cents for my information/music somehow. :) best regards JB On Tue, Jun 10, 2008 at 1:58 PM, Random Unsung wrote: > JB, I'm glad you concede that SL is not a mere web browser, but your other > statement about IP and lawyers is merely one ideological take, one common to > programmers, and not even one all programmers, especially moderates, agree > on. > > Number one, just because you can break into a house or steal the silver > from the knife drawer technically doesn't mean this is morally and legally > allowed. It isn't. And it's this decoupling of coders from the moral and > legal suasion of real life that makes them continually morally and legally > suspect. Locksmiths, architects, and doormen don't constantly inform their > customers that their work is all hackable and pointless; they work to close > the gaps. Software programmers should restore their accountability in the > spirit of those real life professions. > > I don't think you can call yourself scientific, as in the science of > computing, by claiming something "can never be done". By that logic, you > would never stream a virtual world in 3-D across 20,000 servers because "it > can't be done". > > Most people do not say their theft of a silver spoon in someone else's > drawer is legitimate merely because it is always a drawer-pull away, > because, well it is. Civilization is based on such scruples. I would urge > you to restore them to your own field. > > The RIAA is not futile. It's not perfect; perhaps it is not the final say. > But it works to secure many people's IP, despite the constant claims that it > is futile by such as yourself. > > The existing legal and moral structures of thousands of years are perfectly > adequate in their bare essentials to address the issue of creativity and > theft and property. It is only in modern times that the progress was made in > fact to establish property rights in the face of the tribe, the leader, the > king. No need to go backwards to pre-Enlightenment eras just because we're > on the Internet. > > No one who has a stake in SL can be directed to "quit talking about > programming metaphors". The making of metaphors, and indeed the entire > debate about programming the world of Second Life, is not the solve provence > of coders. > > > _______________________________________________ > 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/20080610/0c3cdf42/attachment.htm From kerdezixe at gmail.com Tue Jun 10 11:14:00 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:14:03 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <484CEFFD.4060408@gmail.com> References: <484CEFFD.4060408@gmail.com> Message-ID: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> 2008/6/9 Jason Giglio : > > Who cares? A small utility anyone can write in a few hours can do this > today. > *NOT* anyone, just "any coder willing to spend some time on it". Writing a software to decode the current cache isn't that much complex than decoding a XOR'd texture cache. A lot of software protection can be unlocked replacing a JNZ with a JNC instruction, extremly simple, but most people simply can't do that. But the question is : does the current obfuscation have any impact on cache performance ? As far as i remember, we agreed that the current cache have a very little impact on performance and most of the cpu time is spent in decoding j2c. The current cache is working, have a very little perfomance impact, and provide enough protection against script-kiddies. The probleme is in the jpeg2000 decoding performance. -- F4FQM Kerunix Flan Laurent Laborde From kerdezixe at gmail.com Tue Jun 10 11:31:04 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:31:07 2008 Subject: [sldev] Fun with 010 Editor + some random tought about texture cache In-Reply-To: <484E5AAE.5030507@signpostmarv.name> References: <8a1bfe660806071045yd8cb8c9y3e1768c463d80e32@mail.gmail.com> <484D8605.4090200@signpostmarv.name> <484E5AAE.5030507@signpostmarv.name> Message-ID: <8a1bfe660806101131h6c18cf1hf338a00ff4b2f4a1@mail.gmail.com> 2008/6/10 SignpostMarv Martin : > > Problem 1) Sim gets renamed. Does the UUID stay the same ? Use case: > metaverse development company X gets hired to develop a sim for company Y. > company X owns the sim while the work is being done (with an inconspicuous > name so as to avoid PR issues), company X then transfers ownership of sim to > company Y. Company Y has name of sim changed. No assets within the sim are > changed. > > Problem 2) beta grid vs main grid (and LL's SL vs OpenSim). Use case: aside > from visitors, region A is identical on both grids. region B has a few > differences (one or two buildings weren't yet erected at the time the beta > grid snapshot was made). region C is completely different- few if none > identical assets. > > Problem 3) region being withdrawn. Use case: short term events, like Burning > Life/ SL Birthday it's not really imporatnt. If the sim name, or sim uuid, change. The current cache will probably be useless and/or discarded and all texture downloaded again. So what ? Sim name rarelly change. it *may* happen and the textures will be downloaded again. End of problem. People clear their cache when any single problem occurs. - i lost an item : clear your cache - i lag : clear your cache - my returned object was lost : clear your cache - what's the meaning of life, anyway ? clear your cache - hippo ? clear cache ! - i can't login : clear your cache - i cleared my cache and i still have problems : clear it again the texture cache lifespan(is it the right english word ?) is so short that this kind of situation can be safely ignored, imho. Also, when a sim change name, that's probably because of ownership transfert, and the sim content is wiped anyway, so it's a good thing to discard the textures entries. -- F4FQM Kerunix Flan Laurent Laborde From dahliatrimble at gmail.com Tue Jun 10 11:34:49 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 11:35:12 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> Message-ID: If I wear my "as a user" hat, I'm not sure a small increase in cache performance is going to sway my opinion of the software. If, wearing my "content creator" hat , I see that there are no obstacles to anyone getting full permission access to my content, I'll probably assume that there is no benefit to me to spend a lot of time developing quality content. Sure, I can right click on an image in a web browser and save it, but if I were browsing a stock photo site I would only be able to save a watermarked thumbnail, and I wouldnt get the nice high resolution image until I agreed to the TOS and paid them, so the internet browser analogy doesn't hold water in that case. Further, noone is going to be inducted into the programmer hall of fame for writing a binary file to a disk. If you want to do something that is a benefit to the community, develop a method that improves cache performance, saves network bandwidth, and doesnt alienate a large portion of the user base. If you want to make a cache browser/exporter, then call it that. I see no reason that a standardized image format would necessarily be the highest performance choice for a cache. On Tue, Jun 10, 2008 at 11:14 AM, Laurent Laborde wrote: > 2008/6/9 Jason Giglio : > > > > Who cares? A small utility anyone can write in a few hours can do this > > today. > > > > *NOT* anyone, just "any coder willing to spend some time on it". > Writing a software to decode the current cache isn't that much complex > than decoding a XOR'd texture cache. > > A lot of software protection can be unlocked replacing a JNZ with a > JNC instruction, extremly simple, but most people simply can't do > that. > > But the question is : does the current obfuscation have any impact on > cache performance ? > As far as i remember, we agreed that the current cache have a very > little impact on performance and most of the cpu time is spent in > decoding j2c. > > The current cache is working, have a very little perfomance impact, > and provide enough protection against script-kiddies. > The probleme is in the jpeg2000 decoding performance. > > > -- > F4FQM > Kerunix Flan > Laurent Laborde > _______________________________________________ > 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/20080610/3732fca8/attachment-0001.htm From kerdezixe at gmail.com Tue Jun 10 11:57:49 2008 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jun 10 11:57:52 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> Message-ID: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> 2008/6/10 Dahlia Trimble : > > Further, noone is going to be inducted into the programmer hall of fame for > writing a binary file to a disk. If you want to do something that is a > benefit to the community, develop a method that improves cache performance, > saves network bandwidth, and doesnt alienate a large portion of the user > base. If you want to make a cache browser/exporter, then call it that. I see > no reason that a standardized image format would necessarily be the highest > performance choice for a cache. There is one good reason to use a standardized image format and it's directly related to performance. I widely used open format have tons of coder working on the libraries to use this format and work on optimisation/performance. A library used by millions of users, including large corporate company, is most likely highly optimized, stable, reliable and secure. Just take a look at the discussion about "commercial jpeg2000 librarie" vs "openjpeg2k librarie". that's why we don't even talk about trying to improve the decoding libraries performance anymore : it was done already, and by external coders. If LL develop a custom image format, it will cost a lot of ressource to work on optimization, etc ... -- F4FQM Kerunix Flan Laurent Laborde From dahliatrimble at gmail.com Tue Jun 10 12:08:20 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 12:08:23 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: Only if your goal is interopability with external programs. If that is the goal, it should be stated. If the goal is to improve the performance of the viewer, then that goal should be weighed against user needs. On Tue, Jun 10, 2008 at 11:57 AM, Laurent Laborde wrote: > 2008/6/10 Dahlia Trimble : > > > > Further, noone is going to be inducted into the programmer hall of fame > for > > writing a binary file to a disk. If you want to do something that is a > > benefit to the community, develop a method that improves cache > performance, > > saves network bandwidth, and doesnt alienate a large portion of the user > > base. If you want to make a cache browser/exporter, then call it that. I > see > > no reason that a standardized image format would necessarily be the > highest > > performance choice for a cache. > > There is one good reason to use a standardized image format and it's > directly related to performance. > I widely used open format have tons of coder working on the libraries > to use this format and work on optimisation/performance. > > A library used by millions of users, including large corporate > company, is most likely highly optimized, stable, reliable and secure. > Just take a look at the discussion about "commercial jpeg2000 > librarie" vs "openjpeg2k librarie". > > that's why we don't even talk about trying to improve the decoding > libraries performance anymore : it was done already, and by external > coders. > If LL develop a custom image format, it will cost a lot of ressource > to work on optimization, etc ... > > -- > F4FQM > Kerunix Flan > Laurent Laborde > _______________________________________________ > 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/20080610/9eb317fc/attachment.htm From dahliatrimble at gmail.com Tue Jun 10 12:09:49 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jun 10 12:09:53 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <484CEFFD.4060408@gmail.com> <8a1bfe660806101114j18ab48c4u920e8c4f2fddd308@mail.gmail.com> <8a1bfe660806101157w2b9f7203w55155af8444d23c9@mail.gmail.com> Message-ID: spelling correction: inter-operability On Tue, Jun 10, 2008 at 12:08 PM, Dahlia Trimble wrote: > Only if your goal is interopability with external programs. If that is the > goal, it should be stated. If the goal is to improve the performance of the > viewer, then that goal should be weighed against user needs. > > > On Tue, Jun 10, 2008 at 11:57 AM, Laurent Laborde > wrote: > >> 2008/6/10 Dahlia Trimble : >> > >> > Further, noone is going to be inducted into the programmer hall of fame >> for >> > writing a binary file to a disk. If you want to do something that is a >> > benefit to the community, develop a method that improves cache >> performance, >> > saves network bandwidth, and doesnt alienate a large portion of the user >> > base. If you want to make a cache browser/exporter, then call it that. I >> see >> > no reason that a standardized image format would necessarily be the >> highest >> > performance choice for a cache. >> >> There is one good reason to use a standardized image format and it's >> directly related to performance. >> I widely used open format have tons of coder working on the libraries >> to use this format and work on optimisation/performance. >> >> A library used by millions of users, including large corporate >> company, is most likely highly optimized, stable, reliable and secure. >> Just take a look at the discussion about "commercial jpeg2000 >> librarie" vs "openjpeg2k librarie". >> >> that's why we don't even talk about trying to improve the decoding >> libraries performance anymore : it was done already, and by external >> coders. >> If LL develop a custom image format, it will cost a lot of ressource >> to work on optimization, etc ... >> >> -- >> F4FQM >> Kerunix Flan >> Laurent Laborde >> _______________________________________________ >> 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/20080610/1b67d384/attachment.htm From darien_caldwell at comcast.net Tue Jun 10 12:57:13 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Tue Jun 10 12:57:20 2008 Subject: [sldev] How Far For Security? Message-ID: <061020081957.26755.484EDC990000ADFA00006883221654997604040A990B040E0CA1020A079D0E0B@comcast.net> -------------- Original message ---------------------- From: "John Hurliman" > On Tue, Jun 10, 2008 at 12:46 AM, Argent Stonecutter < > secret.argent@gmail.com> wrote: > > > On 2008-06-10, at 01:34, Jason Giglio wrote: > > > >> Argent Stonecutter wrote: > >> > >>> The corollary of (a) is "eliminate a huge portion of the SL economy, > >>> and possibly go out of business". > >>> > >> > >> > > Yes, because the entire economy collapsed the day after copybot came out. > >> > > > > Don't be silly. If copybot had not been broken, incomplete, and horribly > > inconvenient, if it been built into the standard client, with right click > > "show source" and "save as" that worked like "show source" and "save as" in > > a browser (because that IS what "treat it like the web" implies) in a > > browser and let you trivially grab all prims and assets in a convenient form > > for uploading as your own product, then... yes... it likely would have. > > > > > > Then why hasn't primpreview killed the SL economy? > http://www.youtube.com/watch?v=LfMNygcceAs maybe because nobody knows what it is, what it does, or where to get it? First time i've ever heard of it. -------------- next part -------------- An embedded message was scrubbed... From: "John Hurliman" Subject: Re: [sldev] How Far For Security? Date: Tue, 10 Jun 2008 16:35:38 +0000 Size: 3988 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/35344be1/attachment.eml From missannotoole at yahoo.com Tue Jun 10 13:06:41 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Jun 10 13:06:44 2008 Subject: [sldev] Cache politics: performance vs obfuscation Message-ID: <880510.18376.qm@web59115.mail.re1.yahoo.com> Let us ensure we have the priorities straight. With Time Warner and other cable modem service providers preparing to implement bytes transferred caps it is imperative that the cache operation overall be improved to ensure there is no repetitive downloading of bytes. It simply will not matter if the bytes are obfuscated if the population of Secondlife is gutted by a large scale *perceived inability* to afford to participate. So instead of arguing about politics the emphasis should be on: 1. Increasing the size of the local cache 2. Enhancing the reliability and performance of this local cache I seriously doubt anyone would complain if some increased protection happened to fall out of those 2 priorities. However we generally know this possibility is unlikely unless it came in the form of some compression we have not yet considered. Save SL first. Then worry about the rest. If SL dies because of consumers *not being aware of their choices in service providers* then nothing really matters does it? That is where my opinion stands at this time. Any faster open source image compression libs out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/0f8e3d2f/attachment.htm From robla at lindenlab.com Tue Jun 10 13:29:37 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jun 10 13:29:45 2008 Subject: [sldev] Security issues/Thank you/Congratulations In-Reply-To: References: Message-ID: <484EE431.20902@lindenlab.com> Thanks for sending this. I can't personally take any credit for this, but (of the people I know at least semi-regularly read here) folks like Phoenix and Soft would well deserve to take a bow. Comments, complaints, and of course cheers and pats on the back about our security process are welcome here: https://wiki.secondlife.com/wiki/Talk:Security_issues Rob On 6/10/08 1:20 AM, Brandon Lockaby wrote: > > When I first started digging into the SL protocol, it seemed like just > about everything I tried to do uncovered a security issue. For awhile > I thought we were just doomed, I mean it :D Alot of you who work with > the protocol surely know the sort of thing I'm talking about! > > But right now I'm breathing a sigh of relief because from my point of > view, things have been changing fast! Granted, there are still issues, > and I'm sure they won't dry up just yet as I see an increasing number > of people deciding to work with the protocol lately, but as of now I > can honestly say I don't know a way to crash the official viewer or > ruin someone's business just by using the intended client/server > protocols on LL's grid. > > So I want to thank Linden Lab for responding so well to security > issues, and say congratulations! As far as I'm concerned the response > to these issues is stellar. And I want to extend thanks to everyone > who makes an effort to report security issues. I know many of these > people are probably nervous about talking publically about the things > they've seen but they deserve some recognition. Well here is a huge > THANK YOU to EVERYONE involved in helping improve Second Life in this > very important way! :D > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cenji.neutra at gmail.com Tue Jun 10 13:40:10 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 13:40:12 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484ED636.3060309@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> Message-ID: > Cenji Neutra wrote: > To my mind, the identifiers aren't resource locators (URLs). A URN does > seem like a nice idea though (goes looking for the URI RFC...) > On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter wrote: > XML namespaces ran into the same confusion, where the namespace identifiers > *typically* look like URLs but are often actually unresolvable because they > are "merely" namespace identifiers. The RDDL idea is to make them actually > resolvable URLs, where the intent is that they resolve to a rddl document > that describes the domain that the namespace models. The nice thing about > this approach is that it allows for a completely distributed solution: once > you've got the identifier, you can find out everything else you need to know > to connect without any sort of central registry. The point to make here is > that even in the URL case, the identifier is still just a reference not the > grid it names. > Yes, that is a nice property. The only problem with it is that it requires that everyone who controls the domains corresponding to the identifiers to implement the standard service. That would be like requiring hosts on the internet to run their own DNS name server for the subdomain below (if any). While they can certainly do that with the current DNS delegation mechanism, they're not required to do so - they can have an independent DNS service provider (who has no control over the hosts in the domain) for a whole set of hosts and subdomains if they wish. I hazard a guess that the current success of DNS wouldn't have come about if it had required everyone to implement it on many hosts from the outset. Perhaps it is possible to have the advantages of both systems. Perhaps we can use URIs and specifications that layer above that can require that for lookup, applications first query an extended DNS name. What I mean is, if the identifier is some URI containing "main.mygrid.net" then the application should first query a URL like "http://main.mygrid.net/grid.xml" (or whatever) and if it receives a 404 or other error (including a timeout) it should then try "http://main.mygrid.net.virtualworld.net/grid.xml" where "virtualworld.net" is the configured lookup service provider for that application (and any number of parties can opt to provide that kind of lookup service). That way, we can start providing a conforming service that works for all the existing grids (and new grids) even if they haven't implemented the standard. The 'timeout' could be a problem. Perhaps we should just use DNS to do a SRV record lookup of the domain and the absence of a record would indicate the service isn't supported, the presence of a SVN record can point to the URL of the actual XML. If there is no record, then a SRV record lookup on main.mygrid.net.virtualworld.net (or whatever) is performed instead. Thinking out loud there :) -Cenji. From dmahalko at gmail.com Tue Jun 10 14:29:52 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 10 14:29:55 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") Message-ID: I am of the opinion that this discussion belongs on the developer list, because as yet we still don't seem to know what is the best direction to take regarding the handling of cached assets. The current somewhat obfuscated solution isn't the greatest in terms of performance but it is there and it works for now. We and need to figure out what direction to go if that is going to change. I see the coder-geeks complaining about people like me not "contributing code" and so our participation is deemed worthless, but you cannot launch straight off into writing code without knowing what it is you're supposed to be doing, or if LL is philosophically in support of adding it into the client codebase. I will mention that on the old SL forums years ago I was discussing the possibility of a 3D video card with a dedicated, isolated memory space and a public/private key DRM model. Textures would be sent from the grid to the client in a pre-encrypted form, stored in this encrypted state in the client cache, and only decoded inside the protected memory space of the 3D card. By pairing this with HDCP this would create a secured digital pathway for assets to be reasonably protected from theft. Of course this was attacked in the forums as untenable and that "it will be hacked and you cannot stop it", which is not the point. The point is that it creates a similarly locked front door metaphor. As a thief you must be willing to go to some measures to break this protection in order to steal the content protected inside, and which gives a lawyer a definite case for prosecution since it isn't like the files sit in a raw format in a folder just waiting for Picasa to stumble across it and unknowingly catalog it. Since there are now only two significant players in the 3D card market, nVidia and ATI, it would be relatively easy for a copy protection mechanism to enter the marketplace and silently slip into place, as is already happening now as HDCP is replacing old non-HDCP cards. The overall performance may suffer somewhat due to the heavy encryption, but this would give content creators the legal protection they need to prosecute potential asset thieves. Besides with 3D cards now pushing 1 gigabyte and more of onboard memory plus ultra-high power processing, it's not like there would be a huge step back in performance. Perhaps a dedicated decryption pipeline could be developed so that there is no performance taken away from the main 3D chipset. And, with no need to obfuscate the downloaded cached assets, they can be written directly to that fast massive terabyte local folder-based disk cache with no need for obfuscation. Perhaps as GPU power continues to increase, more than textures could be encrpyted. Perhaps the whole asset system could be encrpyted and most of the client code run inside the protected space with few ways to send raw decrypted asset data back out. It would be interesting to see if a "write-only" physical memory could be created, where the only way to verify data was written correctly into the protected space is via a return path that can only provide a checksum on the written data. If LL wanted a protected asset pathway, this is probably the way forward, though it would take a few years to be implemented and rolled out to the public. I could see the MPEG-V people possibly also being interested in this for content protection purposes. - Scalar Tardis / Dale Mahalko On Tue, Jun 10, 2008 at 1:05 PM, JB Kraft wrote: > I apologize to the list if this particular discussion is somewhat too > philosophical and out of bounds to its purpose but I feel strongly about it > as both a programmer and a musician and think it bears the consideration of > other approaches from both the the litigators asking the programmer to be > locksmiths and the programmers somewhat naively seeing information as > something that "wants to be free". Knowledge may want to be free but I'd > rather you gave me a few cents for my information/music somehow. :) From sldev at catznip.com Tue Jun 10 14:48:43 2008 From: sldev at catznip.com (Kitty) Date: Tue Jun 10 14:45:55 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: Wouldn't that just make it impossible to still take snapshots in SL? Or something like machinema? It also wouldn't stop texture UUID grabbing/reuse, so would it actually make any significant difference that's worth what you'd be giving up? Infringement isn't a technological problem, it's a legal problem. From me at signpostmarv.name Tue Jun 10 15:17:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jun 10 15:17:10 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: <484EFD63.3020504@signpostmarv.name> Dale Mahalko wrote: > I will mention that on the old SL forums years ago I was discussing > the possibility of a 3D video card with a dedicated, isolated memory > space and a public/private key DRM model. Textures would be sent from > the grid to the client in a pre-encrypted form, stored in this > encrypted state in the client cache, and only decoded inside the > protected memory space of the 3D card. By pairing this with HDCP this > would create a secured digital pathway for assets to be reasonably > protected from theft. > > Of course this was attacked in the forums as untenable and that "it > will be hacked and you cannot stop it", which is not the point. The > point is that it creates a similarly locked front door metaphor. As a > thief you must be willing to go to some measures to break this > protection in order to steal the content protected inside, and which > gives a lawyer a definite case for prosecution since it isn't like the > files sit in a raw format in a folder just waiting for Picasa to > stumble across it and unknowingly catalog it. > > Since there are now only two significant players in the 3D card > market, nVidia and ATI, it would be relatively easy for a copy > protection mechanism to enter the marketplace and silently slip into > place, as is already happening now as HDCP is replacing old non-HDCP > cards. > > The overall performance may suffer somewhat due to the heavy > encryption, but this would give content creators the legal protection > they need to prosecute potential asset thieves. Besides with 3D cards > now pushing 1 gigabyte and more of onboard memory plus ultra-high > power processing, it's not like there would be a huge step back in > performance. Wouldn't that lock out every single person and/or device that doesn't have a supporting graphics card ? DRM for 3D apps on the scale of Second Life is rather inefficient and pointless, and would vastly restrict the adoption of SL. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080610/6a57f2e1/smime.bin From cenji.neutra at gmail.com Tue Jun 10 15:25:27 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 15:25:29 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484EFCD4.6080508@isn-oldenburg.de> References: <7b61e3970806100912t5dd7dbe2jc3b7429f01e91e68@mail.gmail.com> <484EFCD4.6080508@isn-oldenburg.de> Message-ID: > Basically you get all of this with either ASN.1 OIDs, X.500 DNs or URNs. > Define a format and than define the resolver that maps IDs to services. No > need to invent something new (just an URN scheme and a spec for a resolver > for that scheme). We'll certainly look at those options. No point needlessly reinventing things - the very reason we threw this out for comment. Thanks for your input. -Cenji. From vexstreeter at gmail.com Tue Jun 10 15:49:12 2008 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue Jun 10 15:49:43 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> Message-ID: <484F04E8.3070201@gmail.com> Cenji Neutra wrote: >> Cenji Neutra wrote: >> To my mind, the identifiers aren't resource locators (URLs). A URN does >> seem like a nice idea though (goes looking for the URI RFC...) >> >> > On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter wrote: > >> XML namespaces ran into the same confusion, where the namespace identifiers >> *typically* look like URLs but are often actually unresolvable because they >> are "merely" namespace identifiers. The RDDL idea is to make them actually >> resolvable URLs, where the intent is that they resolve to a rddl document >> that describes the domain that the namespace models. The nice thing about >> this approach is that it allows for a completely distributed solution: once >> you've got the identifier, you can find out everything else you need to know >> to connect without any sort of central registry. The point to make here is >> that even in the URL case, the identifier is still just a reference not the >> grid it names. >> >> > > Yes, that is a nice property. The only problem with it is that it > requires that everyone who controls the domains corresponding to the > identifiers to implement the standard service. Well, the implication is that the organization running grid X would both own the domain name X and IFF they want the grid to be publicly resolvable would put a grid description document at X. For instance case 1: public SL grid id = "http://grid.secondlife.com/agni" resolved contents of id: Second Life https://login.agni.lindenlab.com/cgi-bin/login.cgi ... etc case 2: my private grid id="http://myprivatemetaverse.org/" resolved contents of id: HTTP 404 error > Perhaps it is possible to have the advantages of both systems. > Perhaps we can use URIs and specifications that layer above that can > require that for lookup, applications first query an extended DNS > name. Two recommendations: - that there be no "search" required to resolve - it either resolves or it doesn't. You might do it on initial discovery, but generally it is a way to advertise your grid in a more structured and useful way than a wiki page, definitely not in the critical path for client boot. - if published, the grid information should be *static*, that is, as a design goal, it ought to define the specific grid in a pretty deep way so you don't need to retrieve it ever again. Use dns to resolve major grid services, etc. Most clients would ship with a set of grid references, e.g. something like Gareth Ellison's supergrid (http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) Cheers, Vex From sllists at boroon.dasgupta.ch Tue Jun 10 15:59:13 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jun 10 15:59:18 2008 Subject: [sldev] Trusted Computing, anyone? (was: 3D cards with DRM support) In-Reply-To: References: Message-ID: <484F0741.1000709@boroon.dasgupta.ch> Dale Mahalko schrieb: > I will mention that on the old SL forums years ago I was discussing > the possibility of a 3D video card with a dedicated, isolated memory > space and a public/private key DRM model. Textures would be sent from > the grid to the client in a pre-encrypted form, stored in this > encrypted state in the client cache, and only decoded inside the > protected memory space of the 3D card. By pairing this with HDCP this > would create a secured digital pathway for assets to be reasonably > protected from theft. Why does this make me remember Seg's message here? https://lists.secondlife.com/pipermail/sldev/2007-September/005111.html Oh well, guess it must be the lafkon link at the end of the message. (Yeah, I admit that's propaganda. But I think the point is valid.) Taking away the users' control over hardware they've bought is IMHO morally as questionable as is illegally copying content. A small hurdle (as the current obfuscation) can't hurt, so that nobody breaks the law without even noticing himself. Everything else is either futile or will bring too much collateral damage with it (sometimes even both). Boroondas From kwerks.sl at gmail.com Tue Jun 10 16:08:04 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jun 10 16:08:06 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484F04E8.3070201@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> <484F04E8.3070201@gmail.com> Message-ID: <7b61e3970806101608t2b8bd081ua7e87dc7fd9e09b7@mail.gmail.com> This is something, XML wise, I was trying to nudge the viewer toward with http://jira.secondlife.com/browse/VWR-7531. LL (Mani) felt LLSD was the better course specifically. I remain dubious to that format myself but updated the patch nonetheless to accommodate. I realize it not specific to the grid notation format in this thread but just thought I'd mention it here in case someone wants to comment there as there is some overlap. regards JB On Tue, Jun 10, 2008 at 6:49 PM, Vex Streeter wrote: > Cenji Neutra wrote: > >> Cenji Neutra wrote: >>> To my mind, the identifiers aren't resource locators (URLs). A URN does >>> seem like a nice idea though (goes looking for the URI RFC...) >>> >>> >>> >> On Tue, Jun 10, 2008 at 3:29 PM, Vex Streeter >> wrote: >> >> >>> XML namespaces ran into the same confusion, where the namespace >>> identifiers >>> *typically* look like URLs but are often actually unresolvable because >>> they >>> are "merely" namespace identifiers. The RDDL idea is to make them >>> actually >>> resolvable URLs, where the intent is that they resolve to a rddl document >>> that describes the domain that the namespace models. The nice thing about >>> this approach is that it allows for a completely distributed solution: >>> once >>> you've got the identifier, you can find out everything else you need to >>> know >>> to connect without any sort of central registry. The point to make here >>> is >>> that even in the URL case, the identifier is still just a reference not >>> the >>> grid it names. >>> >>> >>> >> >> Yes, that is a nice property. The only problem with it is that it >> requires that everyone who controls the domains corresponding to the >> identifiers to implement the standard service. >> > Well, the implication is that the organization running grid X would both > own the domain name X and IFF they want the grid to be publicly resolvable > would put a grid description document at X. > > For instance > case 1: public SL grid > id = "http://grid.secondlife.com/agni" > resolved contents of id: > > Second Life > https://login.agni.lindenlab.com/cgi-bin/login.cgi > ... > etc > > > case 2: my private grid > id="http://myprivatemetaverse.org/" > resolved contents of id: HTTP 404 error > > > Perhaps it is possible to have the advantages of both systems. >> Perhaps we can use URIs and specifications that layer above that can >> require that for lookup, applications first query an extended DNS >> name. >> > Two recommendations: > - that there be no "search" required to resolve - it either resolves or it > doesn't. You might do it on initial discovery, but generally it is a way to > advertise your grid in a more structured and useful way than a wiki page, > definitely not in the critical path for client boot. > - if published, the grid information should be *static*, that is, as a > design goal, it ought to define the specific grid in a pretty deep way so > you don't need to retrieve it ever again. Use dns to resolve major grid > services, etc. Most clients would ship with a set of grid references, e.g. > something like Gareth Ellison's supergrid ( > http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) > > Cheers, > Vex > > _______________________________________________ > 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/20080610/792fb9f6/attachment.htm From cenji.neutra at gmail.com Tue Jun 10 16:23:41 2008 From: cenji.neutra at gmail.com (Cenji Neutra) Date: Tue Jun 10 16:23:43 2008 Subject: [sldev] Open Grid Identifier Notation draft proposal In-Reply-To: <484F04E8.3070201@gmail.com> References: <484EADB1.1050105@gmail.com> <484ED636.3060309@gmail.com> <484F04E8.3070201@gmail.com> Message-ID: On Tue, Jun 10, 2008 at 6:49 PM, Vex Streeter wrote: > Well, the implication is that the organization running grid X would both own > the domain name X and IFF they want the grid to be publicly resolvable would > put a grid description document at X. Right, which is something we don't want to *require* in order to facilitate adoption, but something that should be the defacto case if the scheme is adopted in the future (and hence the 'fast path'). That is to say, we want public grids to be resolvable even if the organization running the grid hasn't implemented the scheme (provided the resolver service knows about it of course). Right now, based on the feedback received, we're leaning toward a URN syntax for the 2nd draft. As for URN resolution (not encompassed by the current spec), having the URN be a URL would certainly be simplest, but to satisfy my requirement above, there has to be more to it than that. As you say, having any kind of complex lookup in the critical path of client startup should be avoid if possible. However, the resolution process we'll propose separately and implement will almost certainly use DNS in some way. Thanks, -Cenji. > > For instance > case 1: public SL grid > id = "http://grid.secondlife.com/agni" > resolved contents of id: > > Second Life > https://login.agni.lindenlab.com/cgi-bin/login.cgi > ... > etc > > > case 2: my private grid > id="http://myprivatemetaverse.org/" > resolved contents of id: HTTP 404 error > > >> Perhaps it is possible to have the advantages of both systems. >> Perhaps we can use URIs and specifications that layer above that can >> require that for lookup, applications first query an extended DNS >> name. > > Two recommendations: > - that there be no "search" required to resolve - it either resolves or it > doesn't. You might do it on initial discovery, but generally it is a way to > advertise your grid in a more structured and useful way than a wiki page, > definitely not in the critical path for client boot. > - if published, the grid information should be *static*, that is, as a > design goal, it ought to define the specific grid in a pretty deep way so > you don't need to retrieve it ever again. Use dns to resolve major grid > services, etc. Most clients would ship with a set of grid references, e.g. > something like Gareth Ellison's supergrid > (http://wiki.secondlife.com/wiki/User:Gareth_Ellison/Supergrid) > > Cheers, > Vex > From loom at loomiverse.net Tue Jun 10 17:55:57 2008 From: loom at loomiverse.net (Loom) Date: Tue Jun 10 17:55:59 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: <880510.18376.qm@web59115.mail.re1.yahoo.com> References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: On 11/06/2008, Ann Otoole wrote: > > Let us ensure we have the priorities straight. > With Time Warner and other cable modem service providers preparing to > implement bytes transferred caps it is imperative that the cache operation > overall be improved to ensure there is no repetitive downloading of bytes. > > It simply will not matter if the bytes are obfuscated if the population of > Secondlife is gutted by a large scale *perceived inability* to afford to > participate. > > Save SL first. Then worry about the rest. > If SL dies because of consumers *not being aware of their choices in > service providers* then nothing really matters does it? > I realise that you have used the word "perceived" in there but I would like to suggest that usage caps are not going to kill secondlife. Personally, I don't agree with the idea of usage caps, however in Australia we have lived with them for quite a while. >From the march 2008 economic stats, there were 12,245 active Australian users or about 0.057% of the population, who clocked up an average of 47 hours each - using usage capped internet connections. Compare that with the US where 194,899 active users (0.064% of the population) clocked up an average of 59 hours each. At worst, SL may take a hit in usage, but suggesting that it will die is imho an extreme view which is more in the line of fearmongering than rational analysis. Loom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/70d710a4/attachment.htm From sakkaku at gmail.com Tue Jun 10 18:05:12 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue Jun 10 18:05:15 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: <79e704e0806101805i3934c6edj6464e8926ebe3be1@mail.gmail.com> On Tue, Jun 10, 2008 at 7:55 PM, Loom wrote: > > > On 11/06/2008, Ann Otoole wrote: >> >> Let us ensure we have the priorities straight. >> With Time Warner and other cable modem service providers preparing to >> implement bytes transferred caps it is imperative that the cache operation >> overall be improved to ensure there is no repetitive downloading of bytes. >> >> It simply will not matter if the bytes are obfuscated if the population of >> Secondlife is gutted by a large scale *perceived inability* to afford to >> participate. >> >> Save SL first. Then worry about the rest. >> If SL dies because of consumers *not being aware of their choices in >> service providers* then nothing really matters does it? > > I realise that you have used the word "perceived" in there but I would like > to suggest that usage caps are not going to kill secondlife. > > Personally, I don't agree with the idea of usage caps, however in Australia > we have lived with them for quite a while. > > From the march 2008 economic stats, there were 12,245 active Australian > users or about 0.057% of the population, who clocked up an average of 47 > hours each - using usage capped internet connections. > > Compare that with the US where 194,899 active users (0.064% of the > population) clocked up an average of 59 hours each. > > At worst, SL may take a hit in usage, but suggesting that it will die is > imho an extreme view which is more in the line of fearmongering than > rational analysis. > > Loom The idea is to plan ahead to avoid running full on into a wall. There is no point in bickering over weather or not people are able to play SL, it is to realize that people ARE capped and MAY be impaired by SL. Why not improve the caching such that the asset servers are hammered less, people have to use less bandwidth and therefor have a more enjoyable experience. From nchase at earthlink.net Tue Jun 10 18:08:30 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Tue Jun 10 18:08:32 2008 Subject: [sldev] Cache politics: performance vs obfuscation In-Reply-To: References: <880510.18376.qm@web59115.mail.re1.yahoo.com> Message-ID: <484F258E.1000305@earthlink.net> Loom wrote: > I realise that you have used the word "perceived" in there but I would > like to suggest that usage caps are not going to kill secondlife. I don't know what the usage caps are link in Australia, but in my last house I had Direcway and using SL for more than an hour or two a day was impossible. If I did, i would blow through my entire quota and would be unable to use the Internet AT ALL for 24 hours. Seriously. I'm currently on cable modem and breathing easy, but I'm getting ready to move again and it is literally a requirement that the new house have some kind of "real" broadband, rather than satellite, because I absolutely cannot function on SL with a cap. ---- Nick From lenglish5 at cox.net Tue Jun 10 18:36:03 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jun 10 18:36:06 2008 Subject: [sldev] Login SL Using Java Client In-Reply-To: References: Message-ID: <484F2C03.20307@cox.net> Waseem Azhar wrote: > Hi, > > I am writing java SL client. Currently I am stuck with > login-to-simulator case. Using xml-rpc I am able to get authenticated > with xml response from server. But when I send UseCircuitCode packet > to simulator on UDP connection, I get no response from the Simulator. > > Can anyone help ? Have you looked at what the Python code is doing? http://wiki.secondlife.com/wiki/Presence_Code_Python If you watch the packets from the SL viewer, you'll see that acks for these packets don't start coming in for a while, so you have to send the first two or three packets wihout waiting for the ack. In order to be sure that you have a good circuit for use with CAPs, you must wait for an ack, but the first 2 or 3 packets won't ack you until after you send the last one in the sequence, or so it appears. This is probably not intended behavior... Lawson From dmahalko at gmail.com Tue Jun 10 18:46:19 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jun 10 18:46:22 2008 Subject: 3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible") In-Reply-To: References: Message-ID: On Tue, Jun 10, 2008 at 4:48 PM, Kitty wrote: > Wouldn't that just make it impossible to still take snapshots in SL? Or > something like machinema? A protected output channel that only produces watermarked snapshots would help to prevent asset theft. In the case of screen recorders, perhaps there would be a way to watermark the entire screen continuously in real-time so that any captures are already protected. (Is it possible to watermark an image "captured" by photographing the screen with a digital camera?) With regard to GL-Intercept, perhaps a modification of OpenGL could appear, called "ClosedGL" or "DRM-GL", which functions only inside the encrypted space and without direct output capability to local system memory. > It also wouldn't stop texture UUID grabbing/reuse, so would it actually make > any significant difference that's worth what you'd be giving up? The overall texture-access system might need to be changed to accommodate a more secure environment. Why should you have access to textures you don't own? It is currently done this way because the client must be able to request textures for every object you see in world, and the asset farm doesn't explicitly know in advance what you "need to see". But the current design model could be changed for a future virtual world. The current model is geared for heavy bandwidth usage and light cache usage, where primitives are separate from their textures, so that the prims can load first and textures appear later. If local caching can be enhanced to be huge and fast to reduce the network dependency, then there is no need for a primitive to be separate from its component textures. Put the primitive and all its textures into a single encrypted asset package that gets stuck in the local cache. When it is to be displayed, this package is loaded into the protected space and the included assets are used with the primitive -- but the user of the client does not have access to those textures to copy them, and doesn't know the UUIDs either since those are inside the package and not externally revealed. To load an object just requires a simple internal reference list, and doesn't need UUID references. "Stored texture at position 1 is applied to all faces of primitive in position 2, in this package." Under such a model, the clients don't even need to know individual UUIDs of objects within a package, to be able to manipulate the package contents. The LL sims can change a texture on a prim's face, by reference to the encrypted package ID: "Apply texture #2 to prim #4 in package X. Change the transparency of prim #23 in package Y." UUIDs may be used in the scripting for simplicity, but becomes an abstract reference for the client, which only knows the encrypted package ID. This does not add additional processing per client, since all clients can use the same offset references to items within a package, and the package is the same across all clients, so the references can be saved into the asset data in the LL asset farm when the encrypted package is created or edited by the asset owner. Encrypted asset packages containing textures, linksets, prims, and sounds would also better fit the multiverse model since there is no need for a global asset farm to store all "your" stuff. Your avatar could cross over to another space with all its protected data held within this single asset package. For this design, the asset downloads would be larger, as unified packages. But if the cache size were in the tens to hundreds of gigabytes, and fast and efficient, then only a single download is needed and that package does not change or need to be redownloaded unless the content creator modifies the package in some way, which requires a new updated package in the cache and expiring the old one. So the initial visit to somewhere would need the assets to load completely before the objects can appear, but the asset packages would never need to download again after that initial visit, if s