From dahliatrimble at gmail.com Tue Jan 1 12:42:11 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jan 1 12:42:13 2008 Subject: [sldev] movement within the client Message-ID: Message: 7 Date: Mon, 31 Dec 2007 21:26:53 -0700 From: Lawson English Subject: Re: [sldev] movement within the client To: John Hurliman Cc: sldev@lists.secondlife.com Message-ID: <4779C10D.7000101@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed John Hurliman wrote: > Callum Lerwick wrote: >> On Mon, 2007-12-31 at 15:06 -0600, Argent Stonecutter wrote: >> >>> On 2007-12-31, at 14:06, Callum Lerwick wrote: >>> >>>> (And of course we can and should always ask the question, "How does >>>> Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", >>>> they've been doing this for years... AFAIK a major difference is they >>>> all perform collisions/physics simultaneously on the client and >>>> server, >>>> and resolve any de-synchronization by holding the server >>>> authoritative.) >>>> >>> Would that require making Havok part of the client code? >>> >> >> Good question, actually. I'd like to know how Doom3 (Which is apparently >> "id Tech 4" now) and Source handle this. Do all clients really perform >> full physics simulation? Is the physics simulation predictable enough to >> do this on large numbers of colliding objects? The Source engine is >> Havok based, actually. However John Carmack has to reinvent the wheel as >> usual. >> >> Still, full client prediction of physics is orthogonal to the >> functionality I/we want. Better client prediction would be nice. The >> "fall through the ground then suddenly pop backwards" thing that happens >> in laggy situations, especially when crossing sims, especially in >> vehicles, is really annoying and I don't even understands why this >> happens. Is the client simulating gravity? As well as the "walk forever" >> thing that happens. The client does not seem to have any code in it that >> does something like "I have not received any updates from the sim in x >> seconds/milliseconds, I should stop moving the avatar as it is likely >> not what is intended by the user". >> > > Second Life clients use http://en.wikipedia.org/wiki/Dead_reckoning > based on position, velocity, acceleration, angular acceleration, and > an attempt to synchronize time steps between the client and the sim. > If you jump in the air and then start falling down or you stop flying > and the sim hiccups in sending you position updates, or you are > crossing a border at the time and the handover goes less then > seamlessly you will probably start falling through the earth. The > client *could* do basic collision detection with the avatar and the > terrain heightmap to prevent this effect. > Wouldnt it be easy for the client to test if the user stopped pressing motion keys, and then slow or stop the dead-reckoning? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080101/9b27797e/attachment.htm From agrimes at speakeasy.net Tue Jan 1 18:16:58 2008 From: agrimes at speakeasy.net (Alan Grimes) Date: Tue Jan 1 17:17:46 2008 Subject: [sldev] How to live on 4kb of t-mem. Message-ID: <477AF41A.8050807@speakeasy.net> I was playing around with the stats bar to see exactly how slow my comp was and what I need to upgrade next to get it up to speed. I GET 4 FPS, ON A GOOD DAY, 1.5 FPS, WHEN OTHER AVS ARE PRESENT!! I think I'm seeing texture memory exhaustion, it reports GL memory "100" which I ASSUME MEANS PERCENTAGE!!!, sometimes going up to 120 or more. This implies that I'm seeing a massive video ram thrashing over my computer's AGP 4X bus. This is utterly confounding because I have 128 mb of video ram, or more than a billion bits worth of memory... Both the playstation 2 and nintendo game CUBE, generally look better than second life in most regards. Neither of them can bost more than 40 mb of total memory. The N64 had no more than 8mb of ram. What the hell is going on then? important>>>> Well, what the N64 did, a machine I studied in considerable depth, is delay the color-space expansion until the very last possible instant. <<< important! What it would do is load several 1-bit, and 4-bit color-mapped bitmaps into the 4k texture memory and then composite these into the 16-bit buffer. When I tried to upload a 1-bit texture to second life, the first thing the server did was convert it into a blurry 24/32 bit image. Thusly, second life is between 8 and 32 times less efficient in terms of memory, bandwidth, and disk space than the N64. =\ For a good time, press and hold the squat key, (pg dn), walk a short ways then keep holding down page-dn. =P -- Give your money to Ron Paul before Helicopter Bernenke makes it worthless! From gigstaggart at gmail.com Wed Jan 2 07:22:10 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jan 2 07:22:13 2008 Subject: [sldev] What's new at SLJiraStats.com Message-ID: <477BAC22.5030701@gmail.com> Lots of new stuff added since the original launch announcement: * New, sleeker, more powerful, search interface. * The ability to view bugs with comments right on the site, without hitting Jira * URL Rewriting so you can just go: http://sljirastats.com/VWR-100 to view that bug * Personal stats, for example http://www.sljirastats.com/view_user.php?user=Gigs+Taggart * Personal stats lets you see recently updated bugs you've commented on in the past, lets you keep up with bugs you aren't watching but have commented on. * Personal efficiency stats, bugs filed vs bugs closed as invalid Here's the most efficient bug reporters: 97.56% McCabe Maxsted 96.00% Celierra Darling 95.83% LaeMi Qian 95.19% Nicholaz Beresford 94.81% Torley Linden * Responsiveness statistics, http://www.sljirastats.com/responsiveness.php * Ability to save/share/bookmark searches. Anyway the point is, if you haven't checked out sljirastats.com since the original launch, go give it another look, lots of neat stuff has been added. -Jason From dzonatas at dzonux.net Wed Jan 2 08:31:25 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jan 2 08:31:15 2008 Subject: [sldev] [IDEA] Partial resolution on +25 groups, highest voted feature request Message-ID: <477BBC5D.8030902@dzonux.net> The votes on the jira issue to request more than 25 groups surely has surpassed the 500 vote count, which means Lindens said they'll comment about in accordance to the FVT. At 706 votes now: http://jira.secondlife.com/browse/MISC-208 I proposed, as a subtask, for a partial resolution with this: Groups: Create an allow/ban list for grouped owned land in order to set prims http://jira.secondlife.com/browse/MISC-870 Please read subtask proposal and comment, Thank you! From monkowsk at watson.ibm.com Wed Jan 2 08:31:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 2 08:32:05 2008 Subject: [sldev] [VWR] morphs, normals, and binormals Message-ID: <477BBC7D.8080008@watson.ibm.com> The viewer uses delta morphs that include displacements as well as normals and binormals. I would like to combine two morphs so that the result is the same as if both were applied simultaneously. I know that the displacements can just be added, but what about the normals and binormals? Any 3D graphics experts out there? :-) Mike From josh at lindenlab.com Wed Jan 2 11:22:10 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 2 11:23:01 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: References: <4776CA43.2040809@lindenlab.com> Message-ID: <477BE462.3020304@lindenlab.com> Alissa Sabre wrote: >> Developers who build from source should correct the URL (to >> "secondlife.com"). Anyone who is distributing viewers based on this code >> base should update and repackage the viewers so that users are not at risk. >> > > Why don't you distribute sources for 1.18.6.3 and 1.18.6.76453 then? > (1) The change was a single URL + release notes. (2) We plan on pushing out 1.18.6.4 with sources tomorrow And the most practical reason.. (3) I was feeling under the weather but happened to be on a street car passing by the Linden offices with my family when I got a call about the exploit. I hopped off the street car, came in to do the viewer builds and push them live, and caught up with my family at home (several hours later) and crawled into bed. We could push them now, but see (1) and (2) above. From richard at lindenlab.com Wed Jan 2 14:37:59 2008 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jan 2 14:38:33 2008 Subject: [sldev] [VWR] morphs, normals, and binormals In-Reply-To: <477BBC7D.8080008@watson.ibm.com> References: <477BBC7D.8080008@watson.ibm.com> Message-ID: Normal and binormal morphs are implemented such that they are additive as well. This is a requirement, since we apply the morphs incrementally, and the customization interface allows you to set the morph values in any order. Technically, we store normal morphs as vector displacements that are applied to the initial normal. At one point, it was the half-angle that was stored as a displacement, to keep the small angle approximation as valid as possible (we then reflect the initial normal about the displaced normal to get the actual result). It's not clear from looking at the code that we still do that. http://en.wikipedia.org/wiki/Small_angle_approximation Regardless, you shouldn't have to worry. R. On Wed, 02 Jan 2008 08:31:57 -0800, Mike Monkowski wrote: > The viewer uses delta morphs that include displacements as well as > normals and binormals. I would like to combine two morphs so that the > result is the same as if both were applied simultaneously. I know that > the displacements can just be added, but what about the normals and > binormals? Any 3D graphics experts out there? :-) > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From alissa_sabre at yahoo.co.jp Wed Jan 2 17:49:16 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jan 2 17:49:30 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <477BE462.3020304@lindenlab.com> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> Message-ID: <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> > (1) The change was a single URL + release notes. Hmm. I have several things to say on this issue, but I'm skillless to say most of them politely in English. So just one point. My own WindLight viewer based on 76116 source with necessary URL change can't connect to the grid because of the version checking. It's natural. You surely changed version number as well as URL and release note. You just forgot mentioning it. But... what else? I knew you forgot telling at least one important thing. I was suspicious you also forgot one or two more things. > (2) We plan on pushing out 1.18.6.4 with sources tomorrow So you knew 1.18.6.4 is scheduled on January 3 when you announced availability of 1.18.6.3 on December 29. Why you didn't say it on December? Linden employees' past practice when an open source developer complained about the lack of future release schedules is to say something like "Release sechedule is managed by someone else in the company. I don't know it." I believe you are the first Linden employee who explicitly admitted that you knew the future release schedule at least six days in advance, had a very good chance to announce it, and kept that information from open source developpers. Hmm... > And the most practical reason... > > (3) I was feeling under the weather but happened to be on a street car > passing by the Linden offices with my family when I got a call about the > exploit. I hopped off the street car, came in to do the viewer builds > and push them live, and caught up with my family at home (several hours > later) and crawled into bed. I'm really puzzled why you disclosed this private thing to the public. Did you cried on open source developpers' shoulders? LL is a company that runs an online service. LL also says it is not just fun but is a serious business infrastructure. I don't know your responsibility in the company, but general understainding is that whatever your position is, working for such a company means there are chances you need to give up your private life on emergency situation. I believe that's why you did the release of 1.18.6.2 on the day under the said situation. That's totally fine. Thank you for doing it. Problem is that you just took care of binary distribution only and kept open source developers out of scenes. Well, some private story on my side, then. I'm not earning money for SL development. I'm just a sunday programmer. Literally I am. I have almost no time on writing code on weekdays. So, holiday season is the best timing to work on some big project. I planned something on WindLight viewer on this holidays. Note that in Japan it comes slightly late than US. It's typically Dec. 29 - Jan. 3... And this sudden 1.18.6.3 (or more specifically FL 76453) mandatory update hit this timing. I was so disappointed with it, and lost all my motivation working on viewer changes... -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From ptpto.kim at samsung.com Wed Jan 2 23:42:40 2008 From: ptpto.kim at samsung.com (=?ks_c_5601-1987?B?sei9wsf2?=) Date: Wed Jan 2 23:42:46 2008 Subject: [sldev] Why is Second-Life viewer so slow on Samsung Q1 uiltra? In-Reply-To: <476C4EFA.6080203@lindenlab.com> Message-ID: <0JU200D1A5ESQ0@mmp1.samsung.com> Hi~! Everyone, I'm wondering why is Second-Life viewer so slow on Samsung Q1 ultra? Is it graphics driver problem? Let?s check graphics accelerator driver Q1 has. It?s Intel GMA 950 chipset. See the product specification (http://www.samsung.com/us/consumer/detail/spec.do?group=computersperipheral s&type=ultramobilepc&subtype=ultramobilepc&model_cd=NP- Q1U/600/SEA&fullspec=F) Q1 supports DirectX 9 and OpenGL 1.4. Current graphics driver version that is installed on my Q1: 6.14.10.4833 and latest version: 6.14.10.4864. It seems that?s not key factor of our problem. Second-Life viewer self-problem? Official viewer may have problem with GMA 950 series but I?m not sure what the problem is exactly. SecondLife doesn't make good harmony with OpenGL 1.4 ver.? If it's true of not, what is the critical problem point? As you know, my point is not chipset level, but graphics API level! From kamilion at gmail.com Thu Jan 3 00:41:47 2008 From: kamilion at gmail.com (Kamilion) Date: Thu Jan 3 00:41:50 2008 Subject: [sldev] Why is Second-Life viewer so slow on Samsung Q1 uiltra? In-Reply-To: <0JU200D1A5ESQ0@mmp1.samsung.com> References: <476C4EFA.6080203@lindenlab.com> <0JU200D1A5ESQ0@mmp1.samsung.com> Message-ID: First of all, that system has a unknown Intel "A100" 600Mhz processor. The Second Life system requirements are at least a minimum 800Mhz P3 or Athlon. Second Life performs a lot of intensive vector calculations -- Can you discern if SL is running with runtime support for SSE2? Intel's documentation specifies that the A100 supports it, but I am unaware of SL's featuretable specifically identifying this processor and enabling SSE -- in fact it may be explicitly disabled due to the low clock rate. Second of all, the Intel GMA 950 is not directly listed as a supported graphics accelerator; however the system requirements mention the 945 explicitly. IIRC, the GMA 950 is the umbrella specification the 945 falls under -- the 945GU, 945GM, 945G, 945GZ all fall under the GMA 950 revision series. See VWR-3099 in JIRA as a meta-issue for unsupported GPUs. Also, The GMA 950 shares the same architectural weakness as the original GMA 900s: no hardware geometry processing. Neither basic (DX7) hardware transform and lighting, nor more advanced vertex shaders (DX8 and later) are handled in the GMA hardware -- therefore this must be performed in software on the 600Mhz A100, which is the most likely candidate for your reported slow behavior. Since linux seems to support the GMA 9XX series with the Intel released v2.1 drivers, I would suggest you attempt to test the viewer under linux and let us know if you notice any difference in framerate. Since most GL accesses under linux go through the MESAGL shim, any fallback to software rendering is handled there instead of the underlying Intel driver in windows, and MESAGL may process things more efficiently since it's software fallback codepaths are much more rigorously tested and optimized. Good to see someone from Samsung.com asking these questions! I assume you're one of the hardware engineers of these UMPC platforms? To put it simply: The Intel GMA adapter is forcing the (slow) CPU to perform most of the necessary functionality that SL requires. This is the most likely reason SL runs slowly on the Q1 ultra. I have this same problem with SL on my Fujitsu Lifebook S2020, using the ATI Radeon Mobility U1, another chipset lacking hardware texture and lighting -- fortunately the lifebook has a AMD 1.66Ghz Athlon XP-M that can pick up the slack in ubuntu linux. Versions of SL prior to 1.8.X on the windows platform would refuse to run entirely for this system. I get framerates of about 7-8 FPS with no avatars around on an unloaded sim with draw distance at 64m with all graphics options disabled. As soon as another avatar comes into view, my FPS drops to 1-2FPS. I have not tested windlight's avatar imposter support yet on this hardware. See VWR-520 on JIRA. -- Kamilion Schnook On Jan 2, 2008 11:42 PM, ??? wrote: > Hi~! Everyone, I'm wondering why is Second-Life viewer so slow on Samsung > Q1 ultra? > > Is it graphics driver problem? > > Let's check graphics accelerator driver Q1 has. It's Intel GMA 950 > chipset. See the product specification > (http://www.samsung.com/us/consumer/detail/spec.do?group=computersperipheral > s&type=ultramobilepc&subtype=ultramobilepc&model_cd=NP- > Q1U/600/SEA&fullspec=F) Q1 supports DirectX 9 and OpenGL 1.4. Current > graphics driver version that is installed on my Q1: 6.14.10.4833 and latest > version: 6.14.10.4864. It seems that's not key factor of our problem. > > Second-Life viewer self-problem? > > Official viewer may have problem with GMA 950 series but I'm not sure what > the problem is exactly. SecondLife doesn't make good harmony with OpenGL > 1.4 ver.? If it's true of not, what is the critical problem point? As you > know, my point is not chipset level, but graphics API level! From robin.cornelius at gmail.com Thu Jan 3 00:53:04 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 3 00:51:46 2008 Subject: [sldev] Why is Second-Life viewer so slow on Samsung Q1 uiltra? In-Reply-To: <0JU200D1A5ESQ0@mmp1.samsung.com> References: <0JU200D1A5ESQ0@mmp1.samsung.com> Message-ID: <477CA270.7060609@gmail.com> ??? wrote: > Hi~! Everyone, I'm wondering why is Second-Life viewer so slow on Samsung > Q1 ultra? > > How slow? how many frames per second do you get? and what are the graphics settings in settings/graphics and advanced graphics set to. Also draw distance what is this set to? > Is it graphics driver problem? > > Let?s check graphics accelerator driver Q1 has. It?s Intel GMA 950 > chipset. See the product specification > (http://www.samsung.com/us/consumer/detail/spec.do?group=computersperipheral > s&type=ultramobilepc&subtype=ultramobilepc&model_cd=NP- > Q1U/600/SEA&fullspec=F) Q1 supports DirectX 9 and OpenGL 1.4. Current > graphics driver version that is installed on my Q1: 6.14.10.4833 and latest > version: 6.14.10.4864. It seems that?s not key factor of our problem. > > Second-Life viewer self-problem? > > According to the spec that graphics card only has 128Mb of *shared* memory so it has to share bus time to get at the memory, for a processor intensive application that uses a lot of physical and graphics memory this could be a bad factor. Also how is the graphics chip connected into the system, on what bus? Moving graphics things around is a huge overhead, i see *enormous* difference if my graphics card is in my PCIex4 slot compared to my PCIex16 slot. If its only on a x4 then this is not the best possible situation. You have 1GB of system ram which is normally acceptable (well is for me under linux, no idea of the footprint of windows tablet). > Official viewer may have problem with GMA 950 series but I?m not sure what > the problem is exactly. SecondLife doesn't make good harmony with OpenGL > 1.4 ver.? If it's true of not, what is the critical problem point? As you > know, my point is not chipset level, but graphics API level! > > How does your processor compare to other processors? I have no idea about the processor, when you are running can you get a %cpu usage, this can indicate where the bottleneck is, for example my amd64 runs at about 75% CPU all the time with the viewer, its my graphics card that is my limiting factor. Regards Robin From kamilion at gmail.com Thu Jan 3 01:12:07 2008 From: kamilion at gmail.com (Kamilion) Date: Thu Jan 3 01:12:11 2008 Subject: [sldev] Why is Second-Life viewer so slow on Samsung Q1 uiltra? In-Reply-To: <477CA270.7060609@gmail.com> References: <0JU200D1A5ESQ0@mmp1.samsung.com> <477CA270.7060609@gmail.com> Message-ID: Replies inline. On Jan 3, 2008 12:53 AM, Robin Cornelius wrote: > ??? wrote: > > Hi~! Everyone, I'm wondering why is Second-Life viewer so slow on Samsung > > Q1 ultra? > > > > > How slow? how many frames per second do you get? and what are the > graphics settings in settings/graphics and advanced graphics set to. > Also draw distance what is this set to? My assumption is around 2-5FPS or less, from the performance I see in the aforementioned Fujitsu Lifebook in my last post. > > > Is it graphics driver problem? > > > > Let's check graphics accelerator driver Q1 has. It's Intel GMA 950 > > chipset. See the product specification > > (http://www.samsung.com/us/consumer/detail/spec.do?group=computersperipheral > > s&type=ultramobilepc&subtype=ultramobilepc&model_cd=NP- > > Q1U/600/SEA&fullspec=F) Q1 supports DirectX 9 and OpenGL 1.4. Current > > graphics driver version that is installed on my Q1: 6.14.10.4833 and latest > > version: 6.14.10.4864. It seems that's not key factor of our problem. > > > > Second-Life viewer self-problem? > > > > > According to the spec that graphics card only has 128Mb of *shared* > memory so it has to share bus time to get at the memory, for a processor > intensive application that uses a lot of physical and graphics memory > this could be a bad factor. > > Also how is the graphics chip connected into the system, on what bus? > Moving graphics things around is a huge overhead, i see *enormous* > difference if my graphics card is in my PCIex4 slot compared to my > PCIex16 slot. If its only on a x4 then this is not the best possible > situation. The graphics chip is integrated in the system's northbridge, therefore I'm not sure if it's even using PCI Express, or simply communicating directly over the FSB. The processor is an Intel A100 600Mhz Ultra Mobile PC (UMPC) low power chip. Since it's a UMPC, it lacks PCI Express *slots* entirely. Since PCIEx is a serial protocol, chances are it's still exposed somewhere on the mainboard, but slots are right out -- unless this specific UMPC has some sort of a dock with PCIEx devices within it, which isn't out of the question. The intel GMA 950 is part of the northbridge, directly connected to the CPU's FSB, so it's already handling addressing of the system memory in the same chip, therefore I doubt the shared memory architecture is causing a problem in itself. Also, how the heck do you fit a PCI Express X16 card into an X4 slot? It shouldn't be physically possible unless you file off the sliver of plastic at the rear of the slot... Unless it's a X16 slot with only 4 lanes connected, and you'd have to have a very crappy motherboard for this, as most SLI boards will have a full 16 lane X16 slot and a 8-lane X16 slot as the secondary, with most boards switching both slots into 8-lane in SLI mode with one of those little reversible cards or jumper blocks. > > You have 1GB of system ram which is normally acceptable (well is for me > under linux, no idea of the footprint of windows tablet). > Actually, it should have 896MB of system ram, since 128MB of the 1024MB is being grabbed by the graphics accelerator. > > Official viewer may have problem with GMA 950 series but I'm not sure what > > the problem is exactly. SecondLife doesn't make good harmony with OpenGL > > 1.4 ver.? If it's true of not, what is the critical problem point? As you > > know, my point is not chipset level, but graphics API level! > > > > > > How does your processor compare to other processors? I have no idea > about the processor, when you are running can you get a %cpu usage, this > can indicate where the bottleneck is, for example my amd64 runs at about > 75% CPU all the time with the viewer, its my graphics card that is my > limiting factor. > For a 600Mhz CPU, it *better* be using 100%. > > Regards > > Robin > -- Kamilion Schnook From robin.cornelius at gmail.com Thu Jan 3 08:58:22 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 3 08:57:00 2008 Subject: [sldev] Open source meeting call for agenda and info on my first agenda item. Message-ID: <477D142E.3030803@gmail.com> Anyone have any items for the agenda for Tonights/This afternoons meeting:- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda I have added one item that i would like to hear a little more about LLMozLib, i may have added it a bit late for Rob to get Callum involved (sorry .. again.. Rob for being so late with my item) . I would detail some of the questions here rather that fill the wiki or try to get them all out in world, as i have quite a few sub issues on the one topic:- *) We are seeing the released llmozlib slip behind the version used to build released secondlife clients, and even the released secondlife source code is requiring newer llmozlibs than we have code for. - Is there anything that can be done about this? - Any chance of keeping the llmozlib svn in closer sync with internal svn, no idea about your internal svn structure but llmozlib should hopefully be nowhere near the server code etc so can it just be kept up todate with out too much worring about releasing things you should not. - Would it be better to host llmozlib on sourceforge etc, so that the current version is always in the "wild" *) Version control - Can we possible update the version string in llmozlib when its updated, it seems to be stuck at 1.1.1 - Any chance of numbering releases instead of using a date as the version - Can we release a source tarball when things change and a new viewer is out and requires it? - Can we use sonames, eg when you change the library and have ABI breakage change from llmozlib0 to llmozlib1 (again the build environment should look after the fine details of this, you just need to declare the soname version number and remember to increment it where necessary). *) Build environment - Are you going to use cmake for llmozlib, a while back i was going to look into this myself but still have not had time and don't really want to expend effort if you have already done this or its not really wanted. - Can we have a build environment, currently its a set of instructions (again i have previously given example of a autotools build env for linux) *) Shared library - Can we build llmozlib as a shared library instead of statically linking it as we currently do? (yes it can be done, i do it) - Can we try to use XULRunner where possible instead of pulling apart mozilla trees. *) Bug tracker - Is it worth having llmozlib as a component on the bug tracker or even have its own bug tracker (if moved to sourceforge for example). I see people using the ubrowser mailing list who are playing with llmozlib for non secondlife projects *) Ubrowser.com - Looks like a project that stopped being worked on in 2006 - May be should link to llmozlib svn and any bug tracker? Sorry if it sounds like i am going on but these issues I believe all need addressing at some point. Thanks Robin From monkowsk at watson.ibm.com Thu Jan 3 09:46:16 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jan 3 09:46:22 2008 Subject: [META] Re: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> Message-ID: <477D1F68.60809@watson.ibm.com> Alissa, I can understand your frustration, and I am aware of the generous contributions that you have made toward improving the viewer, but from an impartial viewpoint, this seems a bit harsh. Yes, the version number changed, but there have been several notes on how to get around the forced updates: edit the version number or pick another channel name. (I guess somebody ought to put that out on the Wiki) I really doubt that anything else changed. I have no problem running the viewer compiled from the 76116 source with the version number changed to 76453. Between December 29 and January 2, I would guess there were 0 work days for most employees of Linden Lab. Actually there may have been 0 between December 22 and January 2. It's an important family-oriented holiday time in the US. As important as SecondLife may be, real life is always more important. :-) I agree with you that more transparency would improve the overall productivity, but I imagine in the depths of http://sljirastats.com/jira_search.php?search=30 there's not a lot of time for most LL developers to think about actually improving the process. We hope however, that a few are dedicated to that task. I hope you continue your contributions to SL, Alissa. Mike Alissa Sabre wrote: >>(1) The change was a single URL + release notes. > > > Hmm. I have several things to say on this issue, but I'm skillless to > say most of them politely in English. So just one point. > > My own WindLight viewer based on 76116 source with necessary URL > change can't connect to the grid because of the version checking. > It's natural. You surely changed version number as well as URL and > release note. You just forgot mentioning it. > > But... what else? I knew you forgot telling at least one important > thing. I was suspicious you also forgot one or two more things. > > >>(2) We plan on pushing out 1.18.6.4 with sources tomorrow > > > So you knew 1.18.6.4 is scheduled on January 3 when you announced > availability of 1.18.6.3 on December 29. > > Why you didn't say it on December? > > Linden employees' past practice when an open source developer > complained about the lack of future release schedules is to say > something like "Release sechedule is managed by someone else in the > company. I don't know it." > > I believe you are the first Linden employee who explicitly admitted > that you knew the future release schedule at least six days in > advance, had a very good chance to announce it, and kept that > information from open source developpers. Hmm... > > >>And the most practical reason... >> >>(3) I was feeling under the weather but happened to be on a street car >>passing by the Linden offices with my family when I got a call about the >>exploit. I hopped off the street car, came in to do the viewer builds >>and push them live, and caught up with my family at home (several hours >>later) and crawled into bed. > > > I'm really puzzled why you disclosed this private thing to the > public. Did you cried on open source developpers' shoulders? > > LL is a company that runs an online service. LL also says it is not > just fun but is a serious business infrastructure. I don't know your > responsibility in the company, but general understainding is that > whatever your position is, working for such a company means there are > chances you need to give up your private life on emergency situation. > I believe that's why you did the release of 1.18.6.2 on the day under > the said situation. That's totally fine. Thank you for doing it. > > Problem is that you just took care of binary distribution only and > kept open source developers out of scenes. > > Well, some private story on my side, then. I'm not earning money for > SL development. I'm just a sunday programmer. Literally I am. I > have almost no time on writing code on weekdays. So, holiday season > is the best timing to work on some big project. I planned something > on WindLight viewer on this holidays. Note that in Japan it comes > slightly late than US. It's typically Dec. 29 - Jan. 3... And this > sudden 1.18.6.3 (or more specifically FL 76453) mandatory update hit > this timing. I was so disappointed with it, and lost all my > motivation working on viewer changes... > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Thu Jan 3 10:16:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 3 10:16:22 2008 Subject: [sldev] Open source meeting call for agenda and info on my first agenda item. In-Reply-To: <477D142E.3030803@gmail.com> References: <477D142E.3030803@gmail.com> Message-ID: On 2008-01-03, at 10:58, Robin Cornelius wrote: > - Can we use sonames, eg when you change the library and have ABI > breakage change from llmozlib0 to llmozlib1 (again the build > environment should look after the fine details of this, you just > need to declare the soname version number and remember to increment > it where necessary). You mean llmozlib.so.1 to llmozlib.so.2? From robin.cornelius at gmail.com Thu Jan 3 13:38:16 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 3 13:36:51 2008 Subject: [sldev] Open source meeting call for agenda and info on my first agenda item. In-Reply-To: References: <477D142E.3030803@gmail.com> Message-ID: <477D55C8.50308@gmail.com> Argent Stonecutter wrote: > On 2008-01-03, at 10:58, Robin Cornelius wrote: >> - Can we use sonames, eg when you change the library and have ABI >> breakage change from llmozlib0 to llmozlib1 (again the build >> environment should look after the fine details of this, you just need >> to declare the soname version number and remember to increment it >> where necessary). > > You mean llmozlib.so.1 to llmozlib.so.2? Yes, exactly. Thats what i was trying to say :-) Thanks Robin From josh at lindenlab.com Thu Jan 3 15:27:24 2008 From: josh at lindenlab.com (Joshua Bell) Date: Thu Jan 3 15:29:32 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> Message-ID: <477D6F5C.3020008@lindenlab.com> (There is some content buried in this mail about halfway down. Look for the bullets. Most of the rest is me saying "yeah, we could do better") Alissa Sabre wrote: >> (1) The change was a single URL + release notes. >> > > My own WindLight viewer based on 76116 source with necessary URL > change can't connect to the grid because of the version checking. > It's natural. You surely changed version number as well as URL and > release note. You just forgot mentioning it. > You're right, I neglected to mention the version numbers as well. :( > So you knew 1.18.6.4 is scheduled on January 3 when you announced > availability of 1.18.6.3 on December 29. > > Why you didn't say it on December? > As previously mentioned: 1.18.6.3 was an emergency release. There wasn't a whole lot of time for planning, nor were there many Lindens around. We've done a poor job of sharing a release roadmap in the past; during a crisis, on a holiday, when there is a grand total of one person in the office, you don't get *improved* communication. > Linden employees' past practice when an open source developer > complained about the lack of future release schedules is to say > something like "Release sechedule is managed by someone else in the > company. I don't know it." > > I believe you are the first Linden employee who explicitly admitted > that you knew the future release schedule at least six days in > advance, had a very good chance to announce it, and kept that > information from open source developpers. Hmm... > It's not a conspiracy! Communication takes time, and competes with everything else. I probably could have fixed some bugs in our deploy mechanisms while I was writing this email, but answering your questions seemed like a more appropriate trade-off. In hindsight, yes, mentioning "we'll do another source drop soon" might have been worthwhile... but we're *always* going to do another source drop soon, and the likelyhood of any RC being followed by another one verges on 75%, so it just didn't occur to me. ... Since I *am* the person who manages the release schedule, here's the roadmap: * We're currently testing 1.18.6 RC4. A few of the fixes have failed internal QA, so there's going to need to be at least one more iteration. Additionally, we're seeing web site load balancer issues that are impacting logins, which we need to fix before 1.18.6 can go final. * We have *just* (within the hour) frozen the code for 1.19.0 as well, and will be doing a source drop shortly. Obviously, any further fixes to 1.18.6 will need to be back ported to 1.19.0. We want to get it out ASAP, but as this version has not had any sustained QA on it in a final state the quality is unknown. (All of the changes that went into this code base had sandbox testing, and integration testing as each piece merged in, but there hasn't been any "bake time".) * In an ideal world, 1.18.6 Viewer goes final circa January 17th, 1.19.0 Viewer is final circa January 31st. * It would be logical to expect 1.19.1 RC0 to occur some time around that date as well. There are a lot of caveats in the above roadmap, which means the dates are uncertain. I'd be somewhat reluctant to post this to the blog not out of worry of information disclosure but because the developers here on SLDEV are in a much better position to interpret the data and the uncertainty involved. (The other thing that folks on SLDEV should be able to infer from the above process is that it's pretty mechanical - freeze code, spit out RC0, RC1.... RCn until it's stabilized, make it final, repeat. At some point the thrill of explaining that loses its charm.) > > I'm really puzzled why you disclosed this private thing to the > public. Did you cried on open source developpers' shoulders? > You asked, I answered. I'm a fan of transparency. I also don't see an "us" vs. "them" here - we're all in this together. The answer to "why didn't you do a source drop?" was not "there's a vast conspiracy..." but "it was a crisis with limited resources." (Maybe I shared too much, but I was trying to be honest - it wasn't ideal circumstances for a release, so it didn't happen.) > Well, some private story on my side, then. I'm not earning money for > SL development. I'm just a sunday programmer. Literally I am. I > have almost no time on writing code on weekdays. So, holiday season > is the best timing to work on some big project. I planned something > on WindLight viewer on this holidays. Note that in Japan it comes > slightly late than US. It's typically Dec. 29 - Jan. 3... And this > sudden 1.18.6.3 (or more specifically FL 76453) mandatory update hit > this timing. I was so disappointed with it, and lost all my > motivation working on viewer changes... > I know how that goes - most of my personal projects get 2-3 hours a month of attention total, and it's hard to stay motivated. Any bug or blocker that can't be tackled in a short window is very demoralizing. ... As you might infer from this mail, I enjoy reading the traffic on SLDEV and wish I had more to contribute. If you haven't heard about an upcoming release roadmap recently enough, PLEASE email me directly. (I tend to be about 100 messages behind on SLDEV traffic.) From carjay at gmx.net Thu Jan 3 16:09:54 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Jan 3 16:10:01 2008 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <476D8F33.2070607@gmail.com> References: <47684BA0.7090506@sun.com> <47684E60.3090700@lindenlab.com> <476C73ED.7000903@gmx.net> <476D8F33.2070607@gmail.com> Message-ID: <477D7952.3070406@gmx.net> Robin Cornelius wrote: > Carsten Juttner wrote: >> Hm, the SVN seems no longer to be up to date, the header file for the RC >> 1.18.6.2 sources includes some additional methods: >> >> > I've marked this on JIRA > http://jira.secondlife.com/browse/VWR-3985 > > so it doesn't get forgotten :-) > Just to let you know, the SVN has been updated and both RC and Windlight client can be built with it now. Thanks for your efforts, Rob. Regards, Carsten From alexander.treptow at zweitgeist.com Fri Jan 4 07:28:09 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Jan 4 07:28:24 2008 Subject: [sldev] Worn Items/Objects Message-ID: <477E5089.9020006@zweitgeist.com> Hi, does anyone know how to render only the worn objects of my avatar. It maybe works by comparing the inventory items with the object list, but i dont know where to set. Anybody has any idea how to? a second question: how can i only draw my own eyes or are eyes the same as items that could be worn? greets, Alex From ts_ryuzo at hotmail.com Fri Jan 4 07:41:04 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Fri Jan 4 07:41:06 2008 Subject: [sldev] Updating the source code Message-ID: Hi, Once in a while, the game would prompt me to download new client as the client version I am using is outdated. Therefore I need to download a new source code and configure everything again. Is there anyway to work around it? Anyone can give me a detailed steps to do it? Regards, Zeph Wiefel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080104/3bfdb48e/attachment.htm From liana at lindenlab.com Fri Jan 4 08:26:20 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Fri Jan 4 08:26:25 2008 Subject: [sldev] SoCal Linux Expo - Feb 8-10 Message-ID: <477E5E2C.80606@lindenlab.com> Anyone else going to be at SCALE ? Let me know and I'll organize a meet-up or BoF for Saturday evening. Cheers, Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080104/34af7fd2/attachment.htm From josh at lindenlab.com Fri Jan 4 09:10:58 2008 From: josh at lindenlab.com (Josh Bell (Joshua Linden)) Date: Fri Jan 4 09:11:54 2008 Subject: [sldev] Updating the source code In-Reply-To: References: Message-ID: <477E68A2.7060507@lindenlab.com> See http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements Look in llcommon/llversionviewer.h You should see definitions for a channel (string) and version vector (4 fields) On login, we check the combination of channel plus version against a list. Within each channel, some versions are allowed and some are blocked. We block viewers that are unsafe (security issues), incompatible (we've changed the protocol in some fundamental way), not supported (so old we can't afford to provide support resources), or (most relevant here) are in a test channel (Release Candidate, First Look) and we only want test data from the most recent. Since this is a convenience for the residents and Linden, but (in most cases) not a technical requirement, if the channel/version pair doesn't match then we let the viewer through. So: simply change the channel to anything else, e.g. "Qian Hao's Most Excellent SL Viewer" and you won't get blocked. (If anyone wants to incorporate any of the above that isn't already well known and/or documented elsewhere into the aforementioned wiki page, that'd be swell.) Qian Hao ~ wrote: > Hi, > > Once in a while, the game would prompt me to download new > client as the client version I am using is outdated. Therefore > I need to download a new source code and configure everything > again. Is there anyway to work around it? Anyone can give me > a detailed steps to do it? > > Regards, > Zeph Wiefel > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tao.takashi at googlemail.com Fri Jan 4 09:16:43 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Fri Jan 4 09:16:48 2008 Subject: [sldev] Wiimote and Headtracking Message-ID: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> A happy new year to all of you! So is anybody already working on getting this into SL? ;-) http://mrtopf.de/blog/secondlife/wii-and-headtracking-wouldnt-this-be-great-for-second-life/ cheers, Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080104/61424e95/attachment.htm From monkowsk at watson.ibm.com Fri Jan 4 11:21:37 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jan 4 11:22:50 2008 Subject: [sldev] Updating the source code In-Reply-To: <477E68A2.7060507@lindenlab.com> References: <477E68A2.7060507@lindenlab.com> Message-ID: <477E8741.1040703@watson.ibm.com> Josh, I noticed that the MS Windows Desktop icon for the WindLight viewer has a command line argument -channel "Second Life WindLight" Does this override the value in llversionviewer.h so that we can set it on the command line rather than changing the source? Mike Josh Bell (Joshua Linden) wrote: > See > > http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements > > Look in llcommon/llversionviewer.h > > You should see definitions for a channel (string) and version vector (4 > fields) > > On login, we check the combination of channel plus version against a > list. Within each channel, some versions are allowed and some are > blocked. We block viewers that are unsafe (security issues), > incompatible (we've changed the protocol in some fundamental way), not > supported (so old we can't afford to provide support resources), or > (most relevant here) are in a test channel (Release Candidate, First > Look) and we only want test data from the most recent. > > Since this is a convenience for the residents and Linden, but (in most > cases) not a technical requirement, if the channel/version pair doesn't > match then we let the viewer through. > > So: simply change the channel to anything else, e.g. "Qian Hao's Most > Excellent SL Viewer" and you won't get blocked. > > (If anyone wants to incorporate any of the above that isn't already well > known and/or documented elsewhere into the aforementioned wiki page, > that'd be swell.) From rdw at lindenlab.com Fri Jan 4 11:55:55 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Fri Jan 4 11:56:30 2008 Subject: [sldev] Updating the source code In-Reply-To: <477E8741.1040703@watson.ibm.com> References: <477E68A2.7060507@lindenlab.com> <477E8741.1040703@watson.ibm.com> Message-ID: <477E8F4B.6030709@lindenlab.com> Mike Monkowski wrote: > Josh, > I noticed that the MS Windows Desktop icon for the WindLight viewer > has a command line argument > -channel "Second Life WindLight" > Does this override the value in llversionviewer.h so that we can set it > on the command line rather than changing the source? Yes. You can also stick command-line arguments in arguments.txt in the .app on os X and in gridargs.dat in the linux directory. -RYaN From george.williams at gmail.com Fri Jan 4 12:46:46 2008 From: george.williams at gmail.com (George Williams) Date: Fri Jan 4 12:46:49 2008 Subject: [sldev] Wiimote and Headtracking In-Reply-To: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> References: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> Message-ID: <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> Tao, I use head-tracking for rendering SL into a stereo head mounted display. The tracking is by polhemus though, not wii. -George On Jan 4, 2008 9:16 AM, Tao Takashi wrote: > A happy new year to all of you! > > So is anybody already working on getting this into SL? ;-) > > http://mrtopf.de/blog/secondlife/wii-and-headtracking-wouldnt-this-be-great-for-second-life/ > > > cheers, > > Tao > > -- > taotakashi@gmail.com > Blog: http://mrtopf.de > Planet: http://worldofsl.com > > RL: Christian Scholz, mrtopf@gmail.com > http://mrtopf.de > > Company: http://comlounge.net > Tech Video Blog: http://comlounge.tv > IRC: MrTopf/Tao_T > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080104/7326601c/attachment.htm From monkowsk at watson.ibm.com Fri Jan 4 13:42:53 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jan 4 13:43:00 2008 Subject: [sldev] Updating the source code In-Reply-To: <477E68A2.7060507@lindenlab.com> References: <477E68A2.7060507@lindenlab.com> Message-ID: <477EA85D.9050706@watson.ibm.com> Josh Bell (Joshua Linden) wrote: > (If anyone wants to incorporate any of the above that isn't already well > known and/or documented elsewhere into the aforementioned wiki page, > that'd be swell.) That page doesn't seem to be editable, but I put it here: http://wiki.secondlife.com/wiki/Get_source_and_compile#Channels_and_Versions and linked to that page. Mike From alissa_sabre at yahoo.co.jp Fri Jan 4 17:06:07 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jan 4 17:06:20 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <477D6F5C.3020008@lindenlab.com> References: <477D6F5C.3020008@lindenlab.com> Message-ID: <16PwwkJ4G5cG7YLtktrkh.alissa_sabre@yahoo.co.jp> Wow, thank you Joshua! > (There is some content buried in this mail about halfway down. > here's the roadmap: This is what I (and many of sldev members) wanted to know. It's nice to work with future timelines in mind. > There are a lot of caveats in the above roadmap, which means the dates > are uncertain. I know. That's fine. Thank you again for sharing this info. If it happened because of the 1.18.6.2 problem and consequent 1.18.6.3 distribution thing, the pain this week was worthwhile... Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From tlang303 at gmail.com Fri Jan 4 21:04:02 2008 From: tlang303 at gmail.com (Tobias Lang) Date: Fri Jan 4 21:04:04 2008 Subject: [sldev] Wiimote and Headtracking In-Reply-To: <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> References: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> Message-ID: <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> Hi, I integrated a VRPN binding in Second Life for our Augmented Reality enabled client http://arsecondlife.gvu.gatech.edu. VRPN is a way to support all kinds of trackers. I was planning to look into the feasibility to create a Wii based VRPN tracker, but before I startm I have to test how accurate Wii based tracking actually is... Does anyone here has experience with a Wii tracker and its performance? -Tobias On Jan 4, 2008 3:46 PM, George Williams wrote: > Tao, > > I use head-tracking for rendering SL into a stereo head mounted display. > The tracking is by polhemus though, not wii. > > -George > > On Jan 4, 2008 9:16 AM, Tao Takashi wrote: > > > A happy new year to all of you! > > > > So is anybody already working on getting this into SL? ;-) > > > > http://mrtopf.de/blog/secondlife/wii-and-headtracking-wouldnt-this-be-great-for-second-life/ > > > > > > cheers, > > > > Tao > > > > -- > > taotakashi@gmail.com > > Blog: http://mrtopf.de > > Planet: http://worldofsl.com > > > > RL: Christian Scholz, mrtopf@gmail.com > > http://mrtopf.de > > > > Company: http://comlounge.net > > Tech Video Blog: http://comlounge.tv > > IRC: MrTopf/Tao_T > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080105/24ab9d49/attachment.htm From tshephard at gmail.com Fri Jan 4 23:03:10 2008 From: tshephard at gmail.com (Tim Shephard) Date: Fri Jan 4 23:03:12 2008 Subject: [sldev] Reality as a VR Simulator and Model for Secondlife? Message-ID: <3b19a500801042303k48c48250ge74d7e4f111f28be@mail.gmail.com> Cool article via Slashdot http://arxiv.org/ftp/arxiv/papers/0801/0801.0337.pdf Brings me back to the days when Andrew Linden was complaining about the quantum effects of small objects with SL Physics. Maybe we should be modeling SL after quantum mechanics? This was an interesting quote: "It [his VR Hypothesis] could also solve the quantum measurement problem, as if our reality is in effect a processing interface, an observer viewing an object could indeed create it. Similarly in an online virtual world the entire world is not calculated onscreen at once. The computer, for practical reasons, only calculates what the viewer chooses to view after they choose to view it, i.e. screen calculations are as required. If what we call reality is a three-dimensional space-time interface, it would likewise be expected to be calculated only on demand." Fun stuff and an easy read. Recommend it to everyone. From tshephard at gmail.com Fri Jan 4 23:11:23 2008 From: tshephard at gmail.com (Tim Shephard) Date: Fri Jan 4 23:11:26 2008 Subject: [sldev] Wiimote and Headtracking In-Reply-To: <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> References: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> Message-ID: <3b19a500801042311n2ffb6dc2pf337c582d4106d68@mail.gmail.com> On Jan 4, 2008 9:04 PM, Tobias Lang wrote: > > Hi, > > I integrated a VRPN binding in Second Life for our Augmented Reality enabled > client http://arsecondlife.gvu.gatech.edu. VRPN is a way to support all > kinds of trackers. I was planning to look into the feasibility to create a > Wii based VRPN tracker, but before I startm I have to test how accurate Wii > based tracking actually is... Does anyone here has experience with a Wii > tracker and its performance? > > -Tobias > > > > > On Jan 4, 2008 3:46 PM, George Williams wrote: > > > > > Tao, > > > > I use head-tracking for rendering SL into a stereo head mounted display. > The tracking is by polhemus though, not wii. > > > > -George > > > > > > > > > > > > On Jan 4, 2008 9:16 AM, Tao Takashi wrote: > > > > > > > > > > > > > > A happy new year to all of you! > > > > > > So is anybody already working on getting this into SL? ;-) > > > > > > > http://mrtopf.de/blog/secondlife/wii-and-headtracking-wouldnt-this-be-great-for-second-life/ > > > > > > cheers, > > > > > > Tao > > > > > > -- > > > taotakashi@gmail.com > > > Blog: http://mrtopf.de > > > Planet: http://worldofsl.com > > > > > > RL: Christian Scholz, mrtopf@gmail.com > > > http://mrtopf.de > > > > > > Company: http://comlounge.net > > > Tech Video Blog: http://comlounge.tv > > > IRC: MrTopf/Tao_T > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From sly_squash at hotmail.com Sat Jan 5 03:30:55 2008 From: sly_squash at hotmail.com (Joshy Squashy) Date: Sat Jan 5 03:30:57 2008 Subject: [sldev] [VWR] VWR-1151 project files still valid for VS2005 source compilations? Message-ID: Hello, I'm slightly torn on the issue of how to go about setting up source compilations. On the one hand, still seems to recommend using the project files at , which saves a lot of work and seems to generate a lot cleaner compilation than I manage to do on my own despite feeling like I follow the manual documentation religiously. On the other hand, these files seem terribly out-of-date. So do you VS2005 devs still use them? What I would love to see would be if we could keep an updated zip of the VS2005 project files for each release, be it by continuing to add them to the JIRA or some other location. Hopefully it won't be too far down the road before we don't have to "convert" anything at all for it to work! ~Squash Otoro _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080105/251a1deb/attachment-0001.htm From sly_squash at hotmail.com Sat Jan 5 04:12:28 2008 From: sly_squash at hotmail.com (Joshy Squashy) Date: Sat Jan 5 04:12:31 2008 Subject: [sldev] [IDEA] Second Life Open Source Developers Forum? Message-ID: Hi again, I was wondering if there would be interest in setting up a Second Life Developers Forum. I hope this question does not hit too close to home considering the resources that we do have such as this mailing list and the Second Life Open Source wiki page. I think this would make it easier to organize threads dealing with specific questions about how the Second Life source code works, and would make it easier for users to filter out those threads that aren't as interesting to them. I suppose the wiki could be of use in this area, but to be blunt it's just too slow to navigate and rarely updated for me to peruse regularly. While I am very happy that we have the existing resources for discussing Second Life development (and that the Lindens released the source code at all!), I don't exactly feel like I'm swimming in documentation. Which in a way is fine; I've been a part of software projects before, and I know how it goes. I just think a forum devoted exclusively to discussing the Second Life source code would help developers fill in the gaps for each other's projects I'm aware that there are a number of forums already at . However, it seems to me that even the "Technical Talk" ones seem aimed at "users" of the client who are discussing Second Life as an application or development using LSL. I would be interested in a forum as a resource for developers working with the viewer source code itself. Squash Otoro _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080105/e2b21082/attachment.htm From secret.argent at gmail.com Sat Jan 5 04:28:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 5 04:28:17 2008 Subject: [sldev] Reality as a VR Simulator and Model for Secondlife? In-Reply-To: <3b19a500801042303k48c48250ge74d7e4f111f28be@mail.gmail.com> References: <3b19a500801042303k48c48250ge74d7e4f111f28be@mail.gmail.com> Message-ID: <6692FE7F-9CC6-43FE-B1CA-93DF34FF21F1@gmail.com> On 2008-01-05, at 01:03, Tim Shephard wrote: > "If what we call reality is a > three-dimensional space-time interface, it would likewise be expected > to be calculated only on demand." It would only be calculated on demand as required by the customers. And we're not the customers, we're content. From dzonatas at dzonux.net Sat Jan 5 07:18:45 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 5 07:19:13 2008 Subject: [sldev] [VWR] VWR-1151 project files still valid for VS2005 source compilations? In-Reply-To: References: Message-ID: <477F9FD5.1020002@dzonux.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080105/5e1bb435/attachment.htm From xybernetix at gmail.com Sat Jan 5 09:40:27 2008 From: xybernetix at gmail.com (Brandon (DEV)) Date: Sat Jan 5 09:40:40 2008 Subject: [Fwd: [sldev] [IDEA] Second Life Open Source Developers Forum?] Message-ID: <477FC10B.9090400@gmail.com> I would absolutely love the idea but would prefer it be a restricted forums for devs only to prevent trolling , as well as wth why did you do this? or why did you do thats? that you all to commonly find on other more "open" forums. Although I only hatched the idea of a closed forum solution I am not sure how exactly I would institute any of the policies. ~The Architech (sig coming soon) -------------- next part -------------- An embedded message was scrubbed... From: Joshy Squashy Subject: [sldev] [IDEA] Second Life Open Source Developers Forum? Date: Sat, 5 Jan 2008 06:12:28 -0600 Size: 7288 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20080105/0bd54435/sldevIDEASecondLifeOpenSourceDevelopersForum.eml From dmahalko at gmail.com Sat Jan 5 14:39:49 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jan 5 14:39:52 2008 Subject: [sldev] Commercial CAVEs / stereoscopic displays ??? Message-ID: I wasn't aware that CAVEs have moved beyond being merely a prototype research project that grad students hack together from spare parts, to being a full commercial product. I never hear anything about BARCO. I know they made CRT-based projectors years ago but I thought they went out of business and disappeared.. Boy was I wrong, after doing a random web search on them today.. I'm sure this is one of those "if you have to ask, you can't afford it" products: http://www.barco.com/projection_systems/images/I-Space_big.jpg BARCO I-Space: Multisided Cubic Immersive Space environment http://www.barco.com/corporate/en/products/product.asp?element=911 Also take a look at this easily reconfigurable VR screen. Make it a CAVE, or open it up, and flatten it out... whoah BARCO MoVE: Modular Virtual Environment http://www.barco.com/corporate/en/products/product.asp?element=893 What are we talking here, hundreds of thousands to millions of dollars for this sort of real-world, ready-to-use virtualization hardware?? :-) Has anyone tried using SL with CAVEs like this yet? (I expect a person would need to either be insanely rich or have access to a well-funded university to do it.) Some avatars in SL have these invisible keyboards that materialize when they type.... presumably you could really do that in an actual CAVEspace, controlling SL with a wholly-virtual user interface that appears out of nowhere and disappears when you don't need it, getting rid of the keyboard and mouse entirely. Though I'd expect any such 3D UI to control a 3D virtual world would have to be managed wholly locally by the client software on top of the virtual world. LSL doesn't have enough access to all the local client functions to be usable for building virtual replacements to the client UI. - Scalar Tardis / Dale Mahalko From bboomslang at googlemail.com Sat Jan 5 18:21:15 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sat Jan 5 18:21:17 2008 Subject: [sldev] animation priorities Message-ID: <347b550f0801051821oea13674he39d058d966acf20@mail.gmail.com> Hi folks, anybody out there looked into the animation priorities? Are they limited due to the message format or the server code, or is the priority limit just a clientside limit? Would it be easy to have more priorities for animations - so for example to allow hug animations to override AOs that use prio 4 for all their animations? Just changing the max value in the floater - of course - isn't enough, but I couldn't find the place where it is limited in the client sourcecode, so I guess it is somehow limited by the server or protocol? bye, Barney -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080106/23dcf7f3/attachment.htm From ts_ryuzo at hotmail.com Sun Jan 6 00:20:47 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sun Jan 6 00:20:48 2008 Subject: [sldev] Improving rendering sequence Message-ID: Hi all, I am looking into improving the performance of second life through changing the order of the rendering. The problem I notice is that sometimes it renders object that are occluded. For example, I saw an object being rendered and the next moment a wall was rendered in front of me and block off the object. In this case, isn't it better to render the wall first and render whatever behind it later? As I am new to the code, can anyone point me to where I can find the code? Currently I am looking at pipeline.cpp. Regards, Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080106/a91aa9dc/attachment.htm From secret.argent at gmail.com Sun Jan 6 04:02:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jan 6 04:02:48 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: Message-ID: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> I think what you're seeing is the order that objects are downloaded to the client from the server. Since the client doesn't know the wall is there until it's downloaded, there's probably not much you can do in the client to fix this. I have thought that it might be a good idea for the server to apply information about the distance of objects from the agent in building the interest list, but unfortunately we don't have the server source so it's likely there's little we can do about that from here. From gigstaggart at gmail.com Sun Jan 6 05:11:43 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jan 6 05:11:45 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: Message-ID: <4780D38F.1020003@gmail.com> Qian Hao ~ wrote: > I am looking into improving the performance of second life through > changing the order of the rendering. The problem I notice is that > sometimes it renders object that are occluded. For example, I saw an > object being rendered and the next moment a wall was rendered in front > of me and block off the object. In this case, isn't it better to render > the wall first and render whatever behind it later? When occlusion culling was first introduced, it was very aggressive and culled all hidden objects. This caused very visible artifacts at the time. I think it was tweaked to be less aggressive about culling since then, for a smoother visual experience. Something to keep in mind when messing in that code. I don't want to discourage you, I'm sure there's still room for improvement, I wouldn't expect any huge windfalls though. -Jason From ts_ryuzo at hotmail.com Sun Jan 6 07:36:43 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sun Jan 6 07:36:46 2008 Subject: [sldev] Improving rendering sequence Message-ID: How about if we use an algorithm to check the distance of objects on the client side before requesting for the object information? In this way, things will be rendered in the correct order. But I am not sure if doing so will improve the performance. I remember reading something about rendering of invisible primitive. Maybe it's a good idea to render these object last as they are not visible. Where can I find the code for this? Regards,Qian Hao> From: secret.argent@gmail.com> Subject: Re: [sldev] Improving rendering sequence> Date: Sun, 6 Jan 2008 06:02:42 -0600> To: sldev@lists.secondlife.com> > I think what you're seeing is the order that objects are downloaded > to the client from the server. Since the client doesn't know the wall > is there until it's downloaded, there's probably not much you can do > in the client to fix this. I have thought that it might be a good > idea for the server to apply information about the distance of > objects from the agent in building the interest list, but > unfortunately we don't have the server source so it's likely there's > little we can do about that from here.> > _______________________________________________> 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/20080106/9e72ad86/attachment.htm From secret.argent at gmail.com Sun Jan 6 08:25:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jan 6 08:25:53 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> Message-ID: <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> On 2008-01-06, at 09:35, Qian Hao ~ wrote: > How about if we use an algorithm to check the distance of objects > on the client side before requesting for the object information? I guess I wasn't clear enough. What I mean is that what I think you are seeing is the order in which the server is telling the client about the objects. The client is rendering the objects that it knows about, in each frame, and is in fact culling objects so that closer objects are shown and hidden objects, further away, are not shown. That is, for the objects the client knows about, it is doing what you want. The objects the client does not know about, even if they are closer, can not be rendered until the server downloads them. From ts_ryuzo at hotmail.com Sun Jan 6 17:17:27 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sun Jan 6 17:17:28 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> Message-ID: I see... Correct me if I am wrong. So the server will just send all the objects that are in the scene, including those that are occluded or culled. The client side will then do culling and occlusion based on what it has received so far. Therefore even if there is a wall infront, but if the client has not receive any information about it yet, things behind it can be seen. Then my next question is, how does the server know what to send to the client? The server execute a raytracing algorithm? So the client is not the one requesting for object information? Regards, Qian Hao > From: secret.argent@gmail.com> Subject: Re: [sldev] Improving rendering sequence> Date: Sun, 6 Jan 2008 10:25:47 -0600> To: sldev@lists.secondlife.com> > On 2008-01-06, at 09:35, Qian Hao ~ wrote:> > How about if we use an algorithm to check the distance of objects > > on the client side before requesting for the object information?> > I guess I wasn't clear enough.> > What I mean is that what I think you are seeing is the order in which > the server is telling the client about the objects. The client is > rendering the objects that it knows about, in each frame, and is in > fact culling objects so that closer objects are shown and hidden > objects, further away, are not shown.> > That is, for the objects the client knows about, it is doing what you > want. The objects the client does not know about, even if they are > closer, can not be rendered until the server downloads them.> > _______________________________________________> 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/20080107/602d4b11/attachment.htm From gigstaggart at gmail.com Sun Jan 6 17:20:27 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jan 6 17:20:30 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> Message-ID: <47817E5B.9060909@gmail.com> Qian Hao ~ wrote: > Then my next question is, how does the server know what to send to > the client? The server execute a raytracing algorithm? So the client > is not the one requesting for object information? There's a subscription system, I believe controlled by both the client and the server. -Jason From mark at 3demb.com Sun Jan 6 19:25:07 2008 From: mark at 3demb.com (Mark Dubin) Date: Sun Jan 6 19:25:21 2008 Subject: [sldev] Re: Commercial CAVEs / stereoscopic displays Message-ID: <43F43985-CEFD-4D95-BC22-8D5B46A40AE8@3demb.com> Hi Folks, Dale Mahalko wrote on Jan 5, 2008 a note about stereo display of SL: > (clip) > Has anyone tried using SL with CAVEs like this yet? (I expect a person > would need to either be insanely rich or have access to a well-funded > university to do it.) > (clip) When my University had a CAVE a few years ago (now closed) we successfully viewed many scenes basically similar to parts of SL SIMs. I am now retired, and managing partner is a small startup (3D Embodiment, LLC, http://3demb.com) that provides immersive 3D displays in real life, and that is developing content in SL on our Embodiment Island. In part, we are investing in SL because we were aware that viewing it in stereo was coming. The references Dale gave to BARCO reflect what is available from a number of commercial firms, at relatively high cost. For example, a vender of interest is Fakespace (http://www.fakespace.com). However, one does not need a full-fledged, multi-walled CAVE to get the benefit of human-scale immersive visualization type, virtual reality. A more affordable solution is the GeoWall (http:// geowall.geo.lsa.umich.edu/intro.html) type system. I like to think of this as essentially a one-wall cave (bordering on being an oxymoron). It is a single screen that reproduces the front wall of a CAVE at whatever size one chooses to use. Installation can be permanent (I still do research at our lab using ceiling mounted projectors and an 8' X 11' front-projection screen) or portable, such as the setup my company uses for demonstrations on a 5' X 8' portable screen. I can report that stereo SL looks very good on this portable setup. A Geowall system is "relatively" low cost. You need: two DLP projectors, a polarization retaining screen, polarizing filters and glasses, and a normal PC with a good two-headed graphics card (we use Nvidia Quadro cards, FX-3450 or better). Starting from scratch, a very good system can be build for about $7,000 (or less). The GeoWall website has lots of details, and I will be happy to provide more info to anyone who wants it. With advances in projector technology and decreasing prices, I think a system could be built even more cheaply in the coming year. "Threedee Shepherd"/Mark Dubin From george.williams at gmail.com Sun Jan 6 19:55:33 2008 From: george.williams at gmail.com (George Williams) Date: Sun Jan 6 19:55:36 2008 Subject: [sldev] Re: Commercial CAVEs / stereoscopic displays In-Reply-To: <43F43985-CEFD-4D95-BC22-8D5B46A40AE8@3demb.com> References: <43F43985-CEFD-4D95-BC22-8D5B46A40AE8@3demb.com> Message-ID: <85e6f7f00801061955h563f6626leb88a39f7900780e@mail.gmail.com> Regarding DLP and Stereo and SL... If anyone is interested ( and in Las Vegas for CES this week ), I will be showing SL in stereo on a SamSung DLP Stereo-enabled HDTV. Interaction via Wii. Just swing by the TI booth starting Tuesday. I apologize for the shameless plug :) -George On Jan 6, 2008 7:25 PM, Mark Dubin wrote: > Hi Folks, > > Dale Mahalko wrote on Jan 5, 2008 a note about stereo display of SL: > > > (clip) > > Has anyone tried using SL with CAVEs like this yet? (I expect a person > > would need to either be insanely rich or have access to a well-funded > > university to do it.) > > (clip) > > > When my University had a CAVE a few years ago (now closed) we > successfully viewed many scenes basically similar to parts of SL > SIMs. I am now retired, and managing partner is a small startup (3D > Embodiment, LLC, http://3demb.com) that provides immersive 3D > displays in real life, and that is developing content in SL on our > Embodiment Island. In part, we are investing in SL because we were > aware that viewing it in stereo was coming. > > The references Dale gave to BARCO reflect what is available from a > number of commercial firms, at relatively high cost. For example, a > vender of interest is Fakespace (http://www.fakespace.com). > > However, one does not need a full-fledged, multi-walled CAVE to get > the benefit of human-scale immersive visualization type, virtual > reality. A more affordable solution is the GeoWall (http:// > geowall.geo.lsa.umich.edu/intro.html) type system. I like to think > of this as essentially a one-wall cave (bordering on being an > oxymoron). It is a single screen that reproduces the front wall of a > CAVE at whatever size one chooses to use. Installation can be > permanent (I still do research at our lab using ceiling mounted > projectors and an 8' X 11' front-projection screen) or portable, such > as the setup my company uses for demonstrations on a 5' X 8' portable > screen. I can report that stereo SL looks very good on this portable > setup. > > A Geowall system is "relatively" low cost. You need: two DLP > projectors, a polarization retaining screen, polarizing filters and > glasses, and a normal PC with a good two-headed graphics card (we use > Nvidia Quadro cards, FX-3450 or better). Starting from scratch, a > very good system can be build for about $7,000 (or less). The GeoWall > website has lots of details, and I will be happy to provide more info > to anyone who wants it. With advances in projector technology and > decreasing prices, I think a system could be built even more cheaply > in the coming year. > > "Threedee Shepherd"/Mark Dubin > _______________________________________________ > 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/20080106/2e5688c8/attachment.htm From dmahalko at gmail.com Sun Jan 6 22:23:56 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Jan 6 22:23:58 2008 Subject: [sldev] Re: Commercial CAVEs / stereoscopic displays In-Reply-To: <85e6f7f00801061955h563f6626leb88a39f7900780e@mail.gmail.com> References: <43F43985-CEFD-4D95-BC22-8D5B46A40AE8@3demb.com> <85e6f7f00801061955h563f6626leb88a39f7900780e@mail.gmail.com> Message-ID: Personally I see no problem with mentioning it even if for commercial purposes, since the integration of SL with stereo-3D technology is currently highly uncommon. Any work to raise awareness of doing it seems like a good thing. It would be nice if there were someone doing reviews of stereo-capable hardware as to the speed, clarity, usable framerates, and reliability of the hardware. But it is such a niche and expensive market right now that no common person can afford to buy this stuff to review it. There is no "Tom's 3D-Stereo Hardware".. :-) The whole standing-VR thing is going to have to go, in my opinion. I get major foot and leg pain from standing for just a few hours, but all these active VR things for for "real work" and interaction seem optimized for standing. I need a chair in there. On 1/6/08, George Williams wrote: > Regarding DLP and Stereo and SL... > > If anyone is interested ( and in Las Vegas for CES this week ), I will be > showing SL in stereo on a SamSung DLP Stereo-enabled HDTV. Interaction via > Wii. Just swing by the TI booth starting Tuesday. > > I apologize for the shameless plug :) From davep at lindenlab.com Mon Jan 7 09:30:46 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Jan 7 09:30:52 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <47817E5B.9060909@gmail.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> Message-ID: <478261C6.5020609@lindenlab.com> The client sends camera frustum information to the server, and the server sends the client information about objects that are "interesting" based on that information. Internally, we refer to this logic as the "interest list," and it's unfortunately implemented entirely server side. The gist of our streaming is "stream objects, ask for textures." Since the network load of a prim is much less than a texture, occlusion culling saves bandwidth by never requesting texture data for occluded objects. Unfortunately, since the interest list is based solely on size vs. distance for sending prims, occluders are often not sent first, so every texture is visible for at least one frame. It's usually OK, because the requested amount of a texture to download atrophies quickly when the texture is not being rendered, lowering its priority as soon as it is occluded. There may be optimization opportunities in the texture download prioritizing code. As far as front-to-back rendering goes to reduce overdraw, work has been done to this end in windlight, but has more to do with changing the order of specific types of geometry rather than reordering prims. In windlight, terrain is rendered after prims, sky is rendered last, etc. Occlusion culling was also rewritten in windlight to use fewer triangles and fewer "guess" queries, getting rid of the "guess" queue and making sure that if something is not visible, it's never rendered. The biggest issue with occlusion culling performance is that very few builds have any significant occluders due to overuse of transparencies and walls that leak (have cracks between prims). I'd encourage any builders to take a good look at how professional level designers layout environments in video games. In "World of Warcraft," for example, there are no windows, and you can never see the complex items inside a building from the outside. In "Call of Duty 4," there are plenty of windows, but you can never see into a window on one side of the building and out the window on the other side, effectively making every building an occluder. Compare this to Second Life, where every building has floor to ceiling windows and no inside walls. Some simple tricks to keep your windows and not kill performance are to make your windows opaque from the outside. This is the perception people have of windows in real life, so doing this will often make a build look "cleaner" or less cluttered. Some builds that play really well with occlusion culling are the cyberpunk city in Suffugium and the giant cube maze in Q. Let me know if you know of others. The other major limiting factor for performance in SL is the small batch size. On average, SL draws about 70 triangles per drawing call. In theory, increasing that number to 200 triangles per drawing call could improve rendering performance by 200%. The primary reason the draw size is so small is because we have to break batches to switch textures and to sort transparent objects to be rendered in depth order. This is why people in the graphics world are making such a fuss over "megatexturing" and similar techniques. These techniques combine all visible textures into a single large texture so all your geometry can be rendered with a single draw call. These techniques require artist intervention from the get go, however, so most are not applicable to SL. The technique that is applicable is good ol' fashioned texture atlasing, which is merely combining several textures into a single texture and modifying object texture coordinates to reference the part of that larger texture that contains the texture the object was originally referencing. Since textures in SL are streaming, though, generating atlases for your builds will result in ugly artifacts as textures load, so the correct solution is probably something between megatexturing and atlasing, where atlases are generated on-the-fly by the viewer and tailored to align texture borders within the atlas along mip borders according to the amount of the texture that's been downloaded so far. We've (somewhat intentionally) done a very poor job at Linden Lab of educating builders on how to be performance conscious, which I think plays a large part in the overall sluggishness of the viewer. This is part of a philosophy that says it should be possible to build a content authoring system where artists don't need to care about performance implications, as the software should just deal with whatever comes its way appropriately. What we've seen, however, is that people (even technically minded people) consume as many resources as are available to them until performance reaches a level they deem is unacceptable, so the more efficient your renderer becomes, the more ludicrous the demands become. In SL, this usually means the performance becomes that of the lowest common denominator in terms of what is acceptable. That is, if you think performance is important and build a nice house with opaque window exteriors and few textures, you'll still have a bad experience if your neighbor thinks a flexi-prim bamboo forest is the bees knees. The free market is winning out here (Otherland sims and similar, managed estates do better than private estates with no building standards), but it's slow going, and an initiative to document the best ways to build beautifully and efficiently is probably in order. Jason Giglio wrote: > Qian Hao ~ wrote: > >> Then my next question is, how does the server know what to send to >> the client? The server execute a raytracing algorithm? So the client >> is not the one requesting for object information? >> > > There's a subscription system, I believe controlled by both the client > and the server. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From davep at lindenlab.com Mon Jan 7 09:44:27 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Jan 7 09:44:29 2008 Subject: [sldev] Re: Commercial CAVEs / stereoscopic displays In-Reply-To: References: <43F43985-CEFD-4D95-BC22-8D5B46A40AE8@3demb.com> <85e6f7f00801061955h563f6626leb88a39f7900780e@mail.gmail.com> Message-ID: <478264FB.6020809@lindenlab.com> I've been a fan of stereo3d for awhile, but it's been a year since the last update. http://www.stereo3d.com/ Dale Mahalko wrote: > Personally I see no problem with mentioning it even if for commercial > purposes, since the integration of SL with stereo-3D technology is > currently highly uncommon. Any work to raise awareness of doing it > seems like a good thing. > > It would be nice if there were someone doing reviews of stereo-capable > hardware as to the speed, clarity, usable framerates, and reliability > of the hardware. But it is such a niche and expensive market right now > that no common person can afford to buy this stuff to review it. There > is no "Tom's 3D-Stereo Hardware".. :-) > > The whole standing-VR thing is going to have to go, in my opinion. I > get major foot and leg pain from standing for just a few hours, but > all these active VR things for for "real work" and interaction seem > optimized for standing. I need a chair in there. > > > On 1/6/08, George Williams wrote: > >> Regarding DLP and Stereo and SL... >> >> If anyone is interested ( and in Las Vegas for CES this week ), I will be >> showing SL in stereo on a SamSung DLP Stereo-enabled HDTV. Interaction via >> Wii. Just swing by the TI booth starting Tuesday. >> >> I apologize for the shameless plug :) >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From monkowsk at watson.ibm.com Mon Jan 7 10:13:56 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jan 7 10:14:12 2008 Subject: [sldev] Wiimote and Headtracking In-Reply-To: <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> References: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> Message-ID: <47826BE4.4000806@watson.ibm.com> See http://www.cs.cmu.edu/~johnny/projects/wii/ Tobias Lang wrote: > Hi, > > I integrated a VRPN binding in Second Life for our Augmented Reality > enabled client http://arsecondlife.gvu.gatech.edu > . VRPN is a way to support all > kinds of trackers. I was planning to look into the feasibility to create > a Wii based VRPN tracker, but before I startm I have to test how > accurate Wii based tracking actually is... Does anyone here has > experience with a Wii tracker and its performance? From monkowsk at watson.ibm.com Mon Jan 7 10:21:56 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jan 7 10:22:13 2008 Subject: [sldev] Worn Items/Objects In-Reply-To: <477E5089.9020006@zweitgeist.com> References: <477E5089.9020006@zweitgeist.com> Message-ID: <47826DC4.8040207@watson.ibm.com> alexander treptow wrote: > Hi, > does anyone know how to render only the worn objects of my avatar. > It maybe works by comparing the inventory items with the object list, > but i dont know where to set. > > Anybody has any idea how to? > > a second question: > how can i only draw my own eyes or are eyes the same as items that could > be worn? I'm not sure what you mean by "render only the worn objects of my avatar." Do you mean to not render those of any other avatar? Or not render objects that are not worn by any avatar? Or not render the avatar, just its worn objects? Or ...? Regarding Eyes: If you go to Edit->Appearance->Eyes and click on the Iris image, you get the opportunity to use your own texture. Mike From matthew.dowd at hotmail.co.uk Mon Jan 7 10:59:23 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jan 7 10:59:25 2008 Subject: [sldev] Jira down? In-Reply-To: <47826DC4.8040207@watson.ibm.com> References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> Message-ID: Although not mentioned explicitly in the blog, are the login problems also affecting jira - I've been unable to log in all day (very slow to respond to the logon page, and when it does I get "The credentials you provided cannot be determined to be authentic.") Matthew _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From rdw at lindenlab.com Mon Jan 7 11:16:05 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jan 7 11:16:09 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478261C6.5020609@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: <47827A75.4000403@lindenlab.com> Dave Parks wrote: > you'll still have a bad experience if > your neighbor thinks a flexi-prim bamboo forest is the bees knees. > > It is too the bees knees! -RYaN From phoenix at secondlife.com Mon Jan 7 11:27:35 2008 From: phoenix at secondlife.com (Phoenix) Date: Mon Jan 7 11:27:44 2008 Subject: [sldev] Jira down? In-Reply-To: References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> Message-ID: We are aware of this issue. There was something odd in the authentication system internally, which has been fixed and that system now passes it's tests. However, authentication still fails. I can announce when it is operational. On 2008-01-07, at 10:59, Matthew Dowd wrote: > Although not mentioned explicitly in the blog, are the login > problems also affecting jira - I've been unable to log in all day > (very slow to respond to the logon page, and when it does I get > "The credentials you provided cannot be determined to be authentic.") > > Matthew > -------------- 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/20080107/ce1a7e47/PGP.pgp From gigstaggart at gmail.com Mon Jan 7 11:52:45 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jan 7 11:52:47 2008 Subject: [sldev] Making builders/scripters performance conscious. Was: Improving rendering sequence In-Reply-To: <478261C6.5020609@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: <4782830D.3060301@gmail.com> Dave Parks wrote: > plays a large part in the overall sluggishness of the viewer. This is > part of a philosophy that says it should be possible to build a content > authoring system where artists don't need to care about performance > implications, as the software should just deal with whatever comes its On a related note, I saw mentioned a *long* time ago, a small display in the client giving users some idea of the load their attachments were causing. This was in the context of scripts, but it could be extended to polygons too. As you said, the free market takes care of things. So give users a tool they can use to measure the products they are buying. People may leave bad reviews for the "ultra bling hair" they bought that has open listens with color changing scripts in all 255 twisted torus prims, if they only had some way to know that it was their hair that was helping to lag the sim down. It doesn't matter that some users won't care, the few that do will do the job of educating the builder/scripter for you. Let the free market put pressure on inefficient creators by giving customers the tools to see how much lag they are causing. -Jason From jhurliman at wsu.edu Mon Jan 7 12:02:27 2008 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jan 7 12:02:30 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478261C6.5020609@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: <47828553.4050703@wsu.edu> Dave Parks wrote: > The other major limiting factor for performance in SL is the small batch > size. On average, SL draws about 70 triangles per drawing call. In > theory, increasing that number to 200 triangles per drawing call could > improve rendering performance by 200%. The primary reason the draw size > is so small is because we have to break batches to switch textures and > to sort transparent objects to be rendered in depth order. This is why > people in the graphics world are making such a fuss over "megatexturing" > and similar techniques. These techniques combine all visible textures > into a single large texture so all your geometry can be rendered with a > single draw call. These techniques require artist intervention from the > get go, however, so most are not applicable to SL. The technique that is > applicable is good ol' fashioned texture atlasing, which is merely > combining several textures into a single texture and modifying object > texture coordinates to reference the part of that larger texture that > contains the texture the object was originally referencing. Since > textures in SL are streaming, though, generating atlases for your builds > will result in ugly artifacts as textures load, so the correct solution > is probably something between megatexturing and atlasing, where atlases > are generated on-the-fly by the viewer and tailored to align texture > borders within the atlas along mip borders according to the amount of > the texture that's been downloaded so far. > I'm working on a UV mapping program for prims (http://wiki.secondlife.com/wiki/Prim_Mapper) (http://www.jhurliman.org/images/primpreview-04.png) that should make it easier for content creators to map full linksets to a single texture as well as do texture editing in Maya, Deep Paint 3D, etc. In theory, a linkset that has no alpha and all shares the same texture should be processed in a single batch correct? John From secret.argent at gmail.com Mon Jan 7 12:05:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 7 12:06:00 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478261C6.5020609@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> On 2008-01-07, at 11:30, Dave Parks wrote: > become. In SL, this usually means the performance becomes that of the > lowest common denominator in terms of what is acceptable. That is, if > you think performance is important and build a nice house with opaque > window exteriors and few textures, you'll still have a bad > experience if > your neighbor thinks a flexi-prim bamboo forest is the bees knees. I've had to put invisiprims behind alpha textured backdrops on a few occasions. This works pretty well, because invisiprims invoke culling, but the alpha texture and the invisiprim both show the sky. Question: how do sculpties interact with culling? A few things that I would like to see in the texture handling, that would improve things immensely: 1a. Define some texture as "transparent - never rendered", and stick it in the library. If a face uses that texture, throw away its geometry completely unless you're in edit mode. Then we can texture completely hidden faces with that texture and eliminate their geometry. This would be particularly useful for "one sided" prims (like signs on walls). As a bonus, this texture would be transparent to touch. Or, 1b. Add a prim face parameter "don't render" that you can set from script or the editor. 2a. Increase the "hang time" for sculpt textures. Maybe increase their priority arbitrarily, or 2b. Implement llSetSculptTextureAnim() with similar parameters to llSetTextureAnim() 3. Put the invisiprim textures and a 100% transparent texture in the library. 4. If possible, tag textures (on upload, and with a background sweep through the db) that have 0 in the alpha channel for every pixel throughout so they're all handled by the client as a single 100% alpha texture (tel the client the UUID is the UUID of '100% transparent' from #3). 5. If possible, remove the alpha channel (on upload, and with a background sweep through the db) from textures that have 255 in the alpha channel for every pixel, so that textures that get uploaded as 32 bit by accident quit being alpha hogs. 6a. Load attachments before unattached prims. Load my OWN attachments first. Or 6b. Render avatars with unloaded attachments with some kind of placeholder. From tofu.linden at lindenlab.com Mon Jan 7 12:21:59 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Jan 7 12:22:36 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> Message-ID: <478289E7.40007@lindenlab.com> Argent Stonecutter wrote: > Question: how do sculpties interact with culling? The same as any other prim, I believe. From xotmid at gmail.com Mon Jan 7 12:27:00 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Jan 7 12:27:03 2008 Subject: [sldev] Wiimote and Headtracking In-Reply-To: <47826BE4.4000806@watson.ibm.com> References: <23bbb49e0801040916p5b2a6f3al53dc241b128c4a51@mail.gmail.com> <85e6f7f00801041246t146e4a8dn3b78b03eece13f03@mail.gmail.com> <66bc8ec50801042104m4fe32274wfaa3fb1553a0b7f5@mail.gmail.com> <47826BE4.4000806@watson.ibm.com> Message-ID: Actually the wi remote thing should be easy.. there is a api for it.. On Jan 7, 2008 12:13 PM, Mike Monkowski wrote: > See http://www.cs.cmu.edu/~johnny/projects/wii/ > > Tobias Lang wrote: > > Hi, > > > > I integrated a VRPN binding in Second Life for our Augmented Reality > > enabled client http://arsecondlife.gvu.gatech.edu > > . VRPN is a way to support all > > kinds of trackers. I was planning to look into the feasibility to create > > a Wii based VRPN tracker, but before I startm I have to test how > > accurate Wii based tracking actually is... Does anyone here has > > experience with a Wii tracker and its performance? > _______________________________________________ > 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/20080107/0c03eecc/attachment.htm From matthew.dowd at hotmail.co.uk Mon Jan 7 12:55:45 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jan 7 12:55:47 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478289E7.40007@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> Message-ID: I would guess that they behave as if they were the unsculpted base prim (which is normally a spheroid) for culling - the sculpted surface playing no part itself in the culling in the same way it doesn't take part in collision detecting. Matthew ---------------------------------------- > Date: Mon, 7 Jan 2008 12:21:59 -0800 > From: tofu.linden@lindenlab.com > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Improving rendering sequence > > Argent Stonecutter wrote: >> Question: how do sculpties interact with culling? > > The same as any other prim, I believe. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From secret.argent at gmail.com Mon Jan 7 13:47:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 7 13:47:10 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478289E7.40007@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> Message-ID: <614772A9-F12C-446C-9F2D-C5FF5DE168DD@gmail.com> On 2008-01-07, at 14:21, Tofu Linden wrote: > Argent Stonecutter wrote: >> Question: how do sculpties interact with culling? > > The same as any other prim, I believe. So the final rendered mesh is used for the culling calculations, not some simplified version? From baba at libsecondlife.org Mon Jan 7 14:30:25 2008 From: baba at libsecondlife.org (Baba) Date: Mon Jan 7 14:33:50 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> Message-ID: <4782A801.2090007@libsecondlife.org> Quoting John Hurliman here whose email server is on vacation. "the client occlusion culling is ignorant of things like prim types since it happens at the opengl level working on meshes using GL_ARB_occlusion_query, while the simulator physics engine uses mostly rough approximations of objects and the two share nothing at all in common" Baba On Mon, Jan 07, 2008 12:55, Matthew Dowd wrote: > I would guess that they behave as if they were the unsculpted base prim (which is normally a spheroid) for culling - the sculpted surface playing no part itself in the culling in the same way it doesn't take part in collision detecting. > > Matthew > > > ---------------------------------------- > >> Date: Mon, 7 Jan 2008 12:21:59 -0800 >> From: tofu.linden@lindenlab.com >> To: sldev@lists.secondlife.com >> Subject: Re: [sldev] Improving rendering sequence >> >> Argent Stonecutter wrote: >> >>> Question: how do sculpties interact with culling? >>> >> The same as any other prim, I believe. >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > Get Hotmail on your mobile, text MSN to 63463! > http://mobile.uk.msn.com/pc/mail.aspx_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From phoenix at secondlife.com Mon Jan 7 14:36:13 2008 From: phoenix at secondlife.com (Phoenix) Date: Mon Jan 7 14:36:23 2008 Subject: [sldev] authentication working again Message-ID: The jira and mediawiki instances are authenticating correctly. A misconfigured firehol blocked access into the service. -------------- 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/20080107/ec6ebc26/PGP-0001.pgp From davep at lindenlab.com Mon Jan 7 14:40:09 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Jan 7 14:39:46 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <47828553.4050703@wsu.edu> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <47828553.4050703@wsu.edu> Message-ID: <4782AA49.5080804@lindenlab.com> John Hurliman wrote: > In theory, a > linkset that has no alpha and all shares the same texture should be > processed in a single batch correct? > > Right. Batches are divided by texture, fullbright, shiny, transparent, and glow, and which spatial group they're in (view spatial groups with the octree info display). Animated texture coordinates also break batches as they're done with a texture matrix. From davep at lindenlab.com Mon Jan 7 14:42:02 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Jan 7 14:41:39 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <4782A801.2090007@libsecondlife.org> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> <4782A801.2090007@libsecondlife.org> Message-ID: <4782AABA.1060806@lindenlab.com> He's right. Baba wrote: > Quoting John Hurliman here whose email server is on vacation. > > "the client occlusion culling is ignorant of things like prim types > since it happens at the opengl level working on meshes using > GL_ARB_occlusion_query, while the simulator physics engine uses mostly > rough approximations of objects and the two share nothing at all in > common" > > > Baba > > > On Mon, Jan 07, 2008 12:55, Matthew Dowd wrote: >> I would guess that they behave as if they were the unsculpted base >> prim (which is normally a spheroid) for culling - the sculpted >> surface playing no part itself in the culling in the same way it >> doesn't take part in collision detecting. >> >> Matthew >> >> >> ---------------------------------------- >> >>> Date: Mon, 7 Jan 2008 12:21:59 -0800 >>> From: tofu.linden@lindenlab.com >>> To: sldev@lists.secondlife.com >>> Subject: Re: [sldev] Improving rendering sequence >>> >>> Argent Stonecutter wrote: >>> >>>> Question: how do sculpties interact with culling? >>>> >>> The same as any other prim, I believe. >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> >> _________________________________________________________________ >> Get Hotmail on your mobile, text MSN to 63463! >> http://mobile.uk.msn.com/pc/mail.aspx_______________________________________________ >> >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Mon Jan 7 15:08:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 7 15:08:51 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <4782A801.2090007@libsecondlife.org> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> <4782A801.2090007@libsecondlife.org> Message-ID: On 2008-01-07, at 16:30, Baba wrote: > Quoting John Hurliman here whose email server is on vacation. > > "the client occlusion culling is ignorant of things like prim types > since it happens at the opengl level working on meshes using > GL_ARB_occlusion_query, while the simulator physics engine uses > mostly rough approximations of objects and the two share nothing at > all in common" Thanks, much appreciated. From warkirby3333 at hotmail.co.uk Mon Jan 7 15:25:27 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Mon Jan 7 15:25:29 2008 Subject: [sldev] RE: Don't render property/texture In-Reply-To: <20080107223625.5464D41B526@stupor.lindenlab.com> References: <20080107223625.5464D41B526@stupor.lindenlab.com> Message-ID: > 1a. Define some texture as "transparent - never rendered", and stick > it in the library. If a face uses that texture, throw away its > geometry completely unless you're in edit mode. Then we can texture > completely hidden faces with that texture and eliminate their > geometry. This would be particularly useful for "one sided" prims > (like signs on walls). As a bonus, this texture would be transparent > to touch. Or, > 1b. Add a prim face parameter "don't render" that you can set from > script or the editor. Argent mentioned the above among a few optimisations. I'd like to say I don't think that would be a good idea, as it would be open to abuse. for example, a griefer cage set to not render. It would be very exploited in a lot of weapons _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From lenglish5 at cox.net Mon Jan 7 16:02:37 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jan 7 16:02:40 2008 Subject: [sldev] Jira down? In-Reply-To: References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> Message-ID: <4782BD9D.1030407@cox.net> Matthew Dowd wrote: > Although not mentioned explicitly in the blog, are the login problems also affecting jira - I've been unable to log in all day (very slow to respond to the logon page, and when it does I get "The credentials you provided cannot be determined to be authentic.") > > Matthew > _________________________________________________________________ > Makes testing post-login python scripts hard, I'll agree... A one page summary of the Convolution that is Second Life: https://wiki.secondlife.com/wiki/ImprovedInstantMessage Lawson From ian at neon.ai Mon Jan 7 16:41:43 2008 From: ian at neon.ai (Ian Wilson) Date: Mon Jan 7 16:41:44 2008 Subject: [sldev] [HELP] Character/Avatar Engine] Message-ID: <4782C6C7.4030909@neon.ai> We are currently planning a project to enhance the capabilities of SL avatar behaviors that may involve swapping out the animation/body system with something more advanced. Has anyone done this before? Has anyone thought about what the problems may be in attempting this? Feedback and pointers much appreciated. From monkowsk at watson.ibm.com Mon Jan 7 16:50:10 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jan 7 16:50:36 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782C6C7.4030909@neon.ai> References: <4782C6C7.4030909@neon.ai> Message-ID: <4782C8C2.8040209@watson.ibm.com> "swapping out the animation/body system" is too vague to all a meaningful response. Will you use the same animation files? (They're stored on the server, by the way.) Will you use the same skeletal definition and avatar meshes? (The avatar appearances depend on it.) What in particular do you wish to change? Mike Ian Wilson wrote: > We are currently planning a project to enhance the capabilities of SL > avatar behaviors that may involve swapping out the animation/body system > with something more advanced. > > Has anyone done this before? Has anyone thought about what the problems > may be in attempting this? Feedback and pointers much appreciated. From ian at neon.ai Mon Jan 7 17:03:52 2008 From: ian at neon.ai (Ian Wilson) Date: Mon Jan 7 17:03:54 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782C8C2.8040209@watson.ibm.com> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> Message-ID: <4782CBF8.9060709@neon.ai> Mike, apologies, I have to be a little vague at this point for a couple of reasons, the project is not yet fully spec'd and the project is for a client so I am not able to mention too much about what is being planned at this stage. But that is a temporary problem. To be a little more detailed, we require a skeleton and meshes that can be driven/deformed procedurally. Animations will not be used (or will be blended into the procedural system movements). It is also possible that we require much more detailed models with more joints and more advanced "meshes". Initially we will investigate the current system and see how far it can be tweaked but if anyone has already looked at this system (as your detailed knowledge seems to indicate) it could save us a good deal of time and pain. Ian Mike Monkowski wrote: > "swapping out the animation/body system" is too vague to all a > meaningful response. Will you use the same animation files? (They're > stored on the server, by the way.) Will you use the same skeletal > definition and avatar meshes? (The avatar appearances depend on it.) > What in particular do you wish to change? > > Mike > > Ian Wilson wrote: >> We are currently planning a project to enhance the capabilities of SL >> avatar behaviors that may involve swapping out the animation/body >> system with something more advanced. >> >> Has anyone done this before? Has anyone thought about what the >> problems may be in attempting this? Feedback and pointers much >> appreciated. > From monkowsk at watson.ibm.com Mon Jan 7 17:19:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jan 7 17:20:02 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782CBF8.9060709@neon.ai> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> Message-ID: <4782CFBD.8040302@watson.ibm.com> Ian Wilson wrote: > Mike, apologies, I have to be a little vague at this point for a couple > of reasons, the project is not yet fully spec'd and the project is for a > client so I am not able to mention too much about what is being planned > at this stage. But that is a temporary problem. > > To be a little more detailed, we require a skeleton and meshes that can > be driven/deformed procedurally. Animations will not be used (or will be > blended into the procedural system movements). It is also possible that > we require much more detailed models with more joints and more advanced > "meshes". > > Initially we will investigate the current system and see how far it can > be tweaked but if anyone has already looked at this system (as your > detailed knowledge seems to indicate) it could save us a good deal of > time and pain. > > Ian All viewers currently use the same mesh for every avatar. The appearance is changed using morphs. The server sends a fixed length vector of morph values to the client to set the morph amounts. There's no requirement that you use this information in your viewer if you don't mind seeing something other than what everyone else does. You can ignore the animations sent from the server if you don't mind all of the avatars moving as rigid figures. If you want to do procedural animation in your viewer that no one else will see, you can do that. The physics system uses an ellipsoid for collisions, not any aspect of the avatar pose, so only the location of the avatar is important to the server. I guess the main point is that you can swap out anything you want in the viewer, but only you will see the effects. No other viewers can be informed of what you see. For example, I am using morphs to do lip sync on the client, but only my viewer shows the lips moving. Of course, I hope to get the lip sync into the standard viewer so everyone can use it, but everyone will still see their own representation computed locally. Mike From gigstaggart at gmail.com Mon Jan 7 17:40:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jan 7 17:40:56 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782C6C7.4030909@neon.ai> References: <4782C6C7.4030909@neon.ai> Message-ID: <4782D4A7.4030902@gmail.com> Ian Wilson wrote: > We are currently planning a project to enhance the capabilities of SL > avatar behaviors that may involve swapping out the animation/body system > with something more advanced. > > Has anyone done this before? Has anyone thought about what the problems > may be in attempting this? Feedback and pointers much appreciated. It's very "hard coded" in a lot of ways. Good luck. -Jason From ian at neon.ai Mon Jan 7 17:48:18 2008 From: ian at neon.ai (Ian Wilson) Date: Mon Jan 7 17:48:19 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782CFBD.8040302@watson.ibm.com> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> Message-ID: <4782D662.8000305@neon.ai> Thanks for the detailed info, it helps a lot. I wanted to generally get a feel for how modular the system was. So if we wanted to change the entire avatar body system we could (or not) using a different model system, different skeleton system and different "morph" control system. As a first stage we will update the client to change the behavior of the local avatar but then we would want to transmit those changes (using some custom messages) to other avatars using the updated client system. This, of course, is also another point of concern in the project. Do you have anything written up on your work with lip syncing? That might be a useful guide for what we are looking at. I also noted that the SL team were working on implementing inverse kinematics which would be an entirely new system, but that has been mothballed while scale/stability issues are fixed. Is that code available anywhere perhaps? Ian Mike Monkowski wrote: > Ian Wilson wrote: >> Mike, apologies, I have to be a little vague at this point for a >> couple of reasons, the project is not yet fully spec'd and the >> project is for a client so I am not able to mention too much about >> what is being planned at this stage. But that is a temporary problem. >> >> To be a little more detailed, we require a skeleton and meshes that >> can be driven/deformed procedurally. Animations will not be used (or >> will be blended into the procedural system movements). It is also >> possible that we require much more detailed models with more joints >> and more advanced "meshes". >> >> Initially we will investigate the current system and see how far it >> can be tweaked but if anyone has already looked at this system (as >> your detailed knowledge seems to indicate) it could save us a good >> deal of time and pain. >> >> Ian > > All viewers currently use the same mesh for every avatar. The > appearance is changed using morphs. The server sends a fixed length > vector of morph values to the client to set the morph amounts. > > There's no requirement that you use this information in your viewer if > you don't mind seeing something other than what everyone else does. > You can ignore the animations sent from the server if you don't mind > all of the avatars moving as rigid figures. > > If you want to do procedural animation in your viewer that no one else > will see, you can do that. The physics system uses an ellipsoid for > collisions, not any aspect of the avatar pose, so only the location of > the avatar is important to the server. > > I guess the main point is that you can swap out anything you want in > the viewer, but only you will see the effects. No other viewers can > be informed of what you see. > > For example, I am using morphs to do lip sync on the client, but only > my viewer shows the lips moving. Of course, I hope to get the lip > sync into the standard viewer so everyone can use it, but everyone > will still see their own representation computed locally. > > Mike > From dzonatas at dzonux.net Mon Jan 7 18:21:43 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jan 7 18:21:54 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782D662.8000305@neon.ai> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> Message-ID: <4782DE37.9010809@dzonux.net> Ian Wilson wrote: > I also noted that the SL team were working on implementing inverse > kinematics which would be an entirely new system, but that has been > mothballed while scale/stability issues are fixed. Is that code > available anywhere perhaps? http://www.secondlifeinsider.com/2006/08/01/expressive-puppeteering/ It will probably follow the Havok 4 update (unless an inside Linden wants to correct this info or confirm). You would be safe to start with the lip sync patch. From alexander.treptow at zweitgeist.com Tue Jan 8 01:22:38 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Tue Jan 8 01:22:58 2008 Subject: [sldev] Worn Items/Objects In-Reply-To: <47826DC4.8040207@watson.ibm.com> References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> Message-ID: <478340DE.3070100@zweitgeist.com> Mike Monkowski schrieb: > alexander treptow wrote: >> Hi, >> does anyone know how to render only the worn objects of my avatar. >> It maybe works by comparing the inventory items with the object list, >> but i dont know where to set. >> >> Anybody has any idea how to? >> >> a second question: >> how can i only draw my own eyes or are eyes the same as items that >> could be worn? > > I'm not sure what you mean by "render only the worn objects of my > avatar." Do you mean to not render those of any other avatar? Or not > render objects that are not worn by any avatar? Or not render the > avatar, just its worn objects? Or ...? > > Regarding Eyes: If you go to Edit->Appearance->Eyes and click on the > Iris image, you get the opportunity to use your own texture. > > Mike I mean rendering "only" the worn objects of "my" avatar. no other objects of any other avatar. to eyes: i only rendering my own avatar, but the eyes of other avatars are still there. i dont know why. so i see the eyes of others without their avatar. that looks quiet funny but its not what i want ;) greets alex From matthew.dowd at hotmail.co.uk Tue Jan 8 02:00:35 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 02:00:37 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <477D6F5C.3020008@lindenlab.com> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> <477D6F5C.3020008@lindenlab.com> Message-ID: Josh, > we're *always* going to do another source drop soon, and the likelyhood > of any RC being followed by another one verges on 75%, so it just didn't > occur to me. I fear you may have got the blunt edge of some growing frustrations within the open source developer community. Open Source is not just sticking the source code somewhere under an OS license, although that is a common mistake to make (I've been there). Successful Open Source projects adopt an Open Community development model (there isn't a single model fits all, and it takes time and effort to get right but the same development model is used by both internal and external developers). In the case of SL, there really shouldn't be seperate internal and external source repositories - there should be a single one which can be read from outside (yes, there will be a need for private internally accessible only directories within that repository for the non-redist source code such as the bHear related code, and there will be a need for private internally accessible only branches, but modern source control systems like subversion support that level of granular access control). A sourcecode drop should ideally be an integrated (and even automated) part of the process of making a public release (both stable and intermediate test releases), not, as currently appears, a manual and optional process which sometimes (I'm afraid) seems to be something of an afterthought. We are about a year in from LL's decision to opensource the client, but whilst to be fair some progress from from a "drop the source and run" model to a full open community development model has been made, there is still a long way to go and it has been at times painfully slow progress, and it isn't always clear how committed LL is to making such a move. > Since I *am* the person who manages the release schedule, here's the > roadmap: I think what we would welcome from a roadmap is not only version numbers and rough (liable to change) dates, but also some idea of what is planned (again with the usual "this is provisional" caveats) for the new versions. Also, we have within the jira, a lot of "fixed internally" issues, proposed features and bugs. In can take 2 or 3 releases (and sometimes months) before a such an internal fix actually makes it into a public release. It would be extremely useful to have some estimate in pjira against such "fixed internally" issues about which public version they are expected to make it into. There are also a long list of imported patches from the OS community which seem stuck in the pipeline - again it isn't clear from jira whether these are in progress, deliberately abandoned, stalled for some reason, requiring a refresh due to underlying changes in the base SL source code, or just forgotten/overlooked. Again some estimate in pjira which version such an imported patch would be expected to be in would be useful. Matthew _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com From matthew.dowd at hotmail.co.uk Tue Jan 8 02:15:44 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 02:15:46 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <4782AABA.1060806@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> <4782A801.2090007@libsecondlife.org> <4782AABA.1060806@lindenlab.com> Message-ID: Ah ok. However, I gather that the current flow (greatly simplified as I realise rendering is actually happening almost continuously): download prim data render download textures of non-occluded prims render My impression is that the sculpt textures get downloaded alongside all other textures, on the basis tha tp-ing an area with lots of sculpts initially appears as a lot of floating blobs which eventually (depending on lag and how many textures to download) resolve themselves into their proper sculpt shapes. Are sculpt textures prioritised over non-sculpt textures in the download queue? A good example is a sculpt tree - initially these appear as a large floating blog (which you can see underneath), and some smaller disconnected blobs. When the sculpt textures have loaded the trunk touches the ground and links up with the branches. As such the sculpt mesh and culling *after* the sculpt texture has loaded will be different from the mesh and culling before the sculpt texture has loaded - so we may get some additional objects/textures downloaded which are occluded by the sculpted mesh but not the intermediate base prim mesh. Naively, it would therefore appear to be an optimisation to pad out the difference between a sculpts volume and its base prim with a few extra prims. I say naively since I suspect in practice in the majority of cases any benefits gained from this would be offset by the overhead of the extra prims, particularly if the observer is moving. Matthew ---------------------------------------- > Date: Mon, 7 Jan 2008 14:42:02 -0800 > From: davep@lindenlab.com > To: baba@libsecondlife.org > CC: matthew.dowd@hotmail.co.uk; sldev@lists.secondlife.com > Subject: Re: [sldev] Improving rendering sequence > > He's right. > > Baba wrote: >> Quoting John Hurliman here whose email server is on vacation. >> >> "the client occlusion culling is ignorant of things like prim types >> since it happens at the opengl level working on meshes using >> GL_ARB_occlusion_query, while the simulator physics engine uses mostly >> rough approximations of objects and the two share nothing at all in >> common" >> >> >> Baba >> >> >> On Mon, Jan 07, 2008 12:55, Matthew Dowd wrote: >>> I would guess that they behave as if they were the unsculpted base >>> prim (which is normally a spheroid) for culling - the sculpted >>> surface playing no part itself in the culling in the same way it >>> doesn't take part in collision detecting. >>> >>> Matthew >>> >>> >>> ---------------------------------------- >>> >>>> Date: Mon, 7 Jan 2008 12:21:59 -0800 >>>> From: tofu.linden@lindenlab.com >>>> To: sldev@lists.secondlife.com >>>> Subject: Re: [sldev] Improving rendering sequence >>>> >>>> Argent Stonecutter wrote: >>>> >>>>> Question: how do sculpties interact with culling? >>>>> >>>> The same as any other prim, I believe. >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>> >>> _________________________________________________________________ >>> Get Hotmail on your mobile, text MSN to 63463! >>> http://mobile.uk.msn.com/pc/mail.aspx_______________________________________________ >>> >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From dzonatas at dzonux.net Tue Jan 8 06:36:47 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 8 06:36:54 2008 Subject: [sldev] Open Source Meeting -- Jan 10 Message-ID: <47838A7F.2010201@dzonux.net> Hi! Reminder for anybody that has something to ask about Open Source, its process at Second Life, and in particular the outstanding issues for an Open Source viewer and workflow -- the next meeting is on Jan 10th at 2pm PST. Please follow this next link for past and previous agendas: http://wiki.secondlife.com/wiki/Open_Source_Meeting (please add your items to the agenda before the meeting starts) Come join us! From lenglish5 at cox.net Tue Jan 8 08:24:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jan 8 08:24:07 2008 Subject: [sldev] [AWG] First AW Groupies meeting of 2008 Message-ID: <4783A3A4.4010605@cox.net> First AW Groupies meeting of 2008 on Tuesday (today) at 9:30 AM SL time. That's the Architectural Working Group[ies], the in-world group associated with the AWG. Topics include: The upcoming AWG meeting in San Francisco. The Protocol Documentation Issue: Past, present and future... (In a word: ick). As always, the AW Groupies meeting is held on Zha Ewry's island, and group membership is required to get there. IM Saijanai Kuhn, Tree Kyomoon or Zha Ewry in-world for a group invite and/or TP. See ya there. Lawson (Saijanai Kuhn) From tofu.linden at lindenlab.com Tue Jan 8 08:46:25 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Jan 8 08:46:13 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782DE37.9010809@dzonux.net> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> <4782DE37.9010809@dzonux.net> Message-ID: <4783A8E1.6@lindenlab.com> Dzonatas wrote: > Ian Wilson wrote: >> I also noted that the SL team were working on implementing inverse >> kinematics which would be an entirely new system, but that has been >> mothballed while scale/stability issues are fixed. Is that code >> available anywhere perhaps? > > http://www.secondlifeinsider.com/2006/08/01/expressive-puppeteering/ > > It will probably follow the Havok 4 update (unless an inside Linden > wants to correct this info or confirm). Puppeteering is (as Ian says) shelved as part of the refocus on quality over features, with no particular resurrection schedule. I've talked to the engineers about releasing the code, but apparently it needs (incomplete, untested, undeployed) server support to do anything useful, and is currently stripped-down for restructuring. From josh at lindenlab.com Tue Jan 8 09:55:23 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 8 10:04:16 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> <477D6F5C.3020008@lindenlab.com> Message-ID: <4783B90B.6070904@lindenlab.com> Excellent discussion, BTW. Thanks for bringing this up. Matthew Dowd wrote: > In the case of SL, there really shouldn't be seperate internal and external source repositories - there should be a single one which can be read from outside (yes, there will be a need for private internally accessible only directories within that repository for the non-redist source code such as the bHear related code, and there will be a need for private internally accessible only branches, but modern source control systems like subversion support that level of granular access control). > Trust me, we know. We've escalated the priority of moving to this model - which has been our intent all along - and hope to have significant, tangible progress here in Q108. The cmake experimenting that's been done internally is formalized into a project now that's basically the first step. As has been mentioned before here, our internal code base is a twisty maze of passages with both viewer and server code intertwingled. Teasing that apart is the next step, followed by moving to development of the viewer code in an external repository. > A sourcecode drop should ideally be an integrated (and even automated) part of the process of making a public release (both stable and intermediate test releases), not, as currently appears, a manual and optional process which sometimes (I'm afraid) seems to be something of an afterthought. > Agreed. We're in the process of getting hardware set up for an automated build farm that should be able to do source drops with each build, in the interim until the aforementioned projects are complete. >> Since I *am* the person who manages the release schedule, here's the >> roadmap: >> > I think what we would welcome from a roadmap is not only version numbers and rough (liable to change) dates, but also some idea of what is planned (again with the usual "this is provisional" caveats) for the new versions. > Yes, this is something we should do a better job of. One issue is that our development model is basically "let projects into the trunk until we hit a freeze date, then freeze, then ship ASAP after the freeze", which means that until the freeze date what's in a release isn't known, and we try and turn things around pretty quickly (i.e. generate a viewer RC0 within a few days) > Also, we have within the jira, a lot of "fixed internally" issues, proposed features and bugs. In can take 2 or 3 releases (and sometimes months) before a such an internal fix actually makes it into a public release. It would be extremely useful to have some estimate in pjira against such "fixed internally" issues about which public version they are expected to make it into. > Completely valid point. Right now we're strapped for bodies to correlate the various data sources. In the future we hope to use PJIRA exclusively for viewer-side work. > There are also a long list of imported patches from the OS community which seem stuck in the pipeline - again it isn't clear from jira whether these are in progress, deliberately abandoned, stalled for some reason, requiring a refresh due to underlying changes in the base SL source code, or just forgotten/overlooked. Again some estimate in pjira which version such an imported patch would be expected to be in would be useful. > Another completely valid point. Again, the long term fix is to reduce the barrier, not just get better at moving things across it. Otherwise, I don't have much useful to contribute, other than commenting that Lindens realize it's a huge problem and incredibly discouraging both internally and externally. Eliminating any notion of "us" vs. "them" is considered high priority... it's just been behind all the "ZOMG the grid is on fire!" items which are higher priority. From josh at lindenlab.com Tue Jan 8 10:16:22 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 8 10:19:20 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer Message-ID: <4783BDF6.6080806@lindenlab.com> As might be inferred from the number, we are planning on making the 1.19.0 Viewer update mandatory for residents at some point in the near future ? probably early February. There are two stages to this: * Stage 1: The viewer itself will be made mandatory; that is, previous viewer versions will be blocked on login. This will have no effect on third party viewers or viewers built from the source, provided they report a different channel/version than Linden Lab?s production viewers. We plan on doing this in early February; probably a week or two after 1.19.0 Viewer has entered production. * Stage 2: Login via the new web-key based authentication will be required; support for transmitting a name/password pair to the login URI will be dropped. This is in anticipation of enabling our anti-fraud team to make changes to the login process, either globally or for individual logins, without requiring viewer changes. We do not expect this to happen until March at the soonest, so that third party viewer providers have plenty of time to accommodate the source changes (already present in the 1.18.6 viewer source drops) and take advantage of additional work we?re doing (details below) The driving reasons for making 1.19.0 mandatory are: * to ensure that all residents are connecting with viewers that support the web-based authentication, to enable our anti-fraud efforts * to reduce support costs by ensuring that the bulk of our residents are on a common code base ? we?re currently supporting viewers back through August * to eliminate enable some server-side cleanup (eliminate code only present for compatibility with older viewers) In more detail: * The bulk of the viewer authentication changes are already in the 1.18.6 viewer source. Only cosmetic changes, and tools for third party developers, are going into 1.19. * We have identified three main failure modes for logins with the 1.18.6 viewer code base (login screen not appearing, stuck ?Loading??, logins timing out, etc), and they all stem from a load balancer problem that is currently being investigated internally. Obviously, releasing 1.18.6 and any subsequent viewers is gated on solving this. * The viewer authentication team?s current focus is on bugs (above) and helping third party developers work with the new authentication: ** Support for clients which do not have a browser, including support for web authentication via LLSD instead of XML/RPC. Development on this is in progress now. ** A "continuation url" login page for thin, Web-based clients. This is live and being tested by a third party. We will send out the full demo and instructions to SLDEV this week. ** Full frameset delivery of login pages, with a specifiable CSS, for third party viewer vendors. We will send out instructions this week to our licensed vendors, SLDEV and document on the public Wiki. ... We're still pulling together the release notes for 1.19.0, but the high-level summary is: * 61 bug fixes * "Voice 1.1" ** Introduces moderated to (formal) group voice and group text conversations ** Moderation ability applies to group owner and group officer roles ** Moderation will NOT apply to one-to-one text or voice chat, ad-hoc group conversation, or to spatial voice chat. * Auto-joining group chat sessions has been removed ** Group members must explicitly choose to actively "join" their SL Group's chat sessions after they log in. ** Starting a new SL group chat only adds the requester to the chat session much like an IRC channel. Obviously, for the voice moderation and group chat improvements there are server side components, so these features will not "light up" until we've updated the servers, which is tentatively planned for next week. ... And while I'm here, here's what we're expecting in 1.18.6 RC4 (deltas from RC3) - some of the changes failed QA so we'll need to iterate a bit: * Language names need to have a consistent format in preferences drop-down * QuickTime disabled message cannot be ignored * Linux client doesn't recognize that a viewer is already running * Display HTML error page in selected language when viewer is unable to connect to second life URL * VWR-3667;About Land > Access: On group owned land, group owner gets eject message when "Public Access" is unchecked * VWR-3829: Cursor in Logon edit boxes difficult to see * VWR-3501: Create/Edit Gesture window preview button blanks after pressing * VWR-4010: New search does not accept non ASCII characters * VWR-3539: Communicate window width will no longer resize smaller in 1.18.5.3 From josh at lindenlab.com Tue Jan 8 10:23:45 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 8 10:31:14 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <4783B90B.6070904@lindenlab.com> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> <477D6F5C.3020008@lindenlab.com> <4783B90B.6070904@lindenlab.com> Message-ID: <4783BFB1.1090300@lindenlab.com> One more thought... Joshua Bell wrote: > Matthew Dowd wrote: >> I think what we would welcome from a roadmap is not only version >> numbers and rough (liable to change) dates, but also some idea of >> what is planned (again with the usual "this is provisional" caveats) >> for the new versions. >> > Yes, this is something we should do a better job of. One issue is that > our development model is basically "let projects into the trunk until > we hit a freeze date, then freeze, then ship ASAP after the freeze", > which means that until the freeze date what's in a release isn't > known, and we try and turn things around pretty quickly (i.e. generate > a viewer RC0 within a few days) Since we're very decentralized, we also encourage development teams to comment here on what they're doing well before it hits the release pipeline (which is the point when I can semi-competently speak to it). For example, Studio Icehouse (Tess, Donovan & co.) have been very active in commenting on the viewer authentication work well before it hit the trunk, and the crew working on WindLight (Asi, Dave, etc) have popped in as well to answer questions about the roadmap for the rendering pipeline. This isn't something we dictate, but everyone at Linden knows how useful sharing this information is. Joshua From Anders at Arnholm.se Tue Jan 8 10:45:08 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Jan 8 10:46:37 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <4783C4B4.1000709@Arnholm.se> Joshua Bell skrev: > As might be inferred from the number, we are planning on making the > 1.19.0 Viewer update mandatory for residents at some point in the near > future ? probably early February. There are two stages to this: Personalty I think mandatory should be reserved for when protocol changes. Half political mandatory like the RC series are not good. > * Auto-joining group chat sessions has been removed > ** Group members must explicitly choose to actively "join" their SL > Group's chat sessions after they log in. This will be deadly on clubs in SL and increase the notice sending very much... (Hope you have loaded up some more mail servers...) > And while I'm here, here's what we're expecting in 1.18.6 RC4 (deltas > from RC3) - some of the changes failed QA so we'll need to iterate a bit: > > * Language names need to have a consistent format in preferences drop-down > * QuickTime disabled message cannot be ignored > * Linux client doesn't recognize that a viewer is already running > * Display HTML error page in selected language when viewer is unable to > connect to second life URL > * VWR-3667;About Land > Access: On group owned land, group owner gets > eject message when "Public Access" is unchecked > * VWR-3829: Cursor in Logon edit boxes difficult to see > * VWR-3501: Create/Edit Gesture window preview button blanks after pressing > * VWR-4010: New search does not accept non ASCII characters > * VWR-3539: Communicate window width will no longer resize smaller in > 1.18.5.3 To bad non of the top wishes in JIRA are on the way to be solved... Like removal of communicate window, more than 25 groups. The stuff we resident so long for... Btw Thanx for sharing the plans... Balp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mattk at electricsheepcompany.com Tue Jan 8 10:55:58 2008 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Tue Jan 8 10:56:02 2008 Subject: [sldev] [VWR] VWR-1151 project files still valid for VS2005 source compilations? In-Reply-To: References: Message-ID: <4783C73E.3050809@electricsheepcompany.com> Hey all, I've attached a set of VS2005 project files for 1.18.5.3 to VWR-1151. Look for a set of 1.18.6 files soon. -Matt (aka Feep Larsson) Joshy Squashy wrote: > Hello, > > I'm slightly torn on the issue of how to go about setting up source > compilations. On the one hand, > > still seems to recommend using the project files at > , which saves a lot of work > and seems to generate a lot cleaner compilation than I manage to do on > my own despite feeling like I follow the manual documentation > religiously. On the other hand, these files seem terribly out-of-date. > > So do you VS2005 devs still use them? > > What I would love to see would be if we could keep an updated zip of the > VS2005 project files for each release, be it by continuing to add them > to the JIRA or some other location. > > Hopefully it won't be too far down the road before we don't have to > "convert" anything at all for it to work! > > ~Squash Otoro > > ------------------------------------------------------------------------ > Put your friends on the big screen with Windows Vista? + Windows Live?. > Start now! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Tue Jan 8 10:56:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 10:56:36 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <48C317FE-6291-4FB7-A9FA-9F95E6AFBD6D@gmail.com> On 2008-01-08, at 12:16, Joshua Bell wrote: > * Auto-joining group chat sessions has been removed > ** Group members must explicitly choose to actively "join" their SL > Group's chat sessions after they log in. On the whole I think this is a REALLY good thing, but it's likely to get a lot of pushback from people in support roles when they find they're forgetting to join a group. > ** Starting a new SL group chat only adds the requester to the chat > session much like an IRC channel. One of the things that makes this work in IRC is that, traditionally, there is a "command mode" in IRC clients. You can stick a bunch of commands into your .ircrc or equivalent and have it always do /join #group_help /join #customer_support Graphical clients may not always have this, but they generally have an option to join certain channels when you log in anyway. You might want to implement one or the other of these options when the complaints hit. :) From davep at lindenlab.com Tue Jan 8 11:32:20 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Jan 8 11:31:17 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> <4782A801.2090007@libsecondlife.org> <4782AABA.1060806@lindenlab.com> Message-ID: <4783CFC4.4040604@lindenlab.com> Matthew Dowd wrote: > Are sculpt textures prioritised over non-sculpt textures in the download queue? > Yes. Textures are prioritized based on how many pixels they cover on the screen, and the priority is "boosted" based on different flags defined in this enum (from llviewerimage.h): enum { BOOST_NONE = 0, BOOST_AVATAR_BAKED = 1, BOOST_AVATAR = 2, BOOST_CLOUDS = 3, BOOST_SCULPTED = 4, BOOST_HIGH = 10, BOOST_TERRAIN = 11, // has to be high priority for minimap / low detail BOOST_SELECTED = 12, BOOST_HUD = 13, BOOST_AVATAR_BAKED_SELF = 14, BOOST_UI = 15, BOOST_PREVIEW = 16, BOOST_MAP = 17, BOOST_MAP_LAYER = 18, BOOST_AVATAR_SELF = 19, // needed for baking avatar BOOST_MAX_LEVEL }; So, sculpt textures are prioritized before avatar skins, clouds, and all "normal" textures. If you alt-zoom or left click on something, its texture becomes high priority. Right clicking on it (selection) gives it a higher priority than the terrain. You get the idea. Looking at the code, it looks like the sculpt textures might have a 5 second delay between the texture being available and it actually being applied to the prim, since mSculptChanged is the flag used to determine when a sculpt gets rebuilt, and it only gets set in LLVOVolume::updateTextures, which only gets called every 5 seconds or on LOD switches or on vertex buffer rebuilds, whichever comes first. Room for improvement there. From secret.argent at gmail.com Tue Jan 8 11:55:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 11:55:20 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <4783CFC4.4040604@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> <6CA8825C-624F-4FB0-BC58-00E3A8304378@gmail.com> <478289E7.40007@lindenlab.com> <4782A801.2090007@libsecondlife.org> <4782AABA.1060806@lindenlab.com> <4783CFC4.4040604@lindenlab.com> Message-ID: On 2008-01-08, at 13:32, Dave Parks wrote: > Textures are prioritized based on how many pixels they cover on the > screen, and the priority is "boosted" based on different flags > defined in this enum (from llviewerimage.h): Does BOOST_AVATAR* apply to textures on avatar attachments? > Looking at the code, it looks like the sculpt textures might have a > 5 second delay between the texture being available and it actually > being applied to the prim, since mSculptChanged is the flag used to > determine when a sculpt gets rebuilt, and it only gets set in > LLVOVolume::updateTextures, which only gets called every 5 seconds > or on LOD switches or on vertex buffer rebuilds, whichever comes > first. Room for improvement there. How about not removing the sculpt texture from a prim when it's updated from the server until the replacement is available? From gigstaggart at gmail.com Tue Jan 8 12:35:38 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jan 8 12:35:40 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <4783DE9A.6080303@gmail.com> Joshua Bell wrote: > * Auto-joining group chat sessions has been removed > ** Group members must explicitly choose to actively "join" their SL > Group's chat sessions after they log in. > ** Starting a new SL group chat only adds the requester to the chat > session much like an IRC channel. So if I ask a question on Scipters of Second Life, unless the other people somehow psychically know that I asked it and join the session, no one will answer? I hope I misunderstood this. -Jason From nik at terminaldischarge.net Tue Jan 8 12:42:45 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Jan 8 12:41:24 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783DE9A.6080303@gmail.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> Message-ID: Hmm Personally in my opinion, you should be able to select which groups auto join you to their chat sessions. For example, I may want my personal friends group (ABC) to automatically join me when a friend speaks into it. But not XYZ group that has people spamming the group chat constantly. So I tick the Do not auto join chat (meaning do not get added to the session when someone talks into it) next to XYZ group (In my opinion defaut should be autojoin, so that it mimicks current behavoir) However, as it doesn't do that and from what I've understood it does what jason said below. I am a little worried. ----- Original Message ----- From: "Jason Giglio" To: "Joshua Bell" Cc: "Second Life Developer Mailing List" Sent: Tuesday, January 08, 2008 8:35 PM Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > Joshua Bell wrote: >> * Auto-joining group chat sessions has been removed >> ** Group members must explicitly choose to actively "join" their SL >> Group's chat sessions after they log in. >> ** Starting a new SL group chat only adds the requester to the chat >> session much like an IRC channel. > > So if I ask a question on Scipters of Second Life, unless the other people > somehow psychically know that I asked it and join the session, no one will > answer? > > I hope I misunderstood this. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From ordinal.malaprop at fastmail.fm Tue Jan 8 12:45:08 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Jan 8 12:45:11 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783DE9A.6080303@gmail.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> Message-ID: Er, yes. Or must one go through all one's groups where conversation might start, and tick them, at each login? The option would certainly be nice to have and cut down on irrelevant spam, but it should be a persistent tickbox by each group, I'd say. On 8 Jan 2008, at 20:35, Jason Giglio wrote: > Joshua Bell wrote: >> * Auto-joining group chat sessions has been removed >> ** Group members must explicitly choose to actively "join" their SL >> Group's chat sessions after they log in. >> ** Starting a new SL group chat only adds the requester to the chat >> session much like an IRC channel. > > So if I ask a question on Scipters of Second Life, unless the other > people somehow psychically know that I asked it and join the > session, no one will answer? > > I hope I misunderstood this. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nik at terminaldischarge.net Tue Jan 8 12:53:52 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Jan 8 12:52:20 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> Message-ID: With my idea, the ticks would be persistant (It'd need to be server side value, so best to make it persistant). With LL's (supposed?) implementation, from what I understood of what it said was that you'll have to open up a chat session with each group you want to chat with upon log in to recieve messages. ----- Original Message ----- From: To: "Second Life Developer Mailing List" Sent: Tuesday, January 08, 2008 8:45 PM Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > Er, yes. Or must one go through all one's groups where conversation might > start, and tick them, at each login? > > The option would certainly be nice to have and cut down on irrelevant > spam, but it should be a persistent tickbox by each group, I'd say. > > On 8 Jan 2008, at 20:35, Jason Giglio wrote: > >> Joshua Bell wrote: >>> * Auto-joining group chat sessions has been removed >>> ** Group members must explicitly choose to actively "join" their SL >>> Group's chat sessions after they log in. >>> ** Starting a new SL group chat only adds the requester to the chat >>> session much like an IRC channel. >> >> So if I ask a question on Scipters of Second Life, unless the other >> people somehow psychically know that I asked it and join the session, no >> one will answer? >> >> I hope I misunderstood this. >> >> -Jason >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jwolk at lindenlab.com Tue Jan 8 13:14:51 2008 From: jwolk at lindenlab.com (Jonathan Wolk) Date: Tue Jan 8 13:12:54 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> Message-ID: <4783E7CB.2050409@lindenlab.com> Nik Radford wrote: > With my idea, the ticks would be persistant (It'd need to be server > side value, so best to make it persistant). > > > With LL's (supposed?) implementation, from what I understood of what > it said was that you'll have to open up a chat session with each group > you want to chat with upon log in to recieve messages. > Hi All, Sorry for the confusion with all this. I/We do plan on (sometime soon) adding an ability to "auto join" group chat sessions on log in. This will basically be a server side bit sent to the viewer in which the viewer will open up your group's chat tab. You could add some viewer side mimicking of this by reading/writing your auto logins to a file, but that obviously will not be persistent across multiple machines. But, yes, group IMs will become opt-in (by manually joining the session) rather than opt-out. -Jonathan Linden From ordinal.malaprop at fastmail.fm Tue Jan 8 13:17:37 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Jan 8 13:17:40 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783E7CB.2050409@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> <4783E7CB.2050409@lindenlab.com> Message-ID: Sorry, I'm still a little confused I'm afraid. There will be a server- side bit to auto-join on login, effectively simulating the current system - but the "you could add" part rather suggests that the official viewer won't actually let you change that? On 8 Jan 2008, at 21:14, Jonathan Wolk wrote: > Nik Radford wrote: >> With my idea, the ticks would be persistant (It'd need to be server >> side value, so best to make it persistant). >> >> >> With LL's (supposed?) implementation, from what I understood of >> what it said was that you'll have to open up a chat session with >> each group you want to chat with upon log in to recieve messages. >> > Hi All, > > Sorry for the confusion with all this. I/We do plan on (sometime > soon) adding an ability to "auto join" group chat sessions on log > in. This will basically be a server side bit sent to the viewer in > which the viewer will open up your group's chat tab. You could add > some viewer side mimicking of this by reading/writing your auto > logins to a file, but that obviously will not be persistent across > multiple machines. > But, yes, group IMs will become opt-in (by manually joining the > session) rather than opt-out. > > -Jonathan Linden > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Tue Jan 8 13:19:47 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 13:19:49 2008 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <4783BFB1.1090300@lindenlab.com> References: <4776CA43.2040809@lindenlab.com> <477BE462.3020304@lindenlab.com> <1ea4kwsfowdsdG24kwdds489.alissa_sabre@yahoo.co.jp> <477D6F5C.3020008@lindenlab.com> <4783B90B.6070904@lindenlab.com> <4783BFB1.1090300@lindenlab.com> Message-ID: > Since we're very decentralized, we also encourage development teams to > comment here on what they're doing well before it hits the release > pipeline (which is the point when I can semi-competently speak to it). > For example, Studio Icehouse (Tess, Donovan & co.) have been very active > in commenting on the viewer authentication work well before it hit the > trunk, Actually, this may also be another reason you got the sharp end of some criticism - the new login screen is something of a sore point. True, Tess, Donovan et al did explain what they were planning - however, a lot of us have genuine concerns that the particular approach taken is not the right one (and the incident over Christmas hasn't allayed these concerns). Now although the feedback wasn't perhaps what LL wanted to hear (i.e we didn't like it), I think that we were constructive about it (then I would since I helped with the wiki response). There was a genuine urge from this community to work with LL to understand what LL was trying to achieve and to think about, propose, and discuss alternatives, and we put in quite a lot of effort thinking about these issues. However, the feeling on this side (and I think I can speak for others) is that we might as well not have bothered, as LL just ignored all our comments, concerns, suggestions etc and press on ahead anyway. This is past history - personally I think LL is going in the wrong direction re the logon screen, I've said as much to Tess in some private e-mail discussions but I'm happy to sit back and either eat my words or gloat later down the line... However, why I raise this now, is I tentative about a repeat performance over the group im chat changes in 1.19. There are some real concerns being raised about this. Now, I'd be happier if this resulted in a proper conversation between the OS developers and LL developers - I think we can all understand what LL is trying to address here, but it maybe that what is in 1.19 isn't quite the right solution, or the way it is implemented is only half there. If that is the case, I would hope that LL would be willing to consider pulling the new group im chat changes from 1.19, work with us here to fix some of the issues, and roll out a more polished solution in 1.20. I'd also like to hope that LL would be willing to pull changes from a RC if it appeared that they weren't working and were extremely unpopular. What worries me is that LL will just go "yep, those are valid issues and those are good suggestions etc., but we've fixed 1.19 now, so tough, we'll roll it out anyway, and maybe try to address these at some indeterminate point in the future..." Matthew _________________________________________________________________ Fancy some celeb spotting? https://www.celebmashup.com From monkowsk at watson.ibm.com Tue Jan 8 13:20:38 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jan 8 13:20:45 2008 Subject: [sldev] [HELP] Character/Avatar Engine] In-Reply-To: <4782D662.8000305@neon.ai> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> Message-ID: <4783E926.9050704@watson.ibm.com> Ian Wilson wrote: > I wanted to generally get a feel for how modular the system was. So if > we wanted to change the entire avatar body system we could (or not) > using a different model system, different skeleton system and different > "morph" control system. Sorry, it's not very modular. > As a first stage we will update the client to change the behavior of the > local avatar but then we would want to transmit those changes (using > some custom messages) to other avatars using the updated client system. > This, of course, is also another point of concern in the project. Either you'd have to use a separate server for your messages like SL does for voice chat, or you'd have to convince LL to make server changes (not very likely). > Do you have anything written up on your work with lip syncing? That > might be a useful guide for what we are looking at. See http://wiki.secondlife.com/wiki/User:Mm_Alder/LipSync Mike From jwolk at lindenlab.com Tue Jan 8 13:26:47 2008 From: jwolk at lindenlab.com (Jonathan Wolk) Date: Tue Jan 8 13:24:45 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer Message-ID: <4783EA97.8010507@lindenlab.com> ordinal.malaprop@fastmail.fm wrote: > Sorry, I'm still a little confused I'm afraid. There will be a > server-side bit to auto-join on login, effectively simulating the > current system - but the "you could add" part rather suggests that the > official viewer won't actually let you change that? The "you can add" bit was meant to mean that, if you want the behavior before the server side bit is released, you could add something client side in the meantime. -Jonathan Linden From secret.argent at gmail.com Tue Jan 8 13:25:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 13:25:27 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> Message-ID: <94371FBC-5C3D-4A4F-9F87-04054A6B7CF2@gmail.com> On 2008-01-08, at 14:53, Nik Radford wrote: > With my idea, the ticks would be persistant (It'd need to be server > side value, so best to make it persistant). Why would it need to be server side? From gigstaggart at gmail.com Tue Jan 8 13:27:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jan 8 13:27:07 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783E7CB.2050409@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> <4783E7CB.2050409@lindenlab.com> Message-ID: <4783EAA8.70202@gmail.com> Jonathan Wolk wrote: > Sorry for the confusion with all this. I/We do plan on (sometime > soon) adding an ability to "auto join" group chat sessions on log in. > This will basically be a server side bit sent to the viewer in which the > viewer will open up your group's chat tab. You could add some viewer > side mimicking of this by reading/writing your auto logins to a file, > but that obviously will not be persistent across multiple machines. > But, yes, group IMs will become opt-in (by manually joining the > session) rather than opt-out. Well that doesn't sound like an altogether bad feature. But if this means needing to clutter up my chat tab with every group I might be interested in hearing group chat from, it would be bad. I know you are aiming for an IRC-style function, but on IRC I have a big chunk of screen I can dedicate to channel tabs, in SL I don't want my IM window to be that wide. -Jason From matthew.dowd at hotmail.co.uk Tue Jan 8 13:29:28 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 13:29:29 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783E7CB.2050409@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> <4783E7CB.2050409@lindenlab.com> Message-ID: > Sorry for the confusion with all this. I/We do plan on (sometime > soon) adding an ability to "auto join" group chat sessions on log in. > This will basically be a server side bit sent to the viewer in which the > viewer will open up your group's chat tab. So if you accidently close the chat tab you are no longer subscribe to the chat session? The chatterbox UI can get cluttered enough without having to keep group tabs open for every group you might want to receive group chat on, and as the tabs are intermingled with private im tabs, closing them accidently would be extremely easy. What I would argue need (as has been mentioned) is a new check box in the group info similar to the current "Receive Group Notices" checkbox, called something like "Auto-accept Group IMs". If checked the viewer would behave as per the current viewer (i.e. automatically join a group IM session if someone sends a message). If unchecked you only get group IMs if you explicitly have the group chat tab open. Matthew _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com From matthew.dowd at hotmail.co.uk Tue Jan 8 13:31:14 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 13:31:16 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <94371FBC-5C3D-4A4F-9F87-04054A6B7CF2@gmail.com> References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> <94371FBC-5C3D-4A4F-9F87-04054A6B7CF2@gmail.com> Message-ID: ---------------------------------------- > From: secret.argent@gmail.com > Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > Date: Tue, 8 Jan 2008 15:25:22 -0600 > To: sldev@lists.secondlife.com > > On 2008-01-08, at 14:53, Nik Radford wrote: >> With my idea, the ticks would be persistant (It'd need to be server >> side value, so best to make it persistant). > > Why would it need to be server side? Ideally it should persist with your avatar if you logon from another computer. Matthew _________________________________________________________________ Fancy some celeb spotting? https://www.celebmashup.com From matthew.dowd at hotmail.co.uk Tue Jan 8 13:34:07 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 13:34:09 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783EA97.8010507@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> Message-ID: > ordinal.malaprop@fastmail.fm wrote: >> Sorry, I'm still a little confused I'm afraid. There will be a >> server-side bit to auto-join on login, effectively simulating the >> current system - but the "you could add" part rather suggests that the >> official viewer won't actually let you change that? > The "you can add" bit was meant to mean that, if you want the behavior > before the server side bit is released, you could add something client > side in the meantime. I really do think that a change of this nature should go live until both the client and server side components are ready - it is going to be too disruptive and unpopular to do this in two stages - whilst a few days between a client release and a rolling restart to introduce the server change might be an acceptable delay between the two, any delay long enough for one of us to implement a third party stop gap is IMHO too long! Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From gigstaggart at gmail.com Tue Jan 8 13:34:26 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jan 8 13:34:27 2008 Subject: [sldev] API for account balance Message-ID: <4783EC62.50908@gmail.com> With all this web authentication overhaul and such, please keep in mind that a way to check our L$ balance with an HTTP API is sorely needed. There's no way to validate that someone actually paid you right now. A nice API that could be used from LSL or outside would be good. It only needs to return the current L$ balance to help out a lot. More information would of course be great, such as the last few transactions, but I'd happily settle for just balance. -Jason From matthew.dowd at hotmail.co.uk Tue Jan 8 13:35:25 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 13:35:27 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783EA97.8010507@lindenlab.com> Message-ID: sorry, typing too fast - of course I meant "should *NOT* go live until both the client and server side components are ready" duh, Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: jwolk@lindenlab.com; sldev@lists.secondlife.com > Subject: RE: [sldev] Roadmap: 1.19.0 Viewer > Date: Tue, 8 Jan 2008 21:34:07 +0000 > > > >> ordinal.malaprop@fastmail.fm wrote: >>> Sorry, I'm still a little confused I'm afraid. There will be a >>> server-side bit to auto-join on login, effectively simulating the >>> current system - but the "you could add" part rather suggests that the >>> official viewer won't actually let you change that? >> The "you can add" bit was meant to mean that, if you want the behavior >> before the server side bit is released, you could add something client >> side in the meantime. > > I really do think that a change of this nature should go live until both the client and server side components are ready - it is going to be too disruptive and unpopular to do this in two stages - whilst a few days between a client release and a rolling restart to introduce the server change might be an acceptable delay between the two, any delay long enough for one of us to implement a third party stop gap is IMHO too long! > > Matthew > _________________________________________________________________ > Telly addicts unite! > http://www.searchgamesbox.com/tvtown.shtml_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From phoenix at secondlife.com Tue Jan 8 13:46:07 2008 From: phoenix at secondlife.com (Phoenix) Date: Tue Jan 8 13:46:17 2008 Subject: [sldev] API for account balance In-Reply-To: <4783EC62.50908@gmail.com> References: <4783EC62.50908@gmail.com> Message-ID: <182B2AA7-44DE-401B-AA14-BCB09C453F2E@secondlife.com> This is on the horizon, but not available any time soon. We do not have sufficient infrastructure at this time to handle the millions of scripts that take advantage of this service of the form: while(1) { llSay(0, "current balance:" + (string)llGetOwnerBalance()); } On 2008-01-08, at 13:34, Jason Giglio wrote: > With all this web authentication overhaul and such, please keep in > mind that a way to check our L$ balance with an HTTP API is sorely > needed. > > There's no way to validate that someone actually paid you right > now. A nice API that could be used from LSL or outside would be > good. It only needs to return the current L$ balance to help out a > lot. > > More information would of course be great, such as the last few > transactions, but I'd happily settle for just balance. > > -Jason > _______________________________________________ > 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/20080108/03c2587c/PGP.pgp From mark.burhop at gmail.com Tue Jan 8 13:58:09 2008 From: mark.burhop at gmail.com (Mark Burhop) Date: Tue Jan 8 13:58:11 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783EA97.8010507@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> Message-ID: <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> On Jan 8, 2008 3:26 PM, Jonathan Wolk wrote: > ordinal.malaprop@fastmail.fm wrote: > > Sorry, I'm still a little confused I'm afraid. There will be a > > server-side bit to auto-join on login, effectively simulating the > > current system - but the "you could add" part rather suggests that the > > official viewer won't actually let you change that? > The "you can add" bit was meant to mean that, if you want the behavior > before the server side bit is released, you could add something client > side in the meantime. > > So if I understand, when I log in, I will first need to go to my groups and add each one to chat. This will create a tab in my chat window. Closing the tab will disconnect me from that group so I need to leave all the tabs open. If I get an incoming message, I will have to open up this window (increasing its size horizontally to see all the tabs) to find the tab that indicates a message just came in. To avoid this and work as I do today, I can create my own viewer with some hacks or wait (days? weeks?) until the server is updated. Surely I've misunderstood. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080108/4ad44266/attachment.htm From jwolk at lindenlab.com Tue Jan 8 14:12:55 2008 From: jwolk at lindenlab.com (Jonathan Wolk) Date: Tue Jan 8 14:10:57 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> Message-ID: <4783F567.9040008@lindenlab.com> Mark Burhop wrote: > So if I understand, when I log in, I will first need to go to my > groups and add each one to chat. This will create a tab in my chat > window. Closing the tab will disconnect me from that group so I need > to leave all the tabs open. If you want to hear what's going on in each group chat session, then yes. Actually this behavior exists today with the exception of the first IM. After that, you need to leave the tab open to hear chatter. > If I get an incoming message, I will have to open up this window > (increasing its size horizontally to see all the tabs) to find the tab > that indicates a message just came in. You can actually "arrow over" to see more of your tabs without needing to increase the window size (I think). Or alternatively changes could be made so that the "new IM" button appears if you receive an IM and your communication window isn't opened or maximized (just throwing that idea out there) > > To avoid this and work as I do today, I can create my own viewer with > some hacks or wait (days? weeks?) until the server is updated. Yup. > > Surely I've misunderstood. You haven't and stop calling me Shirley -Jonathan From ordinal.malaprop at fastmail.fm Tue Jan 8 14:17:10 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Jan 8 14:17:17 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783F567.9040008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> Might I respectfully suggest that this major UI change be kept until there is a way to set automatic preferences without rewriting and recompiling the viewer, and have people be able to change back to the previous state easily? I think that an option to turn off group IMs for certain groups would be very popular - but people have already filtered their groups down, in most cases, to those that they don't mind hearing IMs on. Certainly it will be a pain in the rear end for me - estate problems are announced on estate groups - and I don't even have a huge number of responsibilities. On 8 Jan 2008, at 22:12, Jonathan Wolk wrote: > Mark Burhop wrote: >> So if I understand, when I log in, I will first need to go to my >> groups and add each one to chat. This will create a tab in my chat >> window. Closing the tab will disconnect me from that group so I >> need to leave all the tabs open. > If you want to hear what's going on in each group chat session, then > yes. Actually this behavior exists today with the exception of the > first IM. After that, you need to leave the tab open to hear chatter. >> If I get an incoming message, I will have to open up this window >> (increasing its size horizontally to see all the tabs) to find the >> tab that indicates a message just came in. > You can actually "arrow over" to see more of your tabs without > needing to increase the window size (I think). Or alternatively > changes could be made so that the "new IM" button appears if you > receive an IM and your communication window isn't opened or > maximized (just throwing that idea out there) >> To avoid this and work as I do today, I can create my own viewer >> with some hacks or wait (days? weeks?) until the server is updated. > Yup. >> Surely I've misunderstood. > You haven't and stop calling me Shirley > > -Jonathan > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From monkowsk at watson.ibm.com Tue Jan 8 14:22:20 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jan 8 14:22:25 2008 Subject: [sldev] Worn Items/Objects In-Reply-To: <478340DE.3070100@zweitgeist.com> References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> <478340DE.3070100@zweitgeist.com> Message-ID: <4783F79C.5060009@watson.ibm.com> alexander treptow wrote: > I mean rendering "only" the worn objects of "my" avatar. no other > objects of any other avatar. When you say "worn" you could mean either the textures applied to the mesh to simulate clothes or the avatar attachments. They're treated differently. Look in indra/newview/llvoavatar.cpp at the idleUpdate(). My first guess would be if (!mIsSelf) return TRUE; near the beginning, but I haven't actually tried it. The code you need should be in that function anyway. > to eyes: i only rendering my own avatar, but the eyes of other avatars > are still there. i dont know why. so i see the eyes of others without > their avatar. that looks quiet funny but its not what i want ;) I noticed that when displaying wireframe meshes that the textures for eyes remain, but I don't know where that's done. Mike From secret.argent at gmail.com Tue Jan 8 14:22:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 14:23:05 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4783DE9A.6080303@gmail.com> <94371FBC-5C3D-4A4F-9F87-04054A6B7CF2@gmail.com> Message-ID: <0A255C3D-6FB0-41E2-8BCC-FB9FF00A0236@gmail.com> >> On 2008-01-08, at 14:53, Nik Radford wrote: >>> With my idea, the ticks would be persistant (It'd need to be server >>> side value, so best to make it persistant). >> >> Why would it need to be server side? > > Ideally it should persist with your avatar if you logon from > another computer. Indeed, and so should things like the busy message, but they're currently stored in per-account files in the client configuration directory. So, unless I'm missing something... ideally it should be on the server, but it doesn't need to be. It could be prototyped in an open source client, for example. From secret.argent at gmail.com Tue Jan 8 14:25:39 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 14:25:46 2008 Subject: [sldev] API for account balance In-Reply-To: <182B2AA7-44DE-401B-AA14-BCB09C453F2E@secondlife.com> References: <4783EC62.50908@gmail.com> <182B2AA7-44DE-401B-AA14-BCB09C453F2E@secondlife.com> Message-ID: On 2008-01-08, at 15:46, Phoenix wrote: > while(1) > { > llSay(0, "current balance:" + (string)llGetOwnerBalance()); > } Would it be possible to limit this to scripts that have PERMISSION_DEBIT? From secret.argent at gmail.com Tue Jan 8 14:28:24 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 14:28:34 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783F567.9040008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: <92BB4569-4C8B-4130-B02E-6373D37E7AED@gmail.com> On 2008-01-08, at 16:12, Jonathan Wolk wrote: > Mark Burhop wrote: >> So if I understand, when I log in, I will first need to go to my >> groups and add each one to chat. This will create a tab in my >> chat window. Closing the tab will disconnect me from that group so >> I need to leave all the tabs open. > If you want to hear what's going on in each group chat session, > then yes. Actually this behavior exists today with the exception > of the first IM. After that, you need to leave the tab open to > hear chatter. True, but while I may be in 25 groups, and maybe half of them have occasional chat, normally no more than one or two are active in any given login session. There's a big difference between having two and twelve extra tabs in the window. From jwolk at lindenlab.com Tue Jan 8 15:23:08 2008 From: jwolk at lindenlab.com (Jonathan Wolk) Date: Tue Jan 8 15:21:17 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> Message-ID: <478405DC.2070008@lindenlab.com> Just thought I'd pass along some info as to LL's decision to remove some "features" of group chat in 1.19.0. The main reasons for this was to make group chat (and conference chat) opt-in instead of opt-out as there are countless complaints about "group IM spam" and frankly, I agree with the complainers about this one. Current behavior ---------------------------------------- The current behavior is as follows: When you double click a group IM session to "start" it one of two things happens. 1) The group chat session doesn't exist, so a "new" session is started in which all online group members are looked up and added to the session. This group member lookup is the cause of much DB load and there is currently no way of opting out of this. You get the IM regardless if you want it or not. or 2) A group session exists and you are just added to it. No members are looked up, you can potentially join a session with 1 other member in it. The user currently has *no* way of knowing what scenario will happen and this is very inconsistent. The user has no way of opting-out of group IM. Even if you get a group IM and close it it is possible that you will receive another group IM later (if there was a session that just ended and the code goes down path #1 again, you get the IM regardless). Also, when you log in, you are added to any existing group chat "passively" in the sense that you do not have to open your tab to receive an IM (or a little group voice chat pop up). Doing this adds minimal load to the system but is also opt-out. You'll receive any IMs to the group after you log in regardless whether you want to or not (unless you open and close the tab, but even then you may still get a group IM if a "new" session starts up and all online members are looked up.....sigh). Future Behavior ----------------------------------------- Changes were made in 1.19.0 to remove the group member lookup on new session start in an effort to decrease DB load, to make the group chat opt-in rather than opt-out, and to make the behavior more consistent. In 1.19.0 (or at least when the servers go out) when you start a group IM, you are always added to an existing group chat regardless if it exists or not (though the group may be empty. The inconsistent feature of "IM all online members of the group" is replaced with "IM all online members of the group who chose to opt-in to group chat". A change was also made to remove the auto-login in an effort to make group chat opt-in rather than opt-out. I am working on a way to make the auto join on login a simple checkbox (as mentioned in this list previously) though the previous way of having these be "passive" will not work (though there may be another way of making them passive). I hope this clears a few things up. -Jonathan Linden From ordinal.malaprop at fastmail.fm Tue Jan 8 15:33:17 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Jan 8 15:33:21 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <478405DC.2070008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> Message-ID: <81E75C51-9E3D-4866-8CFA-87D60D7AC2D7@fastmail.fm> Thank you for the more technical details there. I am sure that even the least technical observer is aware of group IM spam, too, and would thus be very keen on the idea of being able to turn it off for particular groups. This will meet with lots of "yay! good job, LL!" sort of reactions. However: I really really _really_ advise you not to put this in until the auto-join-on-login feature is implemented. Firstly it is a big change in UI behaviour without a way to return and that is always an issue, regardless. Secondly, there are lots of groups where one _always_ wants to be aware of IMs. As I stated before, there are estate lists for estates that I have controls over, where people announce griefer attacks and sim problems. I _need_ to have access to these, and so every time I log on I would have to actively join. This will be very irritating very quickly. And I am a very poor example here - I am not that sociable and I'm sure lots of people will have far more need to access different group IMs than I do. Unless there is a really significant need to put the change in group IMs before the server flags allowing auto-login PLEASE don't do so. If you do, it will turn a "oh great! LL has done something cool that is useful to the community!" change into "dammit! LL has screwed everything up again! I used to have that and it doesn't work now! " On 8 Jan 2008, at 23:23, Jonathan Wolk wrote: > Just thought I'd pass along some info as to LL's decision to > remove some "features" of group chat in 1.19.0. The main reasons > for this was to make group chat (and conference chat) opt-in instead > of opt-out as there are countless complaints about "group IM spam" > and frankly, I agree with the complainers about this one. > > Current behavior > ---------------------------------------- > The current behavior is as follows: > > When you double click a group IM session to "start" it one of two > things happens. > 1) The group chat session doesn't exist, so a "new" session is > started in which all online group members are looked up and added to > the session. This group member lookup is the cause of much DB load > and there is currently no way of opting out of this. You get the IM > regardless if you want it or not. > or > 2) A group session exists and you are just added to it. No > members are looked up, you can potentially join a session with 1 > other member in it. > > The user currently has *no* way of knowing what scenario will > happen and this is very inconsistent. The user has no way of opting- > out of group IM. Even if you get a group IM and close it it is > possible that you will receive another group IM later (if there was > a session that just ended and the code goes down path #1 again, you > get the IM regardless). > Also, when you log in, you are added to any existing group chat > "passively" in the sense that you do not have to open your tab to > receive an IM (or a little group voice chat pop up). Doing this > adds minimal load to the system but is also opt-out. You'll receive > any IMs to the group after you log in regardless whether you want to > or not (unless you open and close the tab, but even then you may > still get a group IM if a "new" session starts up and all online > members are looked up.....sigh). > > Future Behavior > ----------------------------------------- > Changes were made in 1.19.0 to remove the group member lookup on > new session start in an effort to decrease DB load, to make the > group chat opt-in rather than opt-out, and to make the behavior more > consistent. > In 1.19.0 (or at least when the servers go out) when you start a > group IM, you are always added to an existing group chat regardless > if it exists or not (though the group may be empty. The > inconsistent feature of "IM all online members of the group" is > replaced with "IM all online members of the group who chose to opt- > in to group chat". > A change was also made to remove the auto-login in an effort to > make group chat opt-in rather than opt-out. I am working on a way > to make the auto join on login a simple checkbox (as mentioned in > this list previously) though the previous way of having these be > "passive" will not work (though there may be another way of making > them passive). > I hope this clears a few things up. > > -Jonathan Linden > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Tue Jan 8 15:40:21 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jan 8 15:40:23 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <478405DC.2070008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> Message-ID: > Just thought I'd pass along some info as to LL's decision to remove > some "features" of group chat in 1.19.0. The main reasons for this was > to make group chat (and conference chat) opt-in instead of opt-out as > there are countless complaints about "group IM spam" and frankly, I > agree with the complainers about this one. I think we *all* agree with the complainers - what we disagree on is the solution. What, I (and I think others) believe the complainers want is a means to *opt out* of Group IMs for a particular group - *not* as has been implemented, making group IMs out in. I'm afraid that by rolling this out before the additional work to allow auto login (preferable without group IM tab clutter) to selected groups, this will be perceives as yet another feature loss and will be *yet another* unpopular change. I can appreciate the DB load issues - and whilst I can understand the desire to reduce DB load by removing features it does seem a worrying trend if we have to sacrifice features in order for SL to grow (we lost ratings due to database load, what will be the next feature to go?) Sorry to sound negative - but I really do think this one needs further work before going live. Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From stephendouglas at gmail.com Tue Jan 8 15:51:57 2008 From: stephendouglas at gmail.com (Stephen Douglas) Date: Tue Jan 8 15:52:00 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> Message-ID: <852876ad0801081551k24327fb6j506b9f615d9b841d@mail.gmail.com> I'm actually going to de-lurk to reinforce the comments of Ordinal and Matthew. I'm very encouraged that you've not only taken steps to understnad the problem, but you've actually come up with a well-thought out solution that seems - to me at least - to cover most use cases for group chat. And you've gone to lengths to tell us it's coming, and given us a detailed background into the current system, the new system, and the reasons for the changes. Excellent! However, it looks to me like you're (as a team, rather than any particular individuals) over-eager to roll part of this out, when in actual fact waiting (a few weeks, a month or two) until the server side is ready wouldn't cause anybody any distress, especially if they knew a change was in the works. And the flip side is that rolling out the client side changes by themselves *would* cause annoyance. I appreciate that DB load is an issue, as always. But I really don't think you can justify the interim change to residents on that basis alone. Please, don't rush this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080108/8769af0e/attachment-0001.htm From ian at neon.ai Tue Jan 8 16:49:31 2008 From: ian at neon.ai (Ian Wilson) Date: Tue Jan 8 16:49:32 2008 Subject: [sldev] Character/Avatar Engine In-Reply-To: <4783E926.9050704@watson.ibm.com> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> <4783E926.9050704@watson.ibm.com> Message-ID: <47841A1B.6090109@neon.ai> As a first stage we will update the client to change the behavior of the local avatar but then we would want to transmit those changes (using some custom messages) to other avatars using the updated client system. This, of course, is also another point of concern in the project. > > Either you'd have to use a separate server for your messages like SL > does for voice chat, or you'd have to convince LL to make server > changes (not very likely). So it is possible to route messages from the client to non LL servers? Is this a straight forward process or a major client change? One solution could be to "stuff" the data into other messages (piggybacking) for now to test the functionality or perhaps use chat text as a messaging system (parsing text in the client). As the initial phase of what we are doing is a technology demo we have the liberty to hack, fortunately. > >> Do you have anything written up on your work with lip syncing? That >> might be a useful guide for what we are looking at. > > See http://wiki.secondlife.com/wiki/User:Mm_Alder/LipSync > Great link, very useful for the animation system in general, should be more prominent. > From rdw at lindenlab.com Tue Jan 8 17:19:07 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Jan 8 17:19:09 2008 Subject: [sldev] Certified HTTP (and Escrow!) Project Update Jan 8 Message-ID: <4784210B.2030607@lindenlab.com> It's been a while! Glad to be back, hope you all had a great holiday. This past week has been a documentation week for us. We went through and added tons of api documentation to the code, and wrote up this wiki page: http://wiki.secondlife.com/wiki/Certified_HTTP_Versioning There's still more to do, though, and documenting the escrow more fully is next on the list. On chttpdev, we've been discussing how to handle the case of migrating agents, alongside a philosophical discussion about the applicability of the "shuffle" model to group membership. Code changes include: - tpool.py, which performs a similar function to saranwrap in that it performs nonblocking database operations, but it's a lot faster since it uses threads instead of processes and therefore doesn't incur serialization overhead. Tpool made the oplog benchmark 10 times faster! - There's also some code in server.py that allows one to retry requests on the server without the client's participation, for debugging purposes. - Lastly, escrow resources (RSRCs) can now be versioned without bumping the revision of the escrow itself. How to do this needs to be added to the wiki. -RYaN P.S. Mad props for the Python syntax highlighting on the wiki. From tateru.nino at gmail.com Tue Jan 8 17:31:17 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jan 8 17:32:31 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783F567.9040008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: <478423E5.40808@gmail.com> Jonathan Wolk wrote: > Mark Burhop wrote: >> So if I understand, when I log in, I will first need to go to my >> groups and add each one to chat. This will create a tab in my chat >> window. Closing the tab will disconnect me from that group so I need >> to leave all the tabs open. > If you want to hear what's going on in each group chat session, then > yes. Actually this behavior exists today with the exception of the > first IM. After that, you need to leave the tab open to hear chatter. >> If I get an incoming message, I will have to open up this window >> (increasing its size horizontally to see all the tabs) to find the >> tab that indicates a message just came in. > You can actually "arrow over" to see more of your tabs without needing > to increase the window size (I think). Or alternatively changes could > be made so that the "new IM" button appears if you receive an IM and > your communication window isn't opened or maximized (just throwing > that idea out there) >> >> To avoid this and work as I do today, I can create my own viewer with >> some hacks or wait (days? weeks?) until the server is updated. > Yup. >> >> Surely I've misunderstood. > You haven't and stop calling me Shirley Wow. Ouch. What's the motivation for the increased awkwardness? -- Tateru Nino http://dwellonit.blogspot.com/ From tateru.nino at gmail.com Tue Jan 8 17:34:30 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jan 8 17:35:45 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <852876ad0801081551k24327fb6j506b9f615d9b841d@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> <852876ad0801081551k24327fb6j506b9f615d9b841d@mail.gmail.com> Message-ID: <478424A6.5030900@gmail.com> I support and/or endorse Stephen, Ordinal and Matthew. Stephen Douglas wrote: > I'm actually going to de-lurk to reinforce the comments of Ordinal and > Matthew. > > I'm very encouraged that you've not only taken steps to understnad the > problem, but you've actually come up with a well-thought out solution > that seems - to me at least - to cover most use cases for group chat. > And you've gone to lengths to tell us it's coming, and given us a > detailed background into the current system, the new system, and the > reasons for the changes. Excellent! > > However, it looks to me like you're (as a team, rather than any > particular individuals) over-eager to roll part of this out, when in > actual fact waiting (a few weeks, a month or two) until the server > side is ready wouldn't cause anybody any distress, especially if they > knew a change was in the works. And the flip side is that rolling out > the client side changes by themselves *would* cause annoyance. > > I appreciate that DB load is an issue, as always. But I really don't > think you can justify the interim change to residents on that basis alone. > > Please, don't rush this. > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From secret.argent at gmail.com Tue Jan 8 18:52:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 8 18:52:07 2008 Subject: [sldev] Character/Avatar Engine In-Reply-To: <47841A1B.6090109@neon.ai> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> <4783E926.9050704@watson.ibm.com> <47841A1B.6090109@neon.ai> Message-ID: <8FE3D862-DA11-4C10-BEEF-51D6B61D0B74@gmail.com> On 2008-01-08, at 18:49, Ian Wilson wrote: > As a first stage we will update the client to change the behavior > of the local avatar but then we would want to transmit those > changes (using some custom messages) to other avatars using the > updated client system. This, of course, is also another point of > concern in the project. >> >> Either you'd have to use a separate server for your messages like >> SL does for voice chat, or you'd have to convince LL to make >> server changes (not very likely). > So it is possible to route messages from the client to non LL > servers? Is this a straight forward process or a major client change? You would simply make your modified client open a connection to (say) http://REGION_X-REGION_Y.your.domain.example.com/anim.svc? region=REGION_X-REGION_Y and send and receive messages of your own devising that would be forwarded to other client connections that have registered with your region or adjacent regions. The region's in there twice to make it easier to scale to multiple servers... you'll reconnect after a region crossing (but keep the old connection until the new one's there) so you can divide the world up or just have a single wildcard A record for all regions to start with. You'll get the X and Y from the region corner, so hopefully you won't get messed up when LL moves regions around... From roamingryozu at gmail.com Tue Jan 8 19:36:53 2008 From: roamingryozu at gmail.com (Andre Roche) Date: Tue Jan 8 19:37:00 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> Message-ID: <5eff6d3b0801081936we6458d1ib46ce5ecc90663b5@mail.gmail.com> I assume you mean on the communications window. I think the design so far is just about perfect.. it just needs a little tweaking, and being fully implemented before being rolled out. I wouldn't change anything so far, in reference to the proposed design in so much as I'd simply add a drop down box setting in the group window, right next to the one that lets you choose your current group title. The options would be pretty simple: 1) Do not autojoin group chat on login. 2) Auto join group chat 3) Auto join group chat (Passive) Passive would be the same as passive mode is now, while option 2 would open the group chat window automatically (With a message "Joined group chat.") These settings would be per group. In addition, I'd add an option under the Preferences that allows a user to default to "Passive" mode whenever they close a group chat tab, as opposed to leaving the chat entirely. (But also include a full "Leave group chat" button as well.) This would make people who want to hear group chat but have a habit of closing group chat windows, without intending to leave the chat, happy. But like others, I feel these things should be fully implemented before any of the changes go live. On Jan 8, 2008 6:40 PM, Matthew Dowd wrote: > > > > Just thought I'd pass along some info as to LL's decision to remove > > some "features" of group chat in 1.19.0. The main reasons for this was > > to make group chat (and conference chat) opt-in instead of opt-out as > > there are countless complaints about "group IM spam" and frankly, I > > agree with the complainers about this one. > > I think we *all* agree with the complainers - what we disagree on is the solution. > > What, I (and I think others) believe the complainers want is a means to *opt out* of Group IMs for a particular group - *not* as has been implemented, making group IMs out in. > > I'm afraid that by rolling this out before the additional work to allow auto login (preferable without group IM tab clutter) to selected groups, this will be perceives as yet another feature loss and will be *yet another* unpopular change. > > I can appreciate the DB load issues - and whilst I can understand the desire to reduce DB load by removing features it does seem a worrying trend if we have to sacrifice features in order for SL to grow (we lost ratings due to database load, what will be the next feature to go?) > > Sorry to sound negative - but I really do think this one needs further work before going live. > > Matthew > _________________________________________________________________ > Telly addicts unite! > http://www.searchgamesbox.com/tvtown.shtml_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From xotmid at gmail.com Tue Jan 8 19:44:37 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Tue Jan 8 19:44:38 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <5eff6d3b0801081936we6458d1ib46ce5ecc90663b5@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> <5eff6d3b0801081936we6458d1ib46ce5ecc90663b5@mail.gmail.com> Message-ID: please please please make it to where we can uncheck send messages to group chat. so esentially a group chat can be moderated On Jan 8, 2008 9:36 PM, Andre Roche wrote: > I assume you mean on the communications window. I think the design so > far is just about perfect.. it just needs a little tweaking, and being > fully implemented before being rolled out. > > I wouldn't change anything so far, in reference to the proposed design > in so much as I'd simply add a drop down box setting in the group > window, right next to the one that lets you choose your current group > title. The options would be pretty simple: 1) Do not autojoin group > chat on login. 2) Auto join group chat 3) Auto join group chat > (Passive) > > Passive would be the same as passive mode is now, while option 2 would > open the group chat window automatically (With a message "Joined group > chat.") These settings would be per group. > > In addition, I'd add an option under the Preferences that allows a > user to default to "Passive" mode whenever they close a group chat > tab, as opposed to leaving the chat entirely. (But also include a > full "Leave group chat" button as well.) This would make people who > want to hear group chat but have a habit of closing group chat > windows, without intending to leave the chat, happy. > > But like others, I feel these things should be fully implemented > before any of the changes go live. > > > > On Jan 8, 2008 6:40 PM, Matthew Dowd wrote: > > > > > > > Just thought I'd pass along some info as to LL's decision to > remove > > > some "features" of group chat in 1.19.0. The main reasons for this > was > > > to make group chat (and conference chat) opt-in instead of opt-out as > > > there are countless complaints about "group IM spam" and frankly, I > > > agree with the complainers about this one. > > > > I think we *all* agree with the complainers - what we disagree on is the > solution. > > > > What, I (and I think others) believe the complainers want is a means to > *opt out* of Group IMs for a particular group - *not* as has been > implemented, making group IMs out in. > > > > I'm afraid that by rolling this out before the additional work to allow > auto login (preferable without group IM tab clutter) to selected groups, > this will be perceives as yet another feature loss and will be *yet another* > unpopular change. > > > > I can appreciate the DB load issues - and whilst I can understand the > desire to reduce DB load by removing features it does seem a worrying trend > if we have to sacrifice features in order for SL to grow (we lost ratings > due to database load, what will be the next feature to go?) > > > > Sorry to sound negative - but I really do think this one needs further > work before going live. > > > > Matthew > > _________________________________________________________________ > > Telly addicts unite! > > > http://www.searchgamesbox.com/tvtown.shtml_______________________________________________ > > > > 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/20080108/e7b96677/attachment-0001.htm From rdw at lindenlab.com Tue Jan 8 20:10:34 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Jan 8 20:10:57 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478423E5.40808@gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <478423E5.40808@gmail.com> Message-ID: <4784493A.2000606@lindenlab.com> Tateru Nino wrote: >> You haven't and stop calling me Shirley > Wow. Ouch. What's the motivation for the increased awkwardness? Airplane quote dude! :-P -RYaN From dahliatrimble at gmail.com Tue Jan 8 22:57:18 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jan 8 22:57:21 2008 Subject: [sldev] 1.19.0 Group Chat Message-ID: A feature suggestion along these lines... If not actively logging into groups would reduce database load, would it be possible to increase the group limits beyond 25, allowing membership in many more groups, but limiting the number of groups one can select to communicate in concurrently to 25? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080108/6c46d2a3/attachment.htm From hakushakukun at gmail.com Tue Jan 8 23:25:26 2008 From: hakushakukun at gmail.com (Adric R) Date: Tue Jan 8 23:25:29 2008 Subject: [sldev] 1.19.0 Group Chat Message-ID: <781e4b420801082325m3a29453fl784bf9343da1609a@mail.gmail.com> This reminds me of when LL took away the ability to view textures/snapshots in non-fixed aspect ratios: a completely arbitrary decision that really doesn't make sense, affects everyone, and makes a feature less useful. A lot of people are going to complain that "See? LL doesn't listen to its users!" and in this case, they'll be right. Looking at https://jira.secondlife.com/browse/MISC-64, I see 301 votes for an option to OPT-OUT of group chat, not opt-in. How often do LL's usability people actually spend inworld? Do they have active social participation? Because I'm really confused how you can be active in SL and think that this solution is better than the one residents have asked for (and have been asking for for a long time). Another brought out of silence lurker, -- McCabe Maxsted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/1743159c/attachment.htm From tateru.nino at gmail.com Tue Jan 8 23:49:30 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jan 8 23:50:45 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4784493A.2000606@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <478423E5.40808@gmail.com> <4784493A.2000606@lindenlab.com> Message-ID: <47847C8A.2040000@gmail.com> Ryan Williams (Which) wrote: > Tateru Nino wrote: > >>> You haven't and stop calling me Shirley >>> >> Wow. Ouch. What's the motivation for the increased awkwardness? >> > > Airplane quote dude! :-P > > -RYaN > > Aware of the quote - and it was nice to see it put in an appearance. I was querying everything before the word "and" :) -- Tateru Nino http://dwellonit.blogspot.com/ From metaxlr8 at gmail.com Wed Jan 9 00:15:38 2008 From: metaxlr8 at gmail.com (Giulio Prisco) Date: Wed Jan 9 00:15:40 2008 Subject: [sldev] SL banking ban: hot comments Message-ID: http://metaxlr8.net/index.php/site/sl_banking_ban_hot_comments/ Sorry, I am sending this to far too many SL lists and it is perhaps off-topic on this list, but I think some points must be made. -- Giulio Prisco gp@metafuturing.com metafuturing S.L. http://metafuturing.com/ http://metaxlr8.net/ C Juan Ram?n Jim?nez 8-1 Complejo Eurobuilding 28036 Madrid - Spain Phone (34) 91 18 19 147 Fax (34) 91 350 47 52 Cell (34) 610 536 144 From alexander.treptow at zweitgeist.com Wed Jan 9 00:38:39 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Wed Jan 9 00:38:53 2008 Subject: [sldev] Worn Items/Objects In-Reply-To: <4783F79C.5060009@watson.ibm.com> References: <477E5089.9020006@zweitgeist.com> <47826DC4.8040207@watson.ibm.com> <478340DE.3070100@zweitgeist.com> <4783F79C.5060009@watson.ibm.com> Message-ID: <4784880F.6020905@zweitgeist.com> >> I mean rendering "only" the worn objects of "my" avatar. no other >> objects of any other avatar. > > When you say "worn" you could mean either the textures applied to the > mesh to simulate clothes or the avatar attachments. They're treated > differently. > Sorry, i ment the avatar attachments, objects like a cap, special hair or a torch for example. > Look in indra/newview/llvoavatar.cpp at the idleUpdate(). My first > guess would be > > if (!mIsSelf) > return TRUE; > > near the beginning, but I haven't actually tried it. The code you > need should be in that function anyway. I dont know if that works i've done the same in a displaying function. but thanks for that ;) greets, Alex From hud at zurich.ibm.com Wed Jan 9 02:56:08 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Wed Jan 9 02:55:43 2008 Subject: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues Message-ID: <4784A848.9000208@zurich.ibm.com> the new web based authentication scheme uses a web page to capture the fullname and the password of an avatar and returns a web_login_key that is passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL client takes that secondlife:///app/login/... URI and extracts the web_login_key (and first and last name and other stuff it seems) and goes to the login service to log the avatar/agent in to the grid. while this works with the LL grid, it does not work with OpenSim grids, because the LL SL client has no clue that it needs to go to a different, non-LL grid login service: the latest release clients and the windlight client do provide the -loginpage which would allow us to direct the client to a login page of our own, where we could then generate the secondlife:///app/login/.. URI --- however, that URI does not include any reference whatsoever to the grid you want to connect to (well, it does to some extent: there is a 'grid' parameter but that only knows about LL grids and also does not include ports, resources, etc) teravus ousley has described this in much more detail (and probably better than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he also tried several other things (have a look at VWR-4021, if you are interested in the details) to no avail: we cannot get the latest windlight and RC clients to connect to OpenSim grids/servers. luckily, we had a chance to discuss this with tess linden at yesterday's AWGroupies meeting. the following two proposals came up: (a) use the currently empty host part of the secondlife:///app/login URI to specify the grid server: that is, to connect to my 4x4 OpenSim grid running here in the lab, i'd have the following URI: secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... the LL SL client would simply do a s/^secondlife:/http:/ substitution and use the resulting URL to login the avatar in. (b) recast the currently used grid parameter to always contain the FQDN of the grid server along with port and resource; that is, for my lab grid that would be: secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... here the client would have to parse the URI, extract the grid parameter, un-quote its value, then construct the login URL and login the avatar in. clearly, approach (a) seems to be the cleanest approach and fits well with the common URI scheme. however... ...during the discussion it transpired that the reason the host part of the secondlife:/// URI is empty, is that the target of that SLURL is *not* the grid server but the *client*! in particular, /app/login signals to the client what it should do: login via a URL that it needs to construct from the supplied URI. ...also, as fword utorid remarked, using the secondlife: URI to trigger a grid login adds a new semantic to the secondlife: URI --- so far it has been used as a kind of secondlife GPS location fix: secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 island, for example. now, secondlife:///app/login?... addresses the secondlife client and tells it to do a login to a grid. the majority of the participants in the discussion did favor approach (a), but given the way the secondlife:/// URI is currently used, the most pragmatic approach for the time being seems to be (b). that will work, but it doesn't really fit well into the "web way of doing things" --- a better approach would be to have another URI scheme name allocated for grid login URI, for example, secondlifegrid: finally, as was pointed out by neas bade, the login page is not the only place that we encounter the assumption that the client will only be used with LL grids --- search, as neas, said is another example. getting rid of all those silent assumptions (and returning the search URI as part of the seed caps, for example) is really a necessary next step if we want to have interoperability! so, in summary (1) we have a pragmatic (kludgy?) solution proposal to providing the grid to use via the login page; though, wouldn't it be better to have a different URI scheme name for grid logins? for example, secondlifegrid://grid.server.com:port/resource/login?... (2) we need to get rid of all silent assumptions about the grid being an LL grid. the complete log of the AWGroupies meeting is available at http://wiki.secondlife.com/wiki/AWGroupies-2008-01-08. cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/ead1a675/attachment-0001.htm From hud at zurich.ibm.com Wed Jan 9 03:07:31 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Wed Jan 9 03:07:36 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <4784AAF3.1000703@zurich.ibm.com> Joshua Bell wrote: > [...] > > We're still pulling together the release notes for 1.19.0, but the > high-level summary is: > > * 61 bug fixes > * "Voice 1.1" will that finally include voice support for linux???? cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From latif at klclub.info Wed Jan 9 05:44:45 2008 From: latif at klclub.info (Latif Khalifa) Date: Wed Jan 9 05:44:51 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783F567.9040008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: On Jan 8, 2008 11:12 PM, Jonathan Wolk wrote: [snip] > > To avoid this and work as I do today, I can create my own viewer with > > some hacks or wait (days? weeks?) until the server is updated. > Yup. > > > > Surely I've misunderstood. > You haven't and stop calling me Shirley This change in how group IM-s work will have a huge impact and perhaps it should not be rushed into live viewer so fast. It changes how groups like "Advanced Scripters of Second Life" operate. No longer will you get the new IM tab open automatically when someone has a question. Cluttering already badly designed communicate window with tabs for each group that you would want to get chat from is not really an option. From usability POV it would be a nightmare. Many communities in SL depend on being able to communicate in this way, this is not a small change. If you really want to improve usability some form of "auto open IM tab when there is chatter in the group" is necessary. Again, having to have 10 - 15 IM tabs open would be such a usability downgrade. And how about implementing what everybody really wants, a check box saying "do not receive IMs from this group". - L From secret.argent at gmail.com Wed Jan 9 06:06:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 06:06:30 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> On 2008-01-09, at 07:44, Latif Khalifa wrote: > And how about implementing what everybody really wants, a check box > saying "do not receive IMs from this group". Hell yes. Or how about something that every IM program in the world has: "log in offline"? When you "log in offline" you don't show up as logged in to IM, to "friends", to "give inventory", on the web, nothing. People interacting with you through any interfaces that don't involve being actually present in-world get the same response as if you're offline. If you do anything that involves the IM system (including accepting inventory from people not in the same sim, sending IMs, and so on) then you go online (after a warning dialog). So you can, you know, log in to build without having 3000 IMs from people who have been waiting to pounce, and without having to play games with alts and tripping over permissions and making sure that you don't create prims in the wrong account for stuff you're going to sell... NO, BUSY MODE AND "ONLY SHOW ONLINE TO FRIENDS" DO NOT COUNT, OK? Busy mode is *especially* useless, and having to go through your friends list and reset who you're going to show as online with when you want to go in and out of offline mode is (a) horribly time consuming, and (b) probably going to lag the hell out of the asset/ presence servers. Sorry about shouting. But this has been a sore spot for... eek, getting on years now. From monkowsk at watson.ibm.com Wed Jan 9 08:43:06 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 9 08:43:20 2008 Subject: [sldev] Character/Avatar Engine In-Reply-To: <47841A1B.6090109@neon.ai> References: <4782C6C7.4030909@neon.ai> <4782C8C2.8040209@watson.ibm.com> <4782CBF8.9060709@neon.ai> <4782CFBD.8040302@watson.ibm.com> <4782D662.8000305@neon.ai> <4783E926.9050704@watson.ibm.com> <47841A1B.6090109@neon.ai> Message-ID: <4784F99A.5000606@watson.ibm.com> Ian Wilson wrote: > So it is possible to route messages from the client to non LL > servers? Is this a straight forward process or a major client change? For voice chat, the viewer uses sockets to connect to a separate process that communicates with the Vivox servers using HTTPS and UDP. See http://wiki.secondlife.com/wiki/Voice#Technical This is a separate message stream from the one going to the Linden Lab servers. If you're familiar with sockets, this kind of implementation should be straightforward, however, unless you're willing to provide servers for the whole community, you're not likely to get this incorporated into the standard viewer (although you never said that was one of your goals). > One solution could be to "stuff" the data into other messages > (piggybacking) for now to test the functionality or perhaps use chat > text as a messaging system (parsing text in the client). As the initial > phase of what we are doing is a technology demo we have the liberty to > hack, fortunately. I'm no expert on the chat channels, but I believe they can be used for communication between LSL scripts and such. That might be worth more investigation. >> See http://wiki.secondlife.com/wiki/User:Mm_Alder/LipSync >> > Great link, very useful for the animation system in general, > should be more prominent. The lip sync is still in beta test, not part of the standard viewer yet. Mike From monkowsk at watson.ibm.com Wed Jan 9 08:59:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 9 09:02:47 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <4784FD8D.7040600@watson.ibm.com> Joshua Bell wrote: > As might be inferred from the number, we are planning on making the > 1.19.0 Viewer update mandatory for residents at some point in the near > future ? probably early February. [...] > We're still pulling together the release notes for 1.19.0, but the > high-level summary is: > > * 61 bug fixes > * "Voice 1.1" > ** Introduces moderated to (formal) group voice and group text > conversations > ** Moderation ability applies to group owner and group officer roles > ** Moderation will NOT apply to one-to-one text or voice chat, ad-hoc > group conversation, or to spatial voice chat. > * Auto-joining group chat sessions has been removed > ** Group members must explicitly choose to actively "join" their SL > Group's chat sessions after they log in. > ** Starting a new SL group chat only adds the requester to the chat > session much like an IRC channel. > > Obviously, for the voice moderation and group chat improvements there > are server side components, so these features will not "light up" until > we've updated the servers, which is tentatively planned for next week. [...] > And while I'm here, here's what we're expecting in 1.18.6 RC4 (deltas > from RC3) - some of the changes failed QA so we'll need to iterate a bit: > * Language names need to have a consistent format in preferences drop-down > * QuickTime disabled message cannot be ignored > * Linux client doesn't recognize that a viewer is already running > * Display HTML error page in selected language when viewer is unable to > connect to second life URL > * VWR-3667;About Land > Access: On group owned land, group owner gets > eject message when "Public Access" is unchecked > * VWR-3829: Cursor in Logon edit boxes difficult to see > * VWR-3501: Create/Edit Gesture window preview button blanks after pressing > * VWR-4010: New search does not accept non ASCII characters > * VWR-3539: Communicate window width will no longer resize smaller in > 1.18.5.3 OK, I don't get it. RC4 will get some new features, but not everything in 1.19.0. And 1.19.0 will go out before the servers can handle it. Yet 1.19.0 will quickly become mandatory. Am I missing the purpose of the "Release Candidate" program? Are some LL developers exempt from the RC track or something? Does the release "roadmap" have "express bypasses" on it? Mike From gigstaggart at gmail.com Wed Jan 9 09:09:34 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jan 9 09:09:36 2008 Subject: [sldev] API for account balance In-Reply-To: <182B2AA7-44DE-401B-AA14-BCB09C453F2E@secondlife.com> References: <4783EC62.50908@gmail.com> <182B2AA7-44DE-401B-AA14-BCB09C453F2E@secondlife.com> Message-ID: <4784FFCE.7080900@gmail.com> Phoenix wrote: > This is on the horizon, but not available any time soon. We do not have > sufficient infrastructure at this time to handle the millions of scripts > that take advantage of this service of the form: > > while(1) > { > llSay(0, "current balance:" + (string)llGetOwnerBalance()); > } Then block it from LSL for now and just give us an external web service. I assume with this new http authentication cookie deal, we could do this easier, right? It's a pretty huge issue, the way we have to do it now is use Curl to log in to the actual SL web site, and bang on the balance there. That surely creates more load! -Jason From bboomslang at googlemail.com Wed Jan 9 09:21:14 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Wed Jan 9 09:21:17 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783BDF6.6080806@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> Message-ID: <347b550f0801090921p539a0e0atf51cc5e32bcbd265@mail.gmail.com> On Jan 8, 2008 7:16 PM, Joshua Bell wrote: > * Auto-joining group chat sessions has been removed > ** Group members must explicitly choose to actively "join" their SL > Group's chat sessions after they log in. > ** Starting a new SL group chat only adds the requester to the chat > session much like an IRC channel Yeah, great, that will make the rather icky "communicate" window even worse to use. If I have to keep multiple group chat tabs open just to get the chat there, even if they are not too active normally, my normal IM conversations that are stuffed into the very same main window will get lost in lots of tabs. Great - so I am officer in a few groups where residents might post questions in my role as officer, or I am a member of the group and some admin might pass on information, and now I have to keep them permanently open, instead of waiting for the first message there to pop up (which in some of them might maybe happen once a week or less - but if it _does_ happen, I damn sure want that IM). Why don't you ditch group chat completely? I mean, come on, IRC is so 90s, that's far to modern, lets go back to BITNET mailinglists (aka group notices), that's obviously enough for everybody, right? And since many people won't bother joining actively to group chats, announcements with mere group IMs are worthless after the proposed change. Which will turn many helping or community chats into wastelands, too - as only a rather minor part will bother to join them before they have a quesiton there, which after your change will fall on deaf ears then ... What refreshing alternative would it have been had you written that you plan to make the group chat actually work with big groups finally, so that not a good deal of group notices get lost somwhere in your servers, but nah, just drop another useability horror on the residents. Sometimes I really wonder wether the changes to the chat UI and system are just intentional malice from the lab ... bye, Barney -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/616765da/attachment.htm From josh at lindenlab.com Wed Jan 9 09:38:56 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 09:38:28 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4784AAF3.1000703@zurich.ibm.com> References: <4783BDF6.6080806@lindenlab.com> <4784AAF3.1000703@zurich.ibm.com> Message-ID: <478506B0.3040301@lindenlab.com> Dr Scofield wrote: > Joshua Bell wrote: >> [...] >> >> We're still pulling together the release notes for 1.19.0, but the >> high-level summary is: >> >> * 61 bug fixes >> * "Voice 1.1" > will that finally include voice support for linux???? Voice for Linux is in internal QA right now; I'm not clear on the status (i.e. if it's complete and being tested, or at a good interim stage to validate the work so far). It will not be part of 1.19.0. From nchase at earthlink.net Wed Jan 9 09:52:34 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Wed Jan 9 09:52:39 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4783F567.9040008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> Message-ID: <478509E2.2060108@earthlink.net> Jonathan Wolk wrote: > Mark Burhop wrote: >> If I get an incoming message, I will have to open up this window >> (increasing its size horizontally to see all the tabs) to find the tab >> that indicates a message just came in. > You can actually "arrow over" to see more of your tabs without needing > to increase the window size (I think). Or alternatively changes could > be made so that the "new IM" button appears if you receive an IM and > your communication window isn't opened or maximized (just throwing that > idea out there) The only way this MIGHT work for me is if the "New IM" button appears EVEN IF the window is maximized. Even today I frequently miss messages because I have so many tabs open the flashing ones are off to the right, where I don't see them. And on a busy day, that's just groups with active (or semi-active) conversations. If I have to open a tab for every group I'm interested in in case there might be a conversation, I'm dead. And yes, I think this will be a real killer for support-type groups, because lots of people who might have the answer aren't listening to the question. Bad, bad, bad idea, as presented. ---- Nick From soft at lindenlab.com Wed Jan 9 09:58:33 2008 From: soft at lindenlab.com (Soft) Date: Wed Jan 9 09:58:36 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm Message-ID: If you have something that should be discussed Thursday, please add it to: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From josh at lindenlab.com Wed Jan 9 10:02:34 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 10:02:02 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4784FD8D.7040600@watson.ibm.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> Message-ID: <47850C3A.1080804@lindenlab.com> Mike Monkowski wrote: > OK, I don't get it. RC4 will get some new features, but not > everything in 1.19.0. And 1.19.0 will go out before the servers can > handle it. Yet 1.19.0 will quickly become mandatory. Am I missing the > purpose of the "Release Candidate" program? Are some LL developers > exempt from the RC track or something? Does the release "roadmap" > have "express bypasses" on it? Good question. The intended process is: (1) developers commit changes that have passed QA into the code trunk; (2) at appropriate times we freeze (branch off) from the trunk to start stabilizing a version and call it an RC; (3) we stabilize the RC branch via iterations of internal QA, fixes, public releases, fixes; meanwhile (1) continues unblocked; (4) when deemed "good enough" then the RC is released. We triage changes going into an RC. When the RC is first frozen, the bar is roughly: regression fixes, bug fix for new features, fit-and-finish on new features, internationalization/localization changes, security, performance, text-only UI changes. We try and raise the bar with each RC iteration. Falling over the holidays and including the new login mechanism, the 1.18.6 RC series has taken longer to stabilize than others. Let me drill into the specific items below and explain why they were "allowed" into the RC rather than waiting for 1.19: Joshua Bell wrote: > * Language names need to have a consistent format in preferences > drop-down Localization: It's a text-only change in the XUI files. > * QuickTime disabled message cannot be ignored Fit-and-finish on new feature > * Linux client doesn't recognize that a viewer is already running This was actually in the 1.18.6 change set originally, but the fix turned out to not work, so this is a fix-on-a-fix. > * Display HTML error page in selected language when viewer is unable > to connect to second life URL Fit-and-finish on new feature (new login page) > * VWR-3667;About Land > Access: On group owned land, group owner gets > eject message when "Public Access" is unchecked Regression fix - the fix was made in a previous RC iteration, but a bug was found in the fix which itself needs fixing. > * VWR-3829: Cursor in Logon edit boxes difficult to see Fit-and-finish on new feature > * VWR-3501: Create/Edit Gesture window preview button blanks after > pressing The fix was a low-risk XUI change. > * VWR-4010: New search does not accept non ASCII characters Internationalization > * VWR-3539: Communicate window width will no longer resize smaller in > 1.18.5.3 The fix was believed to be a low-risk XUI change. It appears (from further testing) that this the fix is not comprehensive (i.e. it failed QA) so we may not include it in 1.18.6 Regarding other points: Mike Monkowski wrote: > RC4 will get some new features, but not everything in 1.19.0. 1.19.0 will be a superset of 1.18.6. RC4 should not include new "features" just changes that meet the triage bar. I realize that's quibbling - the important thing is that the changes allowed in are intended to reduce risk and are triaged. > And 1.19.0 will go out before the servers can handle it. I believe this is referring to the discussion on group chat changes. We're reviewing all of the feedback that has been sent to SLDEV and are looking at plans/schedules to see what we should do. Expect an update soon. > Am I missing the purpose of the "Release Candidate" program? The purpose is to get a "we think it's ready" version to the public for use on the service. Some times we're closer to being ready out of the gate than others. Apart from changes that meet the triage bar, the feature set should be frozen so that as an RC is iterated on the risk is constantly being reduced. > Are some LL developers exempt from the RC track or something? Does > the release "roadmap" have "express bypasses" on it? There are humans in the triage loop, and yes, we may say "you know what, that change is low risk and high impact, and we'd prefer to have it out in the RC and next release, and not wait another month for the next go-round of the cycle". From belxjander at gmail.com Wed Jan 9 10:11:23 2008 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Wed Jan 9 10:11:14 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer Message-ID: <1199902283.12476.25.camel@localhost> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080110/45ed744d/attachment.pgp From matthew.dowd at hotmail.co.uk Wed Jan 9 10:42:22 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jan 9 10:42:24 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47850C3A.1080804@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> Message-ID: > The intended process is: (1) developers commit changes that have passed > QA into the code trunk; (2) at appropriate times we freeze (branch off) > from the trunk to start stabilizing a version and call it an RC; (3) we > stabilize the RC branch via iterations of internal QA, fixes, public > releases, fixes; meanwhile (1) continues unblocked; (4) when deemed > "good enough" then the RC is released. We seem to be missing something in the process - FirstLook are for getting feedback on major new features (such as voice and windlight) whilst RCs are, as I understand it, meant to be frozen re features/patch integration and just a means of knocking out the rough edges before a main release. What we are missing is a means to try out a new feature or patch outside of LL, to see if the feature/patch actually solves the problem/requirement intended without causing more problems than it solves. Group IMs are a good example - we all agree that a means of opting out of Group IMs are a good idea; we generally agree that what has been described in 1.19 isn't too wide of the mark, but wide enough that the general SLDev consensus is that in its current form it isn't workable and will get a pretty negative reception but with a little more work a solution which will be well recieved is possible. I suppose what I'm talking about is a beta stage? whether that involves real software or just an earlier discussion of forthcoming things on lists like this, I'm not sure. Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From lenglish5 at cox.net Wed Jan 9 10:45:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 9 10:45:43 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> Message-ID: <47851654.7060302@cox.net> Argent Stonecutter wrote: > On 2008-01-09, at 07:44, Latif Khalifa wrote: >> And how about implementing what everybody really wants, a check box >> saying "do not receive IMs from this group". > > Hell yes. > > Or how about something that every IM program in the world has: "log in > offline"? > > When you "log in offline" you don't show up as logged in to IM, to > "friends", to "give inventory", on the web, nothing. People > interacting with you through any interfaces that don't involve being > actually present in-world get the same response as if you're offline. > If you do anything that involves the IM system (including accepting > inventory from people not in the same sim, sending IMs, and so on) > then you go online (after a warning dialog). So you can, you know, log > in to build without having 3000 IMs from people who have been waiting > to pounce, and without having to play games with alts and tripping > over permissions and making sure that you don't create prims in the > wrong account for stuff you're going to sell... > > NO, BUSY MODE AND "ONLY SHOW ONLINE TO FRIENDS" DO NOT COUNT, OK? Busy > mode is *especially* useless, and having to go through your friends > list and reset who you're going to show as online with when you want > to go in and out of offline mode is (a) horribly time consuming, and > (b) probably going to lag the hell out of the asset/presence servers. > > Sorry about shouting. But this has been a sore spot for... eek, > getting on years now. > ARegent, I've been documenting how the protocols work, and I've spent the last week trying to understand Group IM. The (horribly not filled in) description of the UDP packet for group IM can be found here: https://wiki.secondlife.com/wiki/ImprovedInstantMessage The flow to get to that point, as I understand it, is: perform login, get seed capability, start sending packets to establish UDP circuit. Send packets to establish agent presence in your login simulator, get (at least) a ruthed avatar into teh world, then send an IMprovedInstantMessage packet with a Dialog byte value of 15 to request a group IM session. THEN go to EventQueueNext cap and poll incoming events for the ChatterboxSessoinStart Event (or whatever it is called), THEN start sending and receiving IIM packets for that particular group. Its a bloody mess. Right now, what you ask for requires a ruthed avatar to be sitting in a simulator someplace. Contrast that with the upcoming group IM procedure that Donovan LInden outlines in his comments below. The difference is startling and will make tweaking the system far, FAR easier: http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/ [reference to article snipt] * the seed capability can give you another seed capability into another service (solves the seed capability requiring global knowledge problem) - the login service gives you an agent domain seed capability - the agent domain seed capability gives you a region domain seed capability (if the agent chooses to enter a region) * capabilities are usually requested at the beginning of a ?session? with some entity and then used repeatedly (thus you do not need 2 http requests per request during normal usage) - a user wants to log in to just group chat: - request the group chat seed capability from the authentication service, and then request the GetNextMessage and SendMessage capabilities from the seed cap - repeatedly invoke these GetNextMessage and SendMessage capabilities for the duration of the chat session with the server From secret.argent at gmail.com Wed Jan 9 10:47:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 10:47:09 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1199902283.12476.25.camel@localhost> References: <1199902283.12476.25.camel@localhost> Message-ID: <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: > Voice is its own "subservice" thread and seperate server, > Why not the same using IRC as a backend for chat? Jabber, please. From lenglish5 at cox.net Wed Jan 9 11:01:31 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 9 11:01:33 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> Message-ID: <47851A0B.3060903@cox.net> Matthew Dowd wrote: > >> The intended process is: (1) developers commit changes that have passed >> QA into the code trunk; (2) at appropriate times we freeze (branch off) >> from the trunk to start stabilizing a version and call it an RC; (3) we >> stabilize the RC branch via iterations of internal QA, fixes, public >> releases, fixes; meanwhile (1) continues unblocked; (4) when deemed >> "good enough" then the RC is released. >> > > We seem to be missing something in the process - FirstLook are for getting feedback on major new features (such as voice and windlight) whilst RCs are, as I understand it, meant to be frozen re features/patch integration and just a means of knocking out the rough edges before a main release. > > What we are missing is a means to try out a new feature or patch outside of LL, to see if the feature/patch actually solves the problem/requirement intended without causing more problems than it solves. > > Group IMs are a good example - we all agree that a means of opting out of Group IMs are a good idea; we generally agree that what has been described in 1.19 isn't too wide of the mark, but wide enough that the general SLDev consensus is that in its current form it isn't workable and will get a pretty negative reception but with a little more work a solution which will be well recieved is possible. > > I suppose what I'm talking about is a beta stage? whether that involves real software or just an earlier discussion of forthcoming things on lists like this, I'm not sure. > At Zero's office horuse yesterday, we were talking about a dev grid specifically to test login transfer between OpenSim and Second LIfe and back. The concept could be extended to test new forms of IM protocols as well. They MUST be new forms. If you read my abreviated description of the current Group IM situation and contrast that with Donovan's plan, you'll see that its a huge change in how things work and will need much testing to make sure things don't break during the transition. Lawson From monkowsk at watson.ibm.com Wed Jan 9 11:08:55 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 9 11:09:00 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47850C3A.1080804@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> Message-ID: <47851BC7.4070607@watson.ibm.com> Joshua Bell wrote: > There are humans in the triage loop, and yes, we may say "you know what, > that change is low risk and high impact, and we'd prefer to have it out > in the RC and next release, and not wait another month for the next > go-round of the cycle". So maybe I missed something. Will we see 1.18.6 RC4 followed by 1.19.0 Release (mandatory update)? Or will we see 1.18.6 RC4 followed by 1.18.6 Release (optional update) then 1.19.0 RC1, 1.19.0 RC2, ... 1.19.0 Release (mandatory update)? Your earlier message implied the former, but now is sounds more like the latter. Mike From matthew.dowd at hotmail.co.uk Wed Jan 9 11:36:51 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jan 9 11:36:52 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47851A0B.3060903@cox.net> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851A0B.3060903@cox.net> Message-ID: > At Zero's office horuse yesterday, we were talking about a dev grid > specifically to test login transfer between OpenSim and Second LIfe and > back. The concept could be extended to test new forms of IM protocols as > well. > > They MUST be new forms. If you read my abreviated description of the > current Group IM situation and contrast that with Donovan's plan, you'll > see that its a huge change in how things work and will need much testing > to make sure things don't break during the transition. Yes, but we already have mechanisms for testing these fairly large changes such as the beta grid (as is being used for Havoc4) and firstlook (as is being used for windlight) We don't have good mechanisms for feedback on minor changes (replacing lag bars with a search box, the 1.19 changes to group IM which seem to be an interim measure coming in somewhat prior to Donovan's changes, etc.) before they get frozen into an RC. Matthew _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com From secret.argent at gmail.com Wed Jan 9 11:50:23 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 11:50:31 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <47851654.7060302@cox.net> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> Message-ID: <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> This is really a new subject... On 2008-01-09, at 12:45, Lawson English wrote: >> Or how about something that every IM program in the world has: >> "log in offline"? > > ARegent, I've been documenting how the protocols work, and I've > spent the last week trying to understand Group IM. > > [...] > > Right now, what you ask for requires a ruthed avatar to be sitting > in a simulator someplace. I think you've got things backwards. I'm not talking about logging in to IM without being inworld. I'm talking about logging in inworld without being in the IM side of things at all. So you can log in to SL, build, deal with local issues, without showing up as being "online" on the website, or via profile, or via give inventory. Yes, I know you'll still show up with some LSL calls and people can see you, but you won't be getting notices or IMs or so-and-so-has-given-you-a-notecard. That would all go to email like you weren't logged in. It really doesn't even involve the client at all, except that the client won't get (or send) messages that would involve the IM system, and it'd have some new message to say "logging in offline" when you initially log in, and "go online" when you decide to go online. This is not "busy". You don't reject asset transfers (which is a nasty nasty side effect) and send away or busy messages. You just don't show up for people who aren't actually there in-world with you. This is not "only online to my friends". Some times it's my friends I most want to be offline to. And I have WAY too many friends to set them manually. This is "offline to everyone". Period. Temporarily. One step. From josh at lindenlab.com Wed Jan 9 11:31:29 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 11:51:10 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> Message-ID: <47852111.1050409@lindenlab.com> Matthew Dowd wrote: > What we are missing is a means to try out a new feature or patch outside of LL, to see if the feature/patch actually solves the problem/requirement intended without causing more problems than it solves. > I suppose what I'm talking about is a beta stage? whether that involves real software or just an earlier discussion of forthcoming things on lists like this, I'm not sure. > Yes indeed - in the past we did this with Beta Grid testing for significant client/server changes like this. I think we'll return to that model as well, soon. Right now, the Havok4 project is "hogging" the Beta Grid. It's true that we could have multiple simultaneous betas open - we've done so in the past - but it takes a lot of resources to manage the main service (possibly running multiple versions of the code), production viewers (current and previous), First Looks, RCs, Beta Grid.... Anyway, I totally agree. From Anders at Arnholm.se Wed Jan 9 12:00:32 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 9 12:01:58 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <478405DC.2070008@lindenlab.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> Message-ID: <478527E0.2020904@Arnholm.se> Jonathan Wolk skrev: > A change was also made to remove the auto-login in an effort to make > group chat opt-in rather than opt-out. I am working on a way to make > the auto join on login a simple checkbox (as mentioned in this list > previously) though the previous way of having these be "passive" will > not work (though there may be another way of making them passive). > I hope this clears a few things up. Not really, you seams to take to easy on the regular day to day use of group IM's, none of my 25 groups is filled with no or really little spam, once or twice a week one of the club groups get someone joining that don't know (about 3000 in that group now...) This will drive all club spam from IM chats to notices, making all members get the pop-up or an email, I'm not sure you'll gain as much as you hope on. One more turn on the drawing board is probably needed. It will make help groups talk groups less working, I'm afraid this will make an even worse situation that today. I don't have any good of the shelf solutions, maybe at login adding automatic to all selected groups will work, the opt-in will however force all that need's or likes to get informations out to use something else than group IM. I hope you have scaled these solutions up... (email, will probably be one of the bigger needed resources. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tao.takashi at googlemail.com Wed Jan 9 12:10:20 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Jan 9 12:10:22 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> Message-ID: <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> On Jan 9, 2008 8:50 PM, Argent Stonecutter wrote: > I'm talking about logging in inworld without being in the IM side of > things at all. So you can log in to SL, build, deal with local > issues, without showing up as being "online" on the website, or via > profile, or via give inventory. Yes, I know you'll still show up with > some LSL calls and people can see you, but you won't be getting > notices or IMs or so-and-so-has-given-you-a-notecard. That would all > go to email like you weren't logged in. > > It really doesn't even involve the client at all, except that the > client won't get (or send) messages that would involve the IM system, > and it'd have some new message to say "logging in offline" when you > initially log in, and "go online" when you decide to go online. > > This is not "busy". You don't reject asset transfers (which is a > nasty nasty side effect) and send away or busy messages. You just > don't show up for people who aren't actually there in-world with you. > > This is not "only online to my friends". Some times it's my friends I > most want to be offline to. And I have WAY too many friends to set > them manually. > > This is "offline to everyone". Period. Temporarily. One step. Actually that was what I was hoping for when these changes to the friends list have been made. I personally do not really use that "show online to friend" feature as I really simply would like to be invisible complete e.g. if I have work to do. I am not sure it creates issues though if you also handle object transfers the offline way. What does happen on both sides? I guess you will receive the object. But would you be able to accept it? This migth trigger a response. Should it still go to email, too? So for me it would be ok to accept inventory as I'd think that this does not happen that often. Let IMs go to email would probably be a good thing and having a global online/offline switch, too. The same might be true for showing up on a map. Usually the map show is not friend specific but location specific. If I work on some "secret" build I might not want people to know about it or even TP. In general though I am quite open and would like to let people know where I am. With the change in the past this is rather impossible though with a big amount of friends (or let's call them contacts). -- Tao > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/f8f62d94/attachment.htm From josh at lindenlab.com Wed Jan 9 11:24:27 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 12:12:57 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47851BC7.4070607@watson.ibm.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> Message-ID: <47851F6B.90200@lindenlab.com> Mike Monkowski wrote: > Joshua Bell wrote: >> There are humans in the triage loop, and yes, we may say "you know >> what, that change is low risk and high impact, and we'd prefer to >> have it out in the RC and next release, and not wait another month >> for the next go-round of the cycle". > > So maybe I missed something. Will we see 1.18.6 RC4 followed by > 1.19.0 Release (mandatory update)? Or will we see 1.18.6 RC4 followed > by 1.18.6 Release (optional update) then 1.19.0 RC1, 1.19.0 RC2, ... > 1.19.0 Release (mandatory update)? Your earlier message implied the > former, but now is sounds more like the latter. The latter, with a slight tweak: 1.18.6 RC4 ...(hopefully no RC5 but who knows)... 1.18.6 Release (optional update) then 1.19.0 RC1, 1.19.0 RC2, ... 1.19.0 Release (optional update) ... 1.19.0 Release (mandatory update) (i.e. even 1.19 will be "optional" for a while). My apologies for any confusion caused by the earlier mail. Talking about multiple releases simultaneously (without pretty pictures) is always troublesome. Keep the questions coming! From secret.argent at gmail.com Wed Jan 9 12:24:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 12:24:24 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: <478527E0.2020904@Arnholm.se> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> <478527E0.2020904@Arnholm.se> Message-ID: I think that at the very least it needs to have the ability to select groups to automatically join on login, AND not create a tab for a group selected like this until there's chat in it or you select it from the contacts list, BEFORE it's rolled out. This probably won't have much impact on me, personally, I don't use group chat much... but I can see some huge problems for people who use it a lot. From secret.argent at gmail.com Wed Jan 9 12:37:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 12:37:16 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> Message-ID: <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> On 2008-01-09, at 14:10, Tao Takashi wrote: > Actually that was what I was hoping for when these changes to the > friends list have been made. Yes, me too. > I personally do not really use that "show online to friend" feature > as I really simply would like to > be invisible complete e.g. if I have work to do. I am not sure it > creates issues though if you also > handle object transfers the offline way. If you have a business you get notecards and the like pretty regularly. I'd rather they just get stored with a message to email until you "go online". On the other hand I think there's privacy issues with allowing people to be online without showing up on the map. People wouldn't know who that green dot was, just that there was someone there. When this came up on the forums some people did suggest that the green dots be hidden if you were offline, but that suggestion didn't go down well. From tao.takashi at googlemail.com Wed Jan 9 12:44:18 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Jan 9 12:44:23 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> Message-ID: <23bbb49e0801091244x1cc46f82sb5a78b74c482141a@mail.gmail.com> > > If you have a business you get notecards and the like pretty > regularly. I'd rather they just get stored with a message to email > until you "go online". So they only get Accept-messages when you go "online" again although you might have accepted it already? Thus some queue would be needed. > > On the other hand I think there's privacy issues with allowing people > to be online without showing up on the map. People wouldn't know who > that green dot was, just that there was someone there. When this came > up on the forums some people did suggest that the green dots be > hidden if you were offline, but that suggestion didn't go down well. Why not have that green dot? If I have you set as not showing me on the map it's the same situation. I don't know how that green dot is anyway unless I go and have a look (and I guess this should still work when I am in offline mode. Maybe also initiating IM conversations should work then just not receiving them). -- Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/5b6a5b48/attachment-0001.htm From hakushakukun at gmail.com Wed Jan 9 12:57:22 2008 From: hakushakukun at gmail.com (Adric R) Date: Wed Jan 9 12:57:25 2008 Subject: [sldev] Re: 1.19.0 Group Chat Message-ID: <781e4b420801091257t3361a942p1128419ef58efd66@mail.gmail.com> I still can't get over this. The solution to group chat spam is to make group chat less useful and more cumbersome, which will result in fewer people using it. Just... wow. Out of curiosity, how many people are devoted to the actual usability of SL? Do you need volunteers? I'd gladly donate several hours of my time each day if it meant an improved client. I love SL and want it to succeed, and it really upsets me to see the way usability has suffered this past year, in the face of other improvements. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/8d0247db/attachment.htm From Anders at Arnholm.se Wed Jan 9 12:57:51 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 9 12:59:09 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> <5eff6d3b0801081936we6458d1ib46ce5ecc90663b5@mail.gmail.com> Message-ID: <4785354F.6040606@Arnholm.se> Brandon Husbands skrev: > please please please make it to where we can uncheck send messages to > group chat. so esentially a group chat can be moderated That feature whiuld probaly save more griefing, or make a role that can and can't send IM's -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tao.takashi at googlemail.com Wed Jan 9 13:09:43 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Jan 9 13:09:45 2008 Subject: [sldev] 1.19.0 Group Chat In-Reply-To: References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <2AF7CDA7-C27B-42CB-9BEB-C88AF209F591@fastmail.fm> <478405DC.2070008@lindenlab.com> <478527E0.2020904@Arnholm.se> Message-ID: <23bbb49e0801091309w2888aac8rb6ff489de3903878@mail.gmail.com> I second the proposal to wait for an auto-login feature here or at least put out some RC or other test version for people to test before it's released. To me it seems to be a quite drastic change to many and probably as a surprise (has there been some announcement about this except sldev?). Speaking of group chat: What I also would like is an option to disable group chat in the chat overlay when the IM window is not open (but simply show the IM received message). This would make following a discussion easier. I think somebody said there is a option for that but I think it was something different. -- Tao On Jan 9, 2008 9:24 PM, Argent Stonecutter wrote: > I think that at the very least it needs to have the ability to select > groups to automatically join on login, AND not create a tab for a > group selected like this until there's chat in it or you select it > from the contacts list, BEFORE it's rolled out. > > This probably won't have much impact on me, personally, I don't use > group chat much... but I can see some huge problems for people who > use it a lot. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/699bf1eb/attachment.htm From secret.argent at gmail.com Wed Jan 9 13:17:39 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 13:17:47 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <23bbb49e0801091244x1cc46f82sb5a78b74c482141a@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <773a33dc0801081358y5a3da818k899f34b8a51f7b9f@mail.gmail.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> <23bbb49e0801091244x1cc46f82sb5a78b74c482141a@mail.gmail.com> Message-ID: <394CBA7D-F653-4347-A81F-52A505C0F4B9@gmail.com> On 2008-01-09, at 14:44, Tao Takashi wrote: > So they only get Accept-messages when you go "online" again although > you might have accepted it already? Thus some queue would be needed. I mean you wouldn't get to accept it until you went online. >> On the other hand I think there's privacy issues with allowing people >> to be [in world] without showing up on the map. People wouldn't >> know who >> that green dot was, just that there was someone there. When this came >> up on the forums some [other] people did suggest that the green >> dots be >> hidden if you were [logged in offline], but that suggestion didn't >> go down well. > Why not have that green dot? If I have you set as not showing me on > the map > it's the same situation. I don't know how that green dot is anyway > unless I go > and have a look (and I guess this should still work when I am in > offline mode. I think you just agreed with me under the impression that I wrote the opposite of what I thought I wrote. :) Do the above corrections make more sense? > Maybe also initiating IM conversations should work then just not > receiving them). That should probably take you online, after a warning and a chance to cancel. From tao.takashi at googlemail.com Wed Jan 9 13:22:38 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Jan 9 13:22:41 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <394CBA7D-F653-4347-A81F-52A505C0F4B9@gmail.com> References: <4783EA97.8010507@lindenlab.com> <4783F567.9040008@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> <23bbb49e0801091244x1cc46f82sb5a78b74c482141a@mail.gmail.com> <394CBA7D-F653-4347-A81F-52A505C0F4B9@gmail.com> Message-ID: <23bbb49e0801091322v2370666aieae07a65566a6746@mail.gmail.com> If we agree it's all great, now just waiting for the implementation then ;-) -- Tao On Jan 9, 2008 10:17 PM, Argent Stonecutter wrote: > On 2008-01-09, at 14:44, Tao Takashi wrote: > > So they only get Accept-messages when you go "online" again although > > you might have accepted it already? Thus some queue would be needed. > > I mean you wouldn't get to accept it until you went online. > > >> On the other hand I think there's privacy issues with allowing people > >> to be [in world] without showing up on the map. People wouldn't > >> know who > >> that green dot was, just that there was someone there. When this came > >> up on the forums some [other] people did suggest that the green > >> dots be > >> hidden if you were [logged in offline], but that suggestion didn't > >> go down well. > > > Why not have that green dot? If I have you set as not showing me on > > the map > > it's the same situation. I don't know how that green dot is anyway > > unless I go > > and have a look (and I guess this should still work when I am in > > offline mode. > > I think you just agreed with me under the impression that I wrote the > opposite of what I thought I wrote. :) > > Do the above corrections make more sense? > > > Maybe also initiating IM conversations should work then just not > > receiving them). > > That should probably take you online, after a warning and a chance to > cancel. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/00d12de8/attachment.htm From Anders at Arnholm.se Wed Jan 9 13:48:57 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 9 13:50:30 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> Message-ID: <47854149.1070409@Arnholm.se> Argent Stonecutter skrev: > On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: >> Voice is its own "subservice" thread and seperate server, >> Why not the same using IRC as a backend for chat? > > Jabber, please. Jabber back end would be really great... and jabber login :-) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From monkowsk at watson.ibm.com Wed Jan 9 14:10:17 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 9 14:10:29 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47851F6B.90200@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> Message-ID: <47854649.8050602@watson.ibm.com> OK, that makes more sense. Now a question regarding "Fixed Internally" on the JIRA. If I understand correcly, some bug fixes get into RC2, RC3, and so forth, depending on their severity and complexity, but all remaining internal fixes should show up in the next RC1. Correct? Mike Joshua Bell wrote: > Mike Monkowski wrote: > >> Joshua Bell wrote: >> >>> There are humans in the triage loop, and yes, we may say "you know >>> what, that change is low risk and high impact, and we'd prefer to >>> have it out in the RC and next release, and not wait another month >>> for the next go-round of the cycle". >> >> >> So maybe I missed something. Will we see 1.18.6 RC4 followed by >> 1.19.0 Release (mandatory update)? Or will we see 1.18.6 RC4 followed >> by 1.18.6 Release (optional update) then 1.19.0 RC1, 1.19.0 RC2, ... >> 1.19.0 Release (mandatory update)? Your earlier message implied the >> former, but now is sounds more like the latter. > > The latter, with a slight tweak: > > 1.18.6 RC4 ...(hopefully no RC5 but who knows)... 1.18.6 Release > (optional update) then 1.19.0 RC1, 1.19.0 RC2, ... 1.19.0 Release > (optional update) ... 1.19.0 Release (mandatory update) > > (i.e. even 1.19 will be "optional" for a while). > > My apologies for any confusion caused by the earlier mail. Talking about > multiple releases simultaneously (without pretty pictures) is always > troublesome. Keep the questions coming! From sean at dague.net Wed Jan 9 14:10:12 2008 From: sean at dague.net (Sean Dague) Date: Wed Jan 9 14:11:17 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <4784A848.9000208@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> Message-ID: <20080109221012.GD20981@dague.net> On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote: > the new web based authentication scheme uses a web page to capture the > fullname and the password of an avatar and returns a web_login_key that is > passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL > client takes that secondlife:///app/login/... URI and extracts the > web_login_key (and first and last name and other stuff it seems) and goes > to the login service to log the avatar/agent in to the grid. > > while this works with the LL grid, it does not work with OpenSim grids, > because the LL SL client has no clue that it needs to go to a different, > non-LL grid login service: the latest release clients and the windlight > client do provide the -loginpage which would allow us to direct the client > to a login page of our own, where we could then generate the > secondlife:///app/login/.. URI --- however, that URI does not include any > reference whatsoever to the grid you want to connect to (well, it does to > some extent: there is a 'grid' parameter but that only knows about LL grids > and also does not include ports, resources, etc) > > teravus ousley has described this in much more detail (and probably better > than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he > also tried several other things (have a look at VWR-4021, if you are > interested in the details) to no avail: we cannot get the latest windlight > and RC clients to connect to OpenSim grids/servers. > > luckily, we had a chance to discuss this with tess linden at yesterday's > AWGroupies meeting. the following two proposals came up: > > (a) use the currently empty host part of the secondlife:///app/login > URI to specify the grid server: that is, to connect to my 4x4 > OpenSim grid running here in the lab, i'd have the following URI: > > > secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... > > the LL SL client would simply do a s/^secondlife:/http:/ > substitution and use the resulting URL to login the avatar in. > > (b) recast the currently used grid parameter to always contain the > FQDN of the grid server along with port and resource; that is, for > my lab grid that would be: > > > secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... > > here the client would have to parse the URI, extract the grid > parameter, un-quote its value, then construct the login URL and > login the avatar in. > > clearly, approach (a) seems to be the cleanest approach and fits well with > the common URI scheme. however... > > ...during the discussion it transpired that the reason the host part of the > secondlife:/// URI is empty, is that the target of that SLURL is *not* the > grid server but the *client*! in particular, /app/login signals to the > client what it should do: login via a URL that it needs to construct from > the supplied URI. > > ...also, as fword utorid remarked, using the secondlife: URI to trigger a > grid login adds a new semantic to the secondlife: URI --- so far it has > been used as a kind of secondlife GPS location fix: > secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 > island, for example. now, secondlife:///app/login?... addresses the > secondlife client and tells it to do a login to a grid. I (aka neas bade) will continue to express frustration on this design point. I know that secondlife:/// URI-like-things are currently used as a hack to get a webbrowser to trigger an external application, however I think that sticking with that design point causes confusion as well as leads to the implicit hardcoding of the main grid into the client. secondlife://osgrid.org:8002/app/login equaly conveys to the client what it should do, that is connect to a network resource for login. If we have append the web_login_key= to this request, we can fully process that URI back to the server as a well understood resource on the network, returning to us any appropriate further information needed. secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit hostname is in this URI scheme. That really should be secondlife://secondlife.com/IBM%206/127/104/88, which would let you load SLURLs for other grids in a sensible way (and you'd get appropriately prompted for credentials in the equiv of HTTP AUTH domains). I really think the further these approaches differ from the well understood sematics of URIs on the www, the harder it will be to have real interoperability between multiple grids. My understanding of the early tennents of the future grid work was to use the fundamental model of the www unless there were massively compelling reasons why one couldn't. I don't see the massively compelling reason in not making hostname explicit as part of secondlife:// URIs. And I also think that repeats of it taking over a month to get -loginpage to work with alternate grids (it still doesn't work in released code) will continue if the design of URIs used in the system continues to be host name implicit. Search is another good instance of this, but there are many more that can be found by grepping for secondlife.com in the XUL files for the client. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080109/e77721bb/attachment.pgp From kelly at lindenlab.com Wed Jan 9 14:12:20 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jan 9 14:13:05 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47854149.1070409@Arnholm.se> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> Message-ID: <478546C4.9050802@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/2bc9d37f/attachment.htm From Anders at Arnholm.se Wed Jan 9 14:25:59 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 9 14:27:15 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478546C4.9050802@lindenlab.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: <478549F7.4080604@Arnholm.se> Kelly Linden skrev: > Anders Arnholm wrote: >> Argent Stonecutter skrev: >>> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: >>>> Voice is its own "subservice" thread and seperate server, >>>> Why not the same using IRC as a backend for chat? >>> >>> Jabber, please. >> >> Jabber back end would be really great... and jabber login :-) >> > Even jabber does not support the 'passive listener' mode, where you auto > join a channel you are 'interested in' when someone says something in > the channel. Even just typing that it seems bizarre that we have My got felling is that that joining the channel at login, might be a working db solution. However my knowledge of the details in this implementation is limited especially server side and db. I don't care about passive listener, to choose what groups you get IM's from, (I like the opt-out solution, why join a group if you don't like the chat?) / Balp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sean at dague.net Wed Jan 9 14:10:12 2008 From: sean at dague.net (Sean Dague) Date: Wed Jan 9 14:34:13 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <4784A848.9000208@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> Message-ID: <20080109221012.GD20981@dague.net> On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote: > the new web based authentication scheme uses a web page to capture the > fullname and the password of an avatar and returns a web_login_key that is > passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL > client takes that secondlife:///app/login/... URI and extracts the > web_login_key (and first and last name and other stuff it seems) and goes > to the login service to log the avatar/agent in to the grid. > > while this works with the LL grid, it does not work with OpenSim grids, > because the LL SL client has no clue that it needs to go to a different, > non-LL grid login service: the latest release clients and the windlight > client do provide the -loginpage which would allow us to direct the client > to a login page of our own, where we could then generate the > secondlife:///app/login/.. URI --- however, that URI does not include any > reference whatsoever to the grid you want to connect to (well, it does to > some extent: there is a 'grid' parameter but that only knows about LL grids > and also does not include ports, resources, etc) > > teravus ousley has described this in much more detail (and probably better > than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he > also tried several other things (have a look at VWR-4021, if you are > interested in the details) to no avail: we cannot get the latest windlight > and RC clients to connect to OpenSim grids/servers. > > luckily, we had a chance to discuss this with tess linden at yesterday's > AWGroupies meeting. the following two proposals came up: > > (a) use the currently empty host part of the secondlife:///app/login > URI to specify the grid server: that is, to connect to my 4x4 > OpenSim grid running here in the lab, i'd have the following URI: > > > secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... > > the LL SL client would simply do a s/^secondlife:/http:/ > substitution and use the resulting URL to login the avatar in. > > (b) recast the currently used grid parameter to always contain the > FQDN of the grid server along with port and resource; that is, for > my lab grid that would be: > > > secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... > > here the client would have to parse the URI, extract the grid > parameter, un-quote its value, then construct the login URL and > login the avatar in. > > clearly, approach (a) seems to be the cleanest approach and fits well with > the common URI scheme. however... > > ...during the discussion it transpired that the reason the host part of the > secondlife:/// URI is empty, is that the target of that SLURL is *not* the > grid server but the *client*! in particular, /app/login signals to the > client what it should do: login via a URL that it needs to construct from > the supplied URI. > > ...also, as fword utorid remarked, using the secondlife: URI to trigger a > grid login adds a new semantic to the secondlife: URI --- so far it has > been used as a kind of secondlife GPS location fix: > secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 > island, for example. now, secondlife:///app/login?... addresses the > secondlife client and tells it to do a login to a grid. I (aka neas bade) will continue to express frustration on this design point. I know that secondlife:/// URI-like-things are currently used as a hack to get a webbrowser to trigger an external application, however I think that sticking with that design point causes confusion as well as leads to the implicit hardcoding of the main grid into the client. secondlife://osgrid.org:8002/app/login equaly conveys to the client what it should do, that is connect to a network resource for login. If we have append the web_login_key= to this request, we can fully process that URI back to the server as a well understood resource on the network, returning to us any appropriate further information needed. secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit hostname is in this URI scheme. That really should be secondlife://secondlife.com/IBM%206/127/104/88, which would let you load SLURLs for other grids in a sensible way (and you'd get appropriately prompted for credentials in the equiv of HTTP AUTH domains). I really think the further these approaches differ from the well understood sematics of URIs on the www, the harder it will be to have real interoperability between multiple grids. My understanding of the early tennents of the future grid work was to use the fundamental model of the www unless there were massively compelling reasons why one couldn't. I don't see the massively compelling reason in not making hostname explicit as part of secondlife:// URIs. And I also think that repeats of it taking over a month to get -loginpage to work with alternate grids (it still doesn't work in released code) will continue if the design of URIs used in the system continues to be host name implicit. Search is another good instance of this, but there are many more that can be found by grepping for secondlife.com in the XUL files for the client. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080109/e77721bb/attachment-0001.pgp From odysseus654 at gmail.com Wed Jan 9 14:36:13 2008 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Jan 9 14:36:16 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478549F7.4080604@Arnholm.se> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478549F7.4080604@Arnholm.se> Message-ID: <1674f6c70801091436k67154343w20c8a9c3dbb2112c@mail.gmail.com> On Jan 9, 2008 2:25 PM, Anders Arnholm wrote: > I don't care about passive listener, to choose what groups you get IM's > from, (I like the opt-out solution, why join a group if you don't like > the chat?) > There are a large number of reasons to be part of a group that you are not interested in chatting with. The group tag comes with a large number of permissions and authorities, of which group chat may not be an integral part. The Mentor's list has recently had (another) fairly extended argument about when the group chat should and should not be used, with the intent of having group chat used as little as appropriate (and not bugging the several hundred people that might be listening at the time) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/c349a096/attachment.htm From josh at lindenlab.com Wed Jan 9 14:47:22 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 14:47:28 2008 Subject: [sldev] Re: 1.19.0 Group Chat In-Reply-To: <781e4b420801091257t3361a942p1128419ef58efd66@mail.gmail.com> References: <781e4b420801091257t3361a942p1128419ef58efd66@mail.gmail.com> Message-ID: <47854EFA.5010909@lindenlab.com> Adric R wrote: > I still can't get over this. The solution to group chat spam is to > make group chat less useful and more cumbersome, which will result in > fewer people using it. Just... wow. Based on the feedback so far from SLDEV we're reconsidering our plans. We're exploring several options based on the feedback, and I will post an update once we have something semi-firm. From warkirby3333 at hotmail.co.uk Wed Jan 9 14:52:44 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Wed Jan 9 14:52:45 2008 Subject: [sldev] RE: Group chat In-Reply-To: <20080109221032.2F36741B446@stupor.lindenlab.com> References: <20080109221032.2F36741B446@stupor.lindenlab.com> Message-ID: I'm definitely in the camp of putting a large useability change into a mandatory client is a bad idea. The autologin to selected groups feature and serverside support for the group chat changes really is needed. Even still, this is going to hurt chat groups a lot. Itwould really be best to hold back the mandatory release until those are implemented, a least. _________________________________________________________________ Fancy some celeb spotting? https://www.celebmashup.com From Anders at Arnholm.se Wed Jan 9 14:51:49 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 9 14:53:20 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1674f6c70801091436k67154343w20c8a9c3dbb2112c@mail.gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478549F7.4080604@Arnholm.se> <1674f6c70801091436k67154343w20c8a9c3dbb2112c@mail.gmail.com> Message-ID: <47855005.7000904@Arnholm.se> Erik Anderson skrev: > integral part. The Mentor's list has recently had (another) fairly > extended argument about when the group chat should and should not be > used, with the intent of having group chat used as little as appropriate Yes, but would the group be helped by having the persons on in not getting the IM's. It will work for some small types of groups, but not most, having a flag for this on role might be good that the owner of the group sets. Maybe also a can't chat flag or an chat ban list... Over all i think the idea need an other turn at the design table, feedback and talk about who this will affect clubs? Support groups, right groups. Personally all my groups need auto login for chat, and for all members if to fill the role they have today. If it get out-out some might go over to use all communication as Notice instead. I'm not sure that is an in any way better solution... / Balp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tofu.linden at lindenlab.com Wed Jan 9 14:53:51 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Jan 9 14:54:05 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47854649.8050602@watson.ibm.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> Message-ID: <4785507F.5090905@lindenlab.com> Mike Monkowski wrote: > OK, that makes more sense. > > Now a question regarding "Fixed Internally" on the JIRA. If I > understand correcly, some bug fixes get into RC2, RC3, and so forth, > depending on their severity and complexity, but all remaining internal > fixes should show up in the next RC1. Correct? No, any remaining fixes might still be arbitrarily far from release depending on where their respective branches are in the QA pipeline. -Tofu From alissa_sabre at yahoo.co.jp Wed Jan 9 15:03:07 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jan 9 15:03:19 2008 Subject: [sldev] Any change on the beta grid (aditi)? Message-ID: <74eb4du4ds4dsdfr8s0Qs0.alissa_sabre@yahoo.co.jp> I'm unable to login to the beta grid (aditi). When I try logging in to aditi with the official 1.18.5.3 viewer binary (by invoking the viewer with --aditi option), I get the following message: Login failed. Cannot connect to version manage Adding -channel option doesn't help. I'm experiencing this since 5:00 a.m. Wednesday 9 PST. I was able to login on early Sunday 6 PST. I didn't try between them, so I'm not sure exact starting timing of this symptom. Is it a server trouble, or some intentional change on the beta grid? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From kelly at lindenlab.com Wed Jan 9 15:11:27 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jan 9 15:11:32 2008 Subject: [sldev] Any change on the beta grid (aditi)? In-Reply-To: <74eb4du4ds4dsdfr8s0Qs0.alissa_sabre@yahoo.co.jp> References: <74eb4du4ds4dsdfr8s0Qs0.alissa_sabre@yahoo.co.jp> Message-ID: <4785549F.9060401@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/9cc5dfdd/attachment.htm From latifer at gmail.com Wed Jan 9 15:20:06 2008 From: latifer at gmail.com (Latif Khalifa) Date: Wed Jan 9 15:20:20 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478546C4.9050802@lindenlab.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: <478556A6.7060409@gmail.com> Kelly Linden wrote: > Anders Arnholm wrote: >> Argent Stonecutter skrev: >>> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: >>>> Voice is its own "subservice" thread and seperate server, >>>> Why not the same using IRC as a backend for chat? >>> >>> Jabber, please. >> >> Jabber back end would be really great... and jabber login :-) >> > Even jabber does not support the 'passive listener' mode, where you auto > join a channel you are 'interested in' when someone says something in > the channel. Even just typing that it seems bizarre that we have > developed chat to a point where that makes sense. It could of course be > done with a client hack where you join the channel just don't draw the > tab until you get an actual chat line (not a join/part message etc) for > the channel/room/group. Every dedicated chat system that I know of only > has 2 modes: you are in the channel and can see the chat or you are not, > and you won't see the chat. The half way sort of interested but not > really there until something interesting happens is *weird*. I would > very much like to see us move away from that model if possible. Does > anyone know any other chat system that behaves this way? > > Disclaimer: The above is not a statement of intent or work - Jonathan is > doing some good work on meeting more people's expectations than I > would. It is merely me expressing my desire that more of our system > work in "industry standard" ways when at all possible. Someone is going > to read this and interpret it as "LL says they are going to do FOO" - > and the fear of that happening has prevented me from discussing issues > on this list in the past. I'd like to get past that, so the disclaimer > is now almost as large as the actual content of this message. I understand you wish to move to "standardized" way the chat/im systems work. However, we that spend a lot of time in-world have come to depend and love the way the current system works, where IM tab appears when something interesting happens. There was a great demand on the ability to "mute" or opt out of the chat from specific groups, but I have not heard any in-world demand for opt-in group IMs. Many communities/support groups depend on the current behavior. The reason we want this unique solution where IM tab appears on demand is that in SL is the group chat is one of the subsystems that we use all day, its not the main focus of our activities. We do not have screen real estate to have all those group chats tabs open as we would have in a dedicated IRC / other IM client. > If we were to move to a 'standard' chat backend (woot! yes! I love that > idea! jabber or whatever!) we should try pretty hard to have as few > exceptions or special cases to how it works as possible. In other > words, I think we get a lot more out of using a standard chat system if > we behave like a standard chat system than if we were to behave like our > own special little chat system just using a standard backend. Even > though the latter case still has some value. Again, understanding the desire to standardize, I think that the current behavior should be considered the strength and not the weakness. And its a pure usability issue, the back end does not matter, its how its presented to the user in the viewer. - L From josh at lindenlab.com Wed Jan 9 15:25:52 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 15:25:56 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4785507F.5090905@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> <4785507F.5090905@lindenlab.com> Message-ID: <47855800.5020504@lindenlab.com> Tofu Linden wrote: > Mike Monkowski wrote: > > OK, that makes more sense. > > > > Now a question regarding "Fixed Internally" on the JIRA. If I > > understand correcly, some bug fixes get into RC2, RC3, and so forth, > > depending on their severity and complexity, but all remaining internal > > fixes should show up in the next RC1. Correct? > > No, any remaining fixes might still be arbitrarily far from release > depending on where their respective branches are in the QA pipeline. Oh, yes, good point. I'm generally fixated on things after they clear the development sandbox branch. There's a pretty good explanation here: http://wiki.secondlife.com/wiki/Source_branches The diagram shows a conceptual flow (everything flows from dev branches into release, from whence RCs are spawned) but doesn't represent time: once an RC branches, other things land in release. Basically: (almost*) all dev work happens in sandbox branches. Those merge into the trunk (named "release", a source of potential confusion). Periodically an RC is branched off the trunk. So something can be marked "fixed" in a sandbox branch but, as Tofu mentions, until it merges into the trunk it's not going to be in an RC. * There are always exceptions. Some work is done right in the RC branch to fix regressions. Some work doesn't affect production code so can go right into the trunk. But the goal is to have nothing enter the trunk that hasn't passed QA. From kelly at lindenlab.com Wed Jan 9 15:27:24 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jan 9 15:27:29 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4785507F.5090905@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> <4785507F.5090905@lindenlab.com> Message-ID: <4785585C.2060008@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/ec202a85/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: merging.jpg Type: image/jpeg Size: 33310 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080109/ec202a85/merging-0001.jpg From josh at lindenlab.com Wed Jan 9 15:30:29 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 15:30:33 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47855800.5020504@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> <4785507F.5090905@lindenlab.com> <47855800.5020504@lindenlab.com> Message-ID: <47855915.3020203@lindenlab.com> Joshua Bell wrote: >> Mike Monkowski wrote: >> > OK, that makes more sense. >> > >> > Now a question regarding "Fixed Internally" on the JIRA. If I >> > understand correcly, some bug fixes get into RC2, RC3, and so forth, >> > depending on their severity and complexity, but all remaining internal >> > fixes should show up in the next RC1. Correct? .. oh yes, and since we're geeks we start with RC0. From nchase at earthlink.net Wed Jan 9 15:38:44 2008 From: nchase at earthlink.net (Nicholas Chase) Date: Wed Jan 9 15:38:47 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478556A6.7060409@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> Message-ID: <47855B04.9000504@earthlink.net> Latif Khalifa wrote: > Many communities/support groups depend on the current behavior. The > reason we want this unique solution where IM tab appears on demand is > that in SL is the group chat is one of the subsystems that we use all > day, its not the main focus of our activities. We do not have screen > real estate to have all those group chats tabs open as we would have in > a dedicated IRC / other IM client. Let's also remember that while for us as developers it's just something that we use while we're doing other (IMO more interesting) things, statistically, socializing is what Second Life is used for more than anything else. If it becomes less useful for regular users, that's a problem. ---- Nick From secret.argent at gmail.com Wed Jan 9 16:48:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 9 16:49:06 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478546C4.9050802@lindenlab.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: <611DCF4A-084F-4449-81E1-5F0F5E9ADD48@gmail.com> On 2008-01-09, at 16:12, Kelly Linden wrote: > Even jabber does not support the 'passive listener' mode, where you > auto join a channel you are 'interested in' when someone says > something in the channel. I don't think people have an issue with getting rid of "passive listener" mode where you "auto join" a channel. You shouldn't be "auto joining" the channel, you should either be listening or not listening. The issue is the user interface. What should the impact of a channel you're not actively participating in be? Right now, in the corner of my screen, I have a contact list. This is like the communicator Contacts tab, containing users and groups. They both behave like contacts in the IM world. Adding a box in Groups with an "eye" icon (or something) that says you're watching that group's chat useful, Anyway, I have a contact list. Until I get a message, that's all I have. When I get a message from a contact, THEN it adds a tab to the chat window. In IRC on the other hand, in the classic IRC text application, there's only one "tab", and you don't get any space wasted on channels you're not in. Why waste space in the tab bar on an empty chat? From monkowsk at watson.ibm.com Wed Jan 9 17:01:15 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 9 17:01:20 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4785585C.2060008@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> <4785507F.5090905@lindenlab.com> <4785585C.2060008@lindenlab.com> Message-ID: <47856E5B.9050405@watson.ibm.com> So it looks like the JIRA ought to have another state "passed QA" when foo gets merged into the trunk. This would give statistics for how long fixes spend in QA and how long from then to getting into a RC. The time period from "fixed internally" to incorporation in a RC depends a lot on how long the previous branch of RCs take to go live and where in that cycle the QA completes. And knowing that a patch will get into the next RC branch is more satisfying than knowing that it's "fixed" but somehow still languishing while users suffer. Mike Kelly Linden wrote: > Tofu Linden wrote: > >> Mike Monkowski wrote: >> > OK, that makes more sense. >> > >> > Now a question regarding "Fixed Internally" on the JIRA. If I >> > understand correcly, some bug fixes get into RC2, RC3, and so forth, >> > depending on their severity and complexity, but all remaining internal >> > fixes should show up in the next RC1. Correct? >> >> No, any remaining fixes might still be arbitrarily far from release >> depending on where their respective branches are in the QA pipeline. >> >> -Tofu >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > This is best shown with a picture, attached to this message! It is of > course overly simplified. This diagram *just* shows how a fix that goes > in while 1.18.6 RCx is out may still not make it into 1.19.0 and is not > a complete picture at all. Where I marked 'fix foo submitted' is > actually the point it will often get marked as 'fixed internally' or > 'fix pending', and when it starts going through internal QA. > > The flow is left to right, sorry for the lack of arrows, this was a > quick mock up. From kamilion at gmail.com Wed Jan 9 17:01:44 2008 From: kamilion at gmail.com (Kamilion) Date: Wed Jan 9 17:01:47 2008 Subject: [sldev] log in offline (was Re: [sldev] Roadmap: 1.19.0 Viewer) In-Reply-To: <23bbb49e0801091322v2370666aieae07a65566a6746@mail.gmail.com> References: <4783EA97.8010507@lindenlab.com> <49E2ADB6-A2CE-48DC-95F7-F58833EB111E@gmail.com> <47851654.7060302@cox.net> <14FB799D-95C1-41E9-AD5E-B33E816E2116@gmail.com> <23bbb49e0801091210w6ff9ae8dg7ca8e7a0c10f08bc@mail.gmail.com> <8231447E-3871-460D-987E-BA56A95BB6F0@gmail.com> <23bbb49e0801091244x1cc46f82sb5a78b74c482141a@mail.gmail.com> <394CBA7D-F653-4347-A81F-52A505C0F4B9@gmail.com> <23bbb49e0801091322v2370666aieae07a65566a6746@mail.gmail.com> Message-ID: This is definitely possible already, client side. Tinkering with TestClient on libsl, I've noticed that previously to the brand new callbacks just added, only incoming IMs were actually accepted and marked on the server as read. Every time I logged back on with the normal client, all the stuff that happened while the bot was online would stream in: Group invites, Group notices, Group Votes, Asset offers, and once, even a region estate message. Therefore, there must be something that marks these events as acknowledged. Disabling acknowledging could be hacked onto the existing viewer already. The only thing required on the server side would be logging in with an "Invisible" status (in the sense of modern IM clients) which would send a flag to the presence servers not to mark you as globally online. Only clients in the same region or LSL sensor/getobjectdetails scripts in the same region could detect you. LSL Dataserver scripts should return "offline". You would not be able to accept items. Any incoming gridwide event would go off to the IM2Email gateway just as if you were offline. > The object 'SL Exchange Magic Box standard' in Second Life has offered you inventory. > Log in to accept to decline this inventory. This is basically the equivalent to firefox and thunderbird's "Work Offline" menu entry. When this menu entry is unchecked, a flag is sent to the presence server, you flash online for anyone with notification, all queued messages are delivered the same as if you freshly log in. This should be *ESPECIALLY* easy to do with the new login system, just passing an &invisible=TRUE on the initial GET/POST/PUT or whatever. On Jan 9, 2008 1:22 PM, Tao Takashi wrote: > If we agree it's all great, now just waiting for the implementation then ;-) > -- Tao > On Jan 9, 2008 10:17 PM, Argent Stonecutter > wrote: > > On 2008-01-09, at 14:44, Tao Takashi wrote: > > > So they only get Accept-messages when you go "online" again although > > > you might have accepted it already? Thus some queue would be needed. > > > > I mean you wouldn't get to accept it until you went online. > > > > > > On the other hand I think there's privacy issues with allowing people > > > > to be [in world] without showing up on the map. People wouldn't > > > > know who > > > > that green dot was, just that there was someone there. When this came > > > > up on the forums some [other] people did suggest that the green > > > > dots be > > > > hidden if you were [logged in offline], but that suggestion didn't > > > > go down well. > > > Why not have that green dot? If I have you set as not showing me on > > > the map > > > it's the same situation. I don't know how that green dot is anyway > > > unless I go > > > and have a look (and I guess this should still work when I am in > > > offline mode. > > I think you just agreed with me under the impression that I wrote the > > opposite of what I thought I wrote. :) > > Do the above corrections make more sense? > > > Maybe also initiating IM conversations should work then just not > > > receiving them). > > That should probably take you online, after a warning and a chance to > > cancel. From Celierra at gmail.com Wed Jan 9 17:32:49 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Jan 9 17:32:52 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <611DCF4A-084F-4449-81E1-5F0F5E9ADD48@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <611DCF4A-084F-4449-81E1-5F0F5E9ADD48@gmail.com> Message-ID: On Jan 9, 2008 7:48 PM, Argent Stonecutter wrote: > ... > Why waste space in the tab bar on an empty chat? > > I sorta agree with this. I think that the root problem being solved (with re-implementing 'passive listening') is that tab space is quite cramped in the Communicate window right now. It definitely doesn't hold enough tabs to afford having one for every watched group (right now, I can only have about four tabs on screen before it starts scrolling). It's possible (but I'm not certain) that being able to accommodate enough tabs (i.e. through truncated names for groups, or two or three rows of tabs) would be a decent solution (along with auto-join-on-login). I suppose that there's only so many groups that one would want to have chat with... And a bonus with just tinkering with tabs is that the way to temporarily leave a channel (until next login) is obvious - close the tab. In this context, the suggestion's just another way of reclaiming space. I would suggest thinking of the "passive listening" mode as a way to hide the tab for that group into the groups list, analogous to closing a person's IM window at the end of a conversation (which hides the IM window into the contact list). This saves the space that would be taken up from having a minimized window (in this case, inactive background tab) for an inactive session. I think this is the smoothest change for current users. But then we lose the ability to temporarily stop getting messages from a group chat (unless you build that feature in, too), and there's the whole problem of how randomly encountering a group IM window is jarring to newcomers to SL. (For the function of seeing which group chats you are listening to, I'm sorta assuming that the Groups tab would be made to look more like the Friends tab, with an icon showing whether or not you're subscribing to each group's chat channel. This would take the place of the function of minimized windows/inactive tabs.) I'm not sure which is better; there's benefits and pitfalls to both. Just trying to put more ideas out there... Celierra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/e8f60a00/attachment.htm From gigstaggart at gmail.com Wed Jan 9 17:34:39 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jan 9 17:34:42 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478546C4.9050802@lindenlab.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: <4785762F.9060607@gmail.com> Kelly Linden wrote: > Anders Arnholm wrote: >> Argent Stonecutter skrev: >>> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: >>>> Voice is its own "subservice" thread and seperate server, >>>> Why not the same using IRC as a backend for chat? >>> >>> Jabber, please. >> >> Jabber back end would be really great... and jabber login :-) >> > Even jabber does not support the 'passive listener' mode, where you auto > join a channel you are 'interested in' when someone says something in > the channel. Even just typing that it seems bizarre that we have It's not all that strange. I think you are just thinking about it more from the screwed up way it's implemented now, rather than the user side of things. One-on-one IMs always work that way (from the user's perspective), even in most IRC clients. It's just extending that idea in a straightforward and innovative (I think) way. There's no reason we can't keep that model, as you said, it can be purely a display thing. It can stay a display thing if we migrate to a Jabber/IRC backend too. There's plenty of groups with infrequent chat that I may want to hear when I'm on, but I may not want to crap up my UI with those dozens of inactive channel tabs. We've got a lot less screen real estate to work with than the average chat client. -Jason From lenglish5 at cox.net Wed Jan 9 18:25:03 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 9 18:25:05 2008 Subject: [sldev] Re: 1.19.0 Group Chat In-Reply-To: <781e4b420801091257t3361a942p1128419ef58efd66@mail.gmail.com> References: <781e4b420801091257t3361a942p1128419ef58efd66@mail.gmail.com> Message-ID: <478581FF.9070206@cox.net> Adric R wrote: > I still can't get over this. The solution to group chat spam is to > make group chat less useful and more cumbersome, which will result in > fewer people using it. Just... wow. > > Out of curiosity, how many people are devoted to the actual usability > of SL? Do you need volunteers? I'd gladly donate several hours of my > time each day if it meant an improved client. I love SL and want it to > succeed, and it really upsets me to see the way usability has suffered > this past year, in the face of other improvements. There's alwasys AW Groupies, Bug Triage, and several other venues for trying to make SL more useable, now and/or in the long run. Lawson From josh at lindenlab.com Wed Jan 9 18:44:10 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 9 18:44:14 2008 Subject: [META] What's a RC? was: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47856E5B.9050405@watson.ibm.com> References: <4783BDF6.6080806@lindenlab.com> <4784FD8D.7040600@watson.ibm.com> <47850C3A.1080804@lindenlab.com> <47851BC7.4070607@watson.ibm.com> <47851F6B.90200@lindenlab.com> <47854649.8050602@watson.ibm.com> <4785507F.5090905@lindenlab.com> <4785585C.2060008@lindenlab.com> <47856E5B.9050405@watson.ibm.com> Message-ID: <4785867A.9030001@lindenlab.com> Mike Monkowski wrote: > So it looks like the JIRA ought to have another state "passed QA" when > foo gets merged into the trunk. This would give statistics for how > long fixes spend in QA and how long from then to getting into a RC. > The time period from "fixed internally" to incorporation in a RC > depends a lot on how long the previous branch of RCs take to go live > and where in that cycle the QA completes. And knowing that a patch > will get into the next RC branch is more satisfying than knowing that > it's "fixed" but somehow still languishing while users suffer. We internally track this by tagging the items with an actual Fix Version only at the point where the change has merged into the trunk - which is the soonest point you can predict what version it will be in. I do this by tracking the branches as they go in and doing bulk updates. Therefore, Status = Resolved, Resolution = Fixed, Fix Version = 1.19.0 indicates that not only is it fixed but it's merged into the trunk. We'd create a Version 1.19.1 as soon as 1.19.0 is frozen (branched) so that the next fixes to merge into the trunk can be marked appropriately. Ideally we would sweep through the JIRAs that have PJIRA counterparts and do the same thing. We're still trying to get tools/processes into place for this, and additional people to help. There's also the overhead that suddenly 1.19.1 appears in PJIRA before we're even ready to really start talking in detail about 1.19.0, so suddenly a gazillion questions come our way. But that's why this is fun. :) Joshua From lenglish5 at cox.net Wed Jan 9 20:20:23 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 9 20:20:26 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47855B04.9000504@earthlink.net> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <47855B04.9000504@earthlink.net> Message-ID: <47859D07.9000101@cox.net> Nicholas Chase wrote: > > Latif Khalifa wrote: > >> Many communities/support groups depend on the current behavior. The >> reason we want this unique solution where IM tab appears on demand is >> that in SL is the group chat is one of the subsystems that we use all >> day, its not the main focus of our activities. We do not have screen >> real estate to have all those group chats tabs open as we would have >> in a dedicated IRC / other IM client. > > Let's also remember that while for us as developers it's just > something that we use while we're doing other (IMO more interesting) > things, statistically, socializing is what Second Life is used for > more than anything else. If it becomes less useful for regular users, > that's a problem. Yep. THe obvious long-term solution is to make teh GUI flexable enough to support customized IM windows. But thats going to take a while. Like everything else in SL, to REALLY do it right, would require a completely rewritten from the ground up. Which isn't going to happen for a Very Long While. Lawson From lenglish5 at cox.net Wed Jan 9 20:23:22 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 9 20:23:25 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478556A6.7060409@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> Message-ID: <47859DBA.5090303@cox.net> Latif Khalifa wrote: > > Again, understanding the desire to standardize, I think that the > current behavior should be considered the strength and not the > weakness. And its a pure usability issue, the back end does not > matter, its how its presented to the user in the viewer. > > Unfortunately, the backend DOES matter, if it starts to interfere with the ability to receive IMs at all. I personaly prefer the behavior where I get notifications as well. But, if the short-term "fix" requires them to make things less usable interface-wise, in order to make them usable at all on the back-end, so be it... ... AS LONG AS this isn't seen as anything but a bandaid that needs to be taken off as soon as possible once the real fix is in place on the back end. Lawson From ravenglassrentals at yahoo.com Wed Jan 9 20:37:19 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Wed Jan 9 20:37:21 2008 Subject: [sldev] Re: SLDev Digest, Vol 13, Issue 26 In-Reply-To: <20080109224737.CCAB841B55B@stupor.lindenlab.com> Message-ID: <314778.93288.qm@web55610.mail.re4.yahoo.com> There shouldn't be a forcible opt-out of groups that makes you go through the obstacle of entering their chat. If more people had open groups that you could join and quit at will without queueing up for an invitation, if you were annoyed with the chat, you could just leave. I think many people would prefer the ability to keep open groups, yet be able to ban some members who spam. I think this problem is grossly overblown and would not opt for the Lindens do anything on this as it's a new feature and they should fix what's broken already about groups. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080109/fe45425a/attachment.htm From tao.takashi at googlemail.com Wed Jan 9 23:18:40 2008 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Jan 9 23:18:42 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478556A6.7060409@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> Message-ID: <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> On Jan 10, 2008 12:20 AM, Latif Khalifa wrote: > Kelly Linden wrote: > > Anders Arnholm wrote: > >> Argent Stonecutter skrev: > >>> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: > >>>> Voice is its own "subservice" thread and seperate server, > >>>> Why not the same using IRC as a backend for chat? > >>> > >>> Jabber, please. > >> > >> Jabber back end would be really great... and jabber login :-) > >> > > Even jabber does not support the 'passive listener' mode, where you auto > > join a channel you are 'interested in' when someone says something in > > the channel. Even just typing that it seems bizarre that we have > > developed chat to a point where that makes sense. It could of course be > > done with a client hack where you join the channel just don't draw the > > tab until you get an actual chat line (not a join/part message etc) for > > the channel/room/group. Every dedicated chat system that I know of only > > has 2 modes: you are in the channel and can see the chat or you are not, > > and you won't see the chat. The half way sort of interested but not > > really there until something interesting happens is *weird*. I would > > very much like to see us move away from that model if possible. Does > > anyone know any other chat system that behaves this way? > > > > Disclaimer: The above is not a statement of intent or work - Jonathan is > > doing some good work on meeting more people's expectations than I > > would. It is merely me expressing my desire that more of our system > > work in "industry standard" ways when at all possible. Someone is going > > to read this and interpret it as "LL says they are going to do FOO" - > > and the fear of that happening has prevented me from discussing issues > > on this list in the past. I'd like to get past that, so the disclaimer > > is now almost as large as the actual content of this message. > > > Many communities/support groups depend on the current behavior. The > reason we want this unique solution where IM tab appears on demand is > that in SL is the group chat is one of the subsystems that we use all > day, its not the main focus of our activities. We do not have screen > real estate to have all those group chats tabs open as we would have in > a dedicated IRC / other IM client. Isn't this just a little UI thing anyway? If this means changing the underlying jabber protocol this obviously shouldn't be done for interoperabilty reasons but just not showing the tab seems to me to be just a UI thing. We might even think of automatically hiding the tab if nothing happens for some time. But not sure if this won't be confusing. Then again screen estate is the same for an IRC window and this seems to work there, too ;-) -- Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/257f2659/attachment.htm From hud at zurich.ibm.com Thu Jan 10 00:13:08 2008 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Jan 10 00:13:19 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478506B0.3040301@lindenlab.com> References: <4783BDF6.6080806@lindenlab.com> <4784AAF3.1000703@zurich.ibm.com> <478506B0.3040301@lindenlab.com> Message-ID: <4785D394.3000009@zurich.ibm.com> Joshua Bell wrote: > Dr Scofield wrote: >> Joshua Bell wrote: >>> [...] >>> >>> We're still pulling together the release notes for 1.19.0, but the >>> high-level summary is: >>> >>> * 61 bug fixes >>> * "Voice 1.1" >> will that finally include voice support for linux???? > Voice for Linux is in internal QA right now; I'm not clear on the > status (i.e. if it's complete and being tested, or at a good interim > stage to validate the work so far). It will not be part of 1.19.0. > sigh. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/112f5f79/attachment-0001.htm From matthew.dowd at hotmail.co.uk Thu Jan 10 00:23:16 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jan 10 00:23:18 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478546C4.9050802@lindenlab.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: My few points: i) some of the (IMHO) bad design decisions recently made in the current communicator UI were due to thinking of the communicator as a standalone messaging client - it isn't, it is an integral part of the SL viewer. That basic fact has consequences - the message UI has to fit within a different set of workflows; the message UI needs to be such that it doesn't get in the way of interacting with the 3D world. That a standalone messaging client may work differently is not really an issue since a standalone message client is not trying to be part of the 3D virtual environment. ii) many regard passive mode as a feature which makes the SL communicator better than a typical messaging client - not worse. It has never occured to me to think of passive mode as "wierd" in SL, it seems quite natural. On the other hand, it seems odd that other messaging clients do not have something equivalent. iii) many have built the way group IMs currently work into their workflow - removing functionality in this way will be seem as a deteriation of SL functionality not an improvement iv) as others have said, the issue isn't really passive versus active but a UI one. I don't think anyone would have any real problem with the backend processes/protocol moving to the active model provided that a) you can auto-connect to selected group IM chats at logon b) you did not *have* to keep the group IM tab open in order to be and remain connected to a group IM chat - the idea expressed elsewhere have having a little icon in the group list ala the friends icons is a good one. v) Assuming we get the UI acceptable, would moving to active mode mean the group limit could be increased? Instead (to keep db load down), the number of groups you could auto-subscribe to might be limited to 25? vi) One of the issues with the communicate window at the moment is tab clutter. This results in the window taking up too much valuable screen estate and IMs being overlooked since the flashing tab to indicate a new message gets lost amongst all the other tabs! One solution, I've proposed is to stack the tabs vertically (http://jira.secondlife.com/browse/VWR-3265), which was generally well received although it was suggested this should be optional (and I've not had a chance to revisit this). Matthew ________________________________ > Date: Wed, 9 Jan 2008 14:12:20 -0800 > From: kelly@lindenlab.com > To: Anders@Arnholm.se > Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > CC: sldev@lists.secondlife.com > > Anders Arnholm wrote: > Argent Stonecutter skrev: > On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: > Voice is its own "subservice" thread and seperate server, > Why not the same using IRC as a backend for chat? > > Jabber, please. > > Jabber back end would be really great... and jabber login :-) > > Even jabber does not support the 'passive listener' mode, where you auto join a channel you are 'interested in' when someone says something in the channel. Even just typing that it seems bizarre that we have developed chat to a point where that makes sense. It could of course be done with a client hack where you join the channel just don't draw the tab until you get an actual chat line (not a join/part message etc) for the channel/room/group. Every dedicated chat system that I know of only has 2 modes: you are in the channel and can see the chat or you are not, and you won't see the chat. The half way sort of interested but not really there until something interesting happens is *weird*. I would very much like to see us move away from that model if possible. Does anyone know any other chat system that behaves this way? > > Disclaimer: The above is not a statement of intent or work - Jonathan is doing some good work on meeting more people's expectations than I would. It is merely me expressing my desire that more of our system work in "industry standard" ways when at all possible. Someone is going to read this and interpret it as "LL says they are going to do FOO" - and the fear of that happening has prevented me from discussing issues on this list in the past. I'd like to get past that, so the disclaimer is now almost as large as the actual content of this message. > > If we were to move to a 'standard' chat backend (woot! yes! I love that idea! jabber or whatever!) we should try pretty hard to have as few exceptions or special cases to how it works as possible. In other words, I think we get a lot more out of using a standard chat system if we behave like a standard chat system than if we were to behave like our own special little chat system just using a standard backend. Even though the latter case still has some value. > > - Kelly _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From hud at zurich.ibm.com Thu Jan 10 00:24:10 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Thu Jan 10 00:24:10 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <20080109221012.GD20981@dague.net> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> Message-ID: <4785D62A.4050904@zurich.ibm.com> Sean Dague wrote: > On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote: > >> the new web based authentication scheme uses a web page to capture the >> fullname and the password of an avatar and returns a web_login_key that is >> passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL >> client takes that secondlife:///app/login/... URI and extracts the >> web_login_key (and first and last name and other stuff it seems) and goes >> to the login service to log the avatar/agent in to the grid. >> >> while this works with the LL grid, it does not work with OpenSim grids, >> because the LL SL client has no clue that it needs to go to a different, >> non-LL grid login service: the latest release clients and the windlight >> client do provide the -loginpage which would allow us to direct the client >> to a login page of our own, where we could then generate the >> secondlife:///app/login/.. URI --- however, that URI does not include any >> reference whatsoever to the grid you want to connect to (well, it does to >> some extent: there is a 'grid' parameter but that only knows about LL grids >> and also does not include ports, resources, etc) >> >> teravus ousley has described this in much more detail (and probably better >> than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he >> also tried several other things (have a look at VWR-4021, if you are >> interested in the details) to no avail: we cannot get the latest windlight >> and RC clients to connect to OpenSim grids/servers. >> >> luckily, we had a chance to discuss this with tess linden at yesterday's >> AWGroupies meeting. the following two proposals came up: >> >> (a) use the currently empty host part of the secondlife:///app/login >> URI to specify the grid server: that is, to connect to my 4x4 >> OpenSim grid running here in the lab, i'd have the following URI: >> >> >> secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... >> >> the LL SL client would simply do a s/^secondlife:/http:/ >> substitution and use the resulting URL to login the avatar in. >> >> (b) recast the currently used grid parameter to always contain the >> FQDN of the grid server along with port and resource; that is, for >> my lab grid that would be: >> >> >> secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... >> >> here the client would have to parse the URI, extract the grid >> parameter, un-quote its value, then construct the login URL and >> login the avatar in. >> >> clearly, approach (a) seems to be the cleanest approach and fits well with >> the common URI scheme. however... >> >> ...during the discussion it transpired that the reason the host part of the >> secondlife:/// URI is empty, is that the target of that SLURL is *not* the >> grid server but the *client*! in particular, /app/login signals to the >> client what it should do: login via a URL that it needs to construct from >> the supplied URI. >> >> ...also, as fword utorid remarked, using the secondlife: URI to trigger a >> grid login adds a new semantic to the secondlife: URI --- so far it has >> been used as a kind of secondlife GPS location fix: >> secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 >> island, for example. now, secondlife:///app/login?... addresses the >> secondlife client and tells it to do a login to a grid. >> > > I (aka neas bade) will continue to express frustration on this design > point. I know that secondlife:/// URI-like-things are currently used as > a hack to get a webbrowser to trigger an external application, however I > think that sticking with that design point causes confusion as well as > leads to the implicit hardcoding of the main grid into the client. > > secondlife://osgrid.org:8002/app/login equaly conveys to the client what it > should do, that is connect to a network resource for login. If we have > append the web_login_key= to this request, we can fully process that URI > back to the server as a well understood resource on the network, > returning to us any appropriate further information needed. > > secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit > hostname is in this URI scheme. That really should be > secondlife://secondlife.com/IBM%206/127/104/88, which would let you load > SLURLs for other grids in a sensible way (and you'd get appropriately > prompted for credentials in the equiv of HTTP AUTH domains). > i completely agree...the question is can we get this to work given that we already have a few of those secondlife://Bla%20bla%20/127/104/88 URIs around? it might work as long as you don't have island names that are valid FQDN... dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/ad37192a/attachment.htm From matthew.dowd at hotmail.co.uk Thu Jan 10 00:46:31 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jan 10 00:46:33 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: <4785D62A.4050904@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> Message-ID: > while this works with the LL grid, it does not work with OpenSim grids, > because the LL SL client has no clue that it needs to go to a different, > non-LL grid login service: I must confess I prefered the solution proposed in http://jira.secondlife.com/browse/VWR-3808 Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From robin.cornelius at gmail.com Thu Jan 10 01:10:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 10 01:08:20 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> Message-ID: <4785E0E8.60704@gmail.com> Matthew Dowd wrote: > >> while this works with the LL grid, it does not work with OpenSim grids, >> because the LL SL client has no clue that it needs to go to a different, >> non-LL grid login service: >> > > I must confess I prefered the solution proposed in http://jira.secondlife.com/browse/VWR-3808 > Can i clarify which of the points you referrer to. There are a couple raised in that JIRA, one gives a legacylogin option for opensim etc grids (and thats what th patch does) and this is a temporary workaround for opensim really. My preferred solution is in the comments and that is for the authentication webpage to return the loginuri to use on the next stage of login. This gives numerous advantages and means that grids can be added or removed ad-hoc without viewer updates. You want 2 beta grids today, just change the authentication webpage to give you the new option, all clients (who request a grid choice) can see it. Also works well for opensim etc and is probably the most clean solution as the login destination is controlled by a single parameter not a whole bunch of parameters that are mutually inclusive. Actually as this is now referring to a changes to the login authentication page we really should file this as a SVC? as thats where (the important) changes are required to implement this solution, the viewer just needs to parse one extra returned parameter in the secondlife:// protocol return which is fairly trivial. Of cause the command line options can be left there too for people who so desire. Robin > Matthew > _________________________________________________________________ > Telly addicts unite! > http://www.searchgamesbox.com/tvtown.shtml_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From belxjander at gmail.com Thu Jan 10 02:09:40 2008 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Thu Jan 10 02:09:26 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47859D07.9000101@cox.net> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <47855B04.9000504@earthlink.net> <47859D07.9000101@cox.net> Message-ID: <1199959780.12476.26.camel@localhost> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080110/63fcd18d/attachment-0001.pgp From robin.cornelius at gmail.com Thu Jan 10 02:28:01 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 10 02:26:27 2008 Subject: [sldev] [VWR] openAL wind generator WIP Message-ID: <4785F331.7010308@gmail.com> Hi Guys, I have been hacking up Seg's openAL patch again and have started implementing wind noise generation. I know many of you don't care about wind noise (but thats a seperate discussion) but to be "feature complete" wrt FMOD it needs implementing. I have it working to a point, but get no wind sound. I am not quite sure why yet, so if any one has an idea please let me know. I can see the openAL buffers being processed but no audio appears at the speakers. Heres the link to the patch :- http://www.byteme.org.uk/uploads/openALv4.patch As its not complete i have not pushed it to JIRA yet and i am not currently doing diff's against Seg's original patch because diffs of diffs become a mess quickly. Additional changes are that it does not now jump up and down on FMOD. FMOD and OpenAL can be build time enabled with FMOD=? and OPENAL=? scons lines (which generate -DLL_OPENAL flags to include/exclude code same as fmod always did). Can also be runtime selected. The LL_BAD_ALSA etc all effect FMOD only and a new LL_BAD_OPENAL will effect openal only. FMOD is attempted to be run first if it can't start due to not being compiled in, or due to all 3 LL_BAD_* lines being set, OpenAL is attempted next. The patch also contains the last gstreamer update too, for streaming sound. As for wind noise, i am currently doing the following :- OpenAL does not have callbacks as FMOD does. FMOD currently issues a call back to process a "DSP" unit or a buffer of sound. The wind generator code fills this buffer with the wind noise. With OpenAL i am allocating a number of buffers pushing them to the openAL queue then every updatewind() freeing any played buffers and generating new wind for the newly empy buffers and pushing to the queue again. It *should* at least make a noise even if i have miss aligned sound data. I get no openAL errors so i reckon that the gain must be very low or some other parameter is not set. If any one has any ideas on completing the wind noise, from comments left on the openAL JIRA it appears it may not be too long before we can look at merging :-) There are still a few "magic" numbers in (my) wind code and a couple of other small issues but we are getting there. Robin From belxjander at gmail.com Thu Jan 10 02:50:31 2008 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Thu Jan 10 02:50:20 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> Message-ID: <1199962231.12476.44.camel@localhost> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080110/56a86a2a/attachment.pgp From sean at dague.net Thu Jan 10 05:03:46 2008 From: sean at dague.net (Sean Dague) Date: Thu Jan 10 05:03:48 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <4785D62A.4050904@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> Message-ID: <20080110130346.GE20981@dague.net> On Thu, Jan 10, 2008 at 09:24:10AM +0100, Dr Scofield wrote: > Sean Dague wrote: >> On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote: >> >>> the new web based authentication scheme uses a web page to capture the >>> fullname and the password of an avatar and returns a web_login_key that >>> is passed to the LL SL client via a secondlife:///app/login/... URI. the >>> LL SL client takes that secondlife:///app/login/... URI and extracts the >>> web_login_key (and first and last name and other stuff it seems) and goes >>> to the login service to log the avatar/agent in to the grid. >>> >>> while this works with the LL grid, it does not work with OpenSim grids, >>> because the LL SL client has no clue that it needs to go to a different, >>> non-LL grid login service: the latest release clients and the windlight >>> client do provide the -loginpage which would allow us to direct the >>> client to a login page of our own, where we could then generate the >>> secondlife:///app/login/.. URI --- however, that URI does not include any >>> reference whatsoever to the grid you want to connect to (well, it does to >>> some extent: there is a 'grid' parameter but that only knows about LL >>> grids and also does not include ports, resources, etc) >>> >>> teravus ousley has described this in much more detail (and probably >>> better than i have) in VWR-4021 >>> (https://jira.secondlife.com/browse/VWR-4021). he also tried several >>> other things (have a look at VWR-4021, if you are interested in the >>> details) to no avail: we cannot get the latest windlight and RC clients >>> to connect to OpenSim grids/servers. >>> >>> luckily, we had a chance to discuss this with tess linden at yesterday's >>> AWGroupies meeting. the following two proposals came up: >>> >>> (a) use the currently empty host part of the secondlife:///app/login >>> URI to specify the grid server: that is, to connect to my 4x4 >>> OpenSim grid running here in the lab, i'd have the following URI: >>> >>> >>> secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... >>> >>> the LL SL client would simply do a s/^secondlife:/http:/ >>> substitution and use the resulting URL to login the avatar in. >>> >>> (b) recast the currently used grid parameter to always contain the >>> FQDN of the grid server along with port and resource; that is, for >>> my lab grid that would be: >>> >>> >>> secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... >>> >>> here the client would have to parse the URI, extract the grid >>> parameter, un-quote its value, then construct the login URL and >>> login the avatar in. >>> >>> clearly, approach (a) seems to be the cleanest approach and fits well >>> with the common URI scheme. however... >>> >>> ...during the discussion it transpired that the reason the host part of >>> the secondlife:/// URI is empty, is that the target of that SLURL is >>> *not* the grid server but the *client*! in particular, /app/login signals >>> to the client what it should do: login via a URL that it needs to >>> construct from the supplied URI. >>> >>> ...also, as fword utorid remarked, using the secondlife: URI to trigger a >>> grid login adds a new semantic to the secondlife: URI --- so far it has >>> been used as a kind of secondlife GPS location fix: >>> secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 >>> island, for example. now, secondlife:///app/login?... addresses the >>> secondlife client and tells it to do a login to a grid. >>> >> >> I (aka neas bade) will continue to express frustration on this design >> point. I know that secondlife:/// URI-like-things are currently used as >> a hack to get a webbrowser to trigger an external application, however I >> think that sticking with that design point causes confusion as well as >> leads to the implicit hardcoding of the main grid into the client. >> >> secondlife://osgrid.org:8002/app/login equaly conveys to the client what >> it >> should do, that is connect to a network resource for login. If we have >> append the web_login_key= to this request, we can fully process that URI >> back to the server as a well understood resource on the network, >> returning to us any appropriate further information needed. >> >> secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit >> hostname is in this URI scheme. That really should be >> secondlife://secondlife.com/IBM%206/127/104/88, which would let you load >> SLURLs for other grids in a sensible way (and you'd get appropriately >> prompted for credentials in the equiv of HTTP AUTH domains). >> > i completely agree...the question is can we get this to work given that we > already have a few of those secondlife://Bla%20bla%20/127/104/88 URIs > around? it might work as long as you don't have island names that are valid > FQDN... The host portion of the secondlife:// URL should be the grid entry point, not the hostname of the sim itself. Much like you don't know which physical machines you are hitting when you go to http://www.amazon.com. The way you get to introducing hostname into secondlife:// is pretty easy. 1. Make the client support hostname optionally 2. Make all the tools that create SLURLs generate the hostname explicitly as part of the tool 3. Deprecate the concept of SLURLs without hostname RSN 4. After a reasonable time, phase out the non-hostname SLURLS (i.e. 1.20.x client timeframe). We've seen force client upgrades of incompatible bits in the past. Doing so for extremely sensibly architecture reasons should be at least as valid as doing so because Internet Explorer has bugs in URL handling. We are now 4 months after the kickoff of the AWG in SF, and hitting the first of the architectural issues that both directly affect the grid today, and the architectural sanity of future grids. Taking the shortcuts here are already causing pain for OpenSim trying to interoperate with software on the main grid. I also think these kinds of shortcuts jepordize the ability of secondlife to be the seed for standards around virtual worlds. Doing this sensibly will take only a few extra weeks of time, but the pay off will be much greater down the road in terms of extensibility and likeness to existing standards that makes people want to build more bits compatible with the protocol and the environment. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080110/892fafed/attachment.pgp From tateru.nino at gmail.com Thu Jan 10 05:44:32 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jan 10 05:45:52 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47854149.1070409@Arnholm.se> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> Message-ID: <47862140.6090005@gmail.com> Didn't LL announce in February 2006 that they'd be switching the IM systems to Jabber? Lord knows, I was sitting in the audience at the time. Anders Arnholm wrote: > Argent Stonecutter skrev: >> On 2008-01-09, at 12:11, Abh Serechai Belxjander wrote: >>> Voice is its own "subservice" thread and seperate server, >>> Why not the same using IRC as a backend for chat? >> >> Jabber, please. > > Jabber back end would be really great... and jabber login :-) > -- Tateru Nino http://dwellonit.blogspot.com/ From secret.argent at gmail.com Thu Jan 10 06:13:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 06:13:22 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> Message-ID: <55E8C354-2D15-43DB-B0FC-AF48B33F78EB@gmail.com> On 2008-01-10, at 02:23, Matthew Dowd wrote: > vi) One of the issues with the communicate window at the moment is > tab clutter. This results in the window taking up too much valuable > screen estate and IMs being overlooked since the flashing tab to > indicate a new message gets lost amongst all the other tabs! One > solution, I've proposed is to stack the tabs vertically (http:// > jira.secondlife.com/browse/VWR-3265), which was generally well > received although it was suggested this should be optional (and > I've not had a chance to revisit this). I would have to patch the XUI to undo that... again... if that was done. I already patch the XUI every time I install SL to get the contacts tabs on the bottom, as in http://jira.secondlife.com/browse/VWR-1549. I still don't understand why they rejected that one, it's just nested tabs and not confusing at all. I also make them tear off. That works well _for me_ but without matching code changes I have to be careful what order I open windows in, because it's possible to get SL confused and try and render into a non-existent window, which crashes it. From secret.argent at gmail.com Thu Jan 10 06:20:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 06:20:34 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: <4785E0E8.60704@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <4785E0E8.60704@gmail.com> Message-ID: <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> On 2008-01-10, at 03:10, Robin Cornelius wrote: > Can i clarify which of the points you referrer to. There are a > couple raised in that JIRA, one gives a legacylogin option for > opensim etc grids (and thats what th patch does) and this is a > temporary workaround for opensim really. My preferred solution is > in the comments and that is for the authentication webpage to > return the loginuri to use on the next stage of login. You mean it doesn't???? I thought the Lindens had already specified that submitting the form would return a redirect to the login URI. From secret.argent at gmail.com Thu Jan 10 06:24:28 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 06:24:41 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1199962231.12476.44.camel@localhost> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> Message-ID: <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> On 2008-01-10, at 04:50, Abh Serechai Belxjander wrote: > a "Jabber" backend may need a Jabber Enabled EmailID be used when > signing up or "Enable Jabber" for Email ID's > that are not already Jabber-Enabled ( Earthlink / Gmail / > Livejournal / etc... ) Your Jabber ID in SL would be something like Firstname.Lastname@jabber.secondlife.com, and whether that would hook into the rest of the jabber scheme or not is probably outside the scope of this list... AFAIK gmail still doesn't, for example. From secret.argent at gmail.com Thu Jan 10 06:31:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 06:31:40 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <20080110130346.GE20981@dague.net> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <20080110130346.GE20981@dague.net> Message-ID: <28B38386-3913-454F-BCE3-EE51F9802F30@gmail.com> On 2008-01-10, at 07:03, Sean Dague wrote: > The host portion of the secondlife:// URL should be the grid entry > point, not the hostname of the sim itself. That's a separate issue. The perfect solution would be for LL to publish a TXT record for each of Ahern.grid.secondlife.com, da-boom.grid.secondlife.com, and so on. That TXT record would contain the actual host and (as an aside) any other data potentially needed to login to their grid. The client would simply append ".grid.secondlife.com" to the host portion if it's not a FQDN. For other grids, they would have their own TXT records published for their own domains, so for them you'd log in to secondlife://theirsim.theirdomain.example.com/... > Much like you don't know > which physical machines you are hitting when you go to > http://www.amazon.com. That's also a separate issue. I don't know what physical machines I'm hitting when I go to forums.secondlife.com or www.secondlife.com or jira.secondlife.com. The sim identification is like that. From belxjander at gmail.com Thu Jan 10 06:38:04 2008 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Thu Jan 10 06:37:51 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> Message-ID: <1199975884.12476.68.camel@localhost> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080111/376435c7/attachment.pgp From robin.cornelius at gmail.com Thu Jan 10 06:46:12 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 10 06:44:32 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <4785E0E8.60704@gmail.com> <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> Message-ID: <47862FB4.9050609@gmail.com> Argent Stonecutter wrote: > On 2008-01-10, at 03:10, Robin Cornelius wrote: >> Can i clarify which of the points you referrer to. There are a couple >> raised in that JIRA, one gives a legacylogin option for opensim etc >> grids (and thats what th patch does) and this is a temporary >> workaround for opensim really. My preferred solution is in the >> comments and that is for the authentication webpage to return the >> loginuri to use on the next stage of login. > > You mean it doesn't???? > > I thought the Lindens had already specified that submitting the form > would return a redirect to the login URI. > No it only returns a grid=agni, it does not return the required full url. It looks up the returned grid name in the list that is hard coded in llviewernetwork.cpp. I cannot see any point for this hardcoding. It might just as well return the full url for the next xmlrpc auth stage. There is a provision after the xmlrpc request to have an indeterminate state that can then rewrite the loginuri to another location but not at the web auth stage. RObin From matthew.dowd at hotmail.co.uk Thu Jan 10 06:45:33 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jan 10 06:45:36 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <55E8C354-2D15-43DB-B0FC-AF48B33F78EB@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <55E8C354-2D15-43DB-B0FC-AF48B33F78EB@gmail.com> Message-ID: ---------------------------------------- > CC: kelly@lindenlab.com; anders@arnholm.se; sldev@lists.secondlife.com > From: secret.argent@gmail.com > Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > Date: Thu, 10 Jan 2008 08:13:09 -0600 > To: matthew.dowd@hotmail.co.uk > > On 2008-01-10, at 02:23, Matthew Dowd wrote: >> vi) One of the issues with the communicate window at the moment is >> tab clutter. This results in the window taking up too much valuable >> screen estate and IMs being overlooked since the flashing tab to >> indicate a new message gets lost amongst all the other tabs! One >> solution, I've proposed is to stack the tabs vertically (http:// >> jira.secondlife.com/browse/VWR-3265), which was generally well >> received although it was suggested this should be optional (and >> I've not had a chance to revisit this). > > I would have to patch the XUI to undo that... again... if that was done. No - that was were this suggestion has stalled - probably worth doing but only if the user can configure whether to have the IM tabs vertical or horizontal, so you wouldn't need an unpatch, you'd just need to make sure the appropriate checkbox was ticked or unticked (or whatever). However, I was hoping to be able to switch between vert and horizontal modes in real time, but limitations in how the tab widget has been implemented means you may need to have to restart the viewer for any such change to take effect (and at about this time, SL made a mandatory source drop which has some missing pieces and didn't compile out of the zip file, so I didn't do anything more with this, then it was Christmas....) Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From me at hamncheeseomlet.com Thu Jan 10 08:04:19 2008 From: me at hamncheeseomlet.com (Hamncheese) Date: Thu Jan 10 08:05:46 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> References: <1199902283.12476.25.camel@localhost><091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com><47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com><478556A6.7060409@gmail.com><23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com><1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> Message-ID: <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> Actually XMPP (jabber) has a different format than most other non-XMPP IM clients. Make that firstname.lastname@someserver.com/resource and you would be correct Which lends it self real well to signing into groups because resource could be the group token that you are signed into. ----- Original Message ----- From: "Argent Stonecutter" To: "Second Life Developer Mailing List" Sent: Thursday, January 10, 2008 9:24 AM Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > On 2008-01-10, at 04:50, Abh Serechai Belxjander wrote: >> a "Jabber" backend may need a Jabber Enabled EmailID be used when >> signing up or "Enable Jabber" for Email ID's >> that are not already Jabber-Enabled ( Earthlink / Gmail / Livejournal >> / etc... ) > > Your Jabber ID in SL would be something like > Firstname.Lastname@jabber.secondlife.com, and whether that would hook > into the rest of the jabber scheme or not is probably outside the scope > of this list... AFAIK gmail still doesn't, for example. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From hud at zurich.ibm.com Thu Jan 10 08:11:48 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Thu Jan 10 08:11:52 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <4785E0E8.60704@gmail.com> <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> Message-ID: <478643C4.6050608@zurich.ibm.com> Argent Stonecutter wrote: > On 2008-01-10, at 03:10, Robin Cornelius wrote: >> Can i clarify which of the points you referrer to. There are a couple >> raised in that JIRA, one gives a legacylogin option for opensim etc >> grids (and thats what th patch does) and this is a temporary >> workaround for opensim really. My preferred solution is in the >> comments and that is for the authentication webpage to return the >> loginuri to use on the next stage of login. > > You mean it doesn't???? > > I thought the Lindens had already specified that submitting the form > would return a redirect to the login URI. no. it doesn't. it currently returns secondlife:///app/login?...&web_login_key=.... no indication about grid login URI. that's what this discussion is about. cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From hud at zurich.ibm.com Thu Jan 10 08:13:10 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Thu Jan 10 08:13:16 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> Message-ID: <47864416.3060405@zurich.ibm.com> Argent Stonecutter wrote: > On 2008-01-10, at 04:50, Abh Serechai Belxjander wrote: >> a "Jabber" backend may need a Jabber Enabled EmailID be used when >> signing up or "Enable Jabber" for Email ID's >> that are not already Jabber-Enabled ( Earthlink / Gmail / >> Livejournal / etc... ) > > Your Jabber ID in SL would be something like > Firstname.Lastname@jabber.secondlife.com, and whether that would hook > into the rest of the jabber scheme or not is probably outside the > scope of this list... AFAIK gmail still doesn't, for example. google talk does server connects to some jabber servers, jabber.org.uk, for example, works, jabber.org, IIRC, also. dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From gmx0007 at gazeta.pl Thu Jan 10 08:28:35 2008 From: gmx0007 at gazeta.pl (gmx0007@gazeta.pl) Date: Thu Jan 10 08:28:48 2008 Subject: [sldev] SL Protocol Message-ID: <22074073.12161199982515827.JavaMail.webadm@ew7> Hello, I try to connect to Second Life using my simple program. I use xmlrpc method to login to SL according to https://wiki.secondlife.com/wiki/Current_login_protocols. In response LoginServer give me circuit_code(cc),session_id(ss),agent_id(aa),sim_ip,sim_port,.. Which next I use to start circuit by sending UseCircuitCode to (sim_ip,sim_port) and start receive thread to get all UDP packet from simulator. cc - CircuitCode = from login CircuitCode ss - Session UUID = from login session_id aa - Agent UUID = from login agent_id == Sending packet == UseCircuitCode Debug: Send:46 pendingAcks:0 0000 - 40 00 00 00 01 00 ff ff 00 03 cc cc cc cc ss ss 0010 - ss ss ss ss ss ss ss ss ss ss ss ss ss ss aa aa 0020 - aa aa aa aa aa aa aa aa aa aa aa aa aa aa CompleteAgentMovement Debug: Send:46 pendingAcks:0 0000 - 40 00 00 00 02 00 ff ff 00 f9 aa aa aa aa aa aa 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss 0020 - ss ss ss ss ss ss ss ss ss ss cc cc cc cc --- UserInfoRequest --- Debug: Send:42 pendingAcks:0 0000 - 40 00 00 00 07 00 ff ff 01 8f aa aa aa aa aa aa 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss 0020 - ss ss ss ss ss ss ss ss ss ss For last one (UserInfoRequest) Sim didn't send response, but I get PacketAck for this packet. I also have the same problem for: AvatarPropertiesRequest, LogoutRequest It works well with: UUIDNameRequest, StartPingCheck, CloseCircuit and receive UUIDNameReply, CompletePingCheck, PacketAck When at start I send UseCircuitCode with wrong circuitCode or session then no any packets from sim. And this case is clear, no open cicuit. But what with open one ? What might be wrong that I didn't get those replies? Thanks, Tom --- Wiadomo?? zosta?a wys?ana z serwisu bezp?atnych kont pocztowych portalu Gazeta.pl. Agora SA nie odpowiada za spos?b wykorzystywania tych kont przez u?ytkownik?w. From sv193702 at ohio.edu Thu Jan 10 08:30:17 2008 From: sv193702 at ohio.edu (Stan Vernier) Date: Thu Jan 10 08:31:32 2008 Subject: [sldev] Re: movement within the client In-Reply-To: <4775BD8C.6030408@ohio.edu> References: <4775BD8C.6030408@ohio.edu> Message-ID: <47864819.10500@ohio.edu> Stan Vernier wrote: > I'm looking into being able to control the avatar within the client > and I'm trying to simulate the teleport script to move the avatar from > point a to point b within the same region. I can get the avatar to > move from a to b, but the moment I try to move the avatar, it pops > back to point a. I tried sendPositionUpdate(), but it didn't work. > Anyone got any suggestions? > So I've run into another dilemma with handling movement. I've figured out the functions to get movement - moveAt, moveUp, Yaw, Left, Pitch. What I'm stuck on now is how do I create a consistent movement like "move 10m forwards"? From secret.argent at gmail.com Thu Jan 10 08:31:29 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 08:31:39 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general ho In-Reply-To: <47862FB4.9050609@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <4785E0E8.60704@gmail.com> <92949AD9-FD3A-4C4B-B3AC-C60407874444@gmail.com> <47862FB4.9050609@gmail.com> Message-ID: <0D00C905-61C2-41C8-BF0A-E95F42033290@gmail.com> On 2008-01-10, at 08:46, Robin Cornelius wrote: > No it only returns a grid=agni, it does not return the required > full url. I have to say that someone is missing the whole point of HTTP somewhere around here. From monkowsk at watson.ibm.com Thu Jan 10 08:49:21 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jan 10 08:49:32 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1199959780.12476.26.camel@localhost> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <47855B04.9000504@earthlink.net> <47859D07.9000101@cox.net> <1199959780.12476.26.camel@localhost> Message-ID: <47864C91.6030600@watson.ibm.com> Abh Serechai Belxjander wrote: > Is there any map of the existing codebase as to what subsystems exist > and where code for them is located? Start at http://wiki.secondlife.com/wiki/Documentation From tateru.nino at gmail.com Thu Jan 10 08:55:19 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jan 10 08:56:39 2008 Subject: [sldev] SL Protocol In-Reply-To: <22074073.12161199982515827.JavaMail.webadm@ew7> References: <22074073.12161199982515827.JavaMail.webadm@ew7> Message-ID: <47864DF7.10000@gmail.com> Almost all the values in the protocol are big-endian (network order). The circuit code, however, is little-endian - the byte-order is backwards compared to the other values. Does that help at all? gmx0007@gazeta.pl wrote: > Hello, > > I try to connect to Second Life using my simple program. > I use xmlrpc method to login to SL according to > https://wiki.secondlife.com/wiki/Current_login_protocols. > In response LoginServer give me > circuit_code(cc),session_id(ss),agent_id(aa),sim_ip,sim_port,.. > Which next I use to start circuit by sending UseCircuitCode to > (sim_ip,sim_port) and start receive thread to get all UDP packet > from simulator. > > cc - CircuitCode = from login CircuitCode > ss - Session UUID = from login session_id > aa - Agent UUID = from login agent_id > > == Sending packet == > > UseCircuitCode > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 01 00 ff ff 00 03 cc cc cc cc ss ss > 0010 - ss ss ss ss ss ss ss ss ss ss ss ss ss ss aa aa > 0020 - aa aa aa aa aa aa aa aa aa aa aa aa aa aa > > CompleteAgentMovement > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 02 00 ff ff 00 f9 aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss cc cc cc cc > > --- UserInfoRequest --- > Debug: Send:42 pendingAcks:0 > 0000 - 40 00 00 00 07 00 ff ff 01 8f aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss > > For last one (UserInfoRequest) Sim didn't send response, > but I get PacketAck for this packet. > I also have the same problem for: AvatarPropertiesRequest, LogoutRequest > > It works well with: > UUIDNameRequest, StartPingCheck, CloseCircuit > and receive > UUIDNameReply, CompletePingCheck, PacketAck > > When at start I send UseCircuitCode with wrong circuitCode or session > then no any packets from sim. And this case is clear, no open cicuit. > But what with open one ? > > What might be wrong that I didn't get those replies? > > Thanks, > Tom > > > --- > Wiadomo?? zosta?a wys?ana z serwisu bezp?atnych kont pocztowych portalu Gazeta.pl. Agora SA nie odpowiada za spos?b wykorzystywania tych kont przez u?ytkownik?w. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From mark.burhop at gmail.com Thu Jan 10 09:21:54 2008 From: mark.burhop at gmail.com (Mark Burhop) Date: Thu Jan 10 09:21:56 2008 Subject: [sldev] Dual Screens or Multiple Windows Message-ID: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> Anyone looking at or have solutions for dual screens? I use them a lot for other work (like having my app on one screen and debugger in another). What I'd really like is to pull out all the overlaying SL viewer windows (especially what might become a very big chat window in the next release :-) onto a separate screen. We've probably all been in a virtual crowded meeting or room where you are trying to watch the avatars and a lively chat window at the same time. Goodness forbit you have to get something out of your inventory at the same time. I can resize the client across both monitors but this doesn't work too well (more to render, things sitting on the middle seam, and windows are still overlaid). Docking the windows might be good too. Even a non-graphics area where I could park the windows might work as a quick hack. So wondering if there are any existing solutions (maybe I missed an option?) or thoughts for a future one... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/5305c7e0/attachment-0001.htm From tateru.nino at gmail.com Thu Jan 10 09:55:25 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jan 10 09:56:45 2008 Subject: [sldev] Re: movement within the client In-Reply-To: <47864819.10500@ohio.edu> References: <4775BD8C.6030408@ohio.edu> <47864819.10500@ohio.edu> Message-ID: <47865C0D.4080106@gmail.com> Stan Vernier wrote: > Stan Vernier wrote: >> I'm looking into being able to control the avatar within the client >> and I'm trying to simulate the teleport script to move the avatar >> from point a to point b within the same region. I can get the avatar >> to move from a to b, but the moment I try to move the avatar, it pops >> back to point a. I tried sendPositionUpdate(), but it didn't work. >> Anyone got any suggestions? >> > So I've run into another dilemma with handling movement. I've figured > out the functions to get movement - moveAt, moveUp, Yaw, Left, Pitch. > What I'm stuck on now is how do I create a consistent movement like > "move 10m forwards"? Calculate the destination position, and send motion commands, while comparing reported avatar position with calculated destination, until you get to where you're going? (Essentially approximating your way to the target) Of course, you're going to want to implement a pathfinding algorithm the instant something solid winds up in the way. -- Tateru Nino http://dwellonit.blogspot.com/ From sv193702 at ohio.edu Thu Jan 10 10:48:34 2008 From: sv193702 at ohio.edu (Stan Vernier) Date: Thu Jan 10 10:49:06 2008 Subject: [sldev] Re: movement within the client In-Reply-To: <47865C0D.4080106@gmail.com> References: <4775BD8C.6030408@ohio.edu> <47864819.10500@ohio.edu> <47865C0D.4080106@gmail.com> Message-ID: <47866882.6000101@ohio.edu> Tateru Nino wrote: > > > Stan Vernier wrote: >> Stan Vernier wrote: >>> I'm looking into being able to control the avatar within the client >>> and I'm trying to simulate the teleport script to move the avatar >>> from point a to point b within the same region. I can get the >>> avatar to move from a to b, but the moment I try to move the avatar, >>> it pops back to point a. I tried sendPositionUpdate(), but it >>> didn't work. Anyone got any suggestions? >>> >> So I've run into another dilemma with handling movement. I've >> figured out the functions to get movement - moveAt, moveUp, Yaw, >> Left, Pitch. What I'm stuck on now is how do I create a consistent >> movement like "move 10m forwards"? > > Calculate the destination position, and send motion commands, while > comparing reported avatar position with calculated destination, until > you get to where you're going? (Essentially approximating your way to > the target) > Of course, you're going to want to implement a pathfinding algorithm > the instant something solid winds up in the way. > I kinda tried that with a while loop with gAgent.moveAt(1) in it, but it just froze the client. I took a look at some of the other code for movement and it seems to only call a move command once and then somewhere down the line the rest of the movement gets dealt with. For the movement floater, it looks like it uses mMoveDownButton->setHeldDownCallback(moveUp). I guess my question is how to do this without holding a button? From tateru.nino at gmail.com Thu Jan 10 10:53:57 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jan 10 10:55:37 2008 Subject: [sldev] Re: movement within the client In-Reply-To: <47866882.6000101@ohio.edu> References: <4775BD8C.6030408@ohio.edu> <47864819.10500@ohio.edu> <47865C0D.4080106@gmail.com> <47866882.6000101@ohio.edu> Message-ID: <478669C5.7010407@gmail.com> Stan Vernier wrote: > Tateru Nino wrote: >> >> >> Stan Vernier wrote: >>> Stan Vernier wrote: >>>> I'm looking into being able to control the avatar within the client >>>> and I'm trying to simulate the teleport script to move the avatar >>>> from point a to point b within the same region. I can get the >>>> avatar to move from a to b, but the moment I try to move the >>>> avatar, it pops back to point a. I tried sendPositionUpdate(), but >>>> it didn't work. Anyone got any suggestions? >>>> >>> So I've run into another dilemma with handling movement. I've >>> figured out the functions to get movement - moveAt, moveUp, Yaw, >>> Left, Pitch. What I'm stuck on now is how do I create a consistent >>> movement like "move 10m forwards"? >> >> Calculate the destination position, and send motion commands, while >> comparing reported avatar position with calculated destination, until >> you get to where you're going? (Essentially approximating your way to >> the target) >> Of course, you're going to want to implement a pathfinding algorithm >> the instant something solid winds up in the way. >> > I kinda tried that with a while loop with gAgent.moveAt(1) in it, but > it just froze the client. I took a look at some of the other code for > movement and it seems to only call a move command once and then > somewhere down the line the rest of the movement gets dealt with. For > the movement floater, it looks like it uses > mMoveDownButton->setHeldDownCallback(moveUp). I guess my question is > how to do this without holding a button? > You've got to do it asynchronously. If you aren't waiting for server responses it'll definitely freeze. You've got to release the client to perform other tasks and handle communications and other messages. -- Tateru Nino http://dwellonit.blogspot.com/ From roamingryozu at gmail.com Thu Jan 10 11:13:34 2008 From: roamingryozu at gmail.com (Andre Roche) Date: Thu Jan 10 11:13:38 2008 Subject: [sldev] Dual Screens or Multiple Windows In-Reply-To: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> References: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> Message-ID: <5eff6d3b0801101113w72d8654bh4832f66450f44082@mail.gmail.com> I think this kind of thing has been on peoples minds for a long time now. Due to the way SL handles drawing the interface, it's not really possible to pull windows out of the client area, unfortunately. The idea was brought up to put the actual 3D area into a resizable window at some point... I can't recall the reasons why that wouldn't work. Personally, I'd be happy with just a setting to adjust exactly where my "center" focus is in relation to the render area. On Jan 10, 2008 12:21 PM, Mark Burhop wrote: > Anyone looking at or have solutions for dual screens? I use them a lot for > other work (like having my app on one screen and debugger in another). > > What I'd really like is to pull out all the overlaying SL viewer windows > (especially what might become a very big chat window in the next release :-) > onto a separate screen. We've probably all been in a virtual crowded meeting > or room where you are trying to watch the avatars and a lively chat window > at the same time. Goodness forbit you have to get something out of your > inventory at the same time. > > I can resize the client across both monitors but this doesn't work too well > (more to render, things sitting on the middle seam, and windows are still > overlaid). Docking the windows might be good too. Even a non-graphics area > where I could park the windows might work as a quick hack. > > So wondering if there are any existing solutions (maybe I missed an option?) > or thoughts for a future one... > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From secret.argent at gmail.com Thu Jan 10 11:17:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 11:17:29 2008 Subject: [sldev] Re: movement within the client In-Reply-To: <47866882.6000101@ohio.edu> References: <4775BD8C.6030408@ohio.edu> <47864819.10500@ohio.edu> <47865C0D.4080106@gmail.com> <47866882.6000101@ohio.edu> Message-ID: <61FF7614-CCF7-4256-A5DA-3AEE53031E58@gmail.com> On 2008-01-10, at 12:48, Stan Vernier wrote: > I kinda tried that with a while loop with gAgent.moveAt(1) in it, > but it just froze the client. I took a look at some of the other > code for movement and it seems to only call a move command once and > then somewhere down the line the rest of the movement gets dealt > with. For the movement floater, it looks like it uses > mMoveDownButton->setHeldDownCallback(moveUp). I guess my question > is how to do this without holding a button? You could look for the code that's already in the client for double- click autopilot, which seems to be doing pretty much what you want. From gmx0007 at gazeta.pl Thu Jan 10 11:21:40 2008 From: gmx0007 at gazeta.pl (gmx0007@gazeta.pl) Date: Thu Jan 10 11:21:43 2008 Subject: [sldev] SL Protocol Message-ID: <713955.18431199992900386.JavaMail.webadm@ew9> I checked values in those packet and everything seems OK. Circuit code is little-endian, and UUID big-endian. Use same in UseCircuitCode(work correct) packet as UserInfoRequest(doesn't). Maybe there are some constraints from login proces, which make that SIM doesn't send all packets. What should be fill in channel,mac(MAC or MAC hash?),viewer_digest,.. ? Is there any connection between those fileds and behaviour on sim ? Thanks, Tom >>Almost all the values in the protocol are big-endian (network >>order). >>The circuit code, however, is little-endian - the byte-order is >>backwards compared to the other values. Does that help at all? >>gmx0007@gazeta.pl wrote: > Hello, > > I try to connect to Second Life using my simple program. > I use xmlrpc method to login to SL according to > https://wiki.secondlife.com/wiki/Current_login_protocols. > In response LoginServer give me > circuit_code(cc),session_id(ss),agent_id(aa),sim_ip,sim_port,.. > Which next I use to start circuit by sending UseCircuitCode to > (sim_ip,sim_port) and start receive thread to get all UDP packet > from simulator. > > cc - CircuitCode = from login CircuitCode > ss - Session UUID = from login session_id > aa - Agent UUID = from login agent_id > > == Sending packet == > > UseCircuitCode > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 01 00 ff ff 00 03 cc cc cc cc ss ss > 0010 - ss ss ss ss ss ss ss ss ss ss ss ss ss ss aa aa > 0020 - aa aa aa aa aa aa aa aa aa aa aa aa aa aa > > CompleteAgentMovement > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 02 00 ff ff 00 f9 aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss cc cc cc cc > > --- UserInfoRequest --- > Debug: Send:42 pendingAcks:0 > 0000 - 40 00 00 00 07 00 ff ff 01 8f aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss > > For last one (UserInfoRequest) Sim didn't send response, > but I get PacketAck for this packet. > I also have the same problem for: AvatarPropertiesRequest, LogoutRequest > > It works well with: > UUIDNameRequest, StartPingCheck, CloseCircuit > and receive > UUIDNameReply, CompletePingCheck, PacketAck > > When at start I send UseCircuitCode with wrong circuitCode or session > then no any packets from sim. And this case is clear, no open cicuit. > But what with open one ? > > What might be wrong that I didn't get those replies? > > Thanks, > Tom > > > > --- Wiadomo?? zosta?a wys?ana z serwisu bezp?atnych kont pocztowych portalu Gazeta.pl. Agora SA nie odpowiada za spos?b wykorzystywania tych kont przez u?ytkownik?w. From secret.argent at gmail.com Thu Jan 10 11:27:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 10 11:27:30 2008 Subject: [sldev] Dual Screens or Multiple Windows In-Reply-To: <5eff6d3b0801101113w72d8654bh4832f66450f44082@mail.gmail.com> References: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> <5eff6d3b0801101113w72d8654bh4832f66450f44082@mail.gmail.com> Message-ID: <44D74D00-DCE7-4B1A-BF0F-A7C479C4CDD4@gmail.com> On 2008-01-10, at 13:13, Andre Roche wrote: > Personally, I'd be happy with just a setting to adjust exactly where > my "center" focus is in relation to the render area. I'd vote for that! From lenglish5 at cox.net Thu Jan 10 16:25:41 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 10 16:25:43 2008 Subject: [sldev] SL Protocol In-Reply-To: <22074073.12161199982515827.JavaMail.webadm@ew7> References: <22074073.12161199982515827.JavaMail.webadm@ew7> Message-ID: <4786B785.8020907@cox.net> gmx0007@gazeta.pl wrote: > Hello, > > I try to connect to Second Life using my simple program. > I use xmlrpc method to login to SL according to > https://wiki.secondlife.com/wiki/Current_login_protocols. > In response LoginServer give me > circuit_code(cc),session_id(ss),agent_id(aa),sim_ip,sim_port,.. > Which next I use to start circuit by sending UseCircuitCode to > (sim_ip,sim_port) and start receive thread to get all UDP packet > from simulator. > > cc - CircuitCode = from login CircuitCode > ss - Session UUID = from login session_id > aa - Agent UUID = from login agent_id > > == Sending packet == > > UseCircuitCode > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 01 00 ff ff 00 03 cc cc cc cc ss ss > 0010 - ss ss ss ss ss ss ss ss ss ss ss ss ss ss aa aa > 0020 - aa aa aa aa aa aa aa aa aa aa aa aa aa aa > > CompleteAgentMovement > Debug: Send:46 pendingAcks:0 > 0000 - 40 00 00 00 02 00 ff ff 00 f9 aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss cc cc cc cc > > --- UserInfoRequest --- > Debug: Send:42 pendingAcks:0 > 0000 - 40 00 00 00 07 00 ff ff 01 8f aa aa aa aa aa aa > 0010 - aa aa aa aa aa aa aa aa aa aa ss ss ss ss ss ss > 0020 - ss ss ss ss ss ss ss ss ss ss > > For last one (UserInfoRequest) Sim didn't send response, > but I get PacketAck for this packet. > I also have the same problem for: AvatarPropertiesRequest, LogoutRequest > > It works well with: > UUIDNameRequest, StartPingCheck, CloseCircuit > and receive > UUIDNameReply, CompletePingCheck, PacketAck > > When at start I send UseCircuitCode with wrong circuitCode or session > then no any packets from sim. And this case is clear, no open cicuit. > But what with open one ? > > What might be wrong that I didn't get those replies? > > Thanks, > Tom > I'm not really sure there. I know that some packets are coming in through the CAP interface via EventQueueGet, and that may be one of them. However, I'm not sure yet how to use EventQueueGet via Python, sorry. Lawson From lenglish5 at cox.net Thu Jan 10 18:50:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 10 18:50:08 2008 Subject: [sldev] SL Protocol In-Reply-To: <713955.18431199992900386.JavaMail.webadm@ew9> References: <713955.18431199992900386.JavaMail.webadm@ew9> Message-ID: <4786D95E.7080809@cox.net> gmx0007@gazeta.pl wrote: > I checked values in those packet and everything seems OK. > Circuit code is little-endian, and UUID big-endian. > Use same in UseCircuitCode(work correct) > packet as UserInfoRequest(doesn't). > Maybe there are some constraints from login proces, > which make that SIM doesn't send all packets. > > What should be fill in channel,mac(MAC or MAC hash?),viewer_digest,.. ? > Is there any connection between those fileds and behaviour on sim ? > What little you see in the webpages is what I (or someone else, such as John Hurliman with libsecondlife) has been able to glean from chats with Lindens or by trial and error. The documentation that Linden Lab has is apparently no more complete than what we've put up on the wiki, though they may have specific missing bits of info that aren't up there. The rule of thumb that John Hurliman has imparted to me concerning big-endian and little-endian is (if I recall correctly): the header is big-endian. All constants in the body of the packet are little-endian except UUIDs and the packet ID number. The body of the packet (including the packet ID number!!!!!) can be zero-encoded as specified in the header flags (for an incoming packet) and by the packet description in the message template. You have to decode the packet ID number (if needed) before you can completely decode the rest of the packet, because you don't know how long the packet will be otherwise. The acks tacked to the end of a packet are not zero-encoded so if you encode an outgoing packet, besure to add acks after you encode the packet. 1) I hope I gave you accurate info; 2) I hope it helps. Lawson From teravus at gmail.com Thu Jan 10 18:53:53 2008 From: teravus at gmail.com (Teravus Ovares) Date: Thu Jan 10 18:53:56 2008 Subject: [sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues In-Reply-To: <34cc66250801101852y579e9d5fs79aa56ce61e79c22@mail.gmail.com> References: <4784A848.9000208@zurich.ibm.com> <20080109221012.GD20981@dague.net> <4785D62A.4050904@zurich.ibm.com> <20080110130346.GE20981@dague.net> <28B38386-3913-454F-BCE3-EE51F9802F30@gmail.com> <34cc66250801101852y579e9d5fs79aa56ce61e79c22@mail.gmail.com> Message-ID: <34cc66250801101853v33dfe46atb75f6606f861f289@mail.gmail.com> Just a recent event on this topic, You can connect to OpenSim on the latest RC client and the Latest Windlight client assuming you're using a version of OpenSim > revision 3004. Best Regards Teravus Ousley On 1/10/08, Argent Stonecutter wrote: > > On 2008-01-10, at 07:03, Sean Dague wrote: > > The host portion of the secondlife:// URL should be the grid entry > > point, not the hostname of the sim itself. > > That's a separate issue. > > The perfect solution would be for LL to publish a TXT record for each > of Ahern.grid.secondlife.com , > da-boom.grid.secondlife.com, and so on. > That TXT record would contain the actual host and (as an aside) any > other data potentially needed to login to their grid. The client > would simply append ".grid.secondlife.com" to the host portion if > it's not a FQDN. For other grids, they would have their own TXT > records published for their own domains, so for them you'd log in to > secondlife://theirsim.theirdomain.example.com/... > > > Much like you don't know > > which physical machines you are hitting when you go to > > http://www.amazon.com . > > That's also a separate issue. > > I don't know what physical machines I'm hitting when I go to > forums.secondlife.com or www.secondlife.com or jira.secondlife.com. > The sim identification is like that. > > _______________________________________________ > 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/20080110/63859e1d/attachment.htm From dzonatas at dzonux.net Thu Jan 10 19:14:37 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jan 10 19:14:26 2008 Subject: [sldev] Dual Screens or Multiple Windows In-Reply-To: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> References: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> Message-ID: <4786DF1D.1050603@dzonux.net> There is already gtk work in the viewer. More of it, even using win32 compat libs, is an option to allow this kind of feature. Mark Burhop wrote: > Anyone looking at or have solutions for dual screens? I use them a > lot for other work (like having my app on one screen and debugger in > another). > > What I'd really like is to pull out all the overlaying SL viewer > windows (especially what might become a very big chat window in the > next release :-) onto a separate screen. We've probably all been in a > virtual crowded meeting or room where you are trying to watch the > avatars and a lively chat window at the same time. Goodness forbit you > have to get something out of your inventory at the same time. > > I can resize the client across both monitors but this doesn't work too > well (more to render, things sitting on the middle seam, and windows > are still overlaid). Docking the windows might be good too. Even a > non-graphics area where I could park the windows might work as a quick > hack. > > So wondering if there are any existing solutions (maybe I missed an > option?) or thoughts for a future one... > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Thu Jan 10 19:15:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 10 19:16:00 2008 Subject: [sldev] SL Protocol In-Reply-To: <4786D95E.7080809@cox.net> References: <713955.18431199992900386.JavaMail.webadm@ew9> <4786D95E.7080809@cox.net> Message-ID: <4786DF6D.1040909@cox.net> Lawson English wrote: > gmx0007@gazeta.pl wrote: >> I checked values in those packet and everything seems OK. >> Circuit code is little-endian, and UUID big-endian. >> Use same in UseCircuitCode(work correct) >> packet as UserInfoRequest(doesn't). >> Maybe there are some constraints from login proces, >> which make that SIM doesn't send all packets. >> >> What should be fill in channel,mac(MAC or MAC hash?),viewer_digest,.. ? >> Is there any connection between those fileds and behaviour on sim ? >> > What little you see in the webpages is what I (or someone else, such > as John Hurliman with libsecondlife) has been able to glean from chats > with Lindens or by trial and error. Well, the stuff found at http://wiki.secondlife.com/wiki/Protocol is entirely a LInden Lab effort, as far as I know, but its not complete and is getting more and more obsolete as new login protocols, CAPs, etc are brought into the picture. Lawson From jhurliman at jhurliman.org Thu Jan 10 19:50:12 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Thu Jan 10 19:50:15 2008 Subject: [sldev] SL Protocol In-Reply-To: <4786DF6D.1040909@cox.net> References: <713955.18431199992900386.JavaMail.webadm@ew9> <4786D95E.7080809@cox.net> <4786DF6D.1040909@cox.net> Message-ID: On Jan 10, 2008 7:15 PM, Lawson English wrote: > Lawson English wrote: > > gmx0007@gazeta.pl wrote: > >> I checked values in those packet and everything seems OK. > >> Circuit code is little-endian, and UUID big-endian. > >> Use same in UseCircuitCode(work correct) > >> packet as UserInfoRequest(doesn't). > >> Maybe there are some constraints from login proces, > >> which make that SIM doesn't send all packets. > >> > >> What should be fill in channel,mac(MAC or MAC hash?),viewer_digest,.. > ? > >> Is there any connection between those fileds and behaviour on sim ? > >> > > What little you see in the webpages is what I (or someone else, such > > as John Hurliman with libsecondlife) has been able to glean from chats > > with Lindens or by trial and error. > > Well, the stuff found at http://wiki.secondlife.com/wiki/Protocol is > entirely a LInden Lab effort, as far as I know, but its not complete and > is getting more and more obsolete as new login protocols, CAPs, etc are > brought into the picture. > > > You can always look through the page history to see who is working on what on a wiki page. The Protocol page is still a woefully unmaintained skeleton, but it does include a link to the Capabilities and LLSD pages and all of the other "modern" stuff. Those have nothing to do with the binary UDP format though. This page http://wiki.secondlife.com/wiki/Packet_Layout should probably be updated to note what the endianness is of each field. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080110/806f84f5/attachment.htm From lenglish5 at cox.net Thu Jan 10 20:14:25 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 10 20:14:27 2008 Subject: [sldev] SL Protocol In-Reply-To: References: <713955.18431199992900386.JavaMail.webadm@ew9> <4786D95E.7080809@cox.net> <4786DF6D.1040909@cox.net> Message-ID: <4786ED21.1010509@cox.net> John Hurliman wrote: > > > > > You can always look through the page history to see who is working on > what on a wiki page. The Protocol page is still a woefully > unmaintained skeleton, but it does include a link to the Capabilities > and LLSD pages and all of the other "modern" stuff. Those have nothing > to do with the binary UDP format though. This page > http://wiki.secondlife.com/wiki/Packet_Layout should probably be > updated to note what the endianness is of each field. But there's no info on how to use things like EventQueueGet and the packets that are sent as events via this cap. Things will get ever more out-of-synch with the current pages unless the community picks up the slack. Lawson From kamilion at gmail.com Thu Jan 10 22:41:24 2008 From: kamilion at gmail.com (Kamilion) Date: Thu Jan 10 22:41:28 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> Message-ID: Replying to 3 messages (trimmed) here: On Jan 10, 2008 6:13 AM, Argent Stonecutter wrote: > On 2008-01-10, at 02:23, Matthew Dowd wrote: > > vi) One of the issues with the communicate window at the moment is > > tab clutter. This results in the window taking up too much valuable > > screen estate and IMs being overlooked since the flashing tab to > > indicate a new message gets lost amongst all the other tabs! One > > solution, I've proposed is to stack the tabs vertically (http:// > > jira.secondlife.com/browse/VWR-3265), which was generally well > > received although it was suggested this should be optional (and > > I've not had a chance to revisit this). > > I would have to patch the XUI to undo that... again... if that was done. > > I already patch the XUI every time I install SL to get the contacts > tabs on the bottom, as in http://jira.secondlife.com/browse/VWR-1549. > I still don't understand why they rejected that one, it's just nested > tabs and not confusing at all. > > I also make them tear off. That works well _for me_ but without > matching code changes I have to be careful what order I open windows > in, because it's possible to get SL confused and try and render into > a non-existent window, which crashes it. > ---- On Jan 10, 2008 6:45 AM, Matthew Dowd wrote: > > From: secret.argent@gmail.com > > Date: Thu, 10 Jan 2008 08:13:09 -0600 > > On 2008-01-10, at 02:23, Matthew Dowd wrote: > >> vi) One of the issues with the communicate window at the moment is > >> tab clutter. This results in the window taking up too much valuable > >> screen estate and IMs being overlooked since the flashing tab to > >> indicate a new message gets lost amongst all the other tabs! One > >> solution, I've proposed is to stack the tabs vertically (http:// > >> jira.secondlife.com/browse/VWR-3265), which was generally well > >> received although it was suggested this should be optional (and > >> I've not had a chance to revisit this). > > > > I would have to patch the XUI to undo that... again... if that was done. > > No - that was were this suggestion has stalled - probably worth doing but only if the user can > configure whether to have the IM tabs vertical or horizontal, so you wouldn't need an unpatch, > you'd just need to make sure the appropriate checkbox was ticked or unticked (or whatever). > > Matthew Configuration is good. I like the vertical stacks, but it's not something for everyone. I've used a couple IRC clients that can expose a server/channel tree in the same way, but they always have a toggle for the mirc style tabs that SL already uses. However: Upon reading both of these JIRA reports, I realized something. Would this not be much less cluttered if you took VWR-1549's Screenshot-2 as a base, and simply split the tabs logically? Groups tab and group IMs along the upper band Near Me, Friends tab and normal IMs along the bottom band? That would result in a second checkbox: [X] Sort Chat by Message Type _________________________________________________ On Jan 10, 2008 8:04 AM, Hamncheese wrote: > Actually XMPP (jabber) has a different format than most other non-XMPP IM > clients. Make that firstname.lastname@someserver.com/resource and you would > be correct Which lends it self real well to signing into groups because > resource could be the group token that you are signed into. > ----- Original Message ----- > > Your Jabber ID in SL would be something like > > Firstname.Lastname@jabber.secondlife.com, and whether that would hook > > into the rest of the jabber scheme or not is probably outside the scope > > of this list... AFAIK gmail still doesn't, for example. Gmail and Google talk are federated for IM only, not gtalk's SIP/RTP VoIP over XMPP presence. Resources would indeed be able to join IM and group conversations with a participants list on the jabber side. The XMPP protocol, you can consider it a generic message passing through ID architecture. Mainly, XMPP controls presence. A lookup table of endpoints. What messages that pass are layered on in message containers on top of that lookup table. Normally, a jabber server is running at least three resources: Presence, Lookup, and Instant Text Messaging. Everything else that has been layered on, such as file transfer, per-user thumbnail pictures, VoIP, Group Messaging, Group control, has been tacked on top of XMPP's presence and lookup services. They are normally exposed by resources, or in some cases, can be controlled over the Instant Text Messaging message types. The dead simple way of deploying such a large group IM change such as moving over to XMPP, would be to simply duplicate some of the existing behavior of the friends tab -- [X] Group Chat [X] __ Notify when Activity [X] Can see my online status Group chat toggles joining the session on login, Notify on activity will only open the window when a session occurs, and the third will not show you as online in the group roster. Livejournal has a very active XMPP/Jabber system running. Check out http://www.danga.com/djabberd/ Quote: Consider DJabberd the mod_perl/qpsmtpd/Perlbal/Plagger of the XMPP world. Everything is a plugin. The framework lets you override the behavior of: * Authentication * Authorization * Roster Storage * Automatic roster population * Presence lookup * Message delivery * Internode communication * ... * everything else -- Kamilion Schnook From alexander.treptow at zweitgeist.com Fri Jan 11 00:58:53 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Jan 11 00:59:10 2008 Subject: [sldev] Re: movement within the client Message-ID: <47872FCD.9020709@zweitgeist.com> LLVOAvatar *a = gAgent.getAvatarObject(); LLVector3 v = a->getPosition(); v[0] += 0.1f; //move in X if(a) a->setPosition(v); You can use this in the mainloop right before calling the display function. And you can save an offset vector to reset your avatar to a position you want. As far as i know walls or whatever doesnt matter and you can set your avatar to that position you want to. but i think serverside your avatar is still on its old position. that means if you set your avatar from one corner of the region to another .. the objects loaded from the grid refers to your old position. hope this would be a little help ;) greets, Alex Stan Vernier wrote: >>> >>> I'm looking into being able to control the avatar within the client >>> >>> and I'm trying to simulate the teleport script to move the avatar >>> >>> from point a to point b within the same region. I can get the >>> >>> avatar to move from a to b, but the moment I try to move the avatar, >>> >>> it pops back to point a. I tried sendPositionUpdate(), but it >>> >>> didn't work. Anyone got any suggestions? >>> >>> >>> >> >> So I've run into another dilemma with handling movement. I've >> >> figured out the functions to get movement - moveAt, moveUp, Yaw, >> >> Left, Pitch. What I'm stuck on now is how do I create a consistent >> >> movement like "move 10m forwards"? >> > > > > Calculate the destination position, and send motion commands, while > > comparing reported avatar position with calculated destination, until > > you get to where you're going? (Essentially approximating your way to > > the target) > > Of course, you're going to want to implement a pathfinding algorithm > > the instant something solid winds up in the way. > > > I kinda tried that with a while loop with gAgent.moveAt(1) in it, but it just froze the client. I took a look at some of the other code for movement and it seems to only call a move command once and then somewhere down the line the rest of the movement gets dealt with. For the movement floater, it looks like it uses mMoveDownButton->setHeldDownCallback(moveUp). I guess my question is how to do this without holding a button? From gmx0007 at gazeta.pl Fri Jan 11 05:31:55 2008 From: gmx0007 at gazeta.pl (gmx0007@gazeta.pl) Date: Fri Jan 11 05:32:02 2008 Subject: [sldev] SL Protocol Message-ID: <30607192.8761200058315858.JavaMail.webadm@ew6> John Hurliman wrote: > > > > > You can always look through the page history to see who is working on > what on a wiki page. The Protocol page is still a woefully > unmaintained skeleton, but it does include a link to the Capabilities > and LLSD pages and all of the other "modern" stuff. Those have nothing > to do with the binary UDP format though. This page > http://wiki.secondlife.com/wiki/Packet_Layout should probably be > updated to note what the endianness is of each field. >But there's no info on how to use things like EventQueueGet and the >packets that are sent as events via this cap. >Things will get ever more out-of-synch with the current pages >unless the community picks up the slack. >Lawson Isn't sufficient login to SL via rpcxml and next start UDP communications (start with UseCircuitCode) ? Should I use CAP and EventQueueGet to get those responses ? Tom --- Wiadomo?? zosta?a wys?ana z serwisu bezp?atnych kont pocztowych portalu Gazeta.pl. Agora SA nie odpowiada za spos?b wykorzystywania tych kont przez u?ytkownik?w. From secret.argent at gmail.com Fri Jan 11 06:59:24 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 06:59:36 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> Message-ID: > Would this not be much less cluttered if you took VWR-1549's > Screenshot-2 as a base, and simply split the tabs logically? > Groups tab and group IMs along the upper band > Near Me, Friends tab and normal IMs along the bottom band? There are not really two bands, the tabs are nested. When the "Contacts" tab is not selected, you don't have what you're referring to as the second "band" at all. I suppose you could have a separate "groups" tab, with your group chat sessions nested under that. >> Your Jabber ID in SL would be something like >> Firstname.Lastname@jabber.secondlife.com, and whether that would hook >> into the rest of the jabber scheme or not is probably outside the >> scope >> of this list... AFAIK gmail still doesn't, for example. > Gmail and Google talk are federated for IM only, not gtalk's SIP/RTP > VoIP over XMPP presence. [...] I suppose I should not have brought up gmail, because it seems to have caused a certain amount of confusion. All I meant is that there is no reason the user's email address needs to be the Jabber ID that a Jabber-based IM would use, and there are a number of user-expectation and privacy reasons why it shouldn't be. From belxjander at gmail.com Fri Jan 11 07:34:40 2008 From: belxjander at gmail.com (Abh Serechai Belxjander) Date: Fri Jan 11 07:34:37 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> Message-ID: <1200065680.12476.101.camel@localhost> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080112/3a8713b5/attachment.pgp From gmx0007 at gazeta.pl Fri Jan 11 07:43:25 2008 From: gmx0007 at gazeta.pl (gmx0007@gazeta.pl) Date: Fri Jan 11 07:43:27 2008 Subject: [sldev] SL Protocol Message-ID: <32443451.11441200066205269.JavaMail.webadm@ew11> John Hurliman wrote: > > > > > You can always look through the page history to see who is working on > what on a wiki page. The Protocol page is still a woefully > unmaintained skeleton, but it does include a link to the Capabilities > and LLSD pages and all of the other "modern" stuff. Those have nothing > to do with the binary UDP format though. This page > wiki.secondlife.com/wiki/Packet_Layout should probably be > updated to note what the endianness is of each field. >But there's no info on how to use things like EventQueueGet and the >packets that are sent as events via this cap. >Things will get ever more out-of-synch with the current pages >unless the community picks up the slack. >Lawson Isn't sufficient login to SL via rpcxml and next start UDP communications (start with UseCircuitCode) ? Should I use CAP and EventQueueGet to get those responses ? Tom --- Wiadomo?? zosta?a wys?ana z serwisu bezp?atnych kont pocztowych portalu Gazeta.pl. Agora SA nie odpowiada za spos?b wykorzystywania tych kont przez u?ytkownik?w. From matthew.dowd at hotmail.co.uk Fri Jan 11 08:17:14 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jan 11 08:17:16 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1200065680.12476.101.camel@localhost> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <1200065680.12476.101.camel@localhost> Message-ID: > how about also completely breaking the IM subsystem out? > actually have option to use an external IM tool with an SL protocol plugin just for the IM subsystem at the user end? > allow some choice in this matter would that be possible? > > it would also let the IM be dragged off to another monitor and remain closed in-client for the 3D display Or even run a SL IM only client without having to log an avatar presence into SL (current attempts either work through inworld scripted objects, or result in a "dead" avatar presence in world). Matthew _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From secret.argent at gmail.com Fri Jan 11 08:39:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 08:39:55 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <1200065680.12476.101.camel@localhost> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <1200065680.12476.101.camel@localhost> Message-ID: On 2008-01-11, at 09:34, Abh Serechai Belxjander wrote: > as for the layout, why not select "Nearby", "Contacts","Groups" as > 3 tabs, > and have a list on the left... selecting the name in the list can > then show the conversation, That's a slight modification, and would certainly work (with, again, the caveat that I don't want ANYTHING on the left, I want proper nested tabs like you get if you make the change in VWR-1549 and replace "left" with "bottom" in the "my friends" panel). Perhaps the best would be to have, at the top level, "Contacts", "Nearby", "Groups", "Users", and group chat nested under groups, user chat nested under users, and everything but the "Contacts" tab supporting tear-off. That way you could segregate group and user chat, segregate chat windows (wide) from contact windows (tall), and organize things any way you damn please. From tess at lindenlab.com Fri Jan 11 09:07:46 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 09:08:12 2008 Subject: [sldev] Viewer Auth Postponed Message-ID: <4787A262.40302@lindenlab.com> Yesterday afternoon several teams involved with Viewer Auth met to discuss the rising number of critical login issues holding up progress for the release of the 1.18.6 client. The final decision was to postpone Viewer Auth by putting back the old login code. The reasons at the forefront of this decision include: * Internal projects relying on viewer-auth have been delayed. * Problems with web servers serving the login page. * Unknown cause of crashes at startup. * LLMozlib's support of frames has caused numerous bugs. What this means for you: * Second Life client will default to the old login * There is no urgent need to support the new login mechanism in your client. * Existing viewers built with the new login mechanism will continue to function since the server component of the new mechanism will stay in place. In Q1/2008, Studio Icehouse plans to begin work on Agent Domain Login (https://wiki.secondlife.com/wiki/Agent_Domain#How_login_works). When we resume Viewer Auth, it will likely incorporate the interoperability changes from the login protocol work being designed by the Architecture Working Group. Those interested are welcome to participate. From jo_grant at us.ibm.com Fri Jan 11 09:12:38 2008 From: jo_grant at us.ibm.com (Jo Grant/Cambridge/IBM) Date: Fri Jan 11 09:11:39 2008 Subject: [sldev] Re: SL Protocol In-Reply-To: <20080111064132.549F241B5DB@stupor.lindenlab.com> References: <20080111064132.549F241B5DB@stupor.lindenlab.com> Message-ID: Lawson wrote: >Things will get ever more out-of-synch with the current pages unless the >community picks up the slack. I'm very, very keen on seeing a well documented login protocol. I joined this list because I ran into a brick wall trying to implement the protocol in Java. The understanding I got is that there is some vast change immanent in how the protocol works and it wasn't worth embarking on a major project until that was done. I've been skimming subject lines since and I haven't really seen what I thought was a big change in this. I'm sure the answer is in the detailed messages. Forgive me for asking for a summary. What's up? If we write code against what is there at the moment, how quickly can we expect it to go out of date? If we're not shooting at a moving target, I'm more than happy to update the wiki with information gleaned. I did some updates when I was writing my Java code with my discoveries before. Cheers, Jaymin Carthage *************************************** Jo Grant, jo_grant@us.ibm.com http://www-03.ibm.com/developerworks/blogs/page/roivw ISV Developer Enablement Architect, Workplace Technology, 1314, 5 Technology Park Drive, Westford MA 01886 tel: 617-693-6089 SL: Jaymin Carthage -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080111/4f8c3f20/attachment.htm From hud at zurich.ibm.com Thu Jan 10 23:47:53 2008 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Jan 11 09:20:19 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4784A848.9000208@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> Message-ID: <47871F29.8010507@zurich.ibm.com> Dr Scofield wrote: > the new web based authentication scheme uses a web page to capture the > fullname and the password of an avatar and returns a web_login_key > that is passed to the LL SL client via a secondlife:///app/login/... > URI. the LL SL client takes that secondlife:///app/login/... URI and > extracts the web_login_key (and first and last name and other stuff it > seems) and goes to the login service to log the avatar/agent in to the > grid. > > while this works with the LL grid, it does not work with OpenSim > grids, because the LL SL client has no clue that it needs to go to a > different, non-LL grid login service: the latest release clients and > the windlight client do provide the -loginpage which would allow us to > direct the client to a login page of our own, where we could then > generate the secondlife:///app/login/.. URI --- however, that URI does > not include any reference whatsoever to the grid you want to connect > to (well, it does to some extent: there is a 'grid' parameter but that > only knows about LL grids and also does not include ports, resources, etc) > > teravus ousley has described this in much more detail (and probably > better than i have) in VWR-4021 > (https://jira.secondlife.com/browse/VWR-4021). he also tried several > other things (have a look at VWR-4021, if you are interested in the > details) to no avail: we cannot get the latest windlight and RC > clients to connect to OpenSim grids/servers. > > luckily, we had a chance to discuss this with tess linden at > yesterday's AWGroupies meeting. the following two proposals came up: > > (a) use the currently empty host part of the > secondlife:///app/login URI to specify the grid server: that is, > to connect to my 4x4 OpenSim grid running here in the lab, i'd > have the following URI: > > secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=.... > > the LL SL client would simply do a s/^secondlife:/http:/ > substitution and use the resulting URL to login the avatar in. > > (b) recast the currently used grid parameter to always contain the > FQDN of the grid server along with port and resource; that is, for > my lab grid that would be: > > secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... > > here the client would have to parse the URI, extract the grid > parameter, un-quote its value, then construct the login URL and > login the avatar in. > > clearly, approach (a) seems to be the cleanest approach and fits well > with the common URI scheme. however... > > ...during the discussion it transpired that the reason the host part > of the secondlife:/// URI is empty, is that the target of that SLURL > is *not* the grid server but the *client*! in particular, /app/login > signals to the client what it should do: login via a URL that it needs > to construct from the supplied URI. > > ...also, as fword utorid remarked, using the secondlife: URI to > trigger a grid login adds a new semantic to the secondlife: URI --- so > far it has been used as a kind of secondlife GPS location fix: > secondlife://IBM%206/127/104/88 addresses a unique location on the IBM > 6 island, for example. now, secondlife:///app/login?... addresses the > secondlife client and tells it to do a login to a grid. > > the majority of the participants in the discussion did favor approach > (a), but given the way the secondlife:/// URI is currently used, the > most pragmatic approach for the time being seems to be (b). that will > work, but it doesn't really fit well into the "web way of doing > things" --- a better approach would be to have another URI scheme name > allocated for grid login URI, for example, secondlifegrid: > > finally, as was pointed out by neas bade, the login page is not the > only place that we encounter the assumption that the client will only > be used with LL grids --- search, as neas, said is another example. > getting rid of all those silent assumptions (and returning the search > URI as part of the seed caps, for example) is really a necessary next > step if we want to have interoperability! > > so, in summary > > (1) we have a pragmatic (kludgy?) solution proposal to providing > the grid to use via the login page; though, wouldn't it be better > to have a different URI scheme name for grid logins? for example, > > secondlifegrid://grid.server.com:port/resource/login?... > > > (2) we need to get rid of all silent assumptions about the grid > being an LL grid. > during zero's office hours yesterday (at http://slurl.com/secondlife/Grasmere/178/113/27 not secondlife://Grasmere/178/113/27, btw!) we had a chance to discuss the semantics of the secondlife:/// URI scheme with zero: * the assumption that secondlife://Grasmere/178/113/27 addresses a location in the LL grid is actually *wrong* --- according to zero the correct URI for that is http://slurl.com/secondlife/Grasmere/178/113/27 ! * the secondlife: URI scheme name is actually meant to only address the secondlife client and control it, but not to address location in the LL grid based on that context the apparently "kludgy" solution to use secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... actually makes sense: it communicates to the secondlife client to do a login and to use as grid secondlife.zurich.ibm.com:9000. and that is fine, as the secondlife: URI scheme was never intended to address locations within a grid, let alone a grid --- contrary to common conceptions. however, at the end of the discussion we had agreement that for grid interoperability we need to have a way of address locations within grids --- not just the LL grid but *any* grid: * secondlife;//Grasmere/178/113/27 tells the client to go to the 178/113/27 on the Grasmere island on the presently connected grid, how would we tell the client to go to Grasmere on the UK's lake district grid? * http://slurl.com/secondlife/Grasmere/178/113/27 is a bit better, as it would allow to introduce other grid names --- nevertheless, there are a couple of issues with that: o the client (currently) provides no way to input that URL :-( o how do i get my grid registered with slurl.com? why should slurl.com become the gatekeeper? as zero suggested (and fword utorid before him during the discussion at this week's AWGroupies meeting), we in all likelihood need a different URI scheme for that, one that allows us to specify grid and location. the question is, should information such as the login point be included in that new URI scheme or will we get that via an indirection (REST request to the grid name which would have to be a FQDN to retrieve the login URL?) --- i tend towards the later. cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080111/0936c996/attachment.htm From josh at lindenlab.com Fri Jan 11 09:53:52 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jan 11 09:53:56 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787A262.40302@lindenlab.com> References: <4787A262.40302@lindenlab.com> Message-ID: <4787AD30.3000801@lindenlab.com> Obviously this decision has a substantial impact on both the code base (various branches/trunk) and the schedule (1.18.x, 1.19.x, etc). We're going to be meeting today to hash out answers to those. I'll provide details as soon as there are any to share. ("Why is it complicated?" - the integration of the viewer auth work into the viewer code base was a substantial project, and several other projects have merged into the code trunk since then, followed by many iterations for bug fixes. Putting the old login code back in is a non-trivial amount of work itself, and will require its own integration testing with the other features.) Question for the SLDEV community: is there any interest in an interim code drop (of either of the 1.18.6 branch or the 1.19.0 branch) even if those do NOT represent either the direction of the code (i.e. they'll still have the viewer auth code) or what we intend to release? Or should we instead wait and focus our efforts on getting a more representative code drop, even though that may take some time? Tess Chu wrote: > Yesterday afternoon several teams involved with Viewer Auth met to > discuss the rising number of critical login issues holding up progress > for the release of the 1.18.6 client. The final decision was to > postpone Viewer Auth by putting back the old login code. > > The reasons at the forefront of this decision include: > * Internal projects relying on viewer-auth have been delayed. > * Problems with web servers serving the login page. > * Unknown cause of crashes at startup. > * LLMozlib's support of frames has caused numerous bugs. > > What this means for you: > * Second Life client will default to the old login > * There is no urgent need to support the new login mechanism in your > client. > * Existing viewers built with the new login mechanism will continue to > function since the server component of the new mechanism will stay in > place. > > In Q1/2008, Studio Icehouse plans to begin work on Agent Domain Login > (https://wiki.secondlife.com/wiki/Agent_Domain#How_login_works). When > we resume Viewer Auth, it will likely incorporate the interoperability > changes from the login protocol work being designed by the > Architecture Working Group. Those interested are welcome to participate. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From hud at zurich.ibm.com Fri Jan 11 09:57:24 2008 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Jan 11 09:57:01 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787AD30.3000801@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> Message-ID: <4787AE04.4050807@zurich.ibm.com> Joshua Bell wrote: > Obviously this decision has a substantial impact on both the code base > (various branches/trunk) and the schedule (1.18.x, 1.19.x, etc). We're > going to be meeting today to hash out answers to those. I'll provide > details as soon as there are any to share. > > ("Why is it complicated?" - the integration of the viewer auth work > into the viewer code base was a substantial project, and several other > projects have merged into the code trunk since then, followed by many > iterations for bug fixes. Putting the old login code back in is a > non-trivial amount of work itself, and will require its own > integration testing with the other features.) > > Question for the SLDEV community: is there any interest in an interim > code drop (of either of the 1.18.6 branch or the 1.19.0 branch) even > if those do NOT represent either the direction of the code (i.e. > they'll still have the viewer auth code) or what we intend to release? > Or should we instead wait and focus our efforts on getting a more > representative code drop, even though that may take some time? voice for linux would be worth a code drop ;-) cheers, dirk > > Tess Chu wrote: >> Yesterday afternoon several teams involved with Viewer Auth met to >> discuss the rising number of critical login issues holding up >> progress for the release of the 1.18.6 client. The final decision >> was to postpone Viewer Auth by putting back the old login code. >> >> The reasons at the forefront of this decision include: >> * Internal projects relying on viewer-auth have been delayed. >> * Problems with web servers serving the login page. >> * Unknown cause of crashes at startup. >> * LLMozlib's support of frames has caused numerous bugs. >> >> What this means for you: >> * Second Life client will default to the old login >> * There is no urgent need to support the new login mechanism in your >> client. >> * Existing viewers built with the new login mechanism will continue >> to function since the server component of the new mechanism will stay >> in place. >> >> In Q1/2008, Studio Icehouse plans to begin work on Agent Domain Login >> (https://wiki.secondlife.com/wiki/Agent_Domain#How_login_works). >> When we resume Viewer Auth, it will likely incorporate the >> interoperability changes from the login protocol work being designed >> by the Architecture Working Group. Those interested are welcome to >> participate. >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From josh at lindenlab.com Fri Jan 11 09:59:12 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jan 11 09:59:17 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787AE04.4050807@zurich.ibm.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> Message-ID: <4787AE70.4020609@lindenlab.com> dirk husemann wrote: > voice for linux would be worth a code drop ;-) Oh hush. ;) (It's looking like the first-cut of linux voice support should merge into the trunk next week, at which point we can most easily do a source drop.) From robin.cornelius at gmail.com Fri Jan 11 10:08:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jan 11 10:08:35 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787AD30.3000801@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> Message-ID: <4787B09C.9090102@gmail.com> Joshua Bell wrote: > Obviously this decision has a substantial impact on both the code base > (various branches/trunk) and the schedule (1.18.x, 1.19.x, etc). We're > going to be meeting today to hash out answers to those. I'll provide > details as soon as there are any to share. > > ("Why is it complicated?" - the integration of the viewer auth work into > the viewer code base was a substantial project, and several other > projects have merged into the code trunk since then, followed by many > iterations for bug fixes. Putting the old login code back in is a > non-trivial amount of work itself, and will require its own integration > testing with the other features.) From what i have seen its quite possible to have the old and new logins exist side by side. I have already modified lluserauth.cpp to do it both ways by just overloading the function lluserauth::authenticate() to accept either the password or the webkey. (patch was attached to a jira, i did this as an opensim workaround jira is currently stuck so cant give number). Then it should just be a case of dropping back in the old xui login page and the cpp and h file that drove that (with a different (file) name) then a simple branch in llstartup.cpp can select which login to use. Ok its not trival, but is just a case of "doing it" :-) Is it worth having both login systems in the code? with a compile time switch. If things are all backing up it could be a way to keep all the code current with old and new login protocols but with out breaking too many things? Just a random thought 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/20080111/32c7d481/signature.pgp From sean at dague.net Fri Jan 11 10:19:03 2008 From: sean at dague.net (Sean Dague) Date: Fri Jan 11 10:19:08 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <4787AE04.4050807@zurich.ibm.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> Message-ID: <20080111181903.GJ20981@dague.net> On Fri, Jan 11, 2008 at 06:57:24PM +0100, dirk husemann wrote: > Joshua Bell wrote: >> Obviously this decision has a substantial impact on both the code base >> (various branches/trunk) and the schedule (1.18.x, 1.19.x, etc). We're >> going to be meeting today to hash out answers to those. I'll provide >> details as soon as there are any to share. >> >> ("Why is it complicated?" - the integration of the viewer auth work into >> the viewer code base was a substantial project, and several other projects >> have merged into the code trunk since then, followed by many iterations >> for bug fixes. Putting the old login code back in is a non-trivial amount >> of work itself, and will require its own integration testing with the >> other features.) Please make sure that the old login code gets tested with the old -loginuri for alternate grids (i.e. osgrid) as well. It was pulled early in the 1.18.6RCs when new auth went in, and has taken until the last RC to get -loginpage to work with alternate grids (OpenSim currently supports it, btw.) >> Question for the SLDEV community: is there any interest in an interim code >> drop (of either of the 1.18.6 branch or the 1.19.0 branch) even if those >> do NOT represent either the direction of the code (i.e. they'll still have >> the viewer auth code) or what we intend to release? Or should we instead >> wait and focus our efforts on getting a more representative code drop, >> even though that may take some time? > voice for linux would be worth a code drop ;-) +1. Would love voice for Linux to be out there. :) -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080111/5cfdae5c/attachment.pgp From tess at lindenlab.com Fri Jan 11 10:22:59 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 10:23:33 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787B09C.9090102@gmail.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> Message-ID: <4787B403.5080609@lindenlab.com> Robin, We are doing exactly that - a live switch for the XUI code. However, we are also planning to move back the menu bar to after login because we suspect that this change caused the reported client crashes. (VWR-3885). Tess Robin Cornelius wrote: > Joshua Bell wrote: > >> Obviously this decision has a substantial impact on both the code base >> (various branches/trunk) and the schedule (1.18.x, 1.19.x, etc). We're >> going to be meeting today to hash out answers to those. I'll provide >> details as soon as there are any to share. >> >> ("Why is it complicated?" - the integration of the viewer auth work into >> the viewer code base was a substantial project, and several other >> projects have merged into the code trunk since then, followed by many >> iterations for bug fixes. Putting the old login code back in is a >> non-trivial amount of work itself, and will require its own integration >> testing with the other features.) >> > > From what i have seen its quite possible to have the old and new logins > exist side by side. > > I have already modified lluserauth.cpp to do it both ways by just > overloading the function lluserauth::authenticate() to accept either the > password or the webkey. (patch was attached to a jira, i did this as an > opensim workaround jira is currently stuck so cant give number). > > Then it should just be a case of dropping back in the old xui login page > and the cpp and h file that drove that (with a different (file) name) > then a simple branch in llstartup.cpp can select which login to use. > > Ok its not trival, but is just a case of "doing it" :-) > > Is it worth having both login systems in the code? with a compile time > switch. If things are all backing up it could be a way to keep all the > code current with old and new login protocols but with out breaking too > many things? > > Just a random thought > > Robin > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From josh at lindenlab.com Fri Jan 11 10:24:31 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jan 11 10:24:35 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <20080111181903.GJ20981@dague.net> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> Message-ID: <4787B45F.2080806@lindenlab.com> Sean Dague wrote: > Please make sure that the old login code gets tested with the old > -loginuri for alternate grids (i.e. osgrid) as well. It was pulled > early in the 1.18.6RCs when new auth went in, and has taken until the > last RC to get -loginpage to work with alternate grids (OpenSim > currently supports it, btw.) > Will do. We use that internally and I'm not quite sure how we let it get broken, but it was my personal bugaboo for a while. We brought some new internal test grids online while that bug was at the tip of the code base. :( From tess at lindenlab.com Fri Jan 11 10:25:14 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 10:25:41 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <20080111181903.GJ20981@dague.net> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> Message-ID: <4787B48A.5060409@lindenlab.com> > Please make sure that the old login code gets tested with the old > -loginuri for alternate grids (i.e. osgrid) as well. It was pulled > early in the 1.18.6RCs when new auth went in, and has taken until the > last RC to get -loginpage to work with alternate grids (OpenSim > currently supports it, btw.) After we put back the XUI login fields, -loginpage will no longer be necessary for login to OpenSim. You will need to set -loginuri like before, but no other change need to be made. Tess From secret.argent at gmail.com Fri Jan 11 10:46:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 10:46:47 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <47871F29.8010507@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> Message-ID: <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> > the assumption that secondlife://Grasmere/178/113/27 addresses a > location in the LL grid is actually *wrong* --- according to zero > the correct URI for that is http://slurl.com/secondlife/Grasmere/ > 178/113/27 ! Except it isn't. That addresses a location on a map that provides a link to a location in the Second Life grid. The SL client does not understand http://slurl.com, it understands secondlife:// > the secondlife: URI scheme name is actually meant to only address > the secondlife client and control it, but not to address location > in the LL grid I don't think this distinction is really meaningful. The whole context of this discussion is "addressing the secondlife application". The "address" *has to be* something that the SL application can see. And I think it it would be a really bad idea to break either existing links out in the wild, or to deviate from the common internet name syntax (appended, from RFC 1738). That is, if a URL starts with "scheme://" the next part should always allow a hostname. The best solution would be to take advantage of DNS and URL formats. Since the new login code is being postponed, it *is* subject to change, if necessary, because there's no longer any legacy code that isn't going to be modified anyway (when it's revisited) that depends on it. In a previous message I suggested: >> The perfect solution would be for LL to publish a TXT record for >> each of Ahern.grid.secondlife.com, da-boom.grid.secondlife.com, >> and so on. That TXT record would contain the actual host and (as >> an aside) any other data potentially needed to login to their >> grid. The client would simply append ".grid.secondlife.com" to the >> host portion if it's not a FQDN. For other grids, they would have >> their own TXT records published for their own domains, so for them >> you'd log in to secondlife://theirsim.theirdomain.example.com/... There are other approaches that would avoid invalidating existing URLs. For example, overloading the URL 'username' @ 'host' format. secondlife://Grasmere@grid.secondlife.com/... But these all involve a deviation to the common internet name syntax. Using TXT records wouldn't do that, it's a standard way of doing things, AND it's extensible... a TXT record can contain an arbitrary number of name-value pairs up to the limit of packet size, though typically it's intended to be under 100 bytes. So let me elaborate on this... First, the host part of the CINS URL would uniquely encode the location and the grid. The usual TXT record meta-syntax would make it easy to parse out the grid name without dealing with the TXT record lookup if you REALLY needed to: Grasmere._grid.secondlife.com The "local_part . _type{1+} . path" makes "._" a unique separator for the local_part. Secondly, the TXT record returned could contain arbitrary grid-local information in name-value pairs. It should, at the very least, include a "login_server=" string. Third, this would enable smart load balancing. Eg: "login_server=login3.secondlife.zurich.ibm.com". If the host part is not fully qualified, then it would have "._grid.secondlife.com" appended to it, which would allow the legacy scheme to work. This string could be hardcoded in the client or be in the user's XML file. If the path part of the URI doesn't start with "app" then the X, Y, and Z coordinates follow. So the full BNF would be: secondlifeurl = "secondlife://" [ gridspec ] ["/" locpath [ "?" parameters ] ] ; Note: if "hostname" is left out, use "_grid.secondlife.com" gridspec = hostname | regname [ "." hostname ] ; Note: replace "space" with "-" before performing DNS lookup. regname = alpha *[ alpha | digit | space ] locpath = slpath | location [ "/" slpath ] slpath = toplabel "/" *[ hsegment ] location = digits "/" digits "/" digits parameters = parameter | parameters "&" parameter parameter = toplabel "=" unreserved With the remaining definitions taken from RFC1738 section 5. I believe this BNF is unambiguous. ------ 3.1. Common Internet Scheme Syntax While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data: //:@:/ Some or all of the parts ":@", ":", ":", and "/" may be excluded. The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax. The different components obey the following rules: user An optional user name. Some schemes (e.g., ftp) allow the specification of a user name. password An optional password. If present, it follows the user name separated from it by a colon. The user name (and password), if present, are followed by a commercial at-sign "@". Within the user and password field, any ":", "@", or "/" must be encoded. Note that an empty user name or password is different than no user name or password; there is no way to specify a password without specifying a user name. E.g., has an empty user name and no password, has no user name, while has a user name of "foo" and an empty password. host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. port The port number to connect to. Most schemes designate protocols that have a default port number. Another port number may optionally be supplied, in decimal, separated from the host by a colon. If the port is omitted, the colon is as well. url-path The rest of the locator consists of data specific to the scheme, and is known as the "url-path". It supplies the details of how the specified resource can be accessed. Note that the "/" between the host (or port) and the url-path is NOT part of the url-path. The url-path syntax depends on the scheme being used, as does the manner in which it is interpreted. From secret.argent at gmail.com Fri Jan 11 10:49:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 10:49:32 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787AD30.3000801@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> Message-ID: On 2008-01-11, at 11:53, Joshua Bell wrote: > Question for the SLDEV community: is there any interest in an > interim code drop (of either of the 1.18.6 branch or the 1.19.0 > branch) even if those do NOT represent either the direction of the > code (i.e. they'll still have the viewer auth code) or what we > intend to release? Or should we instead wait and focus our efforts > on getting a more representative code drop, even though that may > take some time? I would rather not see a code drop just to get the current to-be- postponed code out there. But if that's the only way to get a snapshot of the *rest* of the code changes (the ones not involved in authentication) out, then go for it. From secret.argent at gmail.com Fri Jan 11 10:53:02 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 10:53:15 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787B09C.9090102@gmail.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> Message-ID: On 2008-01-11, at 12:08, Robin Cornelius wrote: > From what i have seen its quite possible to have the old and new > logins > exist side by side. As several other people have already noted... :) > Is it worth having both login systems in the code? with a compile time > switch. If things are all backing up it could be a way to keep all the > code current with old and new login protocols but with out breaking > too > many things? I think this should be the way forward, with a command line option for the default, regardless of what's going on behind teh scenes. In fact I think the XUI login should remain indefinitely, since (again, as widely discussed) you can use either the new or old login code regardless of whether you're generating the initial login page from XUI or HTML. From secret.argent at gmail.com Fri Jan 11 10:54:05 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 10:54:17 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787B403.5080609@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> <4787B403.5080609@lindenlab.com> Message-ID: On 2008-01-11, at 12:22, Tess Chu wrote: > We are doing exactly that - a live switch for the XUI code. > However, we are also planning to move back the menu bar to after > login because we suspect that this change caused the reported > client crashes. (VWR-3885). Then you need to have some other way to get to Preferences before login. From tess at lindenlab.com Fri Jan 11 10:56:50 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 10:57:16 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> <4787B403.5080609@lindenlab.com> Message-ID: <4787BBF2.2050508@lindenlab.com> > Then you need to have some other way to get to Preferences before login. > The old XUI code will include the entire bottom section of the current release client which has a button to view your Preferences. From kelly at lindenlab.com Fri Jan 11 11:04:29 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Fri Jan 11 11:04:31 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> Message-ID: <4787BDBD.4030708@lindenlab.com> Argent Stonecutter wrote: > On 2008-01-11, at 12:08, Robin Cornelius wrote: >> From what i have seen its quite possible to have the old and new logins >> exist side by side. > > As several other people have already noted... :) > >> Is it worth having both login systems in the code? with a compile time >> switch. If things are all backing up it could be a way to keep all the >> code current with old and new login protocols but with out breaking too >> many things? > > I think this should be the way forward, with a command line option for > the default, regardless of what's going on behind teh scenes. > > In fact I think the XUI login should remain indefinitely, since > (again, as widely discussed) you can use either the new or old login > code regardless of whether you're generating the initial login page > from XUI or HTML. > Just because you can doesn't mean you should. Maintaining this indefinitely would mean more code to maintain which is a Bad Thing. We should strive always to reduce the total amount of code and complexity in the system, that is the only sane path to more stable and more polished code. As an interim solution having both code paths is reasonable, but for the long term there should be one path that really works, whatever that path is. - Kelly From lenglish5 at cox.net Fri Jan 11 11:21:53 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 11 11:21:55 2008 Subject: [sldev] Re: SL Protocol In-Reply-To: References: <20080111064132.549F241B5DB@stupor.lindenlab.com> Message-ID: <4787C1D1.6070509@cox.net> Jo Grant/Cambridge/IBM wrote: > > Lawson wrote: > >Things will get ever more out-of-synch with the current pages unless the > >community picks up the slack. > I'm very, very keen on seeing a well documented login protocol. I > joined this list because I ran into a brick wall trying to implement > the protocol in Java. The understanding I got is that there is some > vast change immanent in how the protocol works and it wasn't worth > embarking on a major project until that was done. I've been skimming > subject lines since and I haven't really seen what I thought was a big > change in this. > I'm sure the answer is in the detailed messages. Forgive me for asking > for a summary. What's up? If we write code against what is there at > the moment, how quickly can we expect it to go out of date? > > If we're not shooting at a moving target, I'm more than happy to > update the wiki with information gleaned. I did some updates when I > was writing my Java code with my discoveries before. > > Cheers, Jo, Zha Ewry (David Levine) of IBM has been testing my protocol docs on the wiki that are basically a description of how I got things to work with Python, by implementing the same thing using Java. You and Zha should get together and compare notes. I'll be happy to put stuff up on the wiki if neither of you do it, but it needs to get done. The Linden budget for creating wiki-based docs is pretty close to non-existent at the moment but if SL is to be come a de facto standard, the docs have to exist, no matter who puts them up. The moving target issue of the protocols is a valid point, but, Zha and I decided that if we don't at least TRY to pin down the current state, even if it changes next week, we'll never understand what the [current] current state is. Since the AWG exists to facilitate getting the protocols ready for the multi-vendor, meta-[second life] grid (and beyond, to the multi-protocol-meta-grid) if the AWG doesn't understand the current protocols, no matter how transitional they are, there's no way to advise on what future protocols might be used to replace them --not without assuming a completely incompatible system is desired, which is definitely NOT the case... ...so, we try to document the protocols-du-jour, knowing full well that they may well change by the time we can get something up on the wiki. Its a losing battle, but the battle has to be fought, even so. Lawson From lenglish5 at cox.net Fri Jan 11 11:25:16 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 11 11:25:18 2008 Subject: [sldev] SL Protocol In-Reply-To: <32443451.11441200066205269.JavaMail.webadm@ew11> References: <32443451.11441200066205269.JavaMail.webadm@ew11> Message-ID: <4787C29C.1020801@cox.net> gmx0007@gazeta.pl wrote: > John Hurliman wrote: > >> >> >> You can always look through the page history to see who is working on >> what on a wiki page. The Protocol page is still a woefully >> unmaintained skeleton, but it does include a link to the Capabilities >> and LLSD pages and all of the other "modern" stuff. Those have nothing >> to do with the binary UDP format though. This page >> wiki.secondlife.com/wiki/Packet_Layout should probably be >> updated to note what the endianness is of each field. >> > > >> But there's no info on how to use things like EventQueueGet and the >> packets that are sent as events via this cap. >> Things will get ever more out-of-synch with the current pages >> unless the community picks up the slack. >> Lawson >> > > Isn't sufficient login to SL via rpcxml and next start UDP > communications (start with UseCircuitCode) ? > Should I use CAP and EventQueueGet to get those responses ? > > Tom > > Some responses are coming in via UDP and some via the EventQueueGet CAP. John understands which far better than I do. I theory, you might still use the UDP, but certain responses (like for starting a group IM session) appear to ONLY come in via CAPs now. Unfortunately, I haven't been able to use SLProxy on a Mac for some time now, and my own Python-based proxy isn't working yet, so I can't help you there. Lawson From lenglish5 at cox.net Fri Jan 11 11:35:09 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 11 11:35:12 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787A262.40302@lindenlab.com> References: <4787A262.40302@lindenlab.com> Message-ID: <4787C4ED.2080108@cox.net> Tess Chu wrote: > Yesterday afternoon several teams involved with Viewer Auth met to > discuss the rising number of critical login issues holding up progress > for the release of the 1.18.6 client. The final decision was to > postpone Viewer Auth by putting back the old login code. > > The reasons at the forefront of this decision include: > * Internal projects relying on viewer-auth have been delayed. > * Problems with web servers serving the login page. > * Unknown cause of crashes at startup. > * LLMozlib's support of frames has caused numerous bugs. > > What this means for you: > * Second Life client will default to the old login > * There is no urgent need to support the new login mechanism in your > client. > * Existing viewers built with the new login mechanism will continue to > function since the server component of the new mechanism will stay in > place. > > In Q1/2008, Studio Icehouse plans to begin work on Agent Domain Login > (https://wiki.secondlife.com/wiki/Agent_Domain#How_login_works). When > we resume Viewer Auth, it will likely incorporate the interoperability > changes from the login protocol work being designed by the > Architecture Working Group. Those interested are welcome to participate. It might be good to create a simple login stub for test purposes. When I was working on my Python-based micro-SLProxy code a few nights ago, I found that the client itself would accept the output from the Python-proxy, but my own Python-based login code would not. I futzed around with that for several hours and it suddenly started working. As far as I can tell, nothing I did actually made a difference: for a while the Python login code was incompatible while the SL Client code was not. Then they both worked. This was during the aftermath of some backend work you guys did on wednesday. Its always possible that I did something without realizing it to make my code work, but I suspect that something was subtly not-kosher on the server end and the Client was robust to handle the issues while the Q&D Python login code was not. So... a reference login server that passes back standardized test data might be a good thing to provide access to so we can test these new protocols without worrying if some strange back-end code issue is causing the problem or if its our own code. Lawson From lenglish5 at cox.net Fri Jan 11 11:41:25 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 11 11:41:27 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <4787B48A.5060409@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> <4787B48A.5060409@lindenlab.com> Message-ID: <4787C665.2090500@cox.net> Tess Chu wrote: > >> Please make sure that the old login code gets tested with the old >> -loginuri for alternate grids (i.e. osgrid) as well. It was pulled >> early in the 1.18.6RCs when new auth went in, and has taken until the >> last RC to get -loginpage to work with alternate grids (OpenSim >> currently supports it, btw.) > After we put back the XUI login fields, -loginpage will no longer be > necessary for login to OpenSim. You will need to set -loginuri like > before, but no other change need to be made. > What about the XML-LLSD login? Is that still operational? I hadn't started working on it, but I am *positive* it will be easier to debug than the xmlrpc code has proved to be. Lawson From tess at lindenlab.com Fri Jan 11 11:45:29 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 11:45:54 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <4787C665.2090500@cox.net> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> <4787B48A.5060409@lindenlab.com> <4787C665.2090500@cox.net> Message-ID: <4787C759.8080507@lindenlab.com> > What about the XML-LLSD login? Is that still operational? I hadn't > started working on it, but I am *positive* it will be easier to debug > than the xmlrpc code has proved to be. > The server portion of the XML-LLSD login is deployed and running live, will not be backed out. The code that handles the login request as well as the login API is identical to before. For the Agent Domain Login project, Icehouse plans to release client for doing Login using XML-LLSD. From lenglish5 at cox.net Fri Jan 11 11:50:48 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 11 11:50:51 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <4787C759.8080507@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> <4787B48A.5060409@lindenlab.com> <4787C665.2090500@cox.net> <4787C759.8080507@lindenlab.com> Message-ID: <4787C898.401@cox.net> Tess Chu wrote: > >> What about the XML-LLSD login? Is that still operational? I hadn't >> started working on it, but I am *positive* it will be easier to debug >> than the xmlrpc code has proved to be. >> > The server portion of the XML-LLSD login is deployed and running live, > will not be backed out. The code that handles the login request as > well as the login API is identical to before. For the Agent Domain > Login project, Icehouse plans to release client for doing Login using > XML-LLSD. > _______________________________________________ So, to clarify, instead of an xmlrpc structure populated with the name/vaue pairs, we POST an xml-LLSD structure with those same name/value pairs and we get back xml-LLSD instead of xmlrpc? I can live with that, trust me. ;-) Lawson From tess at lindenlab.com Fri Jan 11 11:53:04 2008 From: tess at lindenlab.com (Tess Chu) Date: Fri Jan 11 11:53:28 2008 Subject: [sldev] Re: Viewer Auth Postponed In-Reply-To: <4787C898.401@cox.net> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787AE04.4050807@zurich.ibm.com> <20080111181903.GJ20981@dague.net> <4787B48A.5060409@lindenlab.com> <4787C665.2090500@cox.net> <4787C759.8080507@lindenlab.com> <4787C898.401@cox.net> Message-ID: <4787C920.2010601@lindenlab.com> > So, to clarify, instead of an xmlrpc structure populated with the > name/vaue pairs, we POST an xml-LLSD structure with those same > name/value pairs and we get back xml-LLSD instead of xmlrpc? > Correct. From dzonatas at dzonux.net Fri Jan 11 12:07:04 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 11 12:06:48 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <47871F29.8010507@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> Message-ID: <4787CC68.7060605@dzonux.net> dirk husemann wrote: > during zero's office hours yesterday (at > http://slurl.com/secondlife/Grasmere/178/113/27 not > secondlife://Grasmere/178/113/27, btw!) we had a chance to discuss the > semantics of the secondlife:/// URI scheme with zero: > > * the assumption that secondlife://Grasmere/178/113/27 addresses a > location in the LL grid is actually *wrong* --- according to > zero the correct URI for that is > http://slurl.com/secondlife/Grasmere/178/113/27 ! > * the secondlife: URI scheme name is actually meant to only > address the secondlife client and control it, but not to address > location in the LL grid > > based on that context the apparently "kludgy" solution to use > > secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=.... > One suggestion I have not seen here is the use of alternative or paired protocols, for example: metaurl-secondlife://Grasmere/178/113/27 This would be we are defining "metaurl" (or whatever we want to call it, but meta being metaverse) and the 2nd protocol is secondlife. No change is required to the secondlife: url protocol. The metaurl can be used for other means, like: metaurl-opensim://opensim.org/SomeRegion/teleport?x=178&y=113&z=27&web_login_key=ABC or tunnels: metaurl-ssh://totalprogramsim.net/Path/Path/LoginShell P.S. doubt we can use the secondlife: protocol name if it will be trademarked. probably overlooked From hud at zurich.ibm.com Fri Jan 11 13:27:13 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Fri Jan 11 13:26:49 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> Message-ID: <4787DF31.4080901@zurich.ibm.com> Argent Stonecutter wrote: >> the assumption that secondlife://Grasmere/178/113/27 addresses a >> location in the LL grid is actually *wrong* --- according to zero the >> correct URI for that is >> http://slurl.com/secondlife/Grasmere/178/113/27 ! > > Except it isn't. That addresses a location on a map that provides a > link to a location in the Second Life grid. The SL client does not > understand http://slurl.com, it understands secondlife:// that' what i wrote: secondlife: is directed at the client and supposed to control it. it's not meant to address a location on the SL grid. [...] > > And I think it it would be a really bad idea to break either existing > links out in the wild, or to deviate from the common internet name > syntax (appended, from RFC 1738). That is, if a URL starts with > "scheme://" the next part should always allow a hostname. i think we all agree on that. > > The best solution would be to take advantage of DNS and URL formats. > Since the new login code is being postponed, it *is* subject to > change, if necessary, because there's no longer any legacy code that > isn't going to be modified anyway (when it's revisited) that depends > on it. personally, i don't quite like the DNS approach: at first i thought, hey, neat idea --- but coming to think about it, i think it's not really as it requires me to be able to add TXT records to my DNS entries. while i know how to do that and can actually do that, there are situations where that is not the case (joe's garage grid, DNS policies within some companies, etc). i'd propose to instead have one indirection level there: retrieve via REST from the hostname the login server. we can have the DNS solution as well. cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From secret.argent at gmail.com Fri Jan 11 13:28:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 13:28:46 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787BDBD.4030708@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> <4787BDBD.4030708@lindenlab.com> Message-ID: First, let me note that I'm not talking about maintaining the network- level login code indefinitely, just the XUI login page. On 2008-01-11, at 13:04, Kelly Linden wrote: > Just because you can doesn't mean you should. Maintaining this > indefinitely would mean more code to maintain which is a Bad Thing. True, but on the other hand the new login path requires a lot more code than the old login path, because it puts gecko in the critical path for login. Maintaining the XUI login page makes gecko optional. This has a number of advantages. * It reduces the amount of code in the critical path. * It reduces the impact of problems in the very large amount of code associated with gecko. Customers who can't login at all tend to be a lot more upset than customers who can't use search and help and web tabs in profiles. * It allows a greater degree of control over the environment when trying to debug problems. You can eliminate a whole class of problems. * It improves viewer security. If anything, I strongly believe the XUI login page should be retained and the HTML login page eliminated. It's obviously your call and not mine, but I would like you to consider it. From kelly at lindenlab.com Fri Jan 11 13:51:59 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Fri Jan 11 13:52:07 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> <4787BDBD.4030708@lindenlab.com> Message-ID: <4787E4FF.2040408@lindenlab.com> Argent Stonecutter wrote: > First, let me note that I'm not talking about maintaining the > network-level login code indefinitely, just the XUI login page. > > On 2008-01-11, at 13:04, Kelly Linden wrote: >> Just because you can doesn't mean you should. Maintaining this >> indefinitely would mean more code to maintain which is a Bad Thing. > > True, but on the other hand the new login path requires a lot more > code than the old login path, because it puts gecko in the critical > path for login. Maintaining the XUI login page makes gecko optional. > This has a number of advantages. > > * It reduces the amount of code in the critical path. No, it "doubles" it (give or take). The next time there is a bug or new feature or any change that effects the login process it will need to be made in two places instead of one. > > * It reduces the impact of problems in the very large amount of code > associated with gecko. Customers who can't login at all tend to be a > lot more upset than customers who can't use search and help and web > tabs in profiles. I did say it should be one path that *works*. It it might not work then we should not use it. If we can't get the gecko/web version of user login to just work 100% of the time for everyone (give or take a standard margin of error) then we should not use that path at all and the one true path should be XUI. > > * It allows a greater degree of control over the environment when > trying to debug problems. You can eliminate a whole class of problems. I disagree. It approximately squares the complexity of debugging any problem that arises in either path, and in any code *near* those paths. You eliminate a class of problems by eliminating the extra code and only having one path. > > * It improves viewer security. No, every line of code increases the chance of a security problem. Reducing the lines of code and the number of paths possible is probably the single greatest thing we could do to our codebase to increase security. And stability. And reliability. And performance. > > If anything, I strongly believe the XUI login page should be retained > and the HTML login page eliminated. It's obviously your call and not > mine, but I would like you to consider it. I don't necessarily disagree with this, but the HTML login does have its advantages and if it can be made to just work then it could be a viable solution. - Kelly From secret.argent at gmail.com Fri Jan 11 14:14:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 14:14:51 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4787DF31.4080901@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> Message-ID: <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> On 2008-01-11, at 15:27, Dr Scofield wrote: > Argent Stonecutter wrote: >>> the assumption that secondlife://Grasmere/178/113/27 addresses a >>> location in the LL grid is actually *wrong* --- according to zero >>> the correct URI for that is http://slurl.com/secondlife/Grasmere/ >>> 178/113/27 ! >> >> Except it isn't. That addresses a location on a map that provides >> a link to a location in the Second Life grid. The SL client does >> not understand http://slurl.com, it understands secondlife:// > that' what i wrote: secondlife: is directed at the client and > supposed to control it. it's not meant to address a location on the > SL grid. The only component on your computer that can address a location in teh second life grid is an application that communicates to a second life server. The only URL that can address a location in the second life grid is a URL that is handled by an application that communicates with a second life server. An "SLURL" is no more a link to an address on the second life grid than a link to Google Maps is a street address. Also, an SLURL adds an extra and unnecessary trip through HTML in resolving a name, and requires having an HTML parser to get the *real* address out of the page. It's like sending someone your address through a FAX-email gateway because of course everyone has OCR software. Now you could add a "grid:" URL, but that kills legacy secondlife: URLs that people are already using. Doing that without a really good reason is just as unfriendly as changing the way llSetPrimitiveParams () works. >> The best solution would be to take advantage of DNS and URL >> formats. Since the new login code is being postponed, it *is* >> subject to change, if necessary, because there's no longer any >> legacy code that isn't going to be modified anyway (when it's >> revisited) that depends on it. > personally, i don't quite like the DNS approach: at first i > thought, hey, neat idea --- but coming to think about it, i think > it's not really as it requires me to be able to add TXT records to > my DNS entries. while i know how to do that and can actually do > that, there are situations where that is not the case (joe's garage > grid, DNS policies within some companies, etc). i'd propose to > instead have one indirection level there: retrieve via REST from > the hostname the login server. we can have the DNS solution as well. There's always a lot of pushback like this whenever TXT entries come up. 1. This is why they're not supported, because people don't think they should be used, because they're less widely supported. There's enough applications that use TXT records these days that this shouldn't be an issue. 2. I already covered that: >> First, the host part of the CINS URL would uniquely encode the >> location and the grid. The usual TXT record meta-syntax would make >> it easy to parse out the grid name without dealing with the TXT >> record lookup if you REALLY needed to: >> >> Grasmere._grid.secondlife.com >> >> The "local_part . _type{1+} . path" makes "._" a unique separator >> for the local_part. 3. Second alternative, do a query for either TXT or A. If you don't get TXT, use the A record for the server. From dmahalko at gmail.com Fri Jan 11 14:37:20 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jan 11 14:37:23 2008 Subject: [sldev] Dual Screens or Multiple Windows In-Reply-To: <4786DF1D.1050603@dzonux.net> References: <773a33dc0801100921i744d8669y8b57b6717e0dbb1c@mail.gmail.com> <4786DF1D.1050603@dzonux.net> Message-ID: Hack the hacking. Open a separate client window with a similar renderspace to whatever makes the main window function. Then you can put an XML-defined cross-platform UI control in there as the only thing occupying the new window, When the containing window is resized, resize the UI element inside to fit. Hide the UI element's titlebar and use it to set the name of the actual containing titlebar. On Jan 10, 2008 9:14 PM, Dzonatas wrote: > There is already gtk work in the viewer. More of it, even using win32 > compat libs, is an option to allow this kind of feature. From secret.argent at gmail.com Fri Jan 11 14:41:04 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 11 14:41:17 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787E4FF.2040408@lindenlab.com> References: <4787A262.40302@lindenlab.com> <4787AD30.3000801@lindenlab.com> <4787B09C.9090102@gmail.com> <4787BDBD.4030708@lindenlab.com> <4787E4FF.2040408@lindenlab.com> Message-ID: <0718E2F8-BAAC-48DB-BAA7-F3B89C5F6D5E@gmail.com> On 2008-01-11, at 15:51, Kelly Linden wrote: > Argent Stonecutter wrote: >> First, let me note that I'm not talking about maintaining the >> network-level login code indefinitely, just the XUI login page. >> On 2008-01-11, at 13:04, Kelly Linden wrote: >>> Just because you can doesn't mean you should. Maintaining this >>> indefinitely would mean more code to maintain which is a Bad Thing. >> >> True, but on the other hand the new login path requires a lot more >> code than the old login path, because it puts gecko in the >> critical path for login. Maintaining the XUI login page makes >> gecko optional. This has a number of advantages. >> * It reduces the amount of code in the critical path. > No, it "doubles" it (give or take). How do you figure? For the XUI page: XUI is already in the critical path anyway, so the only code this adds to the critical path is the XUI form itself. For the HTML page: gecko is a lot bigger chunk of code than XUI, and the HTML login page is a lot bigger chunk of code than an XUI form... and a lot more complex. Most of the login-specific code will be common to both. On one side you've got gecko doing a fetch of the page, displaying it, doing a form submission, and getting a redirect to either another web page (for an error) or a secondlife: URL for success, which gets passed back to the client via the bindings for secondlife: URLs, and then you go through the common login code. On the other you've got the XUI page being used to generate a form submission, and getting back a redirect to a web page (for an error) or a secondlife: URL for success, and that takes you to the common login code. > The next time there is a bug or new feature or any change that > effects the login process it will need to be made in two places > instead of one. Possibly, depends on the bug or feature. >> * It reduces the impact of problems in the very large amount of >> code associated with gecko. Customers who can't login at all tend >> to be a lot more upset than customers who can't use search and >> help and web tabs in profiles. > I did say it should be one path that *works*. It it might not work > then we should not use it. I made that argument already, about the HTML code. :) Supporting both is a second-best position. So I'll grant your arguments against supporting both, and cut to the chase. The big argument against the HTML page is security. Web browsers are inherently exposed to whole classes of attacks that the SL client can be made immune to. At the moment there are components in the SL client that hurt its security, and the two biggest ones are the HTML rendering engine and streaming video... simply because both are huge chunks of code *and* they (plus streaming audio) are the only parts of the client directly exposed to third-party content. I do not normally enable any streaming media, let alone streaming video, and I don't use the HTML rendering engine for anything but Linden-provided content... and I encourage other people to do the same thing. And there's already been one threatened exploit using the HTML login page... and that *is* supposed to be Linden-provided content. So... >> If anything, I strongly believe the XUI login page should be >> retained and the HTML login page eliminated. It's obviously your >> call and not mine, but I would like you to consider it. > I don't necessarily disagree with this, but the HTML login does > have its advantages and if it can be made to just work then it > could be a viable solution. Even if it can, it shouldn't be, simply from a security perspective. From dzonatas at dzonux.net Fri Jan 11 17:10:40 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 11 17:10:21 2008 Subject: [sldev] Free Wireless for Linden Lab Message-ID: <47881390.5040005@dzonux.net> It appears there is a free wireless service in the area of the Battery Street building and further south. Take a look at the map: http://sf.meraki.com/map From seg at haxxed.com Fri Jan 11 21:07:06 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jan 11 21:07:29 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787A262.40302@lindenlab.com> References: <4787A262.40302@lindenlab.com> Message-ID: <1200114426.3642.132.camel@localhost> On Fri, 2008-01-11 at 09:07 -0800, Tess Chu wrote: > Yesterday afternoon several teams involved with Viewer Auth met to > discuss the rising number of critical login issues holding up progress > for the release of the 1.18.6 client. The final decision was to > postpone Viewer Auth by putting back the old login code. Is it my birthday? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080111/987d7caf/attachment.pgp From hud at zurich.ibm.com Sat Jan 12 08:06:00 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Sat Jan 12 08:05:32 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> Message-ID: <4788E568.1070700@zurich.ibm.com> Argent Stonecutter wrote: > On 2008-01-11, at 15:27, Dr Scofield wrote: >> Argent Stonecutter wrote: >>>> the assumption that secondlife://Grasmere/178/113/27 addresses a >>>> location in the LL grid is actually *wrong* --- according to zero >>>> the correct URI for that is >>>> http://slurl.com/secondlife/Grasmere/178/113/27 ! >>> > >>> Except it isn't. That addresses a location on a map that provides a >>> link to a location in the Second Life grid. The SL client does not >>> understand http://slurl.com, it understands secondlife:// > >> that' what i wrote: secondlife: is directed at the client and >> supposed to control it. it's not meant to address a location on the >> SL grid. > > The only component on your computer that can address a location in teh > second life grid is an application that communicates to a second life > server. > > The only URL that can address a location in the second life grid is a > URL that is handled by an application that communicates with a second > life server. > > An "SLURL" is no more a link to an address on the second life grid > than a link to Google Maps is a street address. > > Also, an SLURL adds an extra and unnecessary trip through HTML in > resolving a name, and requires having an HTML parser to get the *real* > address out of the page. It's like sending someone your address > through a FAX-email gateway because of course everyone has OCR software. > > Now you could add a "grid:" URL, but that kills legacy secondlife: > URLs that people are already using. Doing that without a really good > reason is just as unfriendly as changing the way > llSetPrimitiveParams() works. > >>> The best solution would be to take advantage of DNS and URL formats. >>> Since the new login code is being postponed, it *is* subject to >>> change, if necessary, because there's no longer any legacy code that >>> isn't going to be modified anyway (when it's revisited) that depends >>> on it. > >> personally, i don't quite like the DNS approach: at first i thought, >> hey, neat idea --- but coming to think about it, i think it's not >> really as it requires me to be able to add TXT records to my DNS >> entries. while i know how to do that and can actually do that, there >> are situations where that is not the case (joe's garage grid, DNS >> policies within some companies, etc). i'd propose to instead have one >> indirection level there: retrieve via REST from the hostname the >> login server. we can have the DNS solution as well. > > There's always a lot of pushback like this whenever TXT entries come up. > > 1. This is why they're not supported, because people don't think they > should be used, because they're less widely supported. > > There's enough applications that use TXT records these days that this > shouldn't be an issue. i'm not against TXT, just would like to see the possibility of plain A working as well. > > 2. I already covered that: >>> First, the host part of the CINS URL would uniquely encode the >>> location and the grid. The usual TXT record meta-syntax would make >>> it easy to parse out the grid name without dealing with the TXT >>> record lookup if you REALLY needed to: >>> >>> Grasmere._grid.secondlife.com >>> >>> The "local_part . _type{1+} . path" makes "._" a unique separator >>> for the local_part. > > > 3. Second alternative, do a query for either TXT or A. If you don't > get TXT, use the A record for the server. how about, try A then TXT? isn't SMTP working that way? cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From teravus at gmail.com Sat Jan 12 08:13:29 2008 From: teravus at gmail.com (Teravus Ovares) Date: Sat Jan 12 08:13:36 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4788E568.1070700@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> Message-ID: <34cc66250801120813q32c7dd0g8611c6605cfbc2d4@mail.gmail.com> :D Also, a reiteration, Using the -loginURI and the -loginpage, the current release client and windlight can log into a recent version of OpenSim. Teravus Ousley On 1/12/08, Dr Scofield wrote: > > Argent Stonecutter wrote: > > On 2008-01-11, at 15:27, Dr Scofield wrote: > >> Argent Stonecutter wrote: > >>>> the assumption that secondlife://Grasmere/178/113/27 addresses a > >>>> location in the LL grid is actually *wrong* --- according to zero > >>>> the correct URI for that is > >>>> http://slurl.com/secondlife/Grasmere/178/113/27 ! > >>> > > > >>> Except it isn't. That addresses a location on a map that provides a > >>> link to a location in the Second Life grid. The SL client does not > >>> understand http://slurl.com, it understands secondlife:// > > > >> that' what i wrote: secondlife: is directed at the client and > >> supposed to control it. it's not meant to address a location on the > >> SL grid. > > > > The only component on your computer that can address a location in teh > > second life grid is an application that communicates to a second life > > server. > > > > The only URL that can address a location in the second life grid is a > > URL that is handled by an application that communicates with a second > > life server. > > > > An "SLURL" is no more a link to an address on the second life grid > > than a link to Google Maps is a street address. > > > > Also, an SLURL adds an extra and unnecessary trip through HTML in > > resolving a name, and requires having an HTML parser to get the *real* > > address out of the page. It's like sending someone your address > > through a FAX-email gateway because of course everyone has OCR software. > > > > Now you could add a "grid:" URL, but that kills legacy secondlife: > > URLs that people are already using. Doing that without a really good > > reason is just as unfriendly as changing the way > > llSetPrimitiveParams() works. > > > >>> The best solution would be to take advantage of DNS and URL formats. > >>> Since the new login code is being postponed, it *is* subject to > >>> change, if necessary, because there's no longer any legacy code that > >>> isn't going to be modified anyway (when it's revisited) that depends > >>> on it. > > > >> personally, i don't quite like the DNS approach: at first i thought, > >> hey, neat idea --- but coming to think about it, i think it's not > >> really as it requires me to be able to add TXT records to my DNS > >> entries. while i know how to do that and can actually do that, there > >> are situations where that is not the case (joe's garage grid, DNS > >> policies within some companies, etc). i'd propose to instead have one > >> indirection level there: retrieve via REST from the hostname the > >> login server. we can have the DNS solution as well. > > > > There's always a lot of pushback like this whenever TXT entries come up. > > > > 1. This is why they're not supported, because people don't think they > > should be used, because they're less widely supported. > > > > There's enough applications that use TXT records these days that this > > shouldn't be an issue. > i'm not against TXT, just would like to see the possibility of plain A > working as well. > > > > 2. I already covered that: > >>> First, the host part of the CINS URL would uniquely encode the > >>> location and the grid. The usual TXT record meta-syntax would make > >>> it easy to parse out the grid name without dealing with the TXT > >>> record lookup if you REALLY needed to: > >>> > >>> Grasmere._grid.secondlife.com > >>> > >>> The "local_part . _type{1+} . path" makes "._" a unique separator > >>> for the local_part. > > > > > > 3. Second alternative, do a query for either TXT or A. If you don't > > get TXT, use the A record for the server. > how about, try A then TXT? isn't SMTP working that way? > > cheers, > dr scofield > > -- > dr dirk husemann, pervasive computing, ibm zurich research lab > --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080112/e0697864/attachment.htm From hud at zurich.ibm.com Sat Jan 12 08:20:18 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Sat Jan 12 08:19:51 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <34cc66250801120813q32c7dd0g8611c6605cfbc2d4@mail.gmail.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> <34cc66250801120813q32c7dd0g8611c6605cfbc2d4@mail.gmail.com> Message-ID: <4788E8C2.70307@zurich.ibm.com> Teravus Ovares wrote: > :D Also, a reiteration, > Using the -loginURI and the -loginpage, the current release client > and windlight can log into a recent version of OpenSim. yep, tried that, works :-) excellent work, teravus! would be nice to have just -loginpage working though :-) cheers, dirk > > Teravus Ousley > > On 1/12/08, *Dr Scofield* > wrote: > > Argent Stonecutter wrote: > > On 2008-01-11, at 15:27, Dr Scofield wrote: > >> Argent Stonecutter wrote: > >>>> the assumption that secondlife://Grasmere/178/113/27 addresses a > >>>> location in the LL grid is actually *wrong* --- according to zero > >>>> the correct URI for that is > >>>> http://slurl.com/secondlife/Grasmere/178/113/27 ! > >>> > > > >>> Except it isn't. That addresses a location on a map that > provides a > >>> link to a location in the Second Life grid. The SL client does not > >>> understand http://slurl.com, it understands secondlife:// > > > >> that' what i wrote: secondlife: is directed at the client and > >> supposed to control it. it's not meant to address a location on the > >> SL grid. > > > > The only component on your computer that can address a location > in teh > > second life grid is an application that communicates to a second > life > > server. > > > > The only URL that can address a location in the second life grid > is a > > URL that is handled by an application that communicates with a > second > > life server. > > > > An "SLURL" is no more a link to an address on the second life grid > > than a link to Google Maps is a street address. > > > > Also, an SLURL adds an extra and unnecessary trip through HTML in > > resolving a name, and requires having an HTML parser to get the > *real* > > address out of the page. It's like sending someone your address > > through a FAX-email gateway because of course everyone has OCR > software. > > > > Now you could add a "grid:" URL, but that kills legacy secondlife: > > URLs that people are already using. Doing that without a really good > > reason is just as unfriendly as changing the way > > llSetPrimitiveParams() works. > > > >>> The best solution would be to take advantage of DNS and URL > formats. > >>> Since the new login code is being postponed, it *is* subject to > >>> change, if necessary, because there's no longer any legacy > code that > >>> isn't going to be modified anyway (when it's revisited) that > depends > >>> on it. > > > >> personally, i don't quite like the DNS approach: at first i > thought, > >> hey, neat idea --- but coming to think about it, i think it's not > >> really as it requires me to be able to add TXT records to my DNS > >> entries. while i know how to do that and can actually do that, > there > >> are situations where that is not the case (joe's garage grid, DNS > >> policies within some companies, etc). i'd propose to instead > have one > >> indirection level there: retrieve via REST from the hostname the > >> login server. we can have the DNS solution as well. > > > > There's always a lot of pushback like this whenever TXT entries > come up. > > > > 1. This is why they're not supported, because people don't think > they > > should be used, because they're less widely supported. > > > > There's enough applications that use TXT records these days that > this > > shouldn't be an issue. > i'm not against TXT, just would like to see the possibility of plain A > working as well. > > > > 2. I already covered that: > >>> First, the host part of the CINS URL would uniquely encode the > >>> location and the grid. The usual TXT record meta-syntax would make > >>> it easy to parse out the grid name without dealing with the TXT > >>> record lookup if you REALLY needed to: > >>> > >>> Grasmere._grid.secondlife.com > >>> > >>> The "local_part . _type{1+} . path" makes "._" a unique separator > >>> for the local_part. > > > > > > 3. Second alternative, do a query for either TXT or A. If you don't > > get TXT, use the A record for the server. > how about, try A then TXT? isn't SMTP working that way? > > cheers, > dr scofield > > -- > dr dirk husemann, pervasive computing, ibm zurich research lab > --- hud@zurich.ibm.com --- +41 44 724 > 8573 --- SL: dr scofield > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080112/2e59b026/attachment-0001.htm From secret.argent at gmail.com Sat Jan 12 08:34:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 12 08:35:06 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4788E568.1070700@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> Message-ID: On 2008-01-12, at 10:06, Dr Scofield wrote: >> 3. Second alternative, do a query for either TXT or A. If you >> don't get TXT, use the A record for the server. > how about, try A then TXT? isn't SMTP working that way? * "A query for either TXT or A" is a single operation that returns both records, if they exist, in the same packet. There's no ordering. * SMTP uses MX, not TXT. * As an aside, while some broken SMTP implementations use A if they can't find an MX, but they are not supposed to... if there is no MX the mail is *supposed* to bounce. From secret.argent at gmail.com Sat Jan 12 08:36:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 12 08:36:30 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <34cc66250801120813q32c7dd0g8611c6605cfbc2d4@mail.gmail.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> <34cc66250801120813q32c7dd0g8611c6605cfbc2d4@mail.gmail.com> Message-ID: On 2008-01-12, at 10:13, Teravus Ovares wrote: > :D Also, a reiteration, > Using the -loginURI and the -loginpage, the current release client > and windlight can log into a recent version of OpenSim. That's great for debugging, but it doesn't solve the problem of addressing a grid in a command sent to the client. From gigstaggart at gmail.com Sat Jan 12 08:48:42 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jan 12 08:48:45 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> Message-ID: <4788EF6A.9040000@gmail.com> Kamilion wrote: >> Matthew > > Configuration is good. I like the vertical stacks, but it's not > something for everyone. No, not really: http://www106.pair.com/rhp/free-software-ui.html Every configuration option has a non-zero cost. It's not good enough that someone somewhere might want to change it. It's better to do the right thing than to add yet another stupid config option. -Jason From hud at zurich.ibm.com Sat Jan 12 09:21:46 2008 From: hud at zurich.ibm.com (dirk husemann) Date: Sat Jan 12 09:21:19 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> Message-ID: <4788F72A.6010204@zurich.ibm.com> Argent Stonecutter wrote: > > On 2008-01-12, at 10:06, Dr Scofield wrote: >>> 3. Second alternative, do a query for either TXT or A. If you don't >>> get TXT, use the A record for the server. >> how about, try A then TXT? isn't SMTP working that way? > > * "A query for either TXT or A" is a single operation that returns > both records, if they exist, in the same packet. There's no ordering. > * SMTP uses MX, not TXT. > * As an aside, while some broken SMTP implementations use A if they > can't find an MX, but they are not supposed to... if there is no MX > the mail is *supposed* to bounce. nope: RFC 2821, 3.6 Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. and same, 5: The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. MX is given precedence, though. so, i guess by the same reasoning TXT should be given precedence. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080112/6cf85c29/attachment.htm From secret.argent at gmail.com Sat Jan 12 10:35:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 12 10:36:13 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4788EF6A.9040000@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> Message-ID: On 2008-01-12, at 10:48, Jason Giglio wrote: > http://www106.pair.com/rhp/free-software-ui.html There's some good ideas there, but he's also totally wrong in a huge number of ways. I use a Mac. It's what everyone who writes stuff like this is thinking about when they write stuff like this, whether they say it or not, and when they do that they're taking exactly the wrong lesson from the Mac. And Gnome has suffered from it. > Every configuration option has a non-zero cost. If the design is flexible enough, the cost of a configuration option *is* zero. The Mac is full of configuration options. It's missing some in important places, and most of them are hard to get to or even deliberately hidden, but they're there... and the Mac wouldn't be nearly as successful if they weren't there. They're there as a side effect of the way the windowing system works. It's been like this since Finder 0.9, back in 1984. You used to need resource editors to get to the options, but now they're mostly in separate files in plain text. I don't think I know anyone who's used a Mac long term who hasn't got a couple of dozen under-the-table customizations that they totally depend on. Whether they're Applescripts or DAs or resource patches in classic OS, or Applescripts, XML tweaks, preference panes, and modified image files in OS X, your average Mac user has always hacked their Mac. And Apple *pays attention*. If it wasn't for Max Rudberg's themes that let me tone down the jello theme back in the Puma and Jaguar days I'd have gone nuts... and lo and behold, Panther looked like they'd applied a wash of Max's "Aluminum Alloy" theme over the user interface, and Tiger and Leopard have largely done away with the hated "Brushed Aluminum" and replaced it with something that looks like it came from maxthemes.com. Second Life has the XUI files, configuration operations in the XUI files are pretty close to free... because they have to be there anyway, but they're limited. You can make minor changes, but you can't script them, you can add a tear-off for the contacts tab, but you can't add a button to open it. And you can't save them... every time you get an upgrade they go away. The best thing that LL could do *right now* to improve the UI is have it look in your SL application profile for skins/* before looking in the Second Life application/ resource directory. And then *see what people do with it*. And *learn* from it. From secret.argent at gmail.com Sat Jan 12 11:00:14 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 12 11:00:29 2008 Subject: [AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues) In-Reply-To: <4788F72A.6010204@zurich.ibm.com> References: <4784A848.9000208@zurich.ibm.com> <47871F29.8010507@zurich.ibm.com> <4636639F-021E-4A17-9928-4B8CB7AE2625@gmail.com> <4787DF31.4080901@zurich.ibm.com> <4AC58DBE-C45A-4706-B3E9-F859A63294D5@gmail.com> <4788E568.1070700@zurich.ibm.com> <4788F72A.6010204@zurich.ibm.com> Message-ID: On 2008-01-12, at 11:21, dirk husemann wrote: > Argent Stonecutter wrote: >> >> * As an aside, while some broken SMTP implementations use A if >> they can't find an MX, but they are not supposed to... if there is >> no MX the mail is *supposed* to bounce. > nope: RFC 2821, 3.6 Huh. RFC974 said you should only use MX and WKS records, and that if you didn't have any valid RRs you should bounce the mail (with caveats that an "extremely persistent" host might try to connect directly). RFC1123 said that WKS records were deprecated, and that a sending host MUST provide an MX record to enable reverse mail delivery. It's useful to be able to specify that there shouldn't be any mail delivery for a domain name at all, that's what "no MX records" meant. I guess they finally decided to accept the broken behavior. Wonderful. At least they make it an error to use the A if there are any MX records present, so it's not completely broken. It's not that "MX is given precedence", it's that the A is a fallback if the MX is not present. So you'd make a request for TXT or A, and if there is a TXT you should not use the A record even if the information in the TXT record doesn't work. From lenglish5 at cox.net Sat Jan 12 11:17:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 12 11:18:00 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> Message-ID: <47891263.9030803@cox.net> Argent Stonecutter wrote: > > Second Life has the XUI files, configuration operations in the XUI > files are pretty close to free... because they have to be there > anyway, but they're limited. You can make minor changes, but you can't > script them, you can add a tear-off for the contacts tab, but you > can't add a button to open it. And you can't save them... every time > you get an upgrade they go away. The best thing that LL could do > *right now* to improve the UI is have it look in your SL application > profile for skins/* before looking in the Second Life > application/resource directory. > > And then *see what people do with it*. > > And *learn* from it. > And they should keep in mind that "game" interfaces have always been exempted from the Apple Interface Design Guidelines, even in the earliest days and that even for production-oriented apps, a provision was made for logical exceptions to the Guidelines. The paint-palette-like curving trail of choices used by the original Bryce Tools (IIRC) were later copied by many other interfaces, including Apple's, not simply because they looked cool, but because the natural motion of the arm follows that curve. The point being that the immersive goal of an MMORPG (which is what Second LIfe is cloesest to) allows for a different KIND of interface to facilitate that immersion: we don't need the interface to look and act like a LL version of a commercial app's in order for it to be usable--in fact, quite the opposite, in many situations. So whatever options LL provides for, near-term and with some hoped-for complete rewrite of the GUI, should be with an eye not just for customization, but with an eye to facilitate the immersion process, since that is, I believe the overriding goal of Second Life for most people, including builders. Lawson From secret.argent at gmail.com Sat Jan 12 11:30:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 12 11:30:42 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <47891263.9030803@cox.net> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> <47891263.9030803@cox.net> Message-ID: On 2008-01-12, at 13:17, Lawson English wrote: > And they should keep in mind that "game" interfaces have always > been exempted from the Apple Interface Design Guidelines, This has nothing to do with guidelines, or looking like a desktop application or not looking like a desktop application. This has nothing to do with SL being a game (which it is) or a development tool (which it is) or a chat system (which it also is), though it is also a general purpose platform used for a lot of different things and that it wouldn't be nearly as useful if it was designed around being ANY of the above things. It's also worth noting that games are notorious for having lousy user interfaces, and the example you give of a program that breaks the UI guidelines isn't a game. The point that I'm making here is that configuration hooks are something to be encouraged, not attacked as a sign of a bad UI design, because the "best" general purpose UI out there is just loaded with configuration hooks AND they get used. From carjay at gmx.net Sat Jan 12 11:37:09 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Jan 12 11:37:15 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <4785F331.7010308@gmail.com> References: <4785F331.7010308@gmail.com> Message-ID: <478916E5.9010403@gmx.net> Robin Cornelius wrote: > If any one has any ideas on completing the wind noise, from comments > left on the openAL JIRA it appears it may not be too long before we > can look at merging :-) Alright, took a look at it as promised, it does not work because the wind buffers are never associated with the source (which produced an error in the log, maybe your diff was not against the final version you were using?) and also the position of the wind is set somewhere far away from the listener (close to the origin) so once that position is set up you never hear it. Another problem is that the wind generating code is using as input the same buffer that it writes to which produces a surreal reverberating sound. IIRC, in FMOD, the DSP is inserted after the final result of all sources, so the incoming buffer is the final mixdown of all sources (without the internet stream). OpenAL seems not to give access to this final output stage so it will probably be hard to make it work in the same fashion. But think it should be enough to simply play back the wind as it is generated though I get the feeling the sound is still not exactly the same, I will make some comparisons later. Thanks for your and Segs effort, it is great to finally have full open source sound output. :) Regards, Carsten From lenglish5 at cox.net Sat Jan 12 12:20:29 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 12 12:20:32 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> <47891263.9030803@cox.net> Message-ID: <4789210D.3040409@cox.net> Argent Stonecutter wrote: > On 2008-01-12, at 13:17, Lawson English wrote: >> And they should keep in mind that "game" interfaces have always been >> exempted from the Apple Interface Design Guidelines, > > This has nothing to do with guidelines, or looking like a desktop > application or not looking like a desktop application. > > This has nothing to do with SL being a game (which it is) or a > development tool (which it is) or a chat system (which it also is), > though it is also a general purpose platform used for a lot of > different things and that it wouldn't be nearly as useful if it was > designed around being ANY of the above things. It's also worth noting > that games are notorious for having lousy user interfaces, and the > example you give of a program that breaks the UI guidelines isn't a game. > OK, so I'm wrong on all counts, but my point still stands. > The point that I'm making here is that configuration hooks are > something to be encouraged, not attacked as a sign of a bad UI design, > because the "best" general purpose UI out there is just loaded with > configuration hooks AND they get used. > But configuration hooks should be built-into the interface in a rational way. Often, the hooks are hacked in, which makes the application unstable. Lawson From robin.cornelius at gmail.com Sat Jan 12 12:38:52 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jan 12 12:37:09 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478916E5.9010403@gmx.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> Message-ID: <4789255C.7050703@gmail.com> Carsten Juttner wrote: > Robin Cornelius wrote: >> If any one has any ideas on completing the wind noise, from comments >> left on the openAL JIRA it appears it may not be too long before we >> can look at merging :-) > > Alright, took a look at it as promised, it does not work because the > wind buffers are never associated with the source (which produced an > error in the log, maybe your diff was not against the final version > you were using?) and also the position of the wind is set somewhere > far away from the listener (close to the origin) so once that position > is set up you never hear it. Thanks for that. Doh!, i though i had set the buffers to the source, the version i had posted was my most recent effort. Ohh and the source position is a bit embarising too. lol. /me hangs head in coding shame. > > Another problem is that the wind generating code is using as input the > same buffer that it writes to which produces a surreal reverberating > sound. > Yea, i had not really written optimal code here yet, but at least it makes noise! i think a round-robin buffer or a fifio buffer system etc should solve this. > IIRC, in FMOD, the DSP is inserted after the final result of all > sources, so the incoming buffer is the final mixdown of all sources > (without the internet stream). OpenAL seems not to give access to this > final output stage so it will probably be hard to make it work in the > same fashion. > Yea, i noticed that, but what it appears is fmod is doing a callback on about 20ms interval from what i can determine then the calback code mixes in the generated windbuffer. > But think it should be enough to simply play back the wind as it is > generated though I get the feeling the sound is still not exactly the > same, I will make some comparisons later. > We need buffers, updatewind() is called once per frame (from the main loop) so we could do with stacking some buffers up as we might "run out of wind" if we hit a frame rate lag or if our no_buffers*length_sound*framerate < 1 > Thanks for your and Segs effort, it is great to finally have full open > source sound output. :) > Thanks for spotting my mistakes! Robin From dzonatas at dzonux.net Sat Jan 12 13:05:12 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 12 13:05:08 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478916E5.9010403@gmx.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> Message-ID: <47892B88.301@dzonux.net> Carsten Juttner wrote: > Robin Cornelius wrote: >> If any one has any ideas on completing the wind noise, from comments >> left on the openAL JIRA it appears it may not be too long before we >> can look at merging :-) > > Alright, took a look at it as promised, it does not work because the > wind buffers are never associated with the source (which produced an > error in the log, maybe your diff was not against the final version > you were using?) and also the position of the wind is set somewhere > far away from the listener (close to the origin) so once that position > is set up you never hear it. > > Another problem is that the wind generating code is using as input the > same buffer that it writes to which produces a surreal reverberating > sound. It probably would be good to have optional wind sounds than the default that FMOD plays. The constant noise gets irritating after awhile. It is the same noise. It never changes. The wind is useful to tell when the avi is moving. There are times it is hard to tell, and the wind noise makes it obvious. Does Windlight generate wind sounds? =) > > Thanks for your and Segs effort, it is great to finally have full open > source sound output. :) > Yes, now it would be great if OpenAL and other programs would work nicely with ALSA. They all treat sound like the older OSS. From gigstaggart at gmail.com Sun Jan 13 09:42:37 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jan 13 09:42:40 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> Message-ID: <478A4D8D.3030401@gmail.com> Argent Stonecutter wrote: >> Every configuration option has a non-zero cost. > > If the design is flexible enough, the cost of a configuration option > *is* zero. The Mac is full of configuration options. It's missing some This is absolutely wrong, and it shows you didn't even read the essay. -Jason From secret.argent at gmail.com Sun Jan 13 11:59:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jan 13 11:59:09 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <478A4D8D.3030401@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> <478A4D8D.3030401@gmail.com> Message-ID: <8CC8E226-6FF3-4060-8919-F761649BEFC0@gmail.com> On 2008-01-13, at 11:42, Jason Giglio wrote: > This is absolutely wrong, and it shows you didn't even read the essay. I've read that essay multiple times, in different variants. It is always written by people who confuse user interface features with software design. Preference panes are a user interface feature for making the most commonly used configuration options easy to get to for casual users. Configuration options are parts of a software package's API. I've also used Gnome, and other programs written by people who take that shit seriously, so I know what the thinking behind the essay actually leads to. From dzonatas at dzonux.net Sun Jan 13 13:45:12 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jan 13 13:45:02 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <8CC8E226-6FF3-4060-8919-F761649BEFC0@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> <478A4D8D.3030401@gmail.com> <8CC8E226-6FF3-4060-8919-F761649BEFC0@gmail.com> Message-ID: <478A8668.90808@dzonux.net> Argent Stonecutter wrote: > On 2008-01-13, at 11:42, Jason Giglio wrote: >> This is absolutely wrong, and it shows you didn't even read the essay. > > I've read that essay multiple times, in different variants. It is > always written by people who confuse user interface features with > software design. Preference panes are a user interface feature for > making the most commonly used configuration options easy to get to for > casual users. Configuration options are parts of a software package's > API. > > I've also used Gnome, and other programs written by people who take > that shit seriously, so I know what the thinking behind the essay > actually leads to. > I've used Gnome... svg enabled desktop... gahd that is frakin slick!! From carjay at gmx.net Sun Jan 13 18:02:08 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Jan 13 18:02:19 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <47892B88.301@dzonux.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> Message-ID: <478AC2A0.9050504@gmx.net> Dzonatas wrote: > Yes, now it would be great if OpenAL and other programs would work > nicely with ALSA. They all treat sound like the older OSS. Hm, could you elaborate on this a bit? OpenAL has several audio backends including ALSA. I use the dmix plugin-in to be able to open ALSA from several sources and it works fine. But for my personal experience, both of my soundcards (built-in Intel chipset and USB) produced a nasty distortion (as if samples were skipped) when used with OpenAL and the default settings. I had to set a fix rate of 44100 in asound.conf to "fix" this. Regards, Carsten From robin.cornelius at gmail.com Mon Jan 14 00:54:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jan 14 00:54:39 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478AC2A0.9050504@gmx.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> Message-ID: On Jan 14, 2008 2:02 AM, Carsten Juttner wrote: > Dzonatas wrote: > > Yes, now it would be great if OpenAL and other programs would work > > nicely with ALSA. They all treat sound like the older OSS. > > Hm, could you elaborate on this a bit? OpenAL has several audio backends > including ALSA. I use the dmix plugin-in to be able to open ALSA from > several sources and it works fine. We may need some documentation just to point users in the correct direction or give some example configs. > > But for my personal experience, both of my soundcards (built-in Intel > chipset and USB) produced a nasty distortion (as if samples were > skipped) when used with OpenAL and the default settings. I had to set a > fix rate of 44100 in asound.conf to "fix" this. Hm thats interesting. I am getting a transient distortion on the front edge of *some* samples when played normally. Soft had pointed this out too. Sounded a bit like there was a buffer misalignment or possibly an offset wrt audio zero that caused a step function at start of playback. I will test the asound.conf myself to see if thats my issue too. Shouldn't openAL just do the right thing? if i stuff in PCM data at a given frequency and play it? or is this a openAL->hwdriver issue on some chipsets where the chipset *expects* PCM data at 44.1kHz so openAL must know this in advance. Robin From matthew.dowd at hotmail.co.uk Mon Jan 14 06:02:26 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jan 14 06:02:27 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: <4788EF6A.9040000@gmail.com> References: <1199902283.12476.25.camel@localhost> <091DE764-6D74-46DC-9ED9-5B518A424223@gmail.com> <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> Message-ID: The justification for having a choice between vertical and horizontal tabs for IMs is that whilst some prefer having the tabs horizontal this only really works well if you like the IM window wide but short and say sitting at the top (or bottom) of the SL window. However, then it does have the disadvantage of only allowing a few lines of the IM conversation to be visible (and with the new communicate UI only a few groups or friends visible in the My Friends tab). That aside, many prefer this way of working and for this it makes sense for the IM tabs to be horizontal. If you prefer the IM window narrow and tall and placed on the side of the SL window, this does allow you to see more of the conversation and the entries in the My Friends tab but doesn't allow you to see many of the IM tabs (which means you might miss the tab flashing due to new messages). In this aspect it makes more sense for the tabs to stack vertically. So whether tabs stack vertically ot horizontally really depends which aspect of window you prefer working with - and people *will* differ over this preference; neither is "right" or "wrong". There is precedence - quite a lot of software allows you to choose vertical vs horizontal tabs (e.g. editors with multi-tab UIs for multiple documents). Where this stalled was that I didn't want this to be yet another checkbox in the already overwhelming preference dialog box (and LL themselves have expressed concerns over adding new preferences here). So my initial thought was to add a little button (analogous to the minimise, and tear off buttons) in the IM window title bar which flipped the aspect of the IM window from wide/short to narrow/tall - basically my thought was that this button would swap the horizontal and vertical dimensions as well as flip the tabs from vert to hor (and vice versa), so that you could easily switch between the two different modes of working. The sticking point is that the way the tab control has been implemented does not lend itself to dynamically changing the tab aspect after the control has been initialised, and whilst I think I can see how to change this without a complete rewrite of the tab control, it does mean pulling the tab control code apart an re-assembling it, something I haven't had the time to try yet. Matthew P.S. this change would also have to incorporate my initial patch to the tab position of Friends and Groups in the My Friends tab from http://jira.secondlife.com/browse/VWR-1549 ---------------------------------------- > Date: Sat, 12 Jan 2008 11:48:42 -0500 > From: gigstaggart@gmail.com > To: kamilion@gmail.com > Subject: Re: [sldev] Roadmap: 1.19.0 Viewer > CC: sldev@lists.secondlife.com > > Kamilion wrote: >>> Matthew >> >> Configuration is good. I like the vertical stacks, but it's not >> something for everyone. > > No, not really: > http://www106.pair.com/rhp/free-software-ui.html > > Every configuration option has a non-zero cost. It's not good enough > that someone somewhere might want to change it. It's better to do the > right thing than to add yet another stupid config option. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From Anders at Arnholm.se Mon Jan 14 06:31:27 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Mon Jan 14 06:32:14 2008 Subject: [sldev] Roadmap: 1.19.0 Viewer In-Reply-To: References: <47854149.1070409@Arnholm.se> <478546C4.9050802@lindenlab.com> <478556A6.7060409@gmail.com> <23bbb49e0801092318l2bc336bewca479292451212e0@mail.gmail.com> <1199962231.12476.44.camel@localhost> <6BC2CA3A-8400-47AD-B451-2DC0CB838884@gmail.com> <8AA323E106D744E58244F6F0B4ED74C0@DreamStream> <4788EF6A.9040000@gmail.com> Message-ID: <20080114143127.GA803@arnholm.se> On Mon, Jan 14, 2008 at 02:02:26PM +0000, Matthew Dowd wrote: > So whether tabs stack vertically ot horizontally really depends which > aspect of window you prefer working with - and people *will* differ > over this preference; neither is "right" or "wrong". Or the preference that many, many like if getting it as it was before the voice viewer release. Friend listy not in the chatter box, a big nice IM window at the top a small main chat window to the left and the main chat about the same size as the main chat window. /Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080114/c5dd3758/attachment.pgp From dzonatas at dzonux.net Mon Jan 14 08:29:30 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jan 14 08:29:14 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478AC2A0.9050504@gmx.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> Message-ID: <478B8DEA.9090006@dzonux.net> Carsten Juttner wrote: > Hm, could you elaborate on this a bit? OpenAL has several audio > backends including ALSA. I use the dmix plugin-in to be able to open > ALSA from several sources and it works fine. We need to document the best way. I started to look into JACK, but there is little documentation. It's mainly how nicely sound concurrency works between several apps. Some apps, like Gnome, want to use ESD. Skype wants to use some form of /dev/dsp (ESD or OSS). Icedove wants to use /dev/dsp or ALSA. OpenAL I have set to try to use ALSA, aRts, ESD, OSS, or none. Etc... There is no up-to-date how-to on the best way to get these all to work nicely. One app wants steal the sound and another app hangs or crashes. It doesn't all work out of the box. If all other sound drives fail to open, I did get OpenAL to use the null device instead of fail to let slviewer continue to run: ~/.openalrc: (define devices '(alsa native arts esd null)) (define alsa-device "default") (define speaker-num 2) (define sampling-rate 44100) I thought dmix was only needed if the sound card doesn't support a hardware mixer, so I opted to try to figure out JACK, but there is little documentation. From josh at lindenlab.com Mon Jan 14 16:42:24 2008 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jan 14 16:42:58 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 Message-ID: <478C0170.4050808@lindenlab.com> We plan on releasing 1.18.6 RC4 tomorrow including a source code drop. The intent of this is to get non-viewer-auth related fixes out in the hands of RC users. We will NOT be releasing a 1.18.6 final viewer, however. Between the return to XUI-based login UI and the changes we're making to the group chat code (details below), this makes 1.19 a more complicated beast. So please read carefully - I'll try and explain things from a few different angles: relative to previous discussion, relative to previous release, and what the actual execution steps are. Also, I'm writing about just a fraction of what's going on in development at the Lab and focusing just on the viewer-side work coming out shortly. == What's changed since I last posted == Previously we'd posted that 1.19 included three big buckets of viewer-side changes: (1) substantial number of miscellaneous bug fixes, (2) group chat moderation, (3) no longer auto-join group chats. Based on feedback from the SLDEV community we're revising those plans as follows: * Auto-joining group chat will again be the default. This functions for all 1.18.x and 1.19.x viewers. An option will be introduced to not-auto-join chat in the 1.19.1 viewer. * Part of the group chat moderation work requires new roles and messages, which leads to a wrinkle if a user with an updated viewer grants permissions to a user with an older viewer. Therefore we are also staging the deploy of this across the 1.19.0 and 1.19.1 viewer versions. * The "return to XUI-based login" work also needs to be finished and incorporated into the 1.19.0 codebase. * Since we've "unfrozen" the code, we'll probably let another change or two slip in - like Linux voice support. == Tentative roadmap for 1.19 == In 1.19.0, relative to the last production viewer (1.18.5): * ~80 bug fixes (~20 were in 1.18.6) * Preliminary voice support for the Linux viewer (Can I get a "boo-ya!" ?) * Infrastructure changes to enable moderated chat and making joining group chat optional * Updated crash logger (was in 1.18.6) * Age verification viewer side (was in 1.18.6) * Block unsupported versions of Quicktime (was in 1.18.6) We hope to have the server updates pushed out next week (Jan 22nd/23rd), as well as viewer RC0. Which leaves these slated for 1.19.1: * Moderated group chat (text and voice) * Option to not auto-join group chat sessions. (More is expected in 1.19.1 but that's a ways out now.) == Work Items == To pull all of this off, we have the following underway: * Final QA/pushing of 1.18.6 RC4 * QA on the re-implementation of group chat auto-join * Work on a "restore XUI login" branch, plus QA and integration * Work to split up the group chat moderation feature work into 1.19.0 and 1.19.1 phases We expect this all to be in the hands of our QA team in the next day or two, and we'll do a source drop as soon as we're able. From secret.argent at gmail.com Mon Jan 14 17:12:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 14 17:12:33 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: On 2008-01-14, at 18:42, Joshua Bell wrote: > * Age verification viewer side (was in 1.18.6) What do you mean by this? I thought that this was NOT going to be in the final viewer. From ordinal.malaprop at fastmail.fm Mon Jan 14 17:30:50 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Mon Jan 14 17:30:55 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: References: <478C0170.4050808@lindenlab.com> Message-ID: On 15 Jan 2008, at 01:12, Argent Stonecutter wrote: > On 2008-01-14, at 18:42, Joshua Bell wrote: >> * Age verification viewer side (was in 1.18.6) > > What do you mean by this? I thought that this was NOT going to be in > the final viewer. Wait! What? Yes! From rdw at lindenlab.com Mon Jan 14 17:44:54 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jan 14 17:44:54 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: References: <478C0170.4050808@lindenlab.com> Message-ID: <478C1016.3040605@lindenlab.com> Argent Stonecutter wrote: > On 2008-01-14, at 18:42, Joshua Bell wrote: >> * Age verification viewer side (was in 1.18.6) > > What do you mean by this? I thought that this was NOT going to be in the > final viewer. Are you perhaps confusing viewer auth (which was recently announced to not be in 1.19) with age verification (which has had no announcements recently)? -RYaN From josh at lindenlab.com Mon Jan 14 18:06:04 2008 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jan 14 18:06:10 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C1016.3040605@lindenlab.com> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> Message-ID: <478C150C.10709@lindenlab.com> Ryan Williams (Which) wrote: > Argent Stonecutter wrote: > >> On 2008-01-14, at 18:42, Joshua Bell wrote: >> >>> * Age verification viewer side (was in 1.18.6) >>> >> What do you mean by this? I thought that this was NOT going to be in the >> final viewer. >> > > Are you perhaps confusing viewer auth (which was recently announced to > not be in 1.19) with age verification (which has had no announcements > recently)? > To recap what's in the 1.18.6 release notes, and hence is in the trunk code and hence will be in 1.19: * Age Verification: ** The user interface for parcel and estate access has been clarified and improved. ** Added the ability to restrict access to parcels and estates to age verified adults. See an upcoming blog post for more details ** Removed the ability to *ban* access to Residents who have provided payment info or who have used payment info. We continue to support the ability to *allow* access to only those who have provided payment info. There have been a few tweaks along the way, captured in the various 1.18.6 RC iteration notes. From ordinal.malaprop at fastmail.fm Mon Jan 14 18:17:48 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Mon Jan 14 18:17:52 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C150C.10709@lindenlab.com> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> Message-ID: <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> On 15 Jan 2008, at 02:06, Joshua Bell wrote: > * Age Verification: > ** The user interface for parcel and estate access has been > clarified and improved. > ** Added the ability to restrict access to parcels and estates to > age verified adults. See an upcoming blog post for more details Just to be clear. The next release will mean that age verification is active? In that people will be able to set *ahem* "age-verified"-related bans on parcels? From lenglish5 at cox.net Mon Jan 14 18:33:10 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jan 14 18:33:12 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> Message-ID: <478C1B66.5000807@cox.net> ordinal.malaprop@fastmail.fm wrote: > > On 15 Jan 2008, at 02:06, Joshua Bell wrote: > >> * Age Verification: >> ** The user interface for parcel and estate access has been clarified >> and improved. >> ** Added the ability to restrict access to parcels and estates to age >> verified adults. See an upcoming blog post for more details > > Just to be clear. > > The next release will mean that age verification is active? In that > people will be able to set *ahem* "age-verified"-related bans on parcels? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > I'm not age verified and I hate seeing all that "mature" spam in my searches even though I don't check "mature. When will we see "age verified" search results? Lawson (an old fuddy-duddy) From kamilion at gmail.com Mon Jan 14 19:03:10 2008 From: kamilion at gmail.com (Kamilion) Date: Mon Jan 14 19:03:13 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478B8DEA.9090006@dzonux.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> Message-ID: Might I suggest PulseAudio? Most of the large binary distros are or have moved over to it. http://www.pulseaudio.org/ https://blueprints.launchpad.net/ubuntu/+spec/cleanup-audio-jumble https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble FC8's already got it. Ubuntu 8.04 Hardy already has it as well. Summary The idea is to make PulseAudio the default sound system on Ubuntu, replacing the Esound Sound Daemon (esd) and ALSA dmix. PulseAudio is a drop-in replacement for Esound, but adds new features, opening it for many entirely new areas. Rationale Apple managed to standardize on a single powerful sound system (CoreAudio) for MacOSX which makes almost all users happy, ranging from normal day-to-day desktop users to gamers, to professional audio people. We should be able to provide the same on Linux. PulseAudio can currently provide the functionality at least partially, with the only notable exception being pro audio. PulseAudio is a modular sound server, kind of an "application server" for audio. Beyond the obvious sound mixing functionality it offers advanced audio features like "desktop bling", hot-plug support, transparent network audio, hot moving of playback streams between audio devices, separate volume adjustments for all playback or record streams, very low latency, very precise latency estimation (even over the network), a modern zero-copy memory management, a wide range of extension modules, availability for many operating systems, and compatibility with 90% of all currently available audio applications for Linux in one way or another. ------------ Pulse is very modular. VERY modular. It can talk to nearly anything. Takes input/output from ALSA, OSS, Jack, aRts, ESD, RTP, A2DP, OpenAL, dmix. So far the only known application with real problem is the skype linux binaries. Applications can take full advantage of pulse by using libpulse0. An example to split a four-channel "surround" sound card to two virtual stereo cards (the first virtual card doesn't really do anything else than limit all streams to two channels, so it's not essential to have): #hw load-module module-alsa-sink sink_name=alsa_out device=hw:0 channels=4 channel_map=front-left,front-right,rear-left,rear-right #virtual load-module module-remap-sink sink_name=front_stereo master=alsa_out channels=2 master_channel_map=front-left,front-right channel_map=front-left,front-right load-module module-remap-sink sink_name=rear_stereo master=alsa_out channels=2 master_channel_map=rear-left,rear-right channel_map=front-left,front-right I happen to like this example: On my main linux box (nforce2), the onboard audio is connected to my desktop speakers on the front channel, and the stereo in the living room on the back channel. I can have TV playing on the front channel, and play music from my laptop over the network on the back channel to the stereo. It even stays in sync with the speakers on the laptop -- compensation for network lag. The laptop plays shoutcast through Rhythmbox over wifi to it's local pulseaudio daemon, which forwards it over RTP to the main linux box in the living room, and the remote pulseaudio daemon pipes it to the rear channel via ALSA. Channels can be broken apart and recombined. For instance: Split your surround sound's center channel out, and bridge SL's output to it from another computer. And since it's a sink/source system, other computers on the LAN can link in to either the sink or the source directly. Pidgin could also be prodded to provide it's IM ding to the same channels. We all have different incoming IM sounds here -- but they are *all* piped to three rooms of the house. Living room, kitchen, office. No matter where any of us are we are capable of knowing which of us have an IM, a skype call, or *someone*'s SL session. (that last one's the hard part, since it's "dingding!" for everyone...;) PulseAudio will always accept audio, and supports failover. Say you're using SL, and the audio is going to your USB headset. You lean back in your chair, and the usb cable pops out. With pulseaudio, it just pops the stream over to the last device it was on (if it had one) or to the default device (usually onboard audio), or to the network sink (which is ALWAYS available) until you plug the USB cable back in, and then it returns the stream to the USB headset. Without pulse, SL would have crashed when udev removed the device nodes. (it does on windows and linux! Always fmod barfing.) On Jan 14, 2008 8:29 AM, Dzonatas wrote: > Carsten Juttner wrote: > > Hm, could you elaborate on this a bit? OpenAL has several audio > > backends including ALSA. I use the dmix plugin-in to be able to open > > ALSA from several sources and it works fine. > > We need to document the best way. I started to look into JACK, but > there is little documentation. It's mainly how nicely sound concurrency > works between several apps. Some apps, like Gnome, want to use ESD. > Skype wants to use some form of /dev/dsp (ESD or OSS). Icedove wants to > use /dev/dsp or ALSA. OpenAL I have set to try to use ALSA, aRts, ESD, > OSS, or none. Etc... > > There is no up-to-date how-to on the best way to get these all to work > nicely. One app wants steal the sound and another app hangs or crashes. > It doesn't all work out of the box. > > If all other sound drives fail to open, I did get OpenAL to use the null > device instead of fail to let slviewer continue to run: > > ~/.openalrc: > (define devices '(alsa native arts esd null)) > (define alsa-device "default") > (define speaker-num 2) > (define sampling-rate 44100) > > I thought dmix was only needed if the sound card doesn't support a > hardware mixer, so I opted to try to figure out JACK, but there is > little documentation. Yeah, dmix is only *needed* for hwmixerless cards, but it will mix anything you feed it and it's widely installed. From secret.argent at gmail.com Mon Jan 14 20:27:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 14 20:28:02 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C1016.3040605@lindenlab.com> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> Message-ID: On 2008-01-14, at 19:44, Ryan Williams (Which) wrote: > Argent Stonecutter wrote: >> On 2008-01-14, at 18:42, Joshua Bell wrote: >>> * Age verification viewer side (was in 1.18.6) >> >> What do you mean by this? I thought that this was NOT going to be >> in the >> final viewer. > > Are you perhaps confusing viewer auth (which was recently announced to > not be in 1.19) with age verification (which has had no announcements > recently)? No. In the KB it was explicitly stated that there would be no reference to age verification in the viewer. After it showed up in partial form, there was a spirited discussion in the blog and in Jira followed by an announcement that the KB article was correct and there would be no notification of age verification in the viewer. From secret.argent at gmail.com Mon Jan 14 20:42:33 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 14 20:42:36 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C150C.10709@lindenlab.com> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> Message-ID: On 2008-01-14, at 20:06, Joshua Bell wrote: > * Age Verification: > ** The user interface for parcel and estate access has been > clarified and improved. > ** Added the ability to restrict access to parcels and estates to > age verified adults. See an upcoming blog post for more details > ** Removed the ability to *ban* access to Residents who have > provided payment info or who have used payment info. We continue to > support the ability to *allow* access to only those who have > provided payment info. Thank you for the clarification. I was afraid that this was a return of the age verification display in the profile... now if only the payment-info display could be removed as well. From candide.lemay at gmail.com Mon Jan 14 23:43:41 2008 From: candide.lemay at gmail.com (Candide LeMay) Date: Mon Jan 14 23:43:44 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: On Jan 15, 2008 1:42 AM, Joshua Bell wrote: > * Block unsupported versions of Quicktime (was in 1.18.6) Does this mean QT versions before the streaming exploit fix? Is that really necessary? From hud at zurich.ibm.com Tue Jan 15 00:12:03 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Tue Jan 15 00:11:36 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: <478C6AD3.2060203@zurich.ibm.com> Joshua Bell wrote: [...] > ] > * Since we've "unfrozen" the code, we'll probably let another change > or two slip in - like Linux voice support. yeah! hear, hear! :-) > > == Tentative roadmap for 1.19 == > > In 1.19.0, relative to the last production viewer (1.18.5): > > * ~80 bug fixes (~20 were in 1.18.6) > > * Preliminary voice support for the Linux viewer (Can I get a > "boo-ya!" ?) YEAH! HEAR, HEAR! :-D dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From Celierra at gmail.com Tue Jan 15 00:13:21 2008 From: Celierra at gmail.com (Celierra Darling) Date: Tue Jan 15 00:13:23 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: References: <478C0170.4050808@lindenlab.com> Message-ID: On Jan 15, 2008 2:43 AM, Candide LeMay wrote: > Does this mean QT versions before the streaming exploit fix? Is that > really necessary? YES, as there is a proof-of-concept exploit against SL via Quicktime already out there. (see http://www.securityevaluators.com/sl/) Cel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080115/f6da1edf/attachment.htm From tateru.nino at gmail.com Tue Jan 15 00:20:38 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jan 15 00:22:09 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: References: <478C0170.4050808@lindenlab.com> Message-ID: <478C6CD6.6000802@gmail.com> Candide LeMay wrote: > On Jan 15, 2008 1:42 AM, Joshua Bell wrote: > > >> * Block unsupported versions of Quicktime (was in 1.18.6) >> > > Does this mean QT versions before the streaming exploit fix? Is that > really necessary? > I don't know about *necessary* but probably in the public interest. A lot of our users probably are still using the problematic QT versions. -- Tateru Nino http://www.massively.com/ From seg at haxxed.com Tue Jan 15 00:33:08 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jan 15 00:33:24 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478B8DEA.9090006@dzonux.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> Message-ID: <1200385988.11986.7.camel@localhost> On Mon, 2008-01-14 at 08:29 -0800, Dzonatas wrote: > There is no up-to-date how-to on the best way to get these all to work > nicely. One app wants steal the sound and another app hangs or crashes. > It doesn't all work out of the box. This is not a "Second Life" problem. It is the distribution's problem to have OpenAL working. If it doesn't work, file bugs with your distribution. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080115/08814e8a/attachment.pgp From dzonatas at dzonux.net Tue Jan 15 04:47:31 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 15 04:47:09 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <1200385988.11986.7.camel@localhost> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> <1200385988.11986.7.camel@localhost> Message-ID: <478CAB63.20201@dzonux.net> Callum Lerwick wrote: > On Mon, 2008-01-14 at 08:29 -0800, Dzonatas wrote: > >> There is no up-to-date how-to on the best way to get these all to work >> nicely. One app wants steal the sound and another app hangs or crashes. >> It doesn't all work out of the box. >> > > This is not a "Second Life" problem. It is the distribution's problem to > have OpenAL working. If it doesn't work, file bugs with your > distribution. > OpenAL is distributed with SecondLife. There is no other reason for OpenAL to exist on my system. " Dear Distributor, SecondLife currently includes OpenAL. As much as we have tried so far, OpenAL doesn't want to work fully. The developers of SecondLife say it is your problem to get it working. I know they choose to include OpenAL, but they insist it is your problem to make sure SecondLife and OpenAL works correctly on your distribution. blah blah blah" " Um... I don't think that is going to fly. If you look at this from a business stance, you want people hearing whats going on in sound. We want to find a solution. People want to do business. There are other SecondLife developers here. The resources are here. Callum, we aren't even sure if you even tested SecondLife concurrently with all these other applications when you made the patch. Perhaps, there is a little magic being believed it would work. We tested it. This is the report. I understand that you don't want it to be your problem. Perhaps, it works fine for you. Maybe you can share your setup on how you got it working smoothly. In the meantime, when people ask me for a recommendation on what the best system is to run SecondLife. I'll say Windows -- cause I know it works. I've tested it out of the box. I can assure it. It can get business done. From dzonatas at dzonux.net Tue Jan 15 05:11:27 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 15 05:11:05 2008 Subject: [sldev] [VWR] openAL -- PulseAudio In-Reply-To: References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> Message-ID: <478CB0FF.7090602@dzonux.net> Kamilion wrote: > Might I suggest PulseAudio? > Of course, thank you. > Summary > The idea is to make PulseAudio the default sound system on Ubuntu, > replacing the Esound Sound Daemon (esd) and ALSA dmix. PulseAudio is a > drop-in replacement for Esound, but adds new features, opening it for > many entirely new areas. > > Rationale > Apple managed to standardize on a single powerful sound system > (CoreAudio) for MacOSX which makes almost all users happy, ranging > from normal day-to-day desktop users to gamers, to professional audio > people. We should be able to provide the same on Linux. PulseAudio can > currently provide the functionality at least partially, with the only > notable exception being pro audio. [...] This is a interesting solution. I know JACK offers pro audio, but it straight-up recommends a real-time system setup in order to reliably have pro audio. Bottom-line is there is no generic solution for pro audio (not even on Windows). That's fine. It kinda goes out of scope for the current state of SL, but there is some interest being put in the brew. One thing PulseAudio seems to offer diffently from plain JACK is the server. JACKD is more like a mux but has the be run at the same run-level as the JACK clients. If PulseAudio allows a higher run-level then the clients, then it would be very competitive with what Windows currently offers in sound. I'm glad you mentioned CoreAudio as an example. It has merit. =) I've looked for a solution where the 3D audio is also done on the server-side component (or daemon) instead of being in the client app. This is pretty close to allow such to happen. From sean at dague.net Tue Jan 15 05:18:26 2008 From: sean at dague.net (Sean Dague) Date: Tue Jan 15 05:18:42 2008 Subject: [sldev] Re: Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: <20080115131825.GH4180@dague.net> On Mon, Jan 14, 2008 at 04:42:24PM -0800, Joshua Bell wrote: > > == Tentative roadmap for 1.19 == > > In 1.19.0, relative to the last production viewer (1.18.5): > > * ~80 bug fixes (~20 were in 1.18.6) > > * Preliminary voice support for the Linux viewer (Can I get a > "boo-ya!" ?) I'll even give you 2. :) Thanks much for bringing this in for 1.19! -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080115/909630e7/attachment.pgp From dzonatas at dzonux.net Tue Jan 15 05:19:23 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 15 05:19:00 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: <478CB2DB.1020301@dzonux.net> Joshua Bell wrote: > * Preliminary voice support for the Linux viewer (Can I get a > "boo-ya!" ?) Yay! Ra Ra Ra! (Even came from someone who is not an auditory person like me!) From secret.argent at gmail.com Tue Jan 15 06:20:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 15 06:20:33 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C6CD6.6000802@gmail.com> References: <478C0170.4050808@lindenlab.com> <478C6CD6.6000802@gmail.com> Message-ID: <9FB7A3E6-BE7D-415C-8B3E-F58A9C26DCF0@gmail.com> On 2008-01-15, at 02:20, Tateru Nino wrote: > I don't know about *necessary* but probably in the public interest. > A lot of our users probably are still using the problematic QT > versions. Unfortunately there's no fixed quicktime available for Windows 2000. From secret.argent at gmail.com Tue Jan 15 07:33:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 15 07:33:28 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478CB2DB.1020301@dzonux.net> References: <478C0170.4050808@lindenlab.com> <478CB2DB.1020301@dzonux.net> Message-ID: <0CD1525D-4C53-4515-ACF4-2072D2324161@gmail.com> Please don't fix voice for Linux, I was planning on telling people I was on Linux when they nagged me too much about why I wasn't using voice. Only half a smiley here. Maybe only a quarter. From tarariseq at gmail.com Tue Jan 15 08:38:31 2008 From: tarariseq at gmail.com (Tarari) Date: Tue Jan 15 08:38:42 2008 Subject: [sldev] [PATCH]Improving Recording Movie Message-ID: <582da9dd0801150838p6cf49de9qb0c39ec385f2e093@mail.gmail.com> Hello. I improved recording movie for Windows version. Improved version is available at http://tarari.cocolog-nifty.com/blog/ (japanese). http://tarari.cocolog-nifty.com/downloads/slwl_vfw_20080115.zip http://tarari.cocolog-nifty.com/downloads/slwl_libavformat_20080115.zip http://tarari.cocolog-nifty.com/downloads/moviemaker_20080115.patch (patch only) slwl_vfw_20080115.zip and slwl_libavformat_20080115.zip include exe file. slwl_vfw_20080115.zip includes using VFW(Video for Windows) version. slwl_libavformat_20080115.zip includes using libavformat & libavcodec version. When I say why I made a libavformat and libavcodec version, I think it makes easy to transplant for other platform (particularly for Linux). libavformat and libavcodec used by ffmpeg(http://ffmpeg.mplayerhq.hu/). These libraries implement movie encoder from scratch. So I'm not troubled by behavior of codec by limiting it to some codec. And it's multi-platform library. I want to contribute libavformat and libavcodec version to JIRA. Therefore, I have some question. Cannot you have some opinions? 1. Had better It use libavformat and libavcodec? 2. Is not there the one developing on other platforms when it may use libavformat and libavcodec? I do not have the development and testing environment on other platforms. Regards. Tarari Watanabe From hud at zurich.ibm.com Tue Jan 15 09:38:24 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Tue Jan 15 09:38:03 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <4787A262.40302@lindenlab.com> References: <4787A262.40302@lindenlab.com> Message-ID: <478CEF90.8010005@zurich.ibm.com> Tess Chu wrote: > Yesterday afternoon several teams involved with Viewer Auth met to > discuss the rising number of critical login issues holding up progress > for the release of the 1.18.6 client. The final decision was to > postpone Viewer Auth by putting back the old login code. [...] > * Existing viewers built with the new login mechanism will continue to > function since the server component of the new mechanism will stay in > place. just to clarify (just had a discussion around tying viewer auth to internal DB via loginpage), the next release(s) *won't have viewer auth?* cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From tateru.nino at gmail.com Tue Jan 15 09:38:40 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jan 15 09:40:12 2008 Subject: [sldev] Viewer Auth Postponed In-Reply-To: <478CEF90.8010005@zurich.ibm.com> References: <4787A262.40302@lindenlab.com> <478CEF90.8010005@zurich.ibm.com> Message-ID: <478CEFA0.2080803@gmail.com> Dr Scofield wrote: > Tess Chu wrote: >> Yesterday afternoon several teams involved with Viewer Auth met to >> discuss the rising number of critical login issues holding up >> progress for the release of the 1.18.6 client. The final decision >> was to postpone Viewer Auth by putting back the old login code. > [...] >> * Existing viewers built with the new login mechanism will continue >> to function since the server component of the new mechanism will stay >> in place. > just to clarify (just had a discussion around tying viewer auth to > internal DB via loginpage), the next release(s) *won't have viewer auth?* Next release(s) will return to the XUI-based login that is in 1.18.5 and previous. -- Tateru Nino http://www.massively.com/ From seg at haxxed.com Tue Jan 15 13:38:49 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jan 15 13:39:04 2008 Subject: [sldev] [VWR] openAL wind generator WIP In-Reply-To: <478CAB63.20201@dzonux.net> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> <1200385988.11986.7.camel@localhost> <478CAB63.20201@dzonux.net> Message-ID: <1200433129.13276.31.camel@localhost> On Tue, 2008-01-15 at 04:47 -0800, Dzonatas wrote: > Callum Lerwick wrote: > > On Mon, 2008-01-14 at 08:29 -0800, Dzonatas wrote: > > > >> There is no up-to-date how-to on the best way to get these all to work > >> nicely. One app wants steal the sound and another app hangs or crashes. > >> It doesn't all work out of the box. > >> > > > > This is not a "Second Life" problem. It is the distribution's problem to > > have OpenAL working. If it doesn't work, file bugs with your > > distribution. > > > OpenAL is distributed with SecondLife. There is no other reason for > OpenAL to exist on my system. > > " > Dear Distributor, > > SecondLife currently includes OpenAL. As much as we have tried so far, > OpenAL doesn't want to work fully. The developers of SecondLife say it > is your problem to get it working. I know they choose to include OpenAL, > but they insist it is your problem to make sure SecondLife and OpenAL > works correctly on your distribution. blah blah blah" > " > > Um... I don't think that is going to fly. This is how Open Source is supposed to work. If something is not working, you start a dialog with developers and get it fixed. You are not a passive consumer of product. You are part of the process. We already expect OpenGL to be in place and working. Why is OpenAL any different? > If you look at this from a business stance, you want people hearing > whats going on in sound. We want to find a solution. People want to do > business. There are other SecondLife developers here. The resources are > here. We're talking Linux here. From a "business stance" Windows is the only platform that matters. (Note, recent OSX has OpenAL installed and working out of the box. So no problem there.) And Windows will continue to use fmod in the short term. Hopefully in the long term, fmod will be dragged out into the street and shot, and Creative Labs already has windows taken care of: (Scroll to the bottom, Application Deployment) http://www.openal.org/windows_enumeration.html > Callum, we aren't even sure if you even tested SecondLife concurrently > with all these other applications when you made the patch. Perhaps, > there is a little magic being believed it would work. Well thank you for making presumptions about what I'm doing. https://bugzilla.redhat.com/show_bug.cgi?id=420991 https://bugzilla.redhat.com/show_bug.cgi?id=343911 Okay I wasn't the first to catch these, I don't run Rawhide because I have enough problem with my babies being eaten as it is, but I made damn sure the fixes worked right, and I caught some problems with them before they went out. Remember, I am a Fedora maintainer. If OpenAL isn't Just Working out of the box in Fedora, I will personally see to it that it gets fixed. > We tested it. This is the report. I understand that you don't want it to > be your problem. Perhaps, it works fine for you. Maybe you can share > your setup on how you got it working smoothly. Report of what? You haven't said what distribution is not working here. If there is a problem here, it needs to be pushed to the distribution's bug tracker, not hacked around by outside projects. If your distribution of choice is not interested in having OpenAL fully functional out of the box, then your distribution is rubbish. (I've been watching way too much Top Gear lately... :) > In the meantime, when people ask me for a recommendation on what the > best system is to run SecondLife. I'll say Windows -- cause I know it > works. I've tested it out of the box. I can assure it. It can get > business done. I'm not in sales. I am not a salesman. I am not interested in sales or evangelization. The best system will sell itself. And hacks and kludges and workarounds and "how to" documents are not the path to being the best. It should Just Work. You're derailing the thread with bikeshedding, and Fedora for one, already finished building our bikeshed a year ago. Feel free to copy ours. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080115/5776790e/attachment.pgp From robla at lindenlab.com Tue Jan 15 13:43:19 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jan 15 13:43:24 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <582da9dd0801150838p6cf49de9qb0c39ec385f2e093@mail.gmail.com> References: <582da9dd0801150838p6cf49de9qb0c39ec385f2e093@mail.gmail.com> Message-ID: <478D28F7.20705@lindenlab.com> Hi Tarari, This looks really cool. I can't really comment on the specifics of your implementation (especially before you contrute them via JIRA), but it's nice to see you're getting working captures from the system. My understanding is that our current capture code on Windows and Mac is in such a state that most people don't use it (opting for external tools instead). So, we're still figuring out if it makes sense to even support the feature as it exists in the long haul. One problem: video capture done in a way that requires us shipping a video encoder makes licensing extremely complicated for us. Given the many other problems we have to solve right now, I don't anticipate we'll be in a good position to negotiate/provide a video encoder license for any of the popular video formats (such as MPEG-4, which you seem to be using). To make matters worse, FFMPEG has a few GPL-only features associated with it. I'm not sure if you're using those features, but if so, those may inhibit legal distribution of a fully functional product. So, I'm a bit torn as to what to recommend. On one hand, you've clearly done some interesting work, and we want to encourage that. On the other hand, it's not something that we're likely going to be able to support in a serious way, so I don't want to push you to do a lot of work under the assumption that we'll eventually incorporate it. It *might* be worthwhile to figure out what interfaces you need in the viewer to be able to ship this as a separate plugin. I don't think we can make any promises on that front, either, but I'm guessing this may be a little easier to come up with an abstraction for than most parts of our system. Rob On 1/15/08 8:38 AM, Tarari wrote: > Hello. > > I improved recording movie for Windows version. Improved version is > available at http://tarari.cocolog-nifty.com/blog/ (japanese). > http://tarari.cocolog-nifty.com/downloads/slwl_vfw_20080115.zip > http://tarari.cocolog-nifty.com/downloads/slwl_libavformat_20080115.zip > http://tarari.cocolog-nifty.com/downloads/moviemaker_20080115.patch (patch only) > > slwl_vfw_20080115.zip and slwl_libavformat_20080115.zip include exe > file. slwl_vfw_20080115.zip includes using VFW(Video for Windows) > version. slwl_libavformat_20080115.zip includes using libavformat & > libavcodec version. > > When I say why I made a libavformat and libavcodec version, I think it > makes easy to transplant for other platform (particularly for Linux). > libavformat and libavcodec used by > ffmpeg(http://ffmpeg.mplayerhq.hu/). These libraries implement movie > encoder from scratch. So I'm not troubled by behavior of codec by > limiting it to some codec. And it's multi-platform library. > > I want to contribute libavformat and libavcodec version to JIRA. > Therefore, I have some question. Cannot you have some opinions? > > 1. Had better It use libavformat and libavcodec? > > 2. Is not there the one developing on other platforms when it may use > libavformat and libavcodec? I do not have the development and testing > environment on other platforms. > > Regards. > > Tarari Watanabe > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080115/6c44ef10/signature.pgp From tillie at xp2.de Tue Jan 15 14:03:16 2008 From: tillie at xp2.de (Tillie Ariantho) Date: Tue Jan 15 14:03:38 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478D28F7.20705@lindenlab.com> References: <582da9dd0801150838p6cf49de9qb0c39ec385f2e093@mail.gmail.com> <478D28F7.20705@lindenlab.com> Message-ID: <478D2DA4.4080502@xp2.de> Rob Lanphier wrote: > One problem: video capture done in a way that requires us shipping a > video encoder makes licensing extremely complicated for us. Given the > many other problems we have to solve right now, I don't anticipate we'll > be in a good position to negotiate/provide a video encoder license for > any of the popular video formats (such as MPEG-4, which you seem to be > using). Why not adding some kind of plugin support? Remove all recording stuff completely and instead let SL find usable plugins available on the system, similar to how the movie 'viewing' is done. Tillie From warkirby3333 at hotmail.co.uk Tue Jan 15 15:02:19 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Tue Jan 15 15:02:22 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: <20080115200025.9D64541B35E@stupor.lindenlab.com> References: <20080115200025.9D64541B35E@stupor.lindenlab.com> Message-ID: So there are apparently 80 Misc bugfixes in the upcoming release. This is good, but that's far from enough information. I have a list a mile long, of too-longstanding bugs that really need fixed. I'm hoping some of them are in that number. So please, can we get a full list of what those misc bugfixes are? _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From alissa_sabre at yahoo.co.jp Tue Jan 15 15:04:57 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Jan 15 15:05:21 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C0170.4050808@lindenlab.com> <20080115030315.111BC41B275@stupor.lindenlab.com> References: <478C0170.4050808@lindenlab.com> Message-ID: <6x3kJ7uLav5shrkorkzP.alissa_sabre@yahoo.co.jp> Thank you Joshua for announcing this. I have two comments. > * Since we've "unfrozen" the code, we'll probably let another change or > two slip in - like Linux voice support. On the public JIRA, there are several issue reporting against 1.19.0.76838 source. Some of them have patches already. I want as many Linden devs as possible to just glance over them before 1.19.0 source (re)freeze, if not yet. I personally think some big changes (similar to Linux voice support) are not relevant to be integrated into 1.19.0 source tree at this timing, but simple one-line bug fixes are. > * Auto-joining group chat will again be the default. > * The "return to XUI-based login" work also needs to be finished and > incorporated into the 1.19.0 codebase. Honestly speaking, I have no strong opinions on these two issues; I'm not sure at this moment which is better (opt-in vs opt-out of group IM, or XUI based login vs web based login), since they both have pros and cons. However, I do have a concern on the process of the decision. Apparently, these changes are the ones pushed by sldev list and JIRA inputs. It's far better than these voices are just ignored. However, I'm not 100% confortable with the fact that Linden employees opinions expressed on this list has been supportive to Lindens' (past) decision, and I really don't understand why LL (as a company, or a development team, as opposed to each Linden employee) has change its mind suddenly. I believe LL carefully compared pros and cons on the two possibilities, and decided to revert these changes at this moment. I believe it is a good idea to share the intermediate concerns regarding these issues with open soure developers, but the announcement of the decision. # Ah, I admire this move, of course, and I'm never complaining the point you did revert the changes once decided or the point you announced your decision far earlier than the release. I also believe this is a good change to discuss possible alternatives on future login mechanism. Disclosing the early LL idea why it wanted to switch the login process to web based in the beginning, i.e., what were the problems of the XUI based login to be solved, might be a help. (I believe we have never heard of it yet.) > == Tentative roadmap for 1.19 == > == Work Items == And, thank you again for giving these info. earlier than the release/distribution. I like this. I hope more to be coming in the future! Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From dzonatas at dzonux.net Tue Jan 15 15:15:48 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 15 15:15:21 2008 Subject: [sldev] [VWR] openAL -- Linux Audio In-Reply-To: <1200433129.13276.31.camel@localhost> References: <4785F331.7010308@gmail.com> <478916E5.9010403@gmx.net> <47892B88.301@dzonux.net> <478AC2A0.9050504@gmx.net> <478B8DEA.9090006@dzonux.net> <1200385988.11986.7.camel@localhost> <478CAB63.20201@dzonux.net> <1200433129.13276.31.camel@localhost> Message-ID: <478D3EA4.3010303@dzonux.net> Callum Lerwick wrote: > This is how Open Source is supposed to work. If something is not > working, you start a dialog with developers and get it fixed. You are > not a passive consumer of product. You are part of the process. > Ah... now I understand why you came bluntly on your remark about take it to the distributor. Access to products' blueprints and workflows never implied an obligation to the process on how to fix it. I don't deny that the implication is effective, but I don't push such religion upon others. > We already expect OpenGL to be in place and working. Why is OpenAL any > different? > I think you answered your question with the tidbit about Creative Labs. We know there is support for GPUs and audio HW on Windows. That support is the foundation of Windows itself. Microsoft hates to see its own OS to be (para)virtualized because they know the support would become equal across OSs. > We're talking Linux here. From a "business stance" Windows is the only > platform that matters. I disagree. Linux or Windows, we still have to come up with cost of implementation and stability. If that cost includes the chance that a developer has to go astray and fix another project that is out-of-scope of the original project, it makes it harder for that developer to be competitive. > Hopefully in the long term, fmod will be > dragged out into the street and shot > >> Callum, we aren't even sure if you even tested SecondLife concurrently >> with all these other applications when you made the patch. Perhaps, >> there is a little magic being believed it would work. >> > > Well thank you for making presumptions about what I'm doing. > > https://bugzilla.redhat.com/show_bug.cgi?id=420991 > https://bugzilla.redhat.com/show_bug.cgi?id=343911 > Be sure to drag out SDL with FMOD and make the world a bit happier place. > If there is a problem here, it needs to be pushed to the distribution's > bug tracker, not hacked around by outside projects. If your distribution > of choice is not interested in having OpenAL fully functional out of the > box, then your distribution is rubbish. > I think that cleared up we aren't quite on the same page. The distribution itself doesn't matter, as it is all Linux. I was asked to elaborate when I stated I found it to not work nicely and I posted a way to at least let SecondLife to continue to function. Before the elaboration, it was still about SecondLife. The subject should have change, but go ahead and single me out in the crowd as a thread hijacker for not being one who changed the subject when I tried elaborate. (Let me get a gmail account and change my name for anonymous [coward] reputation =) > You're derailing the thread with bikeshedding, and Fedora for one, > already finished building our bikeshed a year ago. Feel free to copy > ours. :) > I work with them all (Apple, Windows, Linux flavors), but alas I don't have the resources to personally house them all. I'm not evangelistical with any particular platform. Reading your bug report, "By default openal does not work with pulseaudio as openal defaults to oss and thus wants exclusive access to the device." I see your issue is similar to what I stated, that apps tend to default to ESD or OSS instead of working nicely with ALSA. =) It doesn't look like an issue just with Fedora, OpenAL, or PulseAudio, as it is more of a global issue. (probably more problematic on the 64bit side too) Take care From secret.argent at gmail.com Tue Jan 15 16:01:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 15 16:01:58 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <6x3kJ7uLav5shrkorkzP.alissa_sabre@yahoo.co.jp> References: <478C0170.4050808@lindenlab.com> <6x3kJ7uLav5shrkorkzP.alissa_sabre@yahoo.co.jp> Message-ID: <6E01BF8B-7845-4EB8-A2F5-CF453B41A78C@gmail.com> On 2008-01-15, at 17:04, Alissa Sabre wrote: > However, I do have a concern on the process of the decision. > Apparently, these changes are the ones pushed by sldev list and JIRA > inputs. It's far better than these voices are just ignored. I suspect that the latter change was far less due to input on this list, nor to the extensive off-list discussions that some of us had with Tess and others, but the complexity of the web-based login code and its effect on the reliability of the login process. From seg at haxxed.com Tue Jan 15 16:03:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jan 15 16:03:43 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478D28F7.20705@lindenlab.com> References: <582da9dd0801150838p6cf49de9qb0c39ec385f2e093@mail.gmail.com> <478D28F7.20705@lindenlab.com> Message-ID: <1200441808.13534.45.camel@localhost> On Tue, 2008-01-15 at 13:43 -0800, Rob Lanphier wrote: > It *might* be worthwhile to figure out what interfaces you need in the > viewer to be able to ship this as a separate plugin. I don't think we > can make any promises on that front, either, but I'm guessing this may > be a little easier to come up with an abstraction for than most parts of > our system. I think its clear. Apparently "LLMedia" is now the glorious future of slviewer. What is called for here, is an "encoder" side to LLMedia, to compliment its current "decode" focus. Then Windows Media, Quicktime, ffmpeg, gstreamer or whatever else can be slotted in as implementations. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080115/5244c18a/attachment.pgp From josh at lindenlab.com Tue Jan 15 16:09:52 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 15 16:09:58 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <6x3kJ7uLav5shrkorkzP.alissa_sabre@yahoo.co.jp> References: <478C0170.4050808@lindenlab.com> <6x3kJ7uLav5shrkorkzP.alissa_sabre@yahoo.co.jp> Message-ID: <478D4B50.3030406@lindenlab.com> Alissa Sabre wrote: > On the public JIRA, there are several issue reporting against > 1.19.0.76838 source. Some of them have patches already. I want as > many Linden devs as possible to just glance over them before 1.19.0 > source (re)freeze, if not yet. I personally think some big changes > (similar to Linux voice support) are not relevant to be integrated > into 1.19.0 source tree at this timing, but simple one-line bug fixes > are. > I'll try and take a peek soon. Of course, the 1.19.0 viewer will go through the usual RC iterations so there is plenty of opportunity for regression fixes. > I'm not 100% confortable with the fact that Linden employees opinions > expressed on this list has been supportive to Lindens' (past) > decision, and I really don't understand why LL (as a company, or a > development team, as opposed to each Linden employee) has change its > mind suddenly. I believe LL carefully compared pros and cons on the > two possibilities, and decided to revert these changes at this moment. > This is a complicated statement and I'm not sure I understand it completely, but let me clarify: * The new web-based login authentication mechanism is still the direction we wish to pursue. However, the current implementation was not "converging" (we were finding as many bugs as we were fixing) on both the viewer and server side. The choices were (1) release as-is, (2) keep iterating, (3) re-implement, (4) postpone and possibly re-implement. We chose #4. Again, this was based on the data that we collected over the RC iterations. * The group chat changes were announced here very early - basically, as soon as 1.19 started to coalesce, and well before most of the people at Linden had a chance to think about the changes. This is a case of the SLDEV community basically having a chance to provide feedback extremely early - IMHO, a good thing! Let this be more evidence that Linden is not a group mind operating according to some sinister master plan, merely a bunch of developers (etc) trapped behind a communication and collaboration barrier we're trying to chip down whilst doing other work. (Sorry, the analogy just popped into my head.) Joshua From josh at lindenlab.com Tue Jan 15 16:19:01 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 15 16:19:28 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: References: <20080115200025.9D64541B35E@stupor.lindenlab.com> Message-ID: <478D4D75.9080102@lindenlab.com> Paul Cook wrote: > So there are apparently 80 Misc bugfixes in the upcoming release. This is good, but that's far from enough information. > I have a list a mile long, of too-longstanding bugs that really need fixed. I'm hoping some of them are in that number. > > So please, can we get a full list of what those misc bugfixes are? We'll try and pull release notes together later this week. Here are the ones with PJIRA keys - we still need to do friendly descriptions of the others and make sure they're all actually in there. New in 1.19.0: VWR-2142: Parcel voice icon doesn't reflect disabled status if voice isn't used VWR-2614: gActiveChannelSpeakerMgr not deleted at end of program in viewer.cpp VWR-1873: Typos in en-us locale file VWR-2502: Add mute button to script notices VWR-2722: Muting an object with pie menu only mutes the prim you select, not entire linkset VWR-250: Preedit (composition) strings are shown poorly when typing Japanese text on Windows VWR-1590: Keyboard changes inventory selection after right-click VWR-356: Move delete to the bottom of context menus, separated by spacer VWR-1137: Inventory names out of sync after renaming via Properties window VWR-1774: Some avatar positions result in no Z-axis arrow when editing attachments VWR-289: URLs for video media streaming need to be URL-encoded or stream doesn't work VWR-2367: Wrong handling of maximum length of Group Notice message VWR-2256: Mac updater directory permission issues VWR-2854: Some sculpted prims render as balls on close zoom, which look fine in older clients VWR-2550: Scuplty vertex coordinates are size/256 meters too small on the positive faces VWR-2421: ATI Radeon HD 2900 XT + Second Life = "Couldn't match GPU to a class","Setting GPU Class to Class0" VWR-2881: Bundled Mesa libs are not GPL compatible VWR-2959: Windows (Visual Studio) solution file refers to a non-existing project "build_all" VWR-412: Object editing arrows hidden but clickable on objects you can't edit. VWR-2617: Adds LLSD support to flex/light/sculpt params for primitives VWR-2867: Eyes rotate unnaturally around their X axis. Clockwise/Counter-Clockwise VWR-1145: Unable To Connect help not available VWR-1350: Color settings do not appear to be applied to LSL default text VWR-1651: Add ability to open a partners profile whilst viewing an avatar's profile VWR-2652: Changes needed to compile viewer against lastest libopenjpeg2000 VWR-2847: Wrong hover text in Japanese UI VWR-2556: Viewer attempts to log in with no password VWR-2410: noise dot appear in chat window when clien running long with chatting. VWR-3088: Unchecking "Automatic Appearance Camera Movement" no longer has any effect VWR-1475: OpenJPEG always uploads single layer lossless images VWR-3206: OpenJPEG svn478 causes slviewer to crash And then these were in 1.18.6: VWR-250: Preedit (composition) strings are shown poorly when typing Japanese text on Windows VWR-1627: Classified metrics are reset to 0 when the ad is updated VWR-1162: Land for sale includes L$1 parcels that are not actually for sale VWR-1125: Clicking Title Bar While Mouselook'd Repositions SL Window VWR-2483: the macviewer.xcodeprj file doesn't create stripped binaries on Deployment or Universal VWR-2404: lossless texture compression on small textures not lossless VWR-3311: Web UI elements' focus rectangle are offset from their displayed position VWR-3558: llLoadURL cannot be muted VWR-3428: Checking a users profile while editing a linked set causes viewer crash VWR-3815: Double-click on login name/password doesn't select VWR-1115: Internal web browser doesn't support any proxy settings. VWR-3814: Track Classified click-through based on detail page vs. side bar VWR-1919: Remove texture UUID information from UI unless full-perm VWR-3703: No wind sound VWR-3501: Create/Edit Gesture window preview button blanks after pressing VWR-4010: New search does not accept non ASCII characters VWR-3748: Builds fail on 1.18.6 RC if not using MOZLIB due to missing #if LL_LIBXUL_ENABLED in 3 places in indra/newview/llpanellogin.cpp From secret.argent at gmail.com Tue Jan 15 16:35:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 15 16:35:07 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: <478D4D75.9080102@lindenlab.com> References: <20080115200025.9D64541B35E@stupor.lindenlab.com> <478D4D75.9080102@lindenlab.com> Message-ID: <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> On 2008-01-15, at 18:19, Joshua Bell wrote: > VWR-2142: Parcel voice icon doesn't reflect disabled status if > voice isn't used Yes! > VWR-356: Move delete to the bottom of context menus, separated by > spacer Yes! > VWR-1774: Some avatar positions result in no Z-axis arrow when > editing attachments Yes! > VWR-2881: Bundled Mesa libs are not GPL compatible What's the fix here? o_O > VWR-2867: Eyes rotate unnaturally around their X axis. Clockwise/ > Counter-Clockwise Yes! > VWR-3088: Unchecking "Automatic Appearance Camera Movement" no > longer has any effect o_O From josh at lindenlab.com Tue Jan 15 16:52:22 2008 From: josh at lindenlab.com (Joshua Bell) Date: Tue Jan 15 16:52:29 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> References: <20080115200025.9D64541B35E@stupor.lindenlab.com> <478D4D75.9080102@lindenlab.com> <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> Message-ID: <478D5546.9060602@lindenlab.com> Argent Stonecutter wrote: > On 2008-01-15, at 18:19, Joshua Bell wrote: >> VWR-2881: Bundled Mesa libs are not GPL compatible > > What's the fix here? o_O Ah, that's the risk of me just doing a copy/paste without a scrub. The full commit note is something like "upgrade headers to Mesa 7.x, part of the work for VWR-2881..." - so this should probably not be included in the full list. > VWR-3088: Unchecking "Automatic Appearance Camera Movement" no longer > has any effect > > o_O Apparently it was broked at some point. From Anders at Arnholm.se Tue Jan 15 22:01:24 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Jan 15 22:03:08 2008 Subject: [sldev] Linden Lab Viewer Release Roadmap - 2007-01-14 In-Reply-To: <478C1B66.5000807@cox.net> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> <478C1B66.5000807@cox.net> Message-ID: <478D9DB4.4070504@Arnholm.se> Lawson English skrev: > I'm not age verified and I hate seeing all that "mature" spam in my > searches even though I don't check "mature. When will we see "age > verified" search results? That will probably not change as this is about following rules, something that don't change just for one more level comes into play and a level that as mature/pg is very vague and have huge different values in different cultures. My mature and pg as Swedish is definitely not the same as yours. Violence is much less tolerated as PG here and Sex is much more.... Such stuff make the additional voluntary adult line... Useless... at best... Age verification as implemented now is a hoax... /Balp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From matthew.dowd at hotmail.co.uk Wed Jan 16 03:57:36 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jan 16 03:57:38 2008 Subject: [sldev] =?windows-1252?q?VWR-2574=3A_Non-default_sound_devices_for_voice?= =?windows-1252?q?_can=92t_be_used_in_Vista?= In-Reply-To: <478D9DB4.4070504@Arnholm.se> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> <478C1B66.5000807@cox.net> <478D9DB4.4070504@Arnholm.se> Message-ID: Just picked this one off the blog comments for the latest RC The blog has: VWR-2574: Non-default sound devices for voice can?t be used in Vista This appears to be a Vista issue not a Second Life issue. In the comments, someone claims that the real cause of the problem is that Vista (and also WinXP 64bit) allow device names longer than 31 characters. The SL Viewer however truncates any device name down to 31 characters (thus windows doesn't recognise the device name passed and drops down to using the default). I've tracked back into Jira but VWR-2574 was closed as a duplicate, whilst the duplicate it is linked to was closed as "Won't fix" with no explanation (last triage 20 Dec - but I can't find the relevant triage minutes). This may need another look if it really is just a mismatch between device name lengths between vista and SL. Matthew _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From matthew.dowd at hotmail.co.uk Wed Jan 16 07:42:04 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jan 16 07:42:06 2008 Subject: [sldev] Musing over possible connection between VWR-3951 and SVC-972 In-Reply-To: References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> <478C1B66.5000807@cox.net> <478D9DB4.4070504@Arnholm.se> Message-ID: In http://jira.secondlife.com/browse/VWR-3951 (now shelved with the other logon screen issues) Periapse notes that the problem (404 errors appearing instead of the logon screen and logon screen stalls) is due to URLs being mangled somewhere on the LL web servers: "The 404s are because of a mangled url. Originally we indicted the load balancer as the source of the mangling (which happens during the redirect to https). Upon closer examination and direct testing we discovered that the mangling happens on the web servers themselves. We are now trying to isolate precisely where it happens." What struck me is that this doesn't sound a millions miles off some other issues in jira, e.g. http://jira.secondlife.com/browse/SVC-972 (logoffs during teleport). In SVC-972, Jake's prognosis is: "Now that does make it interesting, since it sounds like the HTTPS message is being dropped from the sim to the HTTPS forwarding service which sends it on to the client." Now, I don't know the LL web server topology, so I don't know if the same "web servers" are involved here, or if different web servers are involved whether they are running the same software, but from the outside, it does seem plausible that the same problem which causes the URL mangling on the web servers used in the authentication might also be causing similar problems with other communications which happen between the client and the SL services i.e. might be behind the teleport issue above, and perhaps some other issues? Anyone from LL, who knows the system care to comment? Matthew _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com From soft at lindenlab.com Wed Jan 16 08:11:17 2008 From: soft at lindenlab.com (Soft) Date: Wed Jan 16 08:11:20 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm Message-ID: As usual - be encouraged to add items to the agenda for Thursday's open source meeting - see you in Hippotropolis! https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From sldev at free.fr Wed Jan 16 08:46:46 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Jan 16 08:47:50 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> References: <20080115200025.9D64541B35E@stupor.lindenlab.com> <478D4D75.9080102@lindenlab.com> <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> Message-ID: <20080116174646.78026dc7.sldev@free.fr> On Tue, 15 Jan 2008 18:35:03 -0600, Argent Stonecutter wrote: > On 2008-01-15, at 18:19, Joshua Bell wrote: > > VWR-2142: Parcel voice icon doesn't reflect disabled status if > > voice isn't used > > Yes! No... The "fix" is still wrong as far as voice disabled viewers are concerned (parcel voice status is not displayed at all). Here is a patch to actually fix the bug in v1.19.0.0beta (the version which sources are published on the Wiki). I will also post this patch on the JIRA. Henri. -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-v11900-StatusbarParcelVoiceStatus.patch.bz2 Type: application/octet-stream Size: 505 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080116/c9e55b0a/slviewer-v11900-StatusbarParcelVoiceStatus.patch.obj From tarariseq at gmail.com Wed Jan 16 08:47:56 2008 From: tarariseq at gmail.com (Tarari) Date: Wed Jan 16 08:47:59 2008 Subject: [sldev] [PATCH]Improving Recording Movie Message-ID: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> > One problem: video capture done in a way that requires us shipping a > video encoder makes licensing extremely complicated for us. Given the > many other problems we have to solve right now, I don't anticipate we'll > be in a good position to negotiate/provide a video encoder license for > any of the popular video formats (such as MPEG-4, which you seem to be > using). Ah, It's a difficult problem. I also think encoders code should separate from SL. I will look into way to implement it. > To make matters worse, FFMPEG has a few GPL-only features associated > with it. I'm not sure if you're using those features, but if so, those > may inhibit legal distribution of a fully functional product. I don't use GPL-only features. So, I think there is not the problem in this point. Thanks :) Tarari Watanabe From josh at lindenlab.com Wed Jan 16 09:10:53 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jan 16 09:18:30 2008 Subject: [sldev] Musing over possible connection between VWR-3951 and SVC-972 In-Reply-To: References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> <478C1B66.5000807@cox.net> <478D9DB4.4070504@Arnholm.se> Message-ID: <478E3A9D.1080409@lindenlab.com> Matthew Dowd wrote: > Now, I don't know the LL web server topology, so I don't know if the same "web servers" are involved here, or if different web servers are involved whether they are running the same software, but from the outside, it does seem plausible that the same problem which causes the URL mangling on the web servers used in the authentication might also be causing similar problems with other communications which happen between the client and the SL services i.e. might be behind the teleport issue above, and perhaps some other issues? > > Anyone from LL, who knows the system care to comment? > Interesting speculation. IMHO it's unlikely... the HTTP servers are radically different (hardware, server code, libraries, subnets, etc). But worth pondering! I believe Jake has made more progress in tracking down causes (yes, multiple) of the logoff-during-teleport issue. I'll ping him and see if he can comment further. From secret.argent at gmail.com Wed Jan 16 09:19:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 16 09:19:15 2008 Subject: [sldev] RE: 80 Misc bugfixes In-Reply-To: <20080116174646.78026dc7.sldev@free.fr> References: <20080115200025.9D64541B35E@stupor.lindenlab.com> <478D4D75.9080102@lindenlab.com> <2C2B8AAA-7E79-4A35-9ECC-4BD424EE6987@gmail.com> <20080116174646.78026dc7.sldev@free.fr> Message-ID: <40113913-2BE3-411D-A76A-8F4792304B37@gmail.com> On 2008-01-16, at 10:46, Henri Beauchamp wrote: > The "fix" is still wrong as far as voice disabled viewers are > concerned > (parcel voice status is not displayed at all). Oh, cripes. That's all of a part with disabling the "voice dot" for voice- disabled users. It's at LEAST as important for voice-disabled users to know who is voice-enabled (no, we don't need to tell if they're actually talking). (yes, I'm aware this will likely require a server update and a new packet. It's still necessary) From davep at lindenlab.com Wed Jan 16 12:13:13 2008 From: davep at lindenlab.com (Dave Parks) Date: Wed Jan 16 12:13:26 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> References: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> Message-ID: <478E6559.1000104@lindenlab.com> You might have more success shooting for an open source equivalent of fraps. I may be naive, but it seems greater performance can be achieved if the recording app is a separate process. The embedded recorder really is just for recording bugs, and any serious machinimatographer (is that a word?) will already be using an external app for recording. If you make your project a standalone app that can attach to the window of any other app, you'll have a much larger potential user base. Maybe porting your patch to VLC as an added record feature would work. That project is open source and already deals with the minefield that is video format licensing quite well. A quick peek shows VLC has an existing UI for video capture for using video capture devices. Hooking into that should work. Then you'd be able to stream live video, too. If a good, free, cross-platform solution to making quality movies existed outside the viewer, we could point machinimatographers (there it is again!) to that app and remove the recording code from the viewer altogether, making one less feature for us to support. Tarari wrote: >> One problem: video capture done in a way that requires us shipping a >> video encoder makes licensing extremely complicated for us. Given the >> many other problems we have to solve right now, I don't anticipate we'll >> be in a good position to negotiate/provide a video encoder license for >> any of the popular video formats (such as MPEG-4, which you seem to be >> using). >> > Ah, It's a difficult problem. I also think encoders code should > separate from SL. > I will look into way to implement it. > > >> To make matters worse, FFMPEG has a few GPL-only features associated >> with it. I'm not sure if you're using those features, but if so, those >> may inhibit legal distribution of a fully functional product. >> > I don't use GPL-only features. So, I think there is not the problem in > this point. > > Thanks :) > > Tarari Watanabe > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gryc.ueusp at gmail.com Wed Jan 16 12:43:09 2008 From: gryc.ueusp at gmail.com (Gryc Ueusp) Date: Wed Jan 16 12:43:23 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478E6559.1000104@lindenlab.com> References: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> <478E6559.1000104@lindenlab.com> Message-ID: <200801161443.13096.gryc.ueusp@gmail.com> As for open source fraps equivalents, I personally like "recordmydesktop", available on both gnome and kde as "krecordmydesktop" and "gtk-recordmydesktop". I agree with the "provide a streaming interface", then we can just record with VLC or ffmpeg and get on with it. On Wednesday 16 January 2008 2:13:13 pm Dave Parks wrote: > You might have more success shooting for an open source equivalent of > fraps. I may be naive, but it seems greater performance can be achieved > if the recording app is a separate process. The embedded recorder > really is just for recording bugs, and any serious machinimatographer > (is that a word?) will already be using an external app for recording. > If you make your project a standalone app that can attach to the window > of any other app, you'll have a much larger potential user base. Maybe > porting your patch to VLC as an added record feature would work. That > project is open source and already deals with the minefield that is > video format licensing quite well. A quick peek shows VLC has an > existing UI for video capture for using video capture devices. Hooking > into that should work. Then you'd be able to stream live video, too. > > If a good, free, cross-platform solution to making quality movies > existed outside the viewer, we could point machinimatographers (there it > is again!) to that app and remove the recording code from the viewer > altogether, making one less feature for us to support. > > Tarari wrote: > >> One problem: video capture done in a way that requires us shipping a > >> video encoder makes licensing extremely complicated for us. Given the > >> many other problems we have to solve right now, I don't anticipate we'll > >> be in a good position to negotiate/provide a video encoder license for > >> any of the popular video formats (such as MPEG-4, which you seem to be > >> using). > > > > Ah, It's a difficult problem. I also think encoders code should > > separate from SL. > > I will look into way to implement it. > > > >> To make matters worse, FFMPEG has a few GPL-only features associated > >> with it. I'm not sure if you're using those features, but if so, those > >> may inhibit legal distribution of a fully functional product. > > > > I don't use GPL-only features. So, I think there is not the problem in > > this point. > > > > Thanks :) > > > > Tarari Watanabe > > _______________________________________________ > > 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 -- Gryc Ueusp From secret.argent at gmail.com Wed Jan 16 13:29:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 16 13:29:28 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478E6559.1000104@lindenlab.com> References: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> <478E6559.1000104@lindenlab.com> Message-ID: <2CCEA360-BD3B-4A51-91D3-7F8CAD1E63FC@gmail.com> One thing that is hard to do with an external recorder is to record video without scene decorations (user interface, HUDs, etc) while still doing work normally in SL. I know some people like the "SL effect" of that, and "real" machinimatists use a second viewpoint character, it still seems clumsy. Perhaps the best solution would be to investigate the possibility of SL exposing a video capture device, somehow, so that any application that can work with a video capture device can be used... rather than trying to create yet another special purpose video capture app... From monkowsk at watson.ibm.com Wed Jan 16 13:34:49 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jan 16 13:35:24 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478E6559.1000104@lindenlab.com> References: <582da9dd0801160847y71751334k202147e59686b135@mail.gmail.com> <478E6559.1000104@lindenlab.com> Message-ID: <478E7879.20907@watson.ibm.com> Dave Parks wrote: > any serious machinimatographer (is that a word?) No, it's an obsession. :-) See http://wiki.secondlife.com/wiki/Machinimatographers We even have a mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/machinima Mike From rdw at lindenlab.com Wed Jan 16 15:45:33 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Jan 16 15:45:41 2008 Subject: [sldev] Certified HTTP (and Escrow!) Project Update Jan 16 Message-ID: <478E971D.9010005@lindenlab.com> The escrow project rolls along with new (well, revitalized and completed) group membership transaction tests thanks to Chet. We refactored the oplog.persist method to be more readable (IMO, of course). Previously the persist method would insert a DBMaker object as the first argument of the called method. This was problematic because it required wrappers around builtins to discard the DBMaker. E.g.: op.persist(lambda _db: random.random()) The refactored code leaves the method arguments untouched, and provides the inner_handle method as an alternative. If the caller wants to pass in a db handle, it uses inner_handle property, which the callee can use to get a db handle on demand: def foo(handle, arg): handle().cursor().execute(arg) op.persist(foo, op.inner_handle, "select * from sample") I gave a Linden U about the Escrow to a bunch of engineers this morning, and got lots of great questions and feedback. An additional use case that arose is user-initiated cancellation of a transaction (while still in the gather phase). This may not be a "first-gen" feature, though, since you'd really only be able to do that if a transaction was taking a really long time to gather, something that should hopefully be a rare occurrence. For more information, check out our project page: https://wiki.secondlife.com/wiki/Certified_HTTP_Project Or sign up for the mailing list (or just read the archives): https://lists.secondlife.com/cgi-bin/mailman/listinfo/chttpdev -RYaN From me at signpostmarv.name Wed Jan 16 16:14:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Jan 16 16:14:12 2008 Subject: [sldev] Open development of the Webmap API Message-ID: <478E9DCF.3030608@signpostmarv.name> The Webmap API provided by Linden Lab is almost non-existant. While the wiki page documents how to use the google maps wrapper it doesn't cover the pure API calls, of which there are only two: 1) Finding the name of a region at given co-ordinates 2) Finding the co-ordinates of a given region Bar doing some work with libSL, there is currently no "official" way to access this or related data in batch, which is why it'll be taking me about 3 weeks to scan an area covering 26.5 million acres of virtual land for the existence of Second Life regions. Another downside to the LL "API" is that you don't need an SL account to use it, but you do need a Google account. Which seems rather odd. Users also shouldn't be forced to use a collection of 4 different javascript libraries in order to do simple tasks with the "API". Finally, in order to discuss or ask questions about the LL "API", you require a Second Life account in order to access the wiki. Putting that all together, a non-SL user must create a google account to use the API, then an SL account to talk about it, which seems rather counter-productive. Two areas I have been working on in with regards to the webmap API is the development of my own Webmap API with beefier queries ( https://wiki.secondlife.com/wiki/User:SignpostMarv_Martin/Webmap_API ), and the development of a specification for encapsulating the data pertinent to a grid ( http://dev.signpostmarv.name/pub/llsd-grid-map/ ), although the latter needs updating to include region UUIDs http://agni.sl.mapapi.net/map-api.html#Hippotropolis contains my attempt to create a reference client interface to my version of the LL Webmap API The basic gist of all this- creating a 3rd party Webmap API, designing a data format suitable for 3rd parties to become aware of the state of the grid without having to run queries which take 3 weeks to complete- is the following: A publicly available (e.g. does not require authentication calls) API should be open to development and discussion by *everyone*, not just those with SL accounts. While one could argue that the SLDev mailing list is a public discussion resource, it isn't suitable for documentation & development efforts. This is what I'm proposing: Use a publicly accessible (readable AND editable) MediaWiki install that isn't restricted to Second Life Residents. This would faciliate both open discussion and open development of an SL Webmap API that can already be used by non-Residents. I have an install ready for this purpose on mapapi.net, and in order to facilitate the "openeness" while lending credibility to edits and preventing identity fraud, the mapapi.net wiki has the OpenID extension installed (though it is currently configured to only accept logins from SLOpenID.net ) With the OpenID extension, this allows the mapapi.net wiki to be open to everyone without the problems of enabling anonymous edits. Because OpenID urls typically double as web pages detailing the identity of the owner, visitors to the wiki would be able to easily identify authoritative users- SLOpenID or a first-party OpenID server provided by Linden Lab would provide a means for Linden Lab employees and credible Residents to make edits without worrying about other people pretending to be them or having to "build up" credibility over time (as happens in environments such as the Wikipedia, where one could easily register an account under the name "Griefer Linden" and make a series of seemingly authoritative edits about Linden Lab) The long-term goal of the mapapi.net wiki would be to server as a focal point for the discussion and development of map APIs in general (SL aren't the only people to use the google wrapper technique, see http://mapwow.com/ and http://www.oblivionmap.net/ ) The medium-term goal would be to enable a larger portion of the community to participate in the development of an API that has been languishing in beta since its inception. The short-term goal would be to illustrate how OpenID and MediaWiki can be implemented to enable non-Residents to participate in the development of SL- a topic that was brought up with regards to CHTTP, Mulib and Eventlet at one of the recent Open Source Office Hours in Hippotropolis. As evidenced by the length and content of the email, I do have a tendency to ramble on in a technical manner, so I apologise if there's any confusion in the email- just ask for clarification and I'll try and clear things up :-) ~ 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/20080117/8e13621a/smime-0001.bin From labrat.hb at gmail.com Wed Jan 16 17:21:36 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Jan 16 17:21:39 2008 Subject: [sldev] Open development of the Webmap API In-Reply-To: <478E9DCF.3030608@signpostmarv.name> References: <478E9DCF.3030608@signpostmarv.name> Message-ID: Re-Posting this to the dev list as I didn't on initial reply I re-did most of the new MapAPI interface using OpenLayers (http://openlayers.org/) Example 1. demo here: http://www.rpgstats.com/OpenLayer/example1.html MapMarkers don't work, but that's mostly due to my not having much experiance with how the Google MapAPI works and trying to translate that to a different mapping system. In regards to the MapAPI documentation on the wiki. I was the one who ported it over and added the instructions for the google Map API interface. So no I didn't document everything as the root calls didn't need to be documented for the MapAPI to be used as intended. As for getting information back in blocks: http://secondlife.com/app/voicemap/index.php?var=name&x=1000&y=1000&blocksize=10 The above is a JSON query that will return 32 regions starting at 1000,10000. The information returned is X and Y co-ordinate, Region Name, and if it is capable of voice (all regions should return true now I believe). On Jan 16, 2008 4:14 PM, SignpostMarv Martin wrote: > The Webmap API provided by Linden Lab is almost non-existant. > > While the wiki page documents how to use the google maps wrapper it > doesn't cover the pure API calls, of which there are only two: > 1) Finding the name of a region at given co-ordinates > 2) Finding the co-ordinates of a given region > > Bar doing some work with libSL, there is currently no "official" way to > access this or related data in batch, which is why it'll be taking me > about 3 weeks to scan an area covering 26.5 million acres of virtual > land for the existence of Second Life regions. > From sl-dev at theblob.org Thu Jan 17 02:40:09 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 02:40:11 2008 Subject: [sldev] Machinima and recording movies/demos in SL Message-ID: Hi, I've been meaning for a while to start my own discussion here about a specific way of recording movies in SL, and as there's now a discussion going on about it, it seems like the perfect time to bring this up. It's a separate discussion, though, so I'm starting a new thread. Firstly, let me introduce myself since I haven't really posted much here. I'm Kiwi Alfa in-world, and I do machinima in SL. Recently I've been thinking of making code changes to allow the client to record something similar to demos in other games, but with a bit more freedom. I'm going to copy and paste from something I've been writing on the subject (which isn't yet complete, hence no link): ===== The Problem Machinima in Second Life is currently limited in ways that machinima on game platforms isn't; namely, the ability to record 'demos', which, rather than recording the view from the camera, will record the actual events that happened during the recording. As such, when recording in SL, if two different camera views of the same scene are required, either two 'camera' avatars are needed, both recording their output to a file (which would also necessitate communication between the two avatars to make sure they both start at appropriate times, use appropriate settings, etc) or the same scene will need to be re-enacted and recorded twice by one person. In addition, if, during a recording, the camera isn't pointing at the right place or any other camera error, the scene needs to be re-enacted and recorded again. This leads to a largely inefficient means of producing machinima in a world that is arguably more suited to it than most game engines, which are inevitably biased towards their style of gameplay. The Proposal As Second Life uses a client/server architecture, I propose to create a recording facility that would capture events sent by the server and store them in a potentially redistributable archive, which could also optionally contain textures. The recorder would be built into a custom viewer and would record the initial state of the world as seen by the client when the recording starts, and from then on would record messages received from the server with timestamps. To play back the recorded demo, a separate server would be used, probably based on OpenSim. However, this would not be as advanced as OpenSim; none of the traditional sim interaction methods would need to work (the client would not be able to move themselves, for example). Basically, the server would be simply used for relaying the messages from the saved archive to the client. (The client may have a built-in facility for camera movements, although this would probably come later.) Using this technique, the client would be able to play back exactly the same scene as was recorded, but would be able to use different camera views each time, meaning that the original problems described are eliminated. ===== Obviously, the above is just an overview; I have ideas for how best to implement them which are not discussed above. For example, should the saved archive include the textures themselves, or just UUIDs? My gut feeling is that it should include the textures too, which would mean that after a successful cache hit or texture download by the client, it would need to temporarily store it and flag it along with a timestamp; after the recording finishes, the textures collected in this way can be analysed to work out what needs to be stored in the archive. (This is assuming that the texture referred to by a specific UUID can change or be removed after being stored; if not then it should be easy enough just to store each texture that was hit one or more times into the archive.) I just wanted to ask others on this list what they think of the feasibility of this idea. I'm a coder, though Perl is my main language so I would need to learn C++ and C# a bit more to work properly with the client code and OpenSim code. I've already started on this, though. Thanks for reading! - Kiwi. From matthew.dowd at hotmail.co.uk Thu Jan 17 03:17:35 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jan 17 03:17:37 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: > Machinima in Second Life is currently limited in ways that machinima > on game platforms isn't; namely, the ability to record 'demos', which, > rather than recording the view from the camera, will record the actual > events that happened during the recording. There is a recording option on the client debug menu which I believe records user events - is this anywhere close to what you need? Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From sl-dev at theblob.org Thu Jan 17 03:35:06 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 03:35:08 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: On 1/17/08, Matthew Dowd wrote: > > Machinima in Second Life is currently limited in ways that machinima > > on game platforms isn't; namely, the ability to record 'demos', which, > > rather than recording the view from the camera, will record the actual > > events that happened during the recording. > > There is a recording option on the client debug menu which I believe records user events - is this anywhere close to what you need? Nope; I considered that while pondering this proposal. As you note, it records user events, but that's only a very limited subset of what needs to be recorded for a machinima; I've also had problems using it in the past. Basically what I'd want to record is all events from the server, so that I can log into the 'player' server, tell it to load from the archived event file, and then I would be able to see what the recording of *everything* that events were sent for during the time of the recording. As far as I know (which isn't a lot right now, so someone please correct me if I'm wrong), the SL server doesn't know what the position of your camera is directly, instead relying on the client to ask for new objects when it needs to render them, for which the SL server will then start sending events (presumably until asked to stop). Again, that's based on the little I know so it could be wrong, but given that, it should be possible to view the same scene from different camera angles after having recorded the events to a file. Does that make sense? - Kiwi. From secret.argent at gmail.com Thu Jan 17 04:05:24 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 17 04:05:34 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: On 2008-01-17, at 04:40, Kiwi Alfa wrote: > archive. (This is assuming that the texture referred to by a specific > UUID can change or be removed after being stored; if not then it > should be easy enough just to store each texture that was hit one or > more times into the archive.) A texture is never changed, if it is replaced a new UUID is generated. The same applies to animations and sounds (and notecards and scripts, but you probably don't care about that). From lenglish5 at cox.net Thu Jan 17 05:49:37 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 17 05:49:39 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: <478F5CF1.3090200@cox.net> Kiwi Alfa wrote: > On 1/17/08, Matthew Dowd wrote: > >>> Machinima in Second Life is currently limited in ways that machinima >>> on game platforms isn't; namely, the ability to record 'demos', which, >>> rather than recording the view from the camera, will record the actual >>> events that happened during the recording. >>> >> There is a recording option on the client debug menu which I believe records user events - is this anywhere close to what you need? >> > > Nope; I considered that while pondering this proposal. As you note, it > records user events, but that's only a very limited subset of what > needs to be recorded for a machinima; I've also had problems using it > in the past. > > Basically what I'd want to record is all events from the server, so > that I can log into the 'player' server, tell it to load from the > archived event file, and then I would be able to see what the > recording of *everything* that events were sent for during the time of > the recording. As far as I know (which isn't a lot right now, so > someone please correct me if I'm wrong), the SL server doesn't know > what the position of your camera is directly, instead relying on the > client to ask for new objects when it needs to render them, for which > the SL server will then start sending events (presumably until asked > to stop). Again, that's based on the little I know so it could be > wrong, but given that, it should be possible to view the same scene > from different camera angles after having recorded the events to a > file. > > Does that make sense? > > Absolutely. The original Marathon game did this, in a sense. It would record all user input into a QuickTime file and use the game engine as a playback of that input. Since all actions in the game were controlled by keypresses of the player, the file was extremely compact: 100KB returned 60 minutes of networked game-play of 6 plyers. You could even speedup or slowdown the playback, and switch capera views from player t player What you're looking for is more complicated: the playback of scene information, but in principle everything you see could be reconstructed from what the client got over a period of time. One flat in your plan (and its relatively minor, I think): the server DOES have some idea of where your camera is and does do some culling of the objects sent to the client. This means the range of positions where your camera position will show a valid picture is reduced, but I think you'll still have SOME mobility of the camera, even if its not sim-wide. I might be wrong, of course. The trick will be to mod the viewer to accept the canned data as current and not get upset when certain messages to the server are not responded to. Not a clue how to do those mods. I'd talk to the libsl people and see if they have any ideas.Maybe there's already a way for SLProxy to record that data and play it back from a file. That would be the srart. Lawson From sl-dev at theblob.org Thu Jan 17 06:48:09 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 06:48:14 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: <478F5CF1.3090200@cox.net> References: <478F5CF1.3090200@cox.net> Message-ID: On 1/17/08, Lawson English wrote: > What you're looking for is more complicated: the playback of scene > information, but in principle everything you see could be reconstructed > from what the client got over a period of time. Right. For example, the playback server wouldn't need to have any concept of physics as the information needed will already have been calculated and will be evident in the information recorded. There is one thing I don't know, however. Does the server actually send events of its own accord or does it wait until the client asks for them? I'd suspect the latter, in which case it may need to be a bit more complex, depending on the time of the queries and how complex the server needs to be. It may be that some interpolation is needed in the saved values to keep the demo going at the same rate, which could be a bit of a pain. On the other hand, if the server just relays all the events as they happen without being asked, it would be easy to do just that with the saved events. > One flat in your plan (and its relatively minor, I think): the server > DOES have some idea of where your camera is and does do some culling of > the objects sent to the client. This means the range of positions where > your camera position will show a valid picture is reduced, but I think > you'll still have SOME mobility of the camera, even if its not sim-wide. > I might be wrong, of course. I guess the way to tell for sure would be to use GLInterceptor or similar while testing to see what could be seen. I know SL uses OpenGL on Linux (as I've used OpenGL-intercepting libraries before on the Linux version) - I assume it's the same on Windows. > The trick will be to mod the viewer to accept the canned data as current > and not get upset when certain messages to the server are not responded > to. Not a clue how to do those mods. I'd talk to the libsl people and > see if they have any ideas.Maybe there's already a way for SLProxy to > record that data and play it back from a file. That would be the srart. In my ideas, the recorder was originally conceived as a proxy, actually, but after thinking about it I realised that it would be a lot easier if it was implemented directly in the client; after all, it knows exactly what its own internal structure is. In addition, doing it in the client would make it less of a memory hog, as that state wouldn't need to be duplicated in two apps. Heck, I believe that there's already an option in the debug menus to dump the current state of the world as the client sees it, so if nothing else it shouldn't be too hard to piggyback on that and then record deltas. (It's not the way I would do it and it would probably be likely to slow the client down a great deal, but it shows how easy the main part of this could potentially be.) As for the server not responding to messages, see the point above this one. I would want this to be compliant with the protocol, so anything that needs a response should get a response. Some interpolation may be needed for full accuracy. - Kiwi. From secret.argent at gmail.com Thu Jan 17 06:59:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 17 07:00:00 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: <478F5CF1.3090200@cox.net> Message-ID: On 2008-01-17, at 08:48, Kiwi Alfa wrote: > In my ideas, the recorder was originally conceived as a proxy, > actually, but after thinking about it I realised that it would be a > lot easier if it was implemented directly in the client; after all, it > knows exactly what its own internal structure is. In addition, doing > it in the client would make it less of a memory hog, as that state > wouldn't need to be duplicated in two apps. Heck, I believe that > there's already an option in the debug menus to dump the current state > of the world as the client sees it, so if nothing else it shouldn't be > too hard to piggyback on that and then record deltas. (It's not the > way I would do it and it would probably be likely to slow the client > down a great deal, but it shows how easy the main part of this could > potentially be.) One advantage of doing it outside the client is that you would be able to upgrade the client without reapplying all the changes made in implementing the proxy. From sl-dev at theblob.org Thu Jan 17 07:28:28 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 07:28:31 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: <478F5CF1.3090200@cox.net> Message-ID: (resubmitted as I accidentally posted from a bad address the first time) On 1/17/08, Argent Stonecutter wrote: > One advantage of doing it outside the client is that you would be > able to upgrade the client without reapplying all the changes made in > implementing the proxy. Fair point - I hadn't thought about that. It would presumably require the proxy to know the current state of the world at all times, though, because you need to be able to get a dump when you start recording, which would require reimplementing state objects, including needing to know things like prim parameters. The pointer to SLProxy elsewhere in this thread is a good idea - thanks, Lawson. :D As far as I know, however, SLProxy is more of a tool intended for use by other apps to modify the stream. As such, while it would be invaluable to me (if not to use, then at least to learn from), the only thing it would be able to do without additional apps and with the minimum of coding would be to save packet files and replay them as-is; it has no concept of the contents of the packets. ( http://www.libsecondlife.org/wiki/SLProxy ) If the recorder is implemented as a proxy, and depending on how SLProxy works, I'd probably be using it as-is with the recorder as an SLProxy application or plugin, or at least drawing substantially on its code to start me off. I can see positive and negative points for each method. Currently, though, I think that the benefits of implementing it directly in the client, combined with message liberation, means that it's probably easier to start off doing it there first. As I said before, though, I'm not an SLDev guru so if there's any points I'm missing I'd love to hear about them. (yeah, yeah, I know, the above implies I would be lazy about updating. However, I think that in the early stages of development I would want to get it stable with one version first before moving on, which is why message liberation is so important. Obviously I'd wait until 1.19.x to actually start doing anything, at least.) - Kiwi. From robin.cornelius at gmail.com Thu Jan 17 07:36:40 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 17 07:36:43 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm In-Reply-To: References: Message-ID: On Jan 16, 2008 4:11 PM, Soft wrote: > As usual - be encouraged to add items to the agenda for Thursday's > open source meeting - see you in Hippotropolis! > Hmm nice timing :- http://blog.secondlife.com/2008/01/16/rolling-restart-scheduled-thursday-afternoon-pst/ From ts_ryuzo at hotmail.com Thu Jan 17 08:00:52 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Thu Jan 17 08:00:54 2008 Subject: [sldev] How server decide what to send? Message-ID: Hi, It's about rendering again. Previously, I understand that the client does not request for what they see in front of them but send a camera to the server and the server will send back the prims. Is there any decision algorithm that the server run to decide what to send first? Secondly, is it right that the client, after receiving the prims will run occlusion and culling then tell the server what texture file they need? I was thinking maybe we can write an algorithm to predict player's movement and send a "fake" camera to the server to get the necessary prims from the server first before the player actually move to that location or direction. Will that improve the performance of the client? Regards, Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080118/238279cf/attachment.htm From monkowsk at watson.ibm.com Thu Jan 17 08:49:48 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jan 17 08:49:53 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: <478F5CF1.3090200@cox.net> Message-ID: <478F872C.8090500@watson.ibm.com> Kiwi Alfa wrote: > As for the server not responding to messages, see the point above this > one. I would want this to be compliant with the protocol, so anything > that needs a response should get a response. Some interpolation may be > needed for full accuracy. > > - Kiwi. One other thing to consider is that in order to get information from the server, you have to be logged on, and if you're logged on, you'll also get messages about what's happening currently: avatars moving around, objects responding to scripts being run, etc. Somehow you have to distinguish between live events and recorded events. And then, there's packet loss. :-) Nevertheless, I encourage you to try it. I think it would be great for machinima. Oh, while you're at it, can you add a feature to scrape the timeline? :-) Mike From makosoft at googlemail.com Thu Jan 17 10:46:35 2008 From: makosoft at googlemail.com (Aidan Thornton) Date: Thu Jan 17 10:46:39 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: On Jan 17, 2008 11:35 AM, Kiwi Alfa wrote: > On 1/17/08, Matthew Dowd wrote: > > > Machinima in Second Life is currently limited in ways that machinima > > > on game platforms isn't; namely, the ability to record 'demos', which, > > > rather than recording the view from the camera, will record the actual > > > events that happened during the recording. > > > > There is a recording option on the client debug menu which I believe records user events - is this anywhere close to what you need? > > Nope; I considered that while pondering this proposal. As you note, it > records user events, but that's only a very limited subset of what > needs to be recorded for a machinima; I've also had problems using it > in the past. > > Basically what I'd want to record is all events from the server, so > that I can log into the 'player' server, tell it to load from the > archived event file, and then I would be able to see what the > recording of *everything* that events were sent for during the time of > the recording. As far as I know (which isn't a lot right now, so > someone please correct me if I'm wrong), the SL server doesn't know > what the position of your camera is directly, instead relying on the > client to ask for new objects when it needs to render them, for which > the SL server will then start sending events (presumably until asked > to stop). Again, that's based on the little I know so it could be > wrong, but given that, it should be possible to view the same scene > from different camera angles after having recorded the events to a > file. > > Does that make sense? > > - Kiwi. It's a nice idea, with one thing to beware of (above and beyond the server-side prim culling mentioned by Lawson English) - some information, such as textures, avatar UUID-name mappings and prim data for in-world objects is cached by the client and not sent by the server unless the client asks. Textures and UUID-name mappings should be easy enough to deal with. The prim data will be the really interesting bit - if you clear out your cache before starting, it should work as long as the viewer's cache state remains the same as on the initial run. Otherwise, you'll have to add some smarts in the player. From sl-dev at theblob.org Thu Jan 17 10:58:48 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 10:58:50 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: <478F872C.8090500@watson.ibm.com> References: <478F5CF1.3090200@cox.net> <478F872C.8090500@watson.ibm.com> Message-ID: On 1/17/08, Mike Monkowski wrote: > One other thing to consider is that in order to get information from the > server, you have to be logged on, and if you're logged on, you'll also > get messages about what's happening currently: avatars moving around, > objects responding to scripts being run, etc. Somehow you have to > distinguish between live events and recorded events. Maybe I'm misunderstanding you, but it seems to me there'd be no problem with that; remember that to play back the recorded files you would be using a completely different server, which would be supplied; you wouldn't connect to Linden Lab's servers at all. > And then, there's packet loss. :-) Well, that's always going to happen, even in he way machinima is recorded today. Only events that are actually received would be recorded, though, not the complete conversation, so there'd probably be just a delay in the recording until the events started to be received again. > Nevertheless, I encourage you to try it. I think it would be great for > machinima. Oh, while you're at it, can you add a feature to scrape the > timeline? :-) At first I was going to just concentrate on doing commands for play, pause (which itself will be an interesting challenge - what do you do with physical objects that are paused, for instance?), and seek to the beginning (reset), which I suspect will be accomplished at first by a forced 'teleport' in such a manner that the client forgets everything so that the server can replay the initial setup. I was planning to see if I could build in a fast-forward feature later, which should, I think, be straightforward enough (although there's the problem with physical objects again). Rewind will be more difficult as it essentially involves sending commands that do the opposite of what was recorded, and will require either stateful knowledge of the world or the ability to look up information in prior events on-the-fly - for example, if a prim is deleted in the recorded scene, to rewind you'd need to create a prim instead, with whatever prim parameters and textures were in force at the time it was deleted (which aren't necessarily the same as they were when the prim was created - and by 'created', I mean 'first appeared in the recorded archive'). Once fast-forward and rewind were both implemented, scraping would be easier as the necessary events could just be piled on top of each other, although I suspect that for the sake of sanity, some events that don't affect anything permanently, like sound events, would probably be excluded from being sent while scraping. ;) Thanks for the encouragement! - Kiwi. From sl-dev at theblob.org Thu Jan 17 11:17:23 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Thu Jan 17 11:17:25 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: On 1/17/08, Aidan Thornton wrote: > On Jan 17, 2008 11:35 AM, Kiwi Alfa wrote: [snip] > > Basically what I'd want to record is all events from the server, so > > that I can log into the 'player' server, tell it to load from the > > archived event file, and then I would be able to see what the > > recording of *everything* that events were sent for during the time of > > the recording. As far as I know (which isn't a lot right now, so > > someone please correct me if I'm wrong), the SL server doesn't know > > what the position of your camera is directly, instead relying on the > > client to ask for new objects when it needs to render them, for which > > the SL server will then start sending events (presumably until asked > > to stop). Again, that's based on the little I know so it could be > > wrong, but given that, it should be possible to view the same scene > > from different camera angles after having recorded the events to a > > file. > > > > Does that make sense? > > > > - Kiwi. > > It's a nice idea, with one thing to beware of (above and beyond the > server-side prim culling mentioned by Lawson English) - some > information, such as textures, avatar UUID-name mappings and prim data > for in-world objects is cached by the client and not sent by the > server unless the client asks. Textures and UUID-name mappings should > be easy enough to deal with. The prim data will be the really > interesting bit - if you clear out your cache before starting, it > should work as long as the viewer's cache state remains the same as on > the initial run. Otherwise, you'll have to add some smarts in the > player. Well, this is another reason that I temporarily forgot that I had decided it would be better in the client - as I said in my initial post, it would save these things on either a successful download *or* a cache hit. - Kiwi. From secret.argent at gmail.com Thu Jan 17 12:04:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 17 12:05:10 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: <9EB37D5D-8866-498F-95CD-9EDF77D7DF6C@gmail.com> On 2008-01-17, at 13:17, Kiwi Alfa wrote: > Well, this is another reason that I temporarily forgot that I had > decided it would be better in the client - as I said in my initial > post, it would save these things on either a successful download *or* > a cache hit. Or the proxy could just strip out all UUIDs in the packets going past and forge extra requests for them, cache them, and not pass them on to the client. Operate at a higher level than the client. It could even teleport the camera around behind the client's back, to force the server to send objects that might otherwise be missed. From monkowsk at watson.ibm.com Thu Jan 17 12:58:12 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jan 17 12:58:16 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: <478F5CF1.3090200@cox.net> <478F872C.8090500@watson.ibm.com> Message-ID: <478FC164.8030903@watson.ibm.com> Kiwi Alfa wrote: > On 1/17/08, Mike Monkowski wrote: > >>One other thing to consider is that in order to get information from the >>server, you have to be logged on, and if you're logged on, you'll also >>get messages about what's happening currently: avatars moving around, >>objects responding to scripts being run, etc. Somehow you have to >>distinguish between live events and recorded events. > > > Maybe I'm misunderstanding you, but it seems to me there'd be no > problem with that; remember that to play back the recorded files you > would be using a completely different server, which would be supplied; > you wouldn't connect to Linden Lab's servers at all. That depends on whether you're caching all objects, animations, avatar appearance, textures, etc. or just using UUIDs. You'd have to disable cache deletes and make sure the data structures don't overflow if you're counting on having everything in the cache, and that makes for a pretty large replay file too. >>And then, there's packet loss. :-) I was assuming that you would fetch data by UUID and might possibly have to resend the fetch if the response was lost. > At first I was going to just concentrate on doing commands for play, > pause (which itself will be an interesting challenge - what do you do > with physical objects that are paused, for instance?), and seek to the > beginning (reset), which I suspect will be accomplished at first by a > forced 'teleport' in such a manner that the client forgets everything > so that the server can replay the initial setup. Sorry, I was just joking. Just "Play" would be enough. Mike From alissa_sabre at yahoo.co.jp Thu Jan 17 04:52:54 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Jan 17 14:07:06 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <478E6559.1000104@lindenlab.com> References: <478E6559.1000104@lindenlab.com> Message-ID: <2rk8rkGrLarL8rsGrkbrr8G.alissa_sabre@yahoo.co.jp> > The embedded recorder > really is just for recording bugs, Is this the Linden Lab's official statement or just a personal opinion? Please make sure to void the confusion. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From seg at haxxed.com Thu Jan 17 16:39:39 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jan 17 16:39:58 2008 Subject: [sldev] How server decide what to send? In-Reply-To: References: Message-ID: <1200616779.15354.67.camel@localhost> On Fri, 2008-01-18 at 00:00 +0800, Qian Hao ~ wrote: > Hi, > > It's about rendering again. Previously, I understand that the client > does not request for what they see in front of them but send a camera > to the server and the server will send back the prims. Is there any > decision algorithm that the server run to decide what to send first? > > Secondly, is it right that the client, after receiving the prims will > run occlusion and culling then tell the server what texture file they > need? > > I was thinking maybe we can write an algorithm to predict player's > movement and send a "fake" camera to the server to get the necessary > prims from the server first before the player actually move to that > location or direction. Will that improve the performance of the > client? You're barking up the wrong tree. If you want higher framerates, figure out why avatar rendering is so goddamn slow. It dwarfs all other rendering by far. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080117/f7ea66f1/attachment.pgp From ian at neon.ai Thu Jan 17 16:50:01 2008 From: ian at neon.ai (Ian Wilson) Date: Thu Jan 17 16:50:10 2008 Subject: [sldev] How server decide what to send? In-Reply-To: <1200616779.15354.67.camel@localhost> References: <1200616779.15354.67.camel@localhost> Message-ID: <478FF7B9.1070501@neon.ai> Is frame rate limited in any way or is it purely a function of the available processing power? If you had an environment with little other geometry (inside a small room for example) and few other avatars (maybe 4 in total) would this improve performance greatly? Callum Lerwick wrote: > On Fri, 2008-01-18 at 00:00 +0800, Qian Hao ~ wrote: > >> Hi, >> >> It's about rendering again. Previously, I understand that the client >> does not request for what they see in front of them but send a camera >> to the server and the server will send back the prims. Is there any >> decision algorithm that the server run to decide what to send first? >> >> Secondly, is it right that the client, after receiving the prims will >> run occlusion and culling then tell the server what texture file they >> need? >> >> I was thinking maybe we can write an algorithm to predict player's >> movement and send a "fake" camera to the server to get the necessary >> prims from the server first before the player actually move to that >> location or direction. Will that improve the performance of the >> client? >> > > You're barking up the wrong tree. If you want higher framerates, figure > out why avatar rendering is so goddamn slow. It dwarfs all other > rendering by far. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20080118/44a6aa08/attachment.htm From seg at haxxed.com Thu Jan 17 17:03:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jan 17 17:03:40 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: <1200618208.15354.77.camel@localhost> On Thu, 2008-01-17 at 10:40 +0000, Kiwi Alfa wrote: > As Second Life uses a client/server architecture, I propose to create > a recording facility that would capture events sent by the server and > store them in a potentially redistributable archive, which could also > optionally contain textures. The recorder would be built into a custom > viewer and would record the initial state of the world as seen by the > client when the recording starts, and from then on would record > messages received from the server with timestamps. SL's dynamic, non-deterministic and network-dependent nature makes performance tuning, and even debugging, next to impossible. There's really no practical way to do an objective, automated, 100% repeatable test. Please do this. :) A "timedemo" like facility would make a lot of things so much easier... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080117/cfdc2a73/attachment.pgp From robla at lindenlab.com Thu Jan 17 18:15:14 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jan 17 18:15:27 2008 Subject: [sldev] Requiring login on wiki.secondlife.com (Re: Open development of the Webmap API) In-Reply-To: <478E9DCF.3030608@signpostmarv.name> References: <478E9DCF.3030608@signpostmarv.name> Message-ID: <47900BB2.7090001@lindenlab.com> Hi SignpostMarv, I'm going to leave it to the folks who know the MapAPI to talk more about this topic. However, I'd like to respond to one piece of this which is more in my domain: On 1/16/08 4:14 PM, SignpostMarv Martin wrote: > This is what I'm proposing: Use a publicly accessible (readable AND > editable) MediaWiki install that isn't restricted to Second Life > Residents. > > This would faciliate both open discussion and open development of an > SL Webmap API that can already be used by non-Residents. Here's the problem with developing APIs on a wide open wiki. If this is going to be an API that Linden Lab is going to be expected to implement, we very strongly prefer to operate in a manner that we have the necessary rights to implement the work product, and that we have the rights to take that work and submit it to a standards body if/when the time is right to do that. wiki.secondlife.com is set up in such a way that contributions are jointly owned by you and us. It means that we're ultimately the custodians of the final product, which is a level of trust we hope we've earned. We could *conceivably* work via an outside arbiter instead, but I'm not sure there's a logical choice that we could trust. What we really want to avoid is a situation where every single contributor maintains exclusive ownership of their contribution, since that effectively ensures no one is in a position to relicense the API in the future. We also require the login because we want to make sure you agree to the Second Life Terms of Service, and that we maintain a single user database rather than one for each individual thing we run (wiki, forums, jira, etc). Spamming has been mercifully low on wiki.secondlife.com; much lower than a wiki that I run outside of work on which I seem to be in a spammer arms race. Since accounts are free to anyone, asking people to sign up doesn't seem like an insurmountable hurdle. With respect to OpenID, we may use that in the future in some fashion, but that's not really relevant to the policy discussion above. I don't believe that the auth mechanism we ultimately choose will have much of an impact on the policy, since it wouldn't change the reasons for the policy. So, I'm hoping we can use wiki.secondlife.com to collaborate on whatever APIs you'd like us to implement. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080117/c2af450c/signature.pgp From GordonWendt at gmail.com Thu Jan 17 19:20:36 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu Jan 17 19:20:38 2008 Subject: [sldev] Requiring login on wiki.secondlife.com (Re: Open development of the Webmap API) In-Reply-To: <47900BB2.7090001@lindenlab.com> References: <478E9DCF.3030608@signpostmarv.name> <47900BB2.7090001@lindenlab.com> Message-ID: <493033a70801171920n482b8d12x76883756b98b89c1@mail.gmail.com> I can't believe I'm saying this but I actually agree with rob on this one that for multiple reasons including licensing and to reasonbly prevent spamming (spam and vandalism is nonexistent on the wiki) it's a small price to pay for discussions. Since LL does seem to be spinning off the open source discussions onto opengrid maybe an opengrid wiki solely about open source with it's own database of content and users unlinked from the rest of the logins (like the opengrid page is more or less unlinked to anything else in SL although it's mentioned on the main webpage) would be a good idea. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080117/5590015d/attachment-0001.htm From annagulaev at gmail.com Thu Jan 17 20:04:46 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Thu Jan 17 20:04:54 2008 Subject: [sldev] simulate a sim restart Message-ID: Has anyone figured out a decent way to simulate a sim restart? In today's rolling restart my client crashed on sim restart rather than logging me off, which popped a runtime error dialog, which prevented the viewer from exiting and triggering the restart script with fallback timer. In short, it misbehaved. Has anyone already invented this wheel? I'd like to be able to simulate a sim restart so I can make sure my code fails gracefully. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080117/45fc5b54/attachment.htm From davep at lindenlab.com Thu Jan 17 22:10:17 2008 From: davep at lindenlab.com (Dave Parks) Date: Thu Jan 17 22:10:31 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <2rk8rkGrLarL8rsGrkbrr8G.alissa_sabre@yahoo.co.jp> References: <478E6559.1000104@lindenlab.com> <2rk8rkGrLarL8rsGrkbrr8G.alissa_sabre@yahoo.co.jp> Message-ID: <479042C9.4030308@lindenlab.com> It's a sentiment I've heard around the office. The main problem I have with it is that it's just so damn slow compared to external recorders. Machinamists, please correct me if I'm wrong, but do you ever get decent frame rates when using the built in recorder? Alissa Sabre wrote: >> The embedded recorder >> really is just for recording bugs, >> > > Is this the Linden Lab's official statement or just a personal > opinion? Please make sure to void the confusion. > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > From me at signpostmarv.name Fri Jan 18 04:43:22 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jan 18 04:43:27 2008 Subject: [sldev] Re: Requiring login on wiki.secondlife.com (Re: Open development of the Webmap API) In-Reply-To: <47900BB2.7090001@lindenlab.com> References: <478E9DCF.3030608@signpostmarv.name> <47900BB2.7090001@lindenlab.com> Message-ID: <47909EEA.7000905@signpostmarv.name> Rob Lanphier wrote: > Here's the problem with developing APIs on a wide open wiki. If this > is going to be an API that Linden Lab is going to be expected to > implement, we very strongly prefer to operate in a manner that we have > the necessary rights to implement the work product, and that we have > the rights to take that work and submit it to a standards body if/when > the time is right to do that. > > wiki.secondlife.com is set up in such a way that contributions are > jointly owned by you and us. It means that we're ultimately the > custodians of the final product, which is a level of trust we hope > we've earned. We could *conceivably* work via an outside arbiter > instead, but I'm not sure there's a logical choice that we could > trust. What we really want to avoid is a situation where every single > contributor maintains exclusive ownership of their contribution, since > that effectively ensures no one is in a position to relicense the API > in the future. The mapapi.net wiki is licensed under the CC BY-SA 3.0 license, which I'm guessing is compatible with the 2.5 license used on the SL Wiki, so the point of "every single contributor maintains exclusive ownership" doesn't apply. > We also require the login because we want to make sure you agree to > the Second Life Terms of Service, and that we maintain a single user > database rather than one for each individual thing we run (wiki, > forums, jira, etc). Spamming has been mercifully low on > wiki.secondlife.com; much lower than a wiki that I run outside of work > on which I seem to be in a spammer arms race. > > Since accounts are free to anyone, asking people to sign up doesn't > seem like an insurmountable hurdle. However, it's not entirely open- if a Resident is banned for whatever reason, or they don't access their account for a while they can generally no longer log into Second Life with those credentials. In the long run, this would affect how people are credited for their contributions. > With respect to OpenID, we may use that in the future in some fashion, > but that's not really relevant to the policy discussion above. I > don't believe that the auth mechanism we ultimately choose will have > much of an impact on the policy, since it wouldn't change the reasons > for the policy. > > So, I'm hoping we can use wiki.secondlife.com to collaborate on > whatever APIs you'd like us to implement. Using OpenID for the mapapi.net wiki means "not having to create another account on another service just so you can contribute as yourself" ~ 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/20080118/19bd3fa2/smime.bin From dzonatas at dzonux.net Fri Jan 18 07:46:55 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 18 07:46:10 2008 Subject: [sldev] Avatar Rending Speed (was: How server decide what to send?) In-Reply-To: <1200616779.15354.67.camel@localhost> References: <1200616779.15354.67.camel@localhost> Message-ID: <4790C9EF.4000501@dzonux.net> Callum Lerwick wrote: > You're barking up the wrong tree. If you want higher framerates, figure > out why avatar rendering is so goddamn slow. It dwarfs all other > rendering by far. > (notices subject changed... /me checks-off on list) (changed subject in Subject bar... /me checks-off on list) There was some patches posted to speed up avatar rendering, but that effort has been ..uhm.. derailed. Now that Windlight is coming out with its low quality avi tradeoff for framerates, those patches don't seem to matter anymore. From josh at lindenlab.com Fri Jan 18 10:30:12 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jan 18 10:30:21 2008 Subject: [sldev] simulate a sim restart In-Reply-To: References: Message-ID: <4790F034.1050900@lindenlab.com> Anna Gulaev wrote: > Has anyone figured out a decent way to simulate a sim restart? > > In today's rolling restart my client crashed on sim restart rather > than logging me off, which popped a runtime error dialog, which > prevented the viewer from exiting and triggering the restart script > with fallback timer. In short, it misbehaved. > > Has anyone already invented this wheel? I'd like to be able to > simulate a sim restart so I can make sure my code fails gracefully. I'm happy to bounce a sim on the beta grid (aditi) while you're connected, if that'll do. From robla at lindenlab.com Fri Jan 18 12:45:39 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 18 12:46:07 2008 Subject: [sldev] Re: Requiring login on wiki.secondlife.com (Re: Open development of the Webmap API) In-Reply-To: <47909EEA.7000905@signpostmarv.name> References: <478E9DCF.3030608@signpostmarv.name> <47900BB2.7090001@lindenlab.com> <47909EEA.7000905@signpostmarv.name> Message-ID: <47910FF3.4090006@lindenlab.com> On 1/18/08 4:43 AM, SignpostMarv Martin wrote: > The mapapi.net wiki is licensed under the CC BY-SA 3.0 license, which > I'm guessing is compatible with the 2.5 license used on the SL Wiki, > so the point of "every single contributor maintains exclusive > ownership" doesn't apply. Yes it does. Under the default configuration for most wikis, each contributor still owns their contribution, and merely licenses it under the stated license (e.g. CC BY-SA 3.0). If anyone wants to relicense those contributions under a different license, each contributor must agree to do so, and any contributor can unilaterally veto the move. Since organizations like IETF require submitters to license their contribution under a specific, non-CC license, it means that any contributor could block submission to most standards bodies. See http://www.ietf.org/rfc/rfc3978.txt for more on the IETF as an example. Other bodies are similar. >> We also require the login because we want to make sure you agree to >> the Second Life Terms of Service, and that we maintain a single user >> database rather than one for each individual thing we run (wiki, >> forums, jira, etc). Spamming has been mercifully low on >> wiki.secondlife.com; much lower than a wiki that I run outside of >> work on which I seem to be in a spammer arms race. >> >> Since accounts are free to anyone, asking people to sign up doesn't >> seem like an insurmountable hurdle. > However, it's not entirely open- if a Resident is banned for whatever > reason, or they don't access their account for a while they can > generally no longer log into Second Life with those credentials. In > the long run, this would affect how people are credited for their > contributions. With respect to people losing access because we banned them, that's a feature, not a bug. If someone is displaying anti-social behavior in-world, chances are they are also going to be anti-social on the wiki. I'd prefer not to have to rediscover each griefer's anti-social tendencies on the wiki after we've already determined that they don't play nice with others in-world. With respect to losing wiki access because of account activity: are you familiar with cases of this happening? If you are, let me know, because we need to fix this. > Using OpenID for the mapapi.net wiki means "not having to create > another account on another service just so you can contribute as > yourself" OpenID only solves authentication. On the back end, there still ends up being an account database, and we still need to establish whether that account holder agrees to the terms of service, and we still need much of the information associated with that account (such as contact information in case of copyright dispute). Don't get me wrong; I like the idea of using OpenID in some way to reduce the number of passwords that people have to remember/maintain, but I think many people tend to overestimate the number of policy problems that a system like OpenID truly solves. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080118/ac30ad08/signature.pgp From lenglish5 at cox.net Fri Jan 18 13:05:47 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 18 13:05:49 2008 Subject: [sldev] Requiring login on wiki.secondlife.com (Re: Open development of the Webmap API) In-Reply-To: <493033a70801171920n482b8d12x76883756b98b89c1@mail.gmail.com> References: <478E9DCF.3030608@signpostmarv.name> <47900BB2.7090001@lindenlab.com> <493033a70801171920n482b8d12x76883756b98b89c1@mail.gmail.com> Message-ID: <479114AB.3060901@cox.net> Gordon Wendt wrote: > I can't believe I'm saying this but I actually agree with rob on this > one that for multiple reasons including licensing and to reasonbly > prevent spamming (spam and vandalism is nonexistent on the wiki) it's > a small price to pay for discussions. Since LL does seem to be > spinning off the open source discussions onto opengrid maybe an > opengrid wiki solely about open source with it's own database of > content and users unlinked from the rest of the logins (like the > opengrid page is more or less unlinked to anything else in SL although > it's mentioned on the main webpage) would be a good idea. > > -G.W. Like to point to the AWG/AW Groupies pages. Those organizations exist specifically to deal with new APIs but are, well, underused at this time... Lawson From lenglish5 at cox.net Fri Jan 18 13:08:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 18 13:08:57 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <4790C9EF.4000501@dzonux.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> Message-ID: <47911567.6060403@cox.net> Dzonatas wrote: > Callum Lerwick wrote: >> You're barking up the wrong tree. If you want higher framerates, figure >> out why avatar rendering is so goddamn slow. It dwarfs all other >> rendering by far. >> > > (notices subject changed... /me checks-off on list) > (changed subject in Subject bar... /me checks-off on list) > > There was some patches posted to speed up avatar rendering, but that > effort has been ..uhm.. derailed. > > Now that Windlight is coming out with its low quality avi tradeoff for > framerates, those patches don't seem to matter anymore. > Well, the WIndlight rendering is a step in the right direction, but there's bound to be more that can be done, especially in specific circumstances. Bots/Limited Capability Clients that aren't meant to have massive bling attachments, for example, might be candidates for optimized rendering. Lawson From lenglish5 at cox.net Fri Jan 18 13:12:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 18 13:12:06 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <47911567.6060403@cox.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <47911567.6060403@cox.net> Message-ID: <47911624.3090304@cox.net> Lawson English wrote: > Dzonatas wrote: >> Callum Lerwick wrote: >>> You're barking up the wrong tree. If you want higher framerates, figure >>> out why avatar rendering is so goddamn slow. It dwarfs all other >>> rendering by far. >>> >> >> (notices subject changed... /me checks-off on list) >> (changed subject in Subject bar... /me checks-off on list) >> >> There was some patches posted to speed up avatar rendering, but that >> effort has been ..uhm.. derailed. >> >> Now that Windlight is coming out with its low quality avi tradeoff >> for framerates, those patches don't seem to matter anymore. >> > > Well, the WIndlight rendering is a step in the right direction, but > there's bound to be more that can be done, especially in specific > circumstances. Bots/Limited Capability Clients that aren't meant to > have massive bling attachments, for example, might be candidates for > optimized rendering. > > Which goes back to providing info to the sims about the existence of such LCC's and what they can actually do. Lawson From poppy at lindenlab.com Fri Jan 18 13:27:53 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Fri Jan 18 13:28:47 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: Message-ID: <479119D9.3070405@lindenlab.com> Kiwi Alfa wrote: > As Second Life uses a client/server architecture, I propose to create > a recording facility that would capture events sent by the server and > store them in a potentially redistributable archive, which could also What everyone says is mostly correct, but there's one more thing about those crazy messages: RequestID. It's essentially packet ordering. So you would have to be able to receive a canned message in the viewer and not throw it out. However, there might be bunk messages in your recorded session, so you have to be careful to mark that, along with a *very* accurate timestamp on each message, and change the message system to react differently when in "playback" mode. Then you just need some kind of http proxy to act like the asset store / other http services, and disable message system sending (although it's gonna be hard to get http responses without sending the appropriate get()...). There are probably all kinds of other small issues, but I wouldn't say this is insurmountable. I'm gonna wager you'll see some *wicked* crashes when doing this, but it sounds like you've got a good use case. This would enable you to do things that you cannot do with an external recording app, or likely even a GL "recorder" (as a lot of stuff happens out-of-scene). + poppy From lenglish5 at cox.net Fri Jan 18 14:42:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 18 14:42:51 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: <479119D9.3070405@lindenlab.com> References: <479119D9.3070405@lindenlab.com> Message-ID: <47912B69.5080002@cox.net> Paul Oppenheim (Poppy Linden) wrote: > Kiwi Alfa wrote: >> As Second Life uses a client/server architecture, I propose to create >> a recording facility that would capture events sent by the server and >> store them in a potentially redistributable archive, which could also > > What everyone says is mostly correct, but there's one more thing about > those crazy messages: RequestID. It's essentially packet ordering. So > you would have to be able to receive a canned message in the viewer > and not throw it out. However, there might be bunk messages in your > recorded session, so you have to be careful to mark that, along with a > *very* accurate timestamp on each message, and change the message > system to react differently when in "playback" mode. Then you just > need some kind of http proxy to act like the asset store / other http > services, and disable message system sending (although it's gonna be > hard to get http responses without sending the appropriate get()...). > There are probably all kinds of other small issues, but I wouldn't say > this is insurmountable. > > I'm gonna wager you'll see some *wicked* crashes when doing this, but > it sounds like you've got a good use case. This would enable you to do > things that you cannot do with an external recording app, or likely > even a GL "recorder" (as a lot of stuff happens out-of-scene). > > + poppy Seems to me that in the long run, this should be a use case to design for. Mechanima will be more and more important in the future. https://wiki.secondlife.com/wiki/Use_Cases#Viewer_related_Use_Cases Lawson From sl-dev at theblob.org Fri Jan 18 15:25:45 2008 From: sl-dev at theblob.org (Kiwi Alfa) Date: Fri Jan 18 15:25:47 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: <47912B69.5080002@cox.net> References: <479119D9.3070405@lindenlab.com> <47912B69.5080002@cox.net> Message-ID: On 1/18/08, Lawson English wrote: > Seems to me that in the long run, this should be a use case to design > for. Mechanima will be more and more important in the future. Not to mention Callum's argument earlier in the thread; it's something I hadn't thought about, but this could also help with creating repeatable test cases for SL bugs - and because they would be captured in a file, they could even be emailed. Think Wireshark on steroids or something. From yoz at lindenlab.com Fri Jan 18 15:26:23 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri Jan 18 15:27:25 2008 Subject: [sldev] WebMap API work & in-world meeting Message-ID: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> Since we released the new version of the webmap, we've never fully followed up with proper documentation as well as getting regular feedback. It was always part of the plan, but more urgent projects managed to sideline it. However, we'd like to start rectifying that now. (If you suspect that SignpostMarv Martin's recent mail has something to do with this, you're absolutely right. I'd also like to extend huge thanks to Harold Brown for his work on the wiki and his OpenLayers experimentation) The WebMap API consists of two separate components: The client side JS library was written by a contractor (in world as Jacquard Looming) and extends the Google Maps API. It was written with the aim of being API-compatible with the previous SL WebMap API, which has been *mostly* achieved though there are still a couple of functions missing (such as SLPoint() ). The services side (which SignpostMarv references at the beginning of his mail) consists of a handful of small functions which query and return region metadata. These were dashed out pretty quickly to support the new webmap (which, in its previous incarnation, was downloading the region metadata for the entire grid in 2MB of regularly-regenerated Javascript - ugh). This year, we want to do a LOT more work to provide useful outward-facing web services, including map-related ones. If there are potential map services that would greatly help your work, we want to know about it. Gulliver Linden is leading the charge here. To start with, we're going to hold an office-hour-style in-world meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: http://slurl.com/secondlife/Beaumont/42/218/35 Gulliver Linden, Jacquard Looming and I will be in attendance. Anyone who's interested in the webmap API is welcome. We look forward to seeing you there! -- Yoz Linden, Program Manager for Web & Internal Tools, Linden Lab From yoz at lindenlab.com Fri Jan 18 15:33:08 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri Jan 18 15:33:15 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> Message-ID: <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> On Jan 18, 2008, at 3:26 PM, Yoz Grahame wrote: > To start with, we're going to hold an office-hour-style in-world > meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: > http://slurl.com/secondlife/Beaumont/42/218/35 ... this Tuesday, the 22nd of January. (Doh.) -- Yoz From dzonatas at dzonux.net Fri Jan 18 15:42:06 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 18 15:41:20 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <47911624.3090304@cox.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <47911567.6060403@cox.net> <47911624.3090304@cox.net> Message-ID: <4791394E.7060406@dzonux.net> Lawson English wrote: > Lawson English wrote: >> Dzonatas wrote: >>> Callum Lerwick wrote: >>>> You're barking up the wrong tree. If you want higher framerates, >>>> figure >>>> out why avatar rendering is so goddamn slow. It dwarfs all other >>>> rendering by far. >>>> >>> >>> (notices subject changed... /me checks-off on list) >>> (changed subject in Subject bar... /me checks-off on list) >>> >>> There was some patches posted to speed up avatar rendering, but that >>> effort has been ..uhm.. derailed. >>> >>> Now that Windlight is coming out with its low quality avi tradeoff >>> for framerates, those patches don't seem to matter anymore. >>> >> >> Well, the WIndlight rendering is a step in the right direction, but >> there's bound to be more that can be done, especially in specific >> circumstances. Bots/Limited Capability Clients that aren't meant to >> have massive bling attachments, for example, might be candidates for >> optimized rendering. >> >> > Which goes back to providing info to the sims about the existence of > such LCC's and what they can actually do. > > There are different issues here: the speed in which the geometry of an avatar is rendered and the speed at which the attachments are rendered. The code is separate. I don't understand why an LCC, or any viewer, would need to tell a sim that it is currently rendering at a low quality. I understand with an LCC that it tells the sim not to send as much info that a viewer would normally get. In the end, the step to remove geometric updates does not actually increase render speed... it just lowers the quality as a tradeoff. The vertex shaders help, but I still would like to see multiprocessor rendering threads. From davep at lindenlab.com Fri Jan 18 15:50:10 2008 From: davep at lindenlab.com (Dave Parks) Date: Fri Jan 18 15:50:12 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <4791394E.7060406@dzonux.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <47911567.6060403@cox.net> <47911624.3090304@cox.net> <4791394E.7060406@dzonux.net> Message-ID: <47913B32.3000902@lindenlab.com> Dzonatas wrote: > > The vertex shaders help, but I still would like to see multiprocessor > rendering threads. Really for GL you want one rendering thread since the machine is thread context sensitive. Putting avatar animations on their own thread would help a lot. So would using worker threads for processing network updates. I've got a design for cutting the time spent updating flexi's in half, too, but they could probably go on a thread as well. From seg at haxxed.com Fri Jan 18 16:50:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jan 18 16:50:17 2008 Subject: [sldev] Avatar Rending Speed (was: How server decide what to send?) In-Reply-To: <4790C9EF.4000501@dzonux.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> Message-ID: <1200703802.20890.30.camel@localhost> On Fri, 2008-01-18 at 07:46 -0800, Dzonatas wrote: > Callum Lerwick wrote: > > You're barking up the wrong tree. If you want higher framerates, figure > > out why avatar rendering is so goddamn slow. It dwarfs all other > > rendering by far. > > > There was some patches posted to speed up avatar rendering, but that > effort has been ..uhm.. derailed. Where? > Now that Windlight is coming out with its low quality avi tradeoff for > framerates, those patches don't seem to matter anymore. Wrong. On even my fastest systems, (Radeon r300's) a mere three avatars on screen drops the framerate like a rock. Impostors may help in really, really busy areas, but they are not the answer. Impostors also eat up valuable texture space. Something seems very very wrong in that hanging out with a mere two or three friends in a mostly empty sandbox kills the framerate so much. I've stood in busy areas and toggled Avatar Vertex programs on and off. At best, there was maybe a 0.1 change in framerate. Vertex programs do not appear to be the answer either. All profiling I've done consistently shows that the vast majority of run time is actually spent inside the OpenGL drivers (and OpenJPEG). This suggests to me that the problem is not a cycle-shaving issue in slviewer, but a fundamental issue in the avatar rendering algorithm, an issue in the way OpenGL is being used. Game engines like Doom3 and Source appear to manage to render larger numbers of much more detailed skeletal animated entities, with much higher performance on the very same hardware. As they're not currently open source, I haven't a clue how they're doing it. And of course SL seems to be locking up my Wintendo upon loading the HTML login screen at the moment, so I can't try and get some real numbers at the moment. Sigh. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080118/dacf10dc/attachment.pgp From dzonatas at dzonux.net Fri Jan 18 16:51:32 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 18 16:50:50 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <47913B32.3000902@lindenlab.com> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <47911567.6060403@cox.net> <47911624.3090304@cox.net> <4791394E.7060406@dzonux.net> <47913B32.3000902@lindenlab.com> Message-ID: <47914994.6070606@dzonux.net> Dave Parks wrote: > Dzonatas wrote: >> >> The vertex shaders help, but I still would like to see multiprocessor >> rendering threads. > > Really for GL you want one rendering thread since the machine is > thread context sensitive. I read OpenGL requires a bit of tuning to get it to work well under multiple threads. The SSE issues I ran into with the viewer exploits the context issues. > Putting avatar animations on their own thread would help a lot. So > would using worker threads for processing network updates. I've got a > design for cutting the time spent updating flexi's in half, too, but > they could probably go on a thread as well. > One thing we tried for a speed up is to change the VBOs vector size from 3 floats to 4 floats in size. The last float is a pad. Then, we used SSE 128bit aligned movs from the worker task to the VBO. I reached 100% speed improvement on my machine, but the pad in the VBO didn't seem to work on all machines (some jira issue around here with vectors in weird places). It worked awesome on mine. For cost, that particular code was dropped and no further work done to track down why the weird vectors occurred on some machines. Later, I wrote a routine to write the normal llvector3 sized VBO with a mix of aligned and unaligned SSE movs. The code work well, also. However, that was when I found by many tests that the viewers 50+ context switches on a single CPU were the real problem to slowdown. In an isolated VBO test code, I saw up to 10x speed improvements, but when the same code was ran in the viewer... it maxed around 30-40% performance gain. I ran VTune on it, and discovered the 50+ context switches and wait-state hotspots. SSE context switches can make any speed improvement look like nada when the cache-lines are hit hard. The avatar rendering speed time isn't the true bog on the frame time. Fastimers can't detect the hotspots that VTune does. So ya, I'm for worker threads. From davep at lindenlab.com Fri Jan 18 17:05:10 2008 From: davep at lindenlab.com (Dave Parks) Date: Fri Jan 18 17:04:47 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <1200703802.20890.30.camel@localhost> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <1200703802.20890.30.camel@localhost> Message-ID: <47914CC6.1010702@lindenlab.com> My numbers could be a bit off here, but one avatar in SL has as many triangles as an enemy soldier in half-life 2 BEFORE attachments (about 8-10k triangles). Attachments can easily add up to over 100k triangles at higher LOD's for a single avatar. Also, enemies in games all tend to have the same material properties, so they can be rendered very quickly in batches together, whereas every character in SL is unique, and most attachments are unique as well, having their own distinct sets of textures, animated texture coordinates, and surface properties (transparent, fullbright, shiny, and now glow). A lot of this has to do with prims. Prims are network light, triangle heavy. I've seen some really awesome looking sculptie avatars that run great. Besides all that, though, it sounds like SL is tickling your GL drivers in a bad way. A few avatars, even with heavy attachments, shouldn't hurt framerate that badly. What's your exact system spec (please include OS version and driver version and viewer version)? Callum Lerwick wrote: > On Fri, 2008-01-18 at 07:46 -0800, Dzonatas wrote: > >> Callum Lerwick wrote: >> >>> You're barking up the wrong tree. If you want higher framerates, figure >>> out why avatar rendering is so goddamn slow. It dwarfs all other >>> rendering by far. >>> >>> > > >> There was some patches posted to speed up avatar rendering, but that >> effort has been ..uhm.. derailed. >> > > Where? > > >> Now that Windlight is coming out with its low quality avi tradeoff for >> framerates, those patches don't seem to matter anymore. >> > > Wrong. On even my fastest systems, (Radeon r300's) a mere three avatars > on screen drops the framerate like a rock. Impostors may help in really, > really busy areas, but they are not the answer. Impostors also eat up > valuable texture space. > > Something seems very very wrong in that hanging out with a mere two or > three friends in a mostly empty sandbox kills the framerate so much. > > I've stood in busy areas and toggled Avatar Vertex programs on and off. > At best, there was maybe a 0.1 change in framerate. Vertex programs do > not appear to be the answer either. > > All profiling I've done consistently shows that the vast majority of run > time is actually spent inside the OpenGL drivers (and OpenJPEG). This > suggests to me that the problem is not a cycle-shaving issue in > slviewer, but a fundamental issue in the avatar rendering algorithm, an > issue in the way OpenGL is being used. > > Game engines like Doom3 and Source appear to manage to render larger > numbers of much more detailed skeletal animated entities, with much > higher performance on the very same hardware. As they're not currently > open source, I haven't a clue how they're doing it. > > And of course SL seems to be locking up my Wintendo upon loading the > HTML login screen at the moment, so I can't try and get some real > numbers at the moment. Sigh. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Fri Jan 18 17:29:47 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 18 17:29:00 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <47914CC6.1010702@lindenlab.com> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <1200703802.20890.30.camel@localhost> <47914CC6.1010702@lindenlab.com> Message-ID: <4791528B.8080305@dzonux.net> Dave Parks wrote: > My numbers could be a bit off here, but one avatar in SL has as many > triangles as an enemy soldier in half-life 2 BEFORE attachments (about > 8-10k triangles). Attachments can easily add up to over 100k > triangles at higher LOD's for a single avatar. Here is a way to count memory and vertexes: Turn on Client->UI->Show Render Info turn off all Client->Rending->Types except Character turn off all Client->Rending->Features except UI That doesn't translate the numbers to triangles. If the info display showed the count of normals, that would be close. From jessesa at gmail.com Fri Jan 18 17:29:49 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Fri Jan 18 17:29:52 2008 Subject: [sldev] Using info from Google DB == Violation: Terms of Service: Permissions Exploit? Message-ID: The information available at http://world.secondlife.com/ opens up several possiblities. My favorite is using it for llKey2Group. http://world.secondlife.com/resident/0bf93171-e0d3-4b8c-b6eb-55d2cc30cf26 is the page for my profile. The same data that is available to anyone who clicks on my profile in world, including the picture I have chosen as my profile pic. One of our more creative scripters has come up with a Random Profile Picture Projecture. Every 20 seconds it will scan the surrounding area, pick a avatar key, send in the http request for that key, parse out the message and display the profile pic as a floating texture. Unfortunately people playing around with the script have now start recieving messages like this from some Lindens: "Violation: Community Standards: Disclosure, Second Life Violation: Terms of Service: Permissions Exploit Their explanation: Residents are entitled to a reasonable level of privacy with regard to their Second Lives. Sharing or posting conversation in-world or in the Second Life Forums without consent of all involved Residents is a violation of other Resident's privacy. Regarding your profile scanner, reports received of profile photos being posted in locations without residents permission. These are violations of Disclosure. Several photos returned depicting residents that advised they gave no permission for photos to be used." We have been banging our heads against the wall over in the Scripting Forum trying to understand how this is a violation when it is information available to anyone who wants to click on our profiles. Hoping we could get some clarification on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080118/1cb18c2c/attachment.htm From alissa_sabre at yahoo.co.jp Fri Jan 18 18:22:33 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jan 18 18:22:49 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <479042C9.4030308@lindenlab.com> References: <478E6559.1000104@lindenlab.com> <2rk8rkGrLarL8rsGrkbrr8G.alissa_sabre@yahoo.co.jp> <479042C9.4030308@lindenlab.com> Message-ID: <75L5ekwr6owwLLbGJkG5uw.alissa_sabre@yahoo.co.jp> > It's a sentiment I've heard around the office. I'm sorry I'm not very good at English. I can't understand such rhetorics. Can't you simply answer my question please? Is the statement you wrote "The embedded recorder really is just for recording bugs," you personal opinion or of Linden Lab as a company? > The main problem I have with it is that it's just so damn slow compared > to external recorders. This discussion is on Tarari's patch. Her patch greately improves the recording performance. That's why she did it. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From adam at gwala.net Fri Jan 18 19:00:30 2008 From: adam at gwala.net (Adam Frisby) Date: Fri Jan 18 19:01:27 2008 Subject: [sldev] simulate a sim restart In-Reply-To: <4790F034.1050900@lindenlab.com> References: <4790F034.1050900@lindenlab.com> Message-ID: <479167CE.5030600@gwala.net> Could use OpenSim too, then you can just use the console 'restart' command. :) Joshua Bell wrote: > Anna Gulaev wrote: > >> Has anyone figured out a decent way to simulate a sim restart? >> >> In today's rolling restart my client crashed on sim restart rather >> than logging me off, which popped a runtime error dialog, which >> prevented the viewer from exiting and triggering the restart script >> with fallback timer. In short, it misbehaved. >> >> Has anyone already invented this wheel? I'd like to be able to >> simulate a sim restart so I can make sure my code fails gracefully. > > I'm happy to bounce a sim on the beta grid (aditi) while you're > connected, if that'll do. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From davep at lindenlab.com Fri Jan 18 19:46:59 2008 From: davep at lindenlab.com (Dave Parks) Date: Fri Jan 18 19:47:24 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <4791528B.8080305@dzonux.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <1200703802.20890.30.camel@localhost> <47914CC6.1010702@lindenlab.com> <4791528B.8080305@dzonux.net> Message-ID: <479172B3.3030200@lindenlab.com> I wrote For triangle count look at "KTris Drawn" in the stats bar (View->Statistics Bar->Advanced->Render->KTris Drawn). That number does not include the UI. With one avatar and nothing else, it's 10.9 thousand triangles per frame. On my computer this clocks in at around 200 fps, so rendering a single avatar without attachments is really just noise in the pipe, so I'm interested to know what kind of computer can't handle 3 avatars and why. A 9700 Pro is getting pretty dated (that's a 6 year old card you're talking about), but it should be ok with a few avatars unless you're running linux (ATI support for linux is not so good). When I put on my primiest outfit (which isn't very primmy, I am a performance nut after all), triangle count jumps to 72k/frame with the camera zoomed right up on my avatar, but framerate stays within noise (anything over 60 hz is a moot point, anyway). This is with the latest windlight client. Dzonatas wrote: > Dave Parks wrote: >> My numbers could be a bit off here, but one avatar in SL has as many >> triangles as an enemy soldier in half-life 2 BEFORE attachments >> (about 8-10k triangles). Attachments can easily add up to over 100k >> triangles at higher LOD's for a single avatar. > Here is a way to count memory and vertexes: > > Turn on Client->UI->Show Render Info > > turn off all Client->Rending->Types except Character > turn off all Client->Rending->Features except UI > > That doesn't translate the numbers to triangles. If the info display > showed the count of normals, that would be close. From jessesa at gmail.com Fri Jan 18 20:03:28 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Fri Jan 18 20:03:38 2008 Subject: [sldev] Re: Using info from Google DB == Violation: Terms of Service: Permissions Exploit? In-Reply-To: References: Message-ID: On 1/18/08, Jesse Barnett wrote: > > The information available at http://world.secondlife.com/ opens up several > possiblities. My favorite is using it for llKey2Group. > http://world.secondlife.com/resident/0bf93171-e0d3-4b8c-b6eb-55d2cc30cf26is the page for my profile. The same data that is available to anyone who > clicks on my profile in world, including the picture I have chosen as my > profile pic. One of our more creative scripters has come up with a Random > Profile Picture Projecture. Every 20 seconds it will scan the surrounding > area, pick a avatar key, send in the http request for that key, parse out > the message and display the profile pic as a floating texture. Unfortunately > people playing around with the script have now start recieving messages like this from some Lindens: > > > "Violation: Community Standards: Disclosure, Second Life > > Violation: Terms of Service: Permissions Exploit > > Their explanation: > Residents are entitled to a reasonable level of privacy with > regard to their Second Lives. Sharing or posting > conversation in-world or in the Second Life Forums without > consent of all involved Residents is a violation of other > Resident's privacy. > > Regarding your profile scanner, reports received of profile photos being > posted in locations without residents permission. These are violations of > Disclosure. Several photos returned depicting residents that > advised they gave no permission for photos to be used." > > We have been banging our heads against the wall over in the Scripting > Forum trying to understand how this is a violation when it is information > available to anyone who wants to click on our profiles. > > Hoping we could get some clarification on this? > Apologies. This was supposed to have gone to the Scripters list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080118/f533f1ae/attachment.htm From gigstaggart at gmail.com Fri Jan 18 21:05:07 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jan 18 21:05:10 2008 Subject: [sldev] Re: Using info from Google DB == Violation: Terms of Service: Permissions Exploit? In-Reply-To: References: Message-ID: <47918503.9070606@gmail.com> Jesse Barnett wrote: > "Violation: Community Standards: Disclosure, Second Life > > Violation: Terms of Service: Permissions Exploit Welcome to Second Life, where the level of ignorant screaming is how policy is determined. -Jason From lenglish5 at cox.net Sat Jan 19 00:55:21 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 00:55:24 2008 Subject: [sldev] Machinima and recording movies/demos in SL In-Reply-To: References: <479119D9.3070405@lindenlab.com> <47912B69.5080002@cox.net> Message-ID: <4791BAF9.1090107@cox.net> Kiwi Alfa wrote: > On 1/18/08, Lawson English wrote: > >> Seems to me that in the long run, this should be a use case to design >> for. Mechanima will be more and more important in the future. >> > > Not to mention Callum's argument earlier in the thread; it's something > I hadn't thought about, but this could also help with creating > repeatable test cases for SL bugs - and because they would be captured > in a file, they could even be emailed. Think Wireshark on steroids or > something. > > I think the current SL protocols are too complex to capture that way, but I might be wrong. Once the implementation via CAPs gets further along, might be more doable though. You might want to look at the SLProxy application that comes with libsecondlife. it captures packets going both ways, already. I'd refer you to my Python equivalent, but don't have that working (yet). Lawson From lenglish5 at cox.net Sat Jan 19 00:56:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 00:56:59 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> Message-ID: <4791BB57.2030401@cox.net> Yoz Grahame wrote: > > To start with, we're going to hold an office-hour-style in-world > meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: > http://slurl.com/secondlife/Beaumont/42/218/35 > > Gulliver Linden, Jacquard Looming and I will be in attendance. Anyone > who's interested in the webmap API is welcome. We look forward to > seeing you there! > > -- Yoz Linden, Program Manager for Web & Internal Tools, Linden Lab > You forgot the day... Lawson From lenglish5 at cox.net Sat Jan 19 00:57:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 00:57:18 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> Message-ID: <4791BB6A.5040102@cox.net> Yoz Grahame wrote: > > On Jan 18, 2008, at 3:26 PM, Yoz Grahame wrote: >> To start with, we're going to hold an office-hour-style in-world >> meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: >> http://slurl.com/secondlife/Beaumont/42/218/35 > > ... this Tuesday, the 22nd of January. (Doh.) > > -- Yoz > ;-) L From lenglish5 at cox.net Sat Jan 19 00:59:33 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 00:59:40 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <4791BB6A.5040102@cox.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> <4791BB6A.5040102@cox.net> Message-ID: <4791BBF5.2090501@cox.net> Lawson English wrote: > Yoz Grahame wrote: >> >> On Jan 18, 2008, at 3:26 PM, Yoz Grahame wrote: >>> To start with, we're going to hold an office-hour-style in-world >>> meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: >>> http://slurl.com/secondlife/Beaumont/42/218/35 >> >> ... this Tuesday, the 22nd of January. (Doh.) >> >> -- Yoz >> > ;-) Oops that conflicts with the AW Groupies meeting. Guess I can send an alt and multi-task but its ironic to hold a meeting about documentation and API/protocols that conflicts with the AW Groupies' since we've been kvetching about the lack thereof for quite a few weeks now. L. From lenglish5 at cox.net Sat Jan 19 01:02:54 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 01:02:59 2008 Subject: [sldev] Avatar Rending Speed In-Reply-To: <4791394E.7060406@dzonux.net> References: <1200616779.15354.67.camel@localhost> <4790C9EF.4000501@dzonux.net> <47911567.6060403@cox.net> <47911624.3090304@cox.net> <4791394E.7060406@dzonux.net> Message-ID: <4791BCBE.5050405@cox.net> Dzonatas wrote: > Lawson English wrote: >> Lawson English wrote: >>> Dzonatas wrote: >>>> Callum Lerwick wrote: >>>>> You're barking up the wrong tree. If you want higher framerates, >>>>> figure >>>>> out why avatar rendering is so goddamn slow. It dwarfs all other >>>>> rendering by far. >>>>> >>>> >>>> (notices subject changed... /me checks-off on list) >>>> (changed subject in Subject bar... /me checks-off on list) >>>> >>>> There was some patches posted to speed up avatar rendering, but >>>> that effort has been ..uhm.. derailed. >>>> >>>> Now that Windlight is coming out with its low quality avi tradeoff >>>> for framerates, those patches don't seem to matter anymore. >>>> >>> >>> Well, the WIndlight rendering is a step in the right direction, but >>> there's bound to be more that can be done, especially in specific >>> circumstances. Bots/Limited Capability Clients that aren't meant to >>> have massive bling attachments, for example, might be candidates for >>> optimized rendering. >>> >>> >> Which goes back to providing info to the sims about the existence of >> such LCC's and what they can actually do. >> >> > > There are different issues here: the speed in which the geometry of an > avatar is rendered and the speed at which the attachments are > rendered. The code is separate. Didn't realize that. Though I'm still wondering if it is truly orthogonal, even if the client-side rendering is. The server might still treat avatras the same on its side, even when its certain that no attachments will be present. > > I don't understand why an LCC, or any viewer, would need to tell a sim > that it is currently rendering at a low quality. I understand with an > LCC that it tells the sim not to send as much info that a viewer would > normally get. In the end, the step to remove geometric updates does > not actually increase render speed... it just lowers the quality as a > tradeoff. > > The vertex shaders help, but I still would like to see multiprocessor > rendering threads. > From lenglish5 at cox.net Sat Jan 19 01:41:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 01:41:31 2008 Subject: [sldev] Musing over possible connection between VWR-3951 and SVC-972 In-Reply-To: <478E3A9D.1080409@lindenlab.com> References: <478C0170.4050808@lindenlab.com> <478C1016.3040605@lindenlab.com> <478C150C.10709@lindenlab.com> <95F36982-F514-41F7-A427-FCBE1D671E3B@fastmail.fm> <478C1B66.5000807@cox.net> <478D9DB4.4070504@Arnholm.se> <478E3A9D.1080409@lindenlab.com> Message-ID: <4791C5C7.5010305@cox.net> Joshua Bell wrote: > Matthew Dowd wrote: >> Now, I don't know the LL web server topology, so I don't know if the >> same "web servers" are involved here, or if different web servers are >> involved whether they are running the same software, but from the >> outside, it does seem plausible that the same problem which causes >> the URL mangling on the web servers used in the authentication might >> also be causing similar problems with other communications which >> happen between the client and the SL services i.e. might be behind >> the teleport issue above, and perhaps some other issues? >> >> Anyone from LL, who knows the system care to comment? >> > Interesting speculation. IMHO it's unlikely... the HTTP servers are > radically different (hardware, server code, libraries, subnets, etc). > But worth pondering! I believe Jake has made more progress in tracking > down causes (yes, multiple) of the logoff-during-teleport issue. I'll > ping him and see if he can comment further. > _______________________________________________ Can't comment too much, save to point out that there are plausible interdependencies all over the place with anything associated with ImprovedInstantMessage. And that means just about anything and everything. http://wiki.secondlife.com/wiki/ImprovedInstantMessage Lawson From ts_ryuzo at hotmail.com Sat Jan 19 06:00:03 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sat Jan 19 06:00:05 2008 Subject: [sldev] How server decide what to send? In-Reply-To: <478FF7B9.1070501@neon.ai> References: <1200616779.15354.67.camel@localhost> <478FF7B9.1070501@neon.ai> Message-ID: I am new to networking games. When many clients are requesting for data, does the server send everything to a user then go to another client? Or the server send some data to a client, send a bit to another client then come back again? Regards, Qian Hao Date: Fri, 18 Jan 2008 09:50:01 +0900From: ian@neon.aiTo: seg@haxxed.comSubject: Re: [sldev] How server decide what to send?CC: sldev@lists.secondlife.com Is frame rate limited in any way or is it purely a function of the available processing power?If you had an environment with little other geometry (inside a small room for example) and few other avatars (maybe 4 in total) would this improve performance greatly?Callum Lerwick wrote: On Fri, 2008-01-18 at 00:00 +0800, Qian Hao ~ wrote: Hi, It's about rendering again. Previously, I understand that the client does not request for what they see in front of them but send a camera to the server and the server will send back the prims. Is there any decision algorithm that the server run to decide what to send first? Secondly, is it right that the client, after receiving the prims will run occlusion and culling then tell the server what texture file they need? I was thinking maybe we can write an algorithm to predict player's movement and send a "fake" camera to the server to get the necessary prims from the server first before the player actually move to that location or direction. Will that improve the performance of the client? You're barking up the wrong tree. If you want higher framerates, figure out why avatar rendering is so goddamn slow. It dwarfs all other rendering by far. _______________________________________________ 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/20080119/7a2e46a7/attachment.htm From agrimes at speakeasy.net Sat Jan 19 15:08:49 2008 From: agrimes at speakeasy.net (Alan Grimes) Date: Sat Jan 19 14:09:42 2008 Subject: [sldev] Second Life on eee PC. Message-ID: <47928301.2010603@speakeasy.net> I put second life on my new asus eee pc, (900mhz/512mb/Intel 910/linux/~1gb user HD space) the biggest issue is that the configuration dialog boxes are too tall to fit on the 480(I think) line screen and it's impossible to get to the options lower on the screen and hit the OK button. -- Ron Paul: A man of Peace. Chemistry.com: A total rip-off. From ordinal.malaprop at fastmail.fm Sat Jan 19 14:46:41 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sat Jan 19 14:46:46 2008 Subject: [sldev] Second Life on eee PC. In-Reply-To: <47928301.2010603@speakeasy.net> References: <47928301.2010603@speakeasy.net> Message-ID: Oh, that's interesting - I haven't even tried with mine, although I have been using it quite happily to edit scripts and mindmap and deal with my SVN repository and so on. Is that the 2 or the 4 gig model? On 19 Jan 2008, at 23:08, Alan Grimes wrote: > I put second life on my new asus eee pc, (900mhz/512mb/Intel > 910/linux/~1gb user HD space) the biggest issue is that the > configuration dialog boxes are too tall to fit on the 480(I think) > line > screen and it's impossible to get to the options lower on the screen > and > hit the OK button. > > -- > Ron Paul: A man of Peace. > Chemistry.com: A total rip-off. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Sat Jan 19 15:00:50 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 19 15:00:53 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> Message-ID: <47928122.9020306@cox.net> Yoz Grahame wrote: > > > To start with, we're going to hold an office-hour-style in-world > meeting at 9:30AM SLT, at Meta Linden's place in Beaumont: > http://slurl.com/secondlife/Beaumont/42/218/35 > > Gulliver Linden, Jacquard Looming and I will be in attendance. Anyone > who's interested in the webmap API is welcome. We look forward to > seeing you there! > > -- Yoz Linden, Program Manager for Web & Internal Tools, Linden Lab I set up a stub for a Map API Viewpoint Advocacy Group (VAG): https://wiki.secondlife.com/wiki/Map_API_VAG Enjoy. Lawson From me at signpostmarv.name Sat Jan 19 15:38:15 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat Jan 19 15:38:19 2008 Subject: [sldev] Second Life on eee PC. In-Reply-To: <47928301.2010603@speakeasy.net> References: <47928301.2010603@speakeasy.net> Message-ID: <479289E7.6040701@signpostmarv.name> Have you tried editing the XUI files to be more suitable for the lower resolution ? Alan Grimes wrote: > I put second life on my new asus eee pc, (900mhz/512mb/Intel > 910/linux/~1gb user HD space) the biggest issue is that the > configuration dialog boxes are too tall to fit on the 480(I think) line > screen and it's impossible to get to the options lower on the screen and > hit the OK button. > > -------------- 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/20080119/35fdc9a3/smime.bin From seg at haxxed.com Sat Jan 19 16:47:59 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jan 19 16:48:08 2008 Subject: [sldev] [PATCH]Improving Recording Movie In-Reply-To: <75L5ekwr6owwLLbGJkG5uw.alissa_sabre@yahoo.co.jp> References: <478E6559.1000104@lindenlab.com> <2rk8rkGrLarL8rsGrkbrr8G.alissa_sabre@yahoo.co.jp> <479042C9.4030308@lindenlab.com> <75L5ekwr6owwLLbGJkG5uw.alissa_sabre@yahoo.co.jp> Message-ID: <1200790079.20890.59.camel@localhost> On Sat, 2008-01-19 at 11:22 +0900, Alissa Sabre wrote: > > It's a sentiment I've heard around the office. > > I'm sorry I'm not very good at English. I can't understand such > rhetorics. Can't you simply answer my question please? Is the statement > you wrote "The embedded recorder really is just for recording bugs," > you personal opinion or of Linden Lab as a company? He's saying that it is the opinion of an un-specified number of Lindens. And we should all know by now that getting any kind of statement from Linden Lab as a company is like squeezing blood from a stone, so do not expect to get one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080119/f4c0bee0/attachment.pgp From ts_ryuzo at hotmail.com Sat Jan 19 20:26:55 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sat Jan 19 20:26:58 2008 Subject: [sldev] Precaching time Message-ID: Hi, I found this piece of code in llviewerdisplay that can control the pre caching time before the "curtain" is pulled. So I tried setting it to 20.f which I think it means 20 seconds. However, when it finally finished loaded, I don't see a nicely rendered view right in front of me. Things start popping up one by one except that this time it pops up faster. On the other hand, if i set it to 2.f and wait several seconds for things to render, I can see nicely rendered image and less time taken than 20.f. Can someone explain to me what the precaching is doing and why 20.f rendering is still that slow? Regards, Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080120/c8b21c5f/attachment.htm From labrat.hb at gmail.com Sat Jan 19 23:03:04 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Sat Jan 19 23:03:06 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <47928122.9020306@cox.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> Message-ID: Unfortunatly I have a weekly meeting RL at work at the time scheduled. As for things I'd like to see. 1. Up to date map images for all zoom levels 2. Web Map Service (WMS) or Tile Map Service (TMS) host for pulling map tiles (OpenLayers has support for these two services) 3. More detail available by query from the web (Number of AV's, Prims used, etc.) possibly limited with more available to estate owner via a key From dzonatas at dzonux.net Sat Jan 19 23:43:06 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 19 23:42:09 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> Message-ID: <4792FB8A.4090109@dzonux.net> Harold Brown wrote: > Unfortunatly I have a weekly meeting RL at work at the time scheduled. > > As for things I'd like to see. > > 1. Up to date map images for all zoom levels > 2. Web Map Service (WMS) or Tile Map Service (TMS) host for pulling > map tiles (OpenLayers has support for these two services) > 3. More detail available by query from the web (Number of AV's, Prims > used, etc.) possibly limited with more available to estate owner via > a key 4. Landbots and how they would use the above information, who stores such information, and all who is entrusted with such information. 5. The complete history of the Linden dollar, its value, its enumeration, how it was worked for, how it was trusted from the day it was first created, and how every bit of it was earned. 6. A ceremony to bring together the 22 day of this month as the day WebAPI is given new life so you will see your world, how the AWG protocol brings it a robust and powerful protocol so you will have your imagination, and the day the banks of Second Life shall see no ROI except the almighty LindeX. May the meeting be a good one... or the last of its kind. From labrat.hb at gmail.com Sun Jan 20 00:04:30 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Jan 20 00:04:32 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <4792FB8A.4090109@dzonux.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> Message-ID: Thank you for the non-productive sarcastic post. As two of the items have absolutely nothing to do with a Web Map API.. and the third only marginally as nothing provided would benefit a landbot. As for AWG... I don't see the Web Map API as being a part of that project. But at the very least I do think it should be able to provide the same amount of information that is available via the in-world map. On Jan 19, 2008 11:43 PM, Dzonatas wrote: > > Harold Brown wrote: > > Unfortunatly I have a weekly meeting RL at work at the time scheduled. > > > > As for things I'd like to see. > > > > 1. Up to date map images for all zoom levels > > 2. Web Map Service (WMS) or Tile Map Service (TMS) host for pulling > > map tiles (OpenLayers has support for these two services) > > 3. More detail available by query from the web (Number of AV's, Prims > > used, etc.) possibly limited with more available to estate owner via > > a key > 4. Landbots and how they would use the above information, who stores > such information, and all who is entrusted with such information. > 5. The complete history of the Linden dollar, its value, its > enumeration, how it was worked for, how it was trusted from the day it > was first created, and how every bit of it was earned. > 6. A ceremony to bring together the 22 day of this month as the day > WebAPI is given new life so you will see your world, how the AWG > protocol brings it a robust and powerful protocol so you will have your > imagination, and the day the banks of Second Life shall see no ROI > except the almighty LindeX. > > May the meeting be a good one... or the last of its kind. > > From dzonatas at dzonux.net Sun Jan 20 01:01:22 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jan 20 01:00:24 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> Message-ID: <47930DE2.10002@dzonux.net> Harold Brown wrote: > Thank you for the non-productive sarcastic post. > You're welcome for the productive simplification of the resonance from the e-mails received. > As two of the items have absolutely nothing to do with a Web Map API.. > Like if the apple that fell from a tree had absolutely nothing to do with the math of gravity. From lenglish5 at cox.net Sun Jan 20 01:09:30 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Jan 20 01:09:33 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> Message-ID: <47930FCA.1090504@cox.net> Harold Brown wrote: > Thank you for the non-productive sarcastic post. > > As two of the items have absolutely nothing to do with a Web Map API.. > and the third only marginally as nothing provided would benefit a > landbot. > > As for AWG... I don't see the Web Map API as being a part of that project. > > But at the very least I do think it should be able to provide the same > amount of information that is available via the in-world map. > > If it were merely going to be a better Second Life Map API, then it probably wouldn't have any relationship to the AWG, but the goal, as I understand it, is not only to make it "better," but to make it usable for 3rd-party grids and sims. That certainly intersects with the short and long-term work of the AWG, especially if the same or similar inter-grid data is to be used inside the client for things like TP destinations. You can't TP from a SL sim to an OpenSim sim (or back) without having a destination, and in-keeping with the idea of making the meta-grid interactions as seamless as possible, people will want to see a map image of where they are heading, if at all possible. THAT is certainly an AWG issue. Lawson From fairlight at tigress.com Sun Jan 20 01:51:56 2008 From: fairlight at tigress.com (Fairlight) Date: Sun Jan 20 01:52:23 2008 Subject: [sldev] Web Login / Vista In-Reply-To: <47930FCA.1090504@cox.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> Message-ID: Hi! I am just wondering if anyone else has the problem with the Web-based login (a seen in the current WindLight viewer) that, upon rendering the login screen, the entire PC freezes and all you can do is reset the machine? It's perfectly reproducable here, and I had it with the last 2 versions of WindLight as well. With the last 2 versions, however, deleting the Secondlife folder in my profile seems to have helped, whereas now it just always freezes. (FYI, I am using Vista Ultimate 32bit) Seeyas, Fairlight! From me at signpostmarv.name Sun Jan 20 04:18:40 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Jan 20 04:18:41 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <47930FCA.1090504@cox.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> Message-ID: <47933C20.4090503@signpostmarv.name> Lawson English wrote: > If it were merely going to be a better Second Life Map API, then it > probably wouldn't have any relationship to the AWG, but the goal, as I > understand it, is not only to make it "better," but to make it usable > for 3rd-party grids and sims. That certainly intersects with the short > and long-term work of the AWG, especially if the same or similar > inter-grid data is to be used inside the client for things like TP > destinations. You can't TP from a SL sim to an OpenSim sim (or back) > without having a destination, and in-keeping with the idea of making > the meta-grid interactions as seamless as possible, people will want > to see a map image of where they are heading, if at all possible. THAT > is certainly an AWG issue. People might be interested in Map.llsd ( http://dev.signpostmarv.name/pub/llsd-grid-map/map.llsd.0.2.xml ), a spec I worked in with some of the OpenSim peeps to represent the data relevant to a map of a grid in a single file (which would be a hell of a lot better to use than constant poking of LL's current webmap API) ~ 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/20080120/2f6d2980/smime.bin From secret.argent at gmail.com Sun Jan 20 07:01:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jan 20 07:01:17 2008 Subject: [sldev] How server decide what to send? In-Reply-To: References: <1200616779.15354.67.camel@localhost> <478FF7B9.1070501@neon.ai> Message-ID: On 2008-01-19, at 22:19, Qian Hao ~ wrote: > Then my next question is, is there any algorithm to make decision > on what to send to the client first? Or was it purely random? Or > the server run some raytracing a-like algorithm? There have been several messages posted to the list recently describing in broad terms the way the server fills its "interest list" for each user. Check the archives. From seg at haxxed.com Sun Jan 20 14:01:47 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jan 20 14:01:54 2008 Subject: [sldev] Web Login / Vista In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> Message-ID: <1200866507.20890.76.camel@localhost> On Sun, 2008-01-20 at 09:51 +0000, Fairlight wrote: > Hi! > > I am just wondering if anyone else has the problem with the Web-based > login (a seen in the current WindLight viewer) that, upon rendering the > login screen, the entire PC freezes and all you can do is reset the > machine? It's perfectly reproducable here, and I had it with the last 2 > versions of WindLight as well. With the last 2 versions, however, deleting > the Secondlife folder in my profile seems to have helped, whereas now it > just always freezes. (FYI, I am using Vista Ultimate 32bit) Wow, so its not just me? On plain old XP Pro SP2. I swear "I Didn't Change Anything". I hadn't logged in to SL in like a month, so the client version hasn't changed, and I haven't upgraded my video drivers. But now it locks up. Both Windlight and 1.18.5.3. Wonderful. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080120/1924e909/attachment.pgp From fairlight at tigress.com Sun Jan 20 14:23:17 2008 From: fairlight at tigress.com (Fairlight) Date: Sun Jan 20 14:23:22 2008 Subject: [sldev] Web Login / Vista In-Reply-To: <1200866507.20890.76.camel@localhost> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> <1200866507.20890.76.camel@localhost> Message-ID: Hi! And your system freezes also in the login screen? I see the login screen, and I see it loading the elements of the UI, like buttons, etc. from the web and then it freezes, without further interaction. Not even ctrl-alt-del revives it. Reset button is the only option. Seeya, Fairlight! On Sun, 20 Jan 2008 22:01:47 -0000, Callum Lerwick wrote: > > On Sun, 2008-01-20 at 09:51 +0000, Fairlight wrote: >> Hi! >> >> I am just wondering if anyone else has the problem with the Web-based >> login (a seen in the current WindLight viewer) that, upon rendering the >> login screen, the entire PC freezes and all you can do is reset the >> machine? It's perfectly reproducable here, and I had it with the last 2 >> versions of WindLight as well. With the last 2 versions, however, >> deleting >> the Secondlife folder in my profile seems to have helped, whereas now it >> just always freezes. (FYI, I am using Vista Ultimate 32bit) > > Wow, so its not just me? On plain old XP Pro SP2. I swear "I Didn't > Change Anything". I hadn't logged in to SL in like a month, so the > client version hasn't changed, and I haven't upgraded my video drivers. > But now it locks up. Both Windlight and 1.18.5.3. Wonderful. -------------------------------------------- From annagulaev at gmail.com Sun Jan 20 15:11:12 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun Jan 20 15:11:14 2008 Subject: [sldev] simulate a sim restart In-Reply-To: <479167CE.5030600@gwala.net> References: <4790F034.1050900@lindenlab.com> <479167CE.5030600@gwala.net> Message-ID: Thanks for the suggestion. It was quite easy to build and install. Surprising how small it is. I was able to test being booted, and was a bit surprised that I was gracefully disconnected in the same way I'm normally gracefully disconnected, but I was unable to reproduce the crash. Hopefully my exit-to-restart-script will work now regardless the cause of the crash. On my home-hosted sim I was also unable to test automatic recognition of AvatarMoved, but might try that out on a multi-region open grid. Thanks. On 1/18/08, Adam Frisby wrote: > > Could use OpenSim too, then you can just use the console 'restart' > command. :) > > Joshua Bell wrote: > > > Anna Gulaev wrote: > > > >> Has anyone figured out a decent way to simulate a sim restart? > >> > >> In today's rolling restart my client crashed on sim restart rather > >> than logging me off, which popped a runtime error dialog, which > >> prevented the viewer from exiting and triggering the restart script > >> with fallback timer. In short, it misbehaved. > >> > >> Has anyone already invented this wheel? I'd like to be able to > >> simulate a sim restart so I can make sure my code fails gracefully. > > > > I'm happy to bounce a sim on the beta grid (aditi) while you're > > connected, if that'll do. > > _______________________________________________ > > 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/20080120/cedc9ce9/attachment.htm From thomas.shikami at online.de Sun Jan 20 16:17:44 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Sun Jan 20 16:17:46 2008 Subject: [sldev] Precaching time In-Reply-To: References: Message-ID: <4793E4A8.6000806@online.de> Qian Hao ~ wrote: > Can someone explain to me what the precaching is doing and why 20.f > rendering is still that slow? there are texture uuids found inside a file texture_list_home.xml and texture_list_last.xml, these may be used for texture downloading and decoding during the precaching phase. Can someone confirm this? The files reside inside the (Application Data)\SecondLife\(firstname)_(lastname) folder From sekundlife at yahoo.com Mon Jan 21 00:25:12 2008 From: sekundlife at yahoo.com (Kundanv Indigo) Date: Mon Jan 21 00:25:15 2008 Subject: [sldev] How to Include our own XML data in Sl Message-ID: <408915.27842.qm@web94909.mail.in2.yahoo.com> Hi I got a requirement where I have a data in my XML, and I like to access in the viewer source code. I came to know SL its own defined expat parser, Is there any documentation which helps in writing XML file which reads the data from a function defined in source code(serialization) in SL defined standard, or any other way. please help Thanks kundanv Indigo SL. Did you know? You can CHAT without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080121/2fa5582a/attachment.htm From kamilion at gmail.com Mon Jan 21 04:12:40 2008 From: kamilion at gmail.com (Kamilion) Date: Mon Jan 21 04:12:44 2008 Subject: [sldev] Re: LSL and geometry hierarchy issues (Mark Meijer) In-Reply-To: <2EF503BA-CCB1-48FB-B4FD-56198BAFC531@gmail.com> References: <20080120231353.AD20741B2BE@stupor.lindenlab.com> <2EF503BA-CCB1-48FB-B4FD-56198BAFC531@gmail.com> Message-ID: On Jan 20, 2008 3:36 PM, Argent Stonecutter wrote: > Oh my, what mixed feelings! I heartily agree with your assessment of > Mono - it is a wheel to heavy for the axle that LSL (or any > comparable wheel) must ride upon. Most of the open source > alternatives that come to mind, though, are also quite hefty. > > What languages, though, do you think would serve significantly better > than LSL? The ones that come mind for me are Scheme and Forth, simply > because both have a simple inner interpreter that could readily be > wrapped around any axle. The other names that come up in these > discussions - Lua, Tcl, Javascript, and the like - are likely too > heavy already. What about Ruby 1.9? Or is that a little too risky, considering you can even monkeypatch the core from the debugger console? For those who arn't aware, Ruby is a fully object oriented language. Everything is an object. Objects have methods. Any method or any object can redefine methods. It can be quite english-like to read. @future = 2.weeks.from.now unless today(:christmas) if @future.nil @future = "There is no future" @future += String.new(" but what we make") if currentyear == 1983 @future << [" ", "--", " ", "Sarah", " ", "J.", " ", "Connor"] end It should be noted: Ruby 1.9 was just released with an entirely new runtime engine called YARV with MUCH MUCH improved performance. Ruby 1.8 is quite pokey in comparison. There are also other ruby VMs... jRuby for java, IronRuby for .net/Mono... However, make no mistake, I support Mono over all of the other solutions. Reason One: OpenSim can already run C# scripts, http://teddmaa.blogspot.com/2007/09/pure-c-support.html Reason Two: Mono can interpret practically any language. IronRuby, IronPython, C#, Perl, Parrot, Javascript, VB and so on, http://www.oreillynet.com/xml/blog/2007/05/monodlr_hello_dynamic_language.html Reason Three: Eventually, simulators may be embedded in commercial devices. (I already have a single OpenSim simulator running on a Linksys NSLU2.) Makes sense to use something that can speak any language. Reason Four: Eventually, the client may gain a mono VM of it's own. Or, a new viewer based on libsecondlife that can render textures prims & particles will eventually work. There are already gecko bindings for .net/mono. Reason Five: Mono allows for near-limitless expansion. No limits are *required* to be set. Reason Six: Mono-based scripts will most likely gain properties of their own: UI-set resource limits (In the Properties panel for a script, allow process priority & memory allocation -- Set it at 32KB of memory. Or 128KB of memory. Or if it only requires 2KB of memory, why use the default of 16KB?) or script-requested resource limit expansions. (Wouldn't it be great to allocate an extra 16KB just before you llHTTPRequest a large page, do your parsing, then release the extra memory?) It's far better to do all your work in a single 64KB script than split it into 10 smaller 16KB scripts with huge linked message routines. Object owners should be able to specify script priorities. Got an SLEx cube? High priority. Couch with anim-balls? Low priority. Mono is still young. With a little lovin' and optimization it could really grow to be a stable and useful plot device. After all.... Look at the story of OpenJPEG: Went from being too slow to be usable to nearly on par with libkdu. Just needed some clever people to notice it. There's always low-hanging fruit to pluck. Lindens, Is it possible to get a simulator running the mono engine somewhere on the beta grid with the new het-grid stuff? Perhaps named something like "Mono Sandbox" ? I know it's partially working and still buggy, but so's havok4. It would be nice to be able to play with it, even if it's not finished. Who cares if the sim crashes every hour if you can spend five minutes poking with a script that works so much faster? Debug logs are useful too! And I bet we can point out some glaring bugs too, just like Havok4. Since Joshua Bell was kind enough to share the LL roadmap with us on SLDEV, could we at least get a little data about where the mono project is, what's done, what's broke, and what we can do to help fix it? From kamilion at gmail.com Mon Jan 21 04:24:17 2008 From: kamilion at gmail.com (Kamilion) Date: Mon Jan 21 04:24:23 2008 Subject: [sldev] Re: LSL and geometry hierarchy issues (Mark Meijer) In-Reply-To: References: <20080120231353.AD20741B2BE@stupor.lindenlab.com> <2EF503BA-CCB1-48FB-B4FD-56198BAFC531@gmail.com> Message-ID: Guess I should finish reading my mail before replying to messages.... Ooopsie! https://lists.secondlife.com/pipermail/secondlifescripters/2008-January/002135.html On 1/20/08, Jesse Barnett wrote: > On 1/20/08, Mark Meijer wrote: > > > > What was the last we heard about it? > > > Just last week; http://wiki.secondlife.com/wiki/Mono > "Target date for the Mono beta is 31 January 2008." Color me impressed. Still though, I am indeed interested in this topic. On Jan 21, 2008 4:12 AM, Kamilion wrote: > On Jan 20, 2008 3:36 PM, Argent Stonecutter wrote: > > Oh my, what mixed feelings! I heartily agree with your assessment of > > Mono - it is a wheel to heavy for the axle that LSL (or any > > comparable wheel) must ride upon. Most of the open source > > alternatives that come to mind, though, are also quite hefty. > > > > What languages, though, do you think would serve significantly better > > than LSL? The ones that come mind for me are Scheme and Forth, simply > > because both have a simple inner interpreter that could readily be > > wrapped around any axle. The other names that come up in these > > discussions - Lua, Tcl, Javascript, and the like - are likely too > > heavy already. > > What about Ruby 1.9? Or is that a little too risky, considering you > can even monkeypatch the core from the debugger console? > > For those who arn't aware, Ruby is a fully object oriented language. > Everything is an object. Objects have methods. Any method or any > object can redefine methods. > > It can be quite english-like to read. > > @future = 2.weeks.from.now unless today(:christmas) > > if @future.nil > @future = "There is no future" > @future += String.new(" but what we make") if currentyear == 1983 > @future << [" ", "--", " ", "Sarah", " ", "J.", " ", "Connor"] > end > > > It should be noted: Ruby 1.9 was just released with an entirely new > runtime engine called YARV with MUCH MUCH improved performance. Ruby > 1.8 is quite pokey in comparison. > > There are also other ruby VMs... jRuby for java, IronRuby for .net/Mono... > > > > > However, make no mistake, I support Mono over all of the other solutions. > > Reason One: OpenSim can already run C# scripts, > http://teddmaa.blogspot.com/2007/09/pure-c-support.html > > Reason Two: Mono can interpret practically any language. IronRuby, > IronPython, C#, Perl, Parrot, Javascript, VB and so on, > http://www.oreillynet.com/xml/blog/2007/05/monodlr_hello_dynamic_language.html > > Reason Three: Eventually, simulators may be embedded in commercial > devices. (I already have a single OpenSim simulator running on a > Linksys NSLU2.) Makes sense to use something that can speak any > language. > > Reason Four: Eventually, the client may gain a mono VM of it's own. > Or, a new viewer based on libsecondlife that can render textures prims > & particles will eventually work. There are already gecko bindings for > .net/mono. > > Reason Five: Mono allows for near-limitless expansion. No limits are > *required* to be set. > > Reason Six: Mono-based scripts will most likely gain properties of > their own: UI-set resource limits (In the Properties panel for a > script, allow process priority & memory allocation -- Set it at 32KB > of memory. Or 128KB of memory. Or if it only requires 2KB of memory, > why use the default of 16KB?) or script-requested resource limit > expansions. (Wouldn't it be great to allocate an extra 16KB just > before you llHTTPRequest a large page, do your parsing, then release > the extra memory?) It's far better to do all your work in a single > 64KB script than split it into 10 smaller 16KB scripts with huge > linked message routines. Object owners should be able to specify > script priorities. Got an SLEx cube? High priority. Couch with > anim-balls? Low priority. > > Mono is still young. With a little lovin' and optimization it could > really grow to be a stable and useful plot device. After all.... Look > at the story of OpenJPEG: Went from being too slow to be usable to > nearly on par with libkdu. Just needed some clever people to notice > it. There's always low-hanging fruit to pluck. > > Lindens, Is it possible to get a simulator running the mono engine > somewhere on the beta grid with the new het-grid stuff? Perhaps named > something like "Mono Sandbox" ? > I know it's partially working and still buggy, but so's havok4. > It would be nice to be able to play with it, even if it's not > finished. Who cares if the sim crashes every hour if you can spend > five minutes poking with a script that works so much faster? Debug > logs are useful too! And I bet we can point out some glaring bugs too, > just like Havok4. > > Since Joshua Bell was kind enough to share the LL roadmap with us on > SLDEV, could we at least get a little data about where the mono > project is, what's done, what's broke, and what we can do to help fix > it? > From secret.argent at gmail.com Mon Jan 21 06:30:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jan 21 06:30:26 2008 Subject: [sldev] Re: LSL and geometry hierarchy issues (Mark Meijer) In-Reply-To: References: <20080120231353.AD20741B2BE@stupor.lindenlab.com> <2EF503BA-CCB1-48FB-B4FD-56198BAFC531@gmail.com> Message-ID: Crossposting stuff between mailing lists, particularly when digests are involved, is a bit dangerous. :) On 2008-01-21, at 06:12, Kamilion wrote: > On Jan 20, 2008 3:36 PM, Argent Stonecutter > wrote: >> What languages, though, do you think would serve significantly better >> than LSL? The ones that come mind for me are Scheme and Forth, simply >> because both have a simple inner interpreter that could readily be >> wrapped around any axle. The other names that come up in these >> discussions - Lua, Tcl, Javascript, and the like - are likely too >> heavy already. > > What about Ruby 1.9? Ruby is in the same general family as Perl and Python. These languages aren't even designed around embedding, let along fine grained microthreading... plus they all the overhead of any inherently OO design. If you're thinking about languages in that class you haven't even started thinking about the kinds of problems I'm getting at. > However, make no mistake, I support Mono over all of the other > solutions. Mono is based around a heavy interpreter core. Again, if you're looking at Mono at all you've either no experience in tight realtime environments or you've got answers for me that address the kinds of problems that tight embedded code has... and you're not even talking about those problems. Babbage Linden has come up with some answers, but what he's having to do for transportability is scary. Imagine crossing a region border and having to snapshot a couple of hundred CLI environments (waiting for them to get to a point where they can be snapshotted), cross the border, and instantiate them again. The LSL image is effectively *always* a snapshot, which is why it has a hard 16k limit. Forth and Scheme can work under those environments too... I've done it. I haven't run into anything else that's suitable. From tinacloud at gmx.de Mon Jan 21 10:36:06 2008 From: tinacloud at gmx.de (Zi Ree) Date: Mon Jan 21 10:36:12 2008 Subject: [sldev] Get Avatar UUID by Name Message-ID: <200801211936.07215.tinacloud@gmx.de> Hi List! Is there a way to get an Avatar's UUID by providing the full name? I was digging through the avatar picker code and got deeper and deeper nested into the message structures, but I didn't find a suitable way to get the UUID. Any help is greatly appreciated! Thanks in advance! Zi! From robin.cornelius at gmail.com Mon Jan 21 11:28:51 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jan 21 11:28:52 2008 Subject: [sldev] Get Avatar UUID by Name In-Reply-To: <200801211936.07215.tinacloud@gmx.de> References: <200801211936.07215.tinacloud@gmx.de> Message-ID: <4794F273.7040700@gmail.com> Zi Ree wrote: > Hi List! Hi Zi, > > Is there a way to get an Avatar's UUID by providing the full name? I was > digging through the avatar picker code and got deeper and deeper nested into > the message structures, but I didn't find a suitable way to get the UUID. Any > help is greatly appreciated! The easiest and quickest way I have always used it to rely on the various external sites that provide this service. A sample (in lsl) is given on the bottom of this page http://rpgstats.com/wiki/index.php?title=LlHTTPRequest But as its just a http request, so you can do this from where ever. Its not 100% accurate and some names may be missing but its always been a useful friend to me. I presume if you are hacking the viewer the search tools must search for a name and at some point get the UUID? as they can show profiles etc. If you want to use the viewer route (unless someone knows how to do it) i would start searching down from the "search for person" control. Robin (who probably knows nothing) -------------- 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/20080121/db2bddc1/signature.pgp From tinacloud at gmx.de Mon Jan 21 11:43:19 2008 From: tinacloud at gmx.de (Zi Ree) Date: Mon Jan 21 11:43:23 2008 Subject: [sldev] Get Avatar UUID by Name In-Reply-To: <4794F273.7040700@gmail.com> References: <200801211936.07215.tinacloud@gmx.de> <4794F273.7040700@gmail.com> Message-ID: <200801212043.19644.tinacloud@gmx.de> Am Montag 21 Januar 2008 schrieb Robin Cornelius: Hi Robin, thanks for the reply! > I presume if you are hacking the viewer the search tools must search for Yes, it's supposed to go into the viewer. > a name and at some point get the UUID? as they can show profiles etc. If > you want to use the viewer route (unless someone knows how to do it) i > would start searching down from the "search for person" control. I tried the "Search" dialog way, but I couldn't find the class for it. So I went to the avatar picker and dug deep down to the messaging core. But I couldn't find a "simple" way to find the UUID. Of course I could always keep a cache (as I only want the UUIDs of people who appear in chat), but that seems like a sledgehammer way of doing it ;) > Robin (who probably knows nothing) Zi (not knowing more than you yet) From skaltura at gmail.com Mon Jan 21 12:43:27 2008 From: skaltura at gmail.com (Skal Tura) Date: Mon Jan 21 12:43:31 2008 Subject: [sldev] Get Avatar UUID by Name Message-ID: <50b9a5a40801211243i640c3adeg7d3b11c2db62896b@mail.gmail.com> Hi Zi & Robin, There is already a UUID cache for met avatars, located at: C:\Documents And Settings\(your name)\Application Data\Second Life\cache\name.cache Which is a simple tab delimited list. I don't know what all goes into there, but atleast something. Also, there is several services offering name2key, from which most popular i think is moopf's at: http://www.moopf.com/name2key.php Atleast, that's what i use :) Regards, Tyrian Camilo From tinacloud at gmx.de Mon Jan 21 13:19:05 2008 From: tinacloud at gmx.de (Zi Ree) Date: Mon Jan 21 13:19:10 2008 Subject: [sldev] Get Avatar UUID by Name In-Reply-To: <50b9a5a40801211243i640c3adeg7d3b11c2db62896b@mail.gmail.com> References: <50b9a5a40801211243i640c3adeg7d3b11c2db62896b@mail.gmail.com> Message-ID: <200801212219.05810.tinacloud@gmx.de> Am Montag 21 Januar 2008 schrieb Skal Tura: > There is already a UUID cache for met avatars, located at: > C:\Documents And Settings\(your name)\Application Data\Second > Life\cache\name.cache Yes, the C++ representation is LLCacheName but there is no method to get an avatar UUID by name. I could hack this in probably, but I'd like to go the official way if at all possible. > Which is a simple tab delimited list. I don't know what all goes into > there, but atleast something. You should know that the UUIDs in there are encoded (you can see that in the source, so the keys are unusable as they are in the file). Decoding would be simple, but I just wanted to point that out. > Also, there is several services offering name2key, from which most > popular i think is moopf's at: http://www.moopf.com/name2key.php Yes, but in-viewer this would be very cumbersome ;) > Tyrian Camilo Thanks for your reply! Zi! From annagulaev at gmail.com Mon Jan 21 13:20:37 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Jan 21 13:20:42 2008 Subject: [sldev] Mac build, python error Message-ID: I successfully built both the debug and release versions of the PPC Mac client, then changed some header and cpp files, and now I get this error: Source tree: Destination tree: /Users/Anna/sl/sl_1_18_4_3/linden/indra/newview/build/Deployment/Second Life.app Traceback (most recent call last): File "viewer_manifest.py", line 534, in ? main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) File "../lib/python/indra/util/llmanifest.py", line 194, in main default = default(srctree) File "../lib/python/indra/util/llmanifest.py", line 95, in get_channel channel = re.search("LL_CHANNEL\s=\s\"([\w\s]+)\"", contents).group(1) AttributeError: 'NoneType' object has no attribute 'group' Build failed (1 error) Any clue what this is trying to tell me? The only thing I can think of is that I created a new directory under indra with one header and one cpp file and added it to the project. Is there something else I need to do? FWIW, the python error happens before it tries to compile the new files. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080121/ccc98ac7/attachment.htm From rdw at lindenlab.com Mon Jan 21 14:26:13 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jan 21 14:26:30 2008 Subject: [sldev] Mac build, python error In-Reply-To: References: Message-ID: <47951C05.2090504@lindenlab.com> Looks like something is up with llversionviewer.h. It's searching through there to extract the channel name and it's not finding anything matching that particular regular expression. Can you verify that llversionviewer.h does exist (in llcommon) and that it has a LL_CHANNEL line in it? It should look something like: const char * const LL_CHANNEL = "Second Life Release"; -RYaN Anna Gulaev wrote: > I successfully built both the debug and release versions of the PPC > Mac client, then changed some header and cpp files, and now I get this > error: > > Source tree: > Destination tree: > /Users/Anna/sl/sl_1_18_4_3/linden/indra/newview/build/Deployment/Second > Life.app > Traceback (most recent call last): > File "viewer_manifest.py", line 534, in ? > main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) > File "../lib/python/indra/util/llmanifest.py", line 194, in main > default = default(srctree) > File "../lib/python/indra/util/llmanifest.py", line 95, in get_channel > channel = re.search("LL_CHANNEL\s=\s\"([\w\s]+)\"", contents).group(1) > AttributeError: 'NoneType' object has no attribute 'group' > Build failed (1 error) > > Any clue what this is trying to tell me? The only thing I can think of > is that I created a new directory under indra with one header and one > cpp file and added it to the project. Is there something else I need > to do? FWIW, the python error happens before it tries to compile the > new files. > > Thanks. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From annagulaev at gmail.com Mon Jan 21 14:59:20 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Jan 21 14:59:24 2008 Subject: [sldev] Re: Mac build, python error In-Reply-To: References: Message-ID: This is the pattern matching in the python script failing to find my LL_CHANNEL, which I thought I customized according to the guidelines. It does not like the string Second Life Open Source [Vengeance Studio] Removing the square brackets gets me by this. Perhaps the guidelines meant that including a "brand" was optional, and not that it could be included in squeare brackets? Will be re-reading the guidelines, and learning python pattern matching. On 1/21/08, Anna Gulaev wrote: > > I successfully built both the debug and release versions of the PPC Mac > client, then changed some header and cpp files, and now I get this error: > > Source tree: > Destination tree: > /Users/Anna/sl/sl_1_18_4_3/linden/indra/newview/build/Deployment/Second > Life.app > Traceback (most recent call last): > File "viewer_manifest.py", line 534, in ? > main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) > File "../lib/python/indra/util/llmanifest.py", line 194, in main > default = default(srctree) > File "../lib/python/indra/util/llmanifest.py", line 95, in get_channel > channel = re.search("LL_CHANNEL\s=\s\"([\w\s]+)\"", contents).group(1) > AttributeError: 'NoneType' object has no attribute 'group' > Build failed (1 error) > > Any clue what this is trying to tell me? The only thing I can think of is > that I created a new directory under indra with one header and one cpp file > and added it to the project. Is there something else I need to do? FWIW, the > python error happens before it tries to compile the new files. > > Thanks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080121/323afb88/attachment.htm From rdw at lindenlab.com Mon Jan 21 15:31:54 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Jan 21 15:32:21 2008 Subject: [sldev] Re: Mac build, python error In-Reply-To: References: Message-ID: <47952B6A.5040002@lindenlab.com> Anna Gulaev wrote: > This is the pattern matching in the python script failing to find my > LL_CHANNEL, which I thought I customized according to the guidelines. > It does not like the string > > Second Life Open Source [Vengeance Studio] Hmmm... good to know. I think that the pattern would work better as: "LL_CHANNEL\s=\s\"(.+)\";$" but I haven't tested that to see if it works all the time. The expression should be able to extract the value of the C string, no matter what characters it contains. Leaving aside the issue of why on earth we're parsing a .h file for input to a Python script, of course. I believe that the eventual goal is to generate llversionviewer.h from a template and configuration file, which will make this sort of problem go away. > > Removing the square brackets gets me by this. Perhaps the guidelines > meant that including a "brand" was optional, and not that it could be > included in squeare brackets? > Technically you should be allowed to use any string you want for the channel name; this is a bug. Thanks for reporting it! -RYaN From yoz at lindenlab.com Mon Jan 21 16:28:01 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Mon Jan 21 16:28:09 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <4791BBF5.2090501@cox.net> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> <4791BB6A.5040102@cox.net> <4791BBF5.2090501@cox.net> Message-ID: On Jan 19, 2008, at 12:59 AM, Lawson English wrote: > Oops that conflicts with the AW Groupies meeting. Guess I can send > an alt and multi-task but its ironic to hold a meeting about > documentation and API/protocols that conflicts with the AW Groupies' > since we've been kvetching about the lack thereof for quite a few > weeks now. Good point, and I'm sorry about that. Unfortunately it's too late to reschedule this one, but I'll ensure that all future meetings aren't in that slot. -- Yoz From lenglish5 at cox.net Mon Jan 21 17:57:54 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jan 21 17:57:56 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <33FCF71A-E50C-47CC-9539-A534F5906596@lindenlab.com> <4791BB6A.5040102@cox.net> <4791BBF5.2090501@cox.net> Message-ID: <47954DA2.8090100@cox.net> Yoz Grahame wrote: > On Jan 19, 2008, at 12:59 AM, Lawson English wrote: > >> Oops that conflicts with the AW Groupies meeting. Guess I can send an >> alt and multi-task but its ironic to hold a meeting about >> documentation and API/protocols that conflicts with the AW Groupies' >> since we've been kvetching about the lack thereof for quite a few >> weeks now. > > Good point, and I'm sorry about that. Unfortunately it's too late to > reschedule this one, but I'll ensure that all future meetings aren't > in that slot. > > -- Yoz You may end up with a bunch of groupies at your meeting anyway. Lawson From gigstaggart at gmail.com Mon Jan 21 18:02:29 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jan 21 18:02:32 2008 Subject: [sldev] Get Avatar UUID by Name In-Reply-To: <200801212219.05810.tinacloud@gmx.de> References: <50b9a5a40801211243i640c3adeg7d3b11c2db62896b@mail.gmail.com> <200801212219.05810.tinacloud@gmx.de> Message-ID: <47954EB5.3040903@gmail.com> Zi Ree wrote: > You should know that the UUIDs in there are encoded (you can see that in the > source, so the keys are unusable as they are in the file). Decoding would be > simple, but I just wanted to point that out. What's the point in that? I'd say submit a patch to fix this unnecessary processing overhead. -Jason From ts_ryuzo at hotmail.com Mon Jan 21 19:24:34 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Mon Jan 21 19:24:35 2008 Subject: [sldev] Precaching time Message-ID: Oh. I didn't. How do I clear the cache? Regards,Qian Hao Date: Sun, 20 Jan 2008 17:49:37 -0500From: Celierra@gmail.comTo: ts_ryuzo@hotmail.comSubject: Re: [sldev] Precaching timeOn Jan 19, 2008 11:26 PM, Qian Hao ~ wrote: On the other hand, if i set it to 2.f and wait several seconds for things to render, I can see nicely rendered image and less time taken than 20.f. Just to make sure, did you clear the cache before trying with the 2.f one?Cel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080122/3044d736/attachment.htm From tateru.nino at gmail.com Mon Jan 21 21:31:50 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jan 21 21:33:32 2008 Subject: [sldev] Precaching time In-Reply-To: References: Message-ID: <47957FC6.2030800@gmail.com> EDIT > PREFERENCES > Network, then hit the clear cache button and relog. Or close the viewer and manually delete the cache directory. Qian Hao ~ wrote: > Oh. I didn't. How do I clear the cache? > > Regards, > Qian Hao > > > ------------------------------------------------------------------------ > Date: Sun, 20 Jan 2008 17:49:37 -0500 > From: Celierra@gmail.com > To: ts_ryuzo@hotmail.com > Subject: Re: [sldev] Precaching time > > On Jan 19, 2008 11:26 PM, Qian Hao ~ > wrote: > > > On the other hand, if i set it to 2.f and wait several seconds > for things to render, I can see nicely rendered image and less > time taken than 20.f. > > > Just to make sure, did you clear the cache before trying with the > 2.f one? > > Cel > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 rdw at lindenlab.com Tue Jan 22 00:19:10 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Jan 22 00:19:23 2008 Subject: [sldev] Re: Mac build, python error In-Reply-To: <47952B6A.5040002@lindenlab.com> References: <47952B6A.5040002@lindenlab.com> Message-ID: <4795A6FE.1090506@lindenlab.com> Ryan Williams (Which) wrote: > Anna Gulaev wrote: >> This is the pattern matching in the python script failing to find my >> LL_CHANNEL, which I thought I customized according to the guidelines. >> It does not like the string >> >> Second Life Open Source [Vengeance Studio] > > Hmmm... good to know. I think that the pattern would work better as: > "LL_CHANNEL\s=\s\"(.+)\";$" > but I haven't tested that to see if it works all the time. So I just did some testing and the entire proper line in llmanifest.py is: channel = re.search("LL_CHANNEL\s=\s\"(.+)\";\s*$", contents, flags = re.M).group(1) You can stick that into your checkout of llmanifest.py and it should accept your channel-name-with-brackets. This is committed to our maintenance branch, so you should see it appear in the source drops once it passes through our build/QA process. -RYaN From secret.argent at gmail.com Tue Jan 22 07:11:58 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jan 22 07:11:53 2008 Subject: [sldev] Mac build, python error In-Reply-To: <47951C05.2090504@lindenlab.com> References: <47951C05.2090504@lindenlab.com> Message-ID: <90B9BDA2-0802-48D6-8BFB-1409C391AFE8@gmail.com> >> File "../lib/python/indra/util/llmanifest.py", line 95, in >> get_channel >> channel = re.search("LL_CHANNEL\s=\s\"([\w\s]+)\"", >> contents).group(1) Gah, using regexps to parse out what looks like a name-value list. At the very least I'd make that "\s=\s" into "\s*=\s*" and then check for it with and without quotes. Might need to be two regexps depending on the capability >> AttributeError: 'NoneType' object has no attribute 'group' >> Build failed (1 error) >> >> Any clue what this is trying to tell me? The only thing I can >> think of is that I created a new directory under indra with one >> header and one cpp file and added it to the project. Is there >> something else I need to do? FWIW, the python error happens before >> it tries to compile the new files. >> >> Thanks. >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> 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 Peter da Silva peter@taronga.com From zariok at zariok.com Tue Jan 22 09:03:09 2008 From: zariok at zariok.com (zariok) Date: Tue Jan 22 09:03:13 2008 Subject: [sldev] Web Login / Vista In-Reply-To: References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> <1200866507.20890.76.camel@localhost> Message-ID: Ack, didn't reply to the list.. On 1/22/08, zariok wrote: > > I was getting to the login screen followed by a crash with Windlight (XP > SP2). > > As I was hunting for the solution, I'm not sure which of the following > fixed, but it works now. > > Uninstall Quicktime. > Reinstall the latest Quicktime ( 7.3.1?). > > Add "-purge" to the startup line purge all cached textures. This can be > done by right-clicking the "SecondLife" icon, going to "command" and adding > " -purge" to the end. Remove this after the initial login or it will always > purge your cache. > > Hope this helps. > > > On 1/20/08, Callum Lerwick wrote: > > > > > On Sun, 2008-01-20 at 09:51 +0000, Fairlight wrote: > > > Hi! > > > > > > I am just wondering if anyone else has the problem with the Web-based > > > login (a seen in the current WindLight viewer) that, upon rendering > > the > > > login screen, the entire PC freezes and all you can do is reset the > > > machine? It's perfectly reproducable here, and I had it with the last > > 2 > > > versions of WindLight as well. With the last 2 versions, however, > > deleting > > > the Secondlife folder in my profile seems to have helped, whereas now > > it > > > just always freezes. (FYI, I am using Vista Ultimate 32bit) > > > > Wow, so its not just me? On plain old XP Pro SP2. I swear "I Didn't > > Change Anything". I hadn't logged in to SL in like a month, so the > > client version hasn't changed, and I haven't upgraded my video drivers. > > But now it locks up. Both Windlight and 1.18.5.3. Wonderful. > > > > _______________________________________________ > > 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/20080122/395befaf/attachment.htm From tinacloud at gmx.de Tue Jan 22 10:59:04 2008 From: tinacloud at gmx.de (Zi Ree) Date: Tue Jan 22 10:59:11 2008 Subject: [sldev] Get Avatar UUID by Name In-Reply-To: <47954EB5.3040903@gmail.com> References: <50b9a5a40801211243i640c3adeg7d3b11c2db62896b@mail.gmail.com> <200801212219.05810.tinacloud@gmx.de> <47954EB5.3040903@gmail.com> Message-ID: <200801221959.04777.tinacloud@gmx.de> Am Dienstag 22 Januar 2008 schriebst du: > What's the point in that? I'd say submit a patch to fix this > unnecessary processing overhead. I suppose it's from the pre-open source days when Lindens tried to keep the files a little harder to decode, so not everybody could just get at the data. Same with the on-disk caches. On topic: I have added a small function to the name cache which reads the key from the map stored internally. I hope this works for all cases I need it. :) > -Jason Zi From donovan at lindenlab.com Tue Jan 22 14:19:59 2008 From: donovan at lindenlab.com (Donovan Preston) Date: Tue Jan 22 14:20:39 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <47933C20.4090503@signpostmarv.name> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> <47933C20.4090503@signpostmarv.name> Message-ID: <0070405B-A27D-4A9D-B862-88B78D50E145@lindenlab.com> On Jan 20, 2008, at 4:18 AM, SignpostMarv Martin wrote: > Lawson English wrote: >> If it were merely going to be a better Second Life Map API, then it >> probably wouldn't have any relationship to the AWG, but the goal, >> as I understand it, is not only to make it "better," but to make it >> usable for 3rd-party grids and sims. That certainly intersects with >> the short and long-term work of the AWG, especially if the same or >> similar inter-grid data is to be used inside the client for things >> like TP destinations. You can't TP from a SL sim to an OpenSim sim >> (or back) without having a destination, and in-keeping with the >> idea of making the meta-grid interactions as seamless as possible, >> people will want to see a map image of where they are heading, if >> at all possible. THAT is certainly an AWG issue. > People might be interested in Map.llsd ( http://dev.signpostmarv.name/pub/llsd-grid-map/map.llsd.0.2.xml > ), a spec I worked in with some of the OpenSim peeps to represent > the data relevant to a map of a grid in a single file (which would > be a hell of a lot better to use than constant poking of LL's > current webmap API) Looks pretty good. But wouldn't it be better to use a map indexed by region id, rather than array? It seems like indexing the structure is going to be a common operation, and walking an array of 15,000 elements not a great strategy. Donovan From lenglish5 at cox.net Tue Jan 22 14:28:16 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jan 22 14:28:18 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <0070405B-A27D-4A9D-B862-88B78D50E145@lindenlab.com> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> <47933C20.4090503@signpostmarv.name> <0070405B-A27D-4A9D-B862-88B78D50E145@lindenlab.com> Message-ID: <47966E00.4080309@cox.net> Donovan Preston wrote: > > On Jan 20, 2008, at 4:18 AM, SignpostMarv Martin wrote: > >> Lawson English wrote: >>> If it were merely going to be a better Second Life Map API, then it >>> probably wouldn't have any relationship to the AWG, but the goal, as >>> I understand it, is not only to make it "better," but to make it >>> usable for 3rd-party grids and sims. That certainly intersects with >>> the short and long-term work of the AWG, especially if the same or >>> similar inter-grid data is to be used inside the client for things >>> like TP destinations. You can't TP from a SL sim to an OpenSim sim >>> (or back) without having a destination, and in-keeping with the idea >>> of making the meta-grid interactions as seamless as possible, people >>> will want to see a map image of where they are heading, if at all >>> possible. THAT is certainly an AWG issue. >> People might be interested in Map.llsd ( >> http://dev.signpostmarv.name/pub/llsd-grid-map/map.llsd.0.2.xml ), a >> spec I worked in with some of the OpenSim peeps to represent the data >> relevant to a map of a grid in a single file (which would be a hell >> of a lot better to use than constant poking of LL's current webmap API) > > Looks pretty good. But wouldn't it be better to use a map indexed by > region id, rather than array? It seems like indexing the structure is > going to be a common operation, and walking an array of 15,000 > elements not a great strategy. In the long run, more than one grid topology might be available. Will be interesting to see how indexing/searching/coordinates are accommodated in a multi-topology meta-grid map API. ;-) Lawson From me at signpostmarv.name Tue Jan 22 15:32:10 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jan 22 15:32:14 2008 Subject: [sldev] WebMap API work & in-world meeting In-Reply-To: <47933C20.4090503@signpostmarv.name> References: <1AA24A8F-6E01-48C7-A9E2-90954D1C5BA1@lindenlab.com> <47928122.9020306@cox.net> <4792FB8A.4090109@dzonux.net> <47930FCA.1090504@cox.net> <47933C20.4090503@signpostmarv.name> Message-ID: <47967CFA.70500@signpostmarv.name> > People might be interested in Map.llsd ( > http://dev.signpostmarv.name/pub/llsd-grid-map/map.llsd.0.2.xml ), a > spec I worked in with some of the OpenSim peeps to represent the data > relevant to a map of a grid in a single file (which would be a hell of > a lot better to use than constant poking of LL's current webmap API) Updated prior to today's meeting: http://dev.signpostmarv.name/pub/llsd-grid-map/map.llsd.0.3.xml -------------- 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/20080122/7b9bf83c/smime.bin From alissa_sabre at yahoo.co.jp Wed Jan 23 05:58:58 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jan 23 05:59:08 2008 Subject: [sldev] Uses of LLString and std::string ? Message-ID: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> I have a question. SL viewer uses two data types LLString and std::string, that are almost identical. They are sometimes intermixed. LLString to std::string conversion is by a simple upcasting, but the opposit is by a deep copy through a constructor that requires some overhead. What is the purpose of LLString? In case it has some, then the next question is why LL uses both LLString and std::string? (Cf. LL never uses C++ bool type.) Assuming there is a good reason to use both LLString and std::string in SL viewer, what is the criteria (or guidelines) to choose from LLString and std::string? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From davep at lindenlab.com Wed Jan 23 08:34:02 2008 From: davep at lindenlab.com (Dave Parks) Date: Wed Jan 23 08:34:20 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> Message-ID: <47976C7A.5040204@lindenlab.com> I believe the point of LLString is to protect against NULL pointer assignments. It's legacy from a time when we used char* strings and began mixing in std::string. Assigning a standard string to NULL dereferences NULL, causing a crash. LLString protects against this by checking for NULL on assignment for char* strings. Alissa Sabre wrote: > I have a question. > > SL viewer uses two data types LLString and std::string, that are > almost identical. They are sometimes intermixed. LLString to > std::string conversion is by a simple upcasting, but the opposit is by > a deep copy through a constructor that requires some overhead. > > What is the purpose of LLString? In case it has some, then the next > question is why LL uses both LLString and std::string? (Cf. LL never > uses C++ bool type.) > > Assuming there is a good reason to use both LLString and std::string > in SL viewer, what is the criteria (or guidelines) to choose from > LLString and std::string? > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nik at terminaldischarge.net Wed Jan 23 08:37:50 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Jan 23 08:37:57 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <47976C7A.5040204@lindenlab.com> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> Message-ID: <51363.86.10.79.229.1201106270.squirrel@webmail.terminaldischarge.net> I thought it was because the std library wasn't too stable when they started out writing SL so they ended up writing there own imlpementation of things. I assume over time, std got stable and standard like and stuff and so its been okay to use it thus the intermixing. Though I'm probably wrong :P I usually am. Nik > I believe the point of LLString is to protect against NULL pointer > assignments. It's legacy from a time when we used char* strings and > began mixing in std::string. Assigning a standard string to NULL > dereferences NULL, causing a crash. LLString protects against this by > checking for NULL on assignment for char* strings. > > Alissa Sabre wrote: >> I have a question. >> >> SL viewer uses two data types LLString and std::string, that are >> almost identical. They are sometimes intermixed. LLString to >> std::string conversion is by a simple upcasting, but the opposit is by >> a deep copy through a constructor that requires some overhead. >> >> What is the purpose of LLString? In case it has some, then the next >> question is why LL uses both LLString and std::string? (Cf. LL never >> uses C++ bool type.) >> >> Assuming there is a good reason to use both LLString and std::string >> in SL viewer, what is the criteria (or guidelines) to choose from >> LLString and std::string? >> >> Alissa Sabre >> -------------------------------------- >> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >> http://pr.mail.yahoo.co.jp/toolbar/ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net From steve at lindenlab.com Wed Jan 23 08:52:22 2008 From: steve at lindenlab.com (Steve Linden) Date: Wed Jan 23 08:53:44 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <47976C7A.5040204@lindenlab.com> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> Message-ID: <479770C6.1010601@lindenlab.com> Correct, LLString exists specifically to protect against passing a NULL char* to a function that takes a const std::string&. C++ will quietly attempt to convert the NULL char* into a std::string causing a crash. e.g. foo (const std::string& s) { } bar (const char* c) { foo(c); // crashes if c is NULL } main() { const char* s = fetchSomeString(); // returns NULL if it fails foo(s); // crash! } Note: we -still- have thousands of char arrays and char*'s in the code, and this pattern exists all over the place, especially in the UI code. We are actively working on eliminating this pattern. Once we do, we can safely replace LLString with std::string. Because of the expense of converting a std::string to a LLString, we try to use LLString anywhere we will pass it as a std::string. However, in the grand scheme of things this is unlikely to be a significant performance bottleneck so we are not as paranoid about it as we might be. -Steve Dave Parks wrote: > I believe the point of LLString is to protect against NULL pointer > assignments. It's legacy from a time when we used char* strings and > began mixing in std::string. Assigning a standard string to NULL > dereferences NULL, causing a crash. LLString protects against this by > checking for NULL on assignment for char* strings. > > Alissa Sabre wrote: >> I have a question. >> >> SL viewer uses two data types LLString and std::string, that are >> almost identical. They are sometimes intermixed. LLString to >> std::string conversion is by a simple upcasting, but the opposit is by >> a deep copy through a constructor that requires some overhead. >> >> What is the purpose of LLString? In case it has some, then the next >> question is why LL uses both LLString and std::string? (Cf. LL never >> uses C++ bool type.) >> >> Assuming there is a good reason to use both LLString and std::string >> in SL viewer, what is the criteria (or guidelines) to choose from >> LLString and std::string? >> >> Alissa Sabre >> -------------------------------------- >> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >> http://pr.mail.yahoo.co.jp/toolbar/ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From tofu.linden at lindenlab.com Wed Jan 23 08:57:02 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Jan 23 08:57:14 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <51363.86.10.79.229.1201106270.squirrel@webmail.terminaldischarge.net> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <51363.86.10.79.229.1201106270.squirrel@webmail.terminaldischarge.net> Message-ID: <479771DE.8020203@lindenlab.com> Nik Radford wrote: > I thought it was because the std library wasn't too stable when they > started out writing SL so they ended up writing there own imlpementation > of things. > > I assume over time, std got stable and standard like and stuff and so its > been okay to use it thus the intermixing. That approximately matches what I've heard from our code historians - and our newer code tries to use std::string exclusively. (The other day I heard someone mutter 'LLString must die'.) Similarly we prefer 'bool' over 'BOOL' now, C++ containers to our own skiplist and hash implementations, etc. -Tofu From richard at lindenlab.com Wed Jan 23 10:08:31 2008 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jan 23 10:08:50 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <479770C6.1010601@lindenlab.com> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: Keep in mind that LLString derives from std::string and can be used anywhere a std::string is. But, as Steve notes, you can't arbitrarily convert a reference to a std::string to a reference to a LLString, so any conversion back to LLString will involve a copy. Before any C++ purists complain, let me note that std::string does not have a virtual destructor and hence we can never add any member variables or implement a non-trivial destructor in LLString. It serves merely as a convenient wrapper for std::string that tests for the null char* case, as Steve mentioned, and provides some handy functions (e.g. case-insensitive string comparison) that would otherwise require boilerplate code. Note that all of the custom functions are implemented as statics, and not member functions. This is to support the ultimate goal of having LLString simply be a namespace for string helper functions that operate on std::strings. R. On Wed, 23 Jan 2008 08:52:22 -0800, Steve Linden wrote: > Correct, LLString exists specifically to protect against passing a NULL > char* to a function that takes a const std::string&. C++ will quietly > attempt to convert the NULL char* into a std::string causing a crash. > > e.g. > > foo (const std::string& s) > { > } > bar (const char* c) > { > foo(c); // crashes if c is NULL > } > main() > { > const char* s = fetchSomeString(); // returns NULL if it fails > foo(s); // crash! > } > > Note: we -still- have thousands of char arrays and char*'s in the code, > and this pattern exists all over the place, especially in the UI code. > We are actively working on eliminating this pattern. Once we do, we can > safely replace LLString with std::string. > > Because of the expense of converting a std::string to a LLString, we try > to use LLString anywhere we will pass it as a std::string. However, in > the grand scheme of things this is unlikely to be a significant > performance bottleneck so we are not as paranoid about it as we might be. > > -Steve > > Dave Parks wrote: >> I believe the point of LLString is to protect against NULL pointer >> assignments. It's legacy from a time when we used char* strings and >> began mixing in std::string. Assigning a standard string to NULL >> dereferences NULL, causing a crash. LLString protects against this by >> checking for NULL on assignment for char* strings. >> >> Alissa Sabre wrote: >>> I have a question. >>> >>> SL viewer uses two data types LLString and std::string, that are >>> almost identical. They are sometimes intermixed. LLString to >>> std::string conversion is by a simple upcasting, but the opposit is by >>> a deep copy through a constructor that requires some overhead. >>> >>> What is the purpose of LLString? In case it has some, then the next >>> question is why LL uses both LLString and std::string? (Cf. LL never >>> uses C++ bool type.) >>> >>> Assuming there is a good reason to use both LLString and std::string >>> in SL viewer, what is the criteria (or guidelines) to choose from >>> LLString and std::string? >>> >>> Alissa Sabre >>> -------------------------------------- >>> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >>> http://pr.mail.yahoo.co.jp/toolbar/ >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From phoenix at secondlife.com Wed Jan 23 11:15:42 2008 From: phoenix at secondlife.com (Phoenix) Date: Wed Jan 23 11:15:24 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: wow, I've never seen so many Lindens reply on a single thread. Guess it shows you what makes a c++ nerd's ears perk. :) Years ago, before open source, in the long ago time, there was LLString. It was a very basic string implementation based on NULL terminated char* which would dynamically resize on every operation. After secretly using standard containers in our code base for a while (they used to be forbidden according to our coding standards) to prove they worked on all of our platforms, I began replacing all instances of char* APIs with a std::string replacement and typically using std::string and std::ostringstream for using and building strings. This worked all right, but std::string has, as noted by Steve and in my humble opinion, at least one fatal flaw -- constructing a std::string with NULL crashes. The most mechanical transition to reduce crashes was to replace all instances of std::string with LLString and magically the crashes disappear. Sadly, the LLString class is not a good use of inheritance and introduces overhead when working with many c++ libraries -- even our own. To make matters worse, at least one method does not work with narrow and wide characters. All new APIs should be using std::string, but the habit of using LLString is hard to break. Personally, I always use std::string, and wrap char* and c APIs with ll_safe_string which is prototyped as: /** * @brief Return a string constructed from in without crashing if the * pointer is NULL. */ std::string ll_safe_string(const char* in); What we cold really use is an LLString that provided native utf-8 support like gtk's ustring. On 2008-01-23, at 10:08, Richard Nelson wrote: > Keep in mind that LLString derives from std::string and can be used > anywhere a std::string is. But, as Steve notes, you can't > arbitrarily convert a reference to a std::string to a reference to > a LLString, so any conversion back to LLString will involve a copy. > > Before any C++ purists complain, let me note that std::string does > not have a virtual destructor and hence we can never add any member > variables or implement a non-trivial destructor in LLString. It > serves merely as a convenient wrapper for std::string that tests > for the null char* case, as Steve mentioned, and provides some > handy functions (e.g. case-insensitive string comparison) that > would otherwise require boilerplate code. > > Note that all of the custom functions are implemented as statics, > and not member functions. This is to support the ultimate goal of > having LLString simply be a namespace for string helper functions > that operate on std::strings. > > R. > > On Wed, 23 Jan 2008 08:52:22 -0800, Steve Linden > wrote: > >> Correct, LLString exists specifically to protect against passing a >> NULL char* to a function that takes a const std::string&. C++ will >> quietly attempt to convert the NULL char* into a std::string >> causing a crash. >> >> e.g. >> >> foo (const std::string& s) >> { >> } >> bar (const char* c) >> { >> foo(c); // crashes if c is NULL >> } >> main() >> { >> const char* s = fetchSomeString(); // returns NULL if it fails >> foo(s); // crash! >> } >> >> Note: we -still- have thousands of char arrays and char*'s in the >> code, and this pattern exists all over the place, especially in >> the UI code. We are actively working on eliminating this pattern. >> Once we do, we can safely replace LLString with std::string. >> >> Because of the expense of converting a std::string to a LLString, >> we try to use LLString anywhere we will pass it as a std::string. >> However, in the grand scheme of things this is unlikely to be a >> significant performance bottleneck so we are not as paranoid about >> it as we might be. >> >> -Steve >> >> Dave Parks wrote: >>> I believe the point of LLString is to protect against NULL >>> pointer assignments. It's legacy from a time when we used char* >>> strings and began mixing in std::string. Assigning a standard >>> string to NULL dereferences NULL, causing a crash. LLString >>> protects against this by checking for NULL on assignment for >>> char* strings. >>> >>> Alissa Sabre wrote: >>>> I have a question. >>>> >>>> SL viewer uses two data types LLString and std::string, that are >>>> almost identical. They are sometimes intermixed. LLString to >>>> std::string conversion is by a simple upcasting, but the opposit >>>> is by >>>> a deep copy through a constructor that requires some overhead. >>>> >>>> What is the purpose of LLString? In case it has some, then the >>>> next >>>> question is why LL uses both LLString and std::string? (Cf. LL >>>> never >>>> uses C++ bool type.) >>>> >>>> Assuming there is a good reason to use both LLString and >>>> std::string >>>> in SL viewer, what is the criteria (or guidelines) to choose from >>>> LLString and std::string? >>>> >>>> Alissa Sabre >>>> -------------------------------------- >>>> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >>>> http://pr.mail.yahoo.co.jp/toolbar/ >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > 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/20080123/7f7cef18/PGP.pgp From secret.argent at gmail.com Wed Jan 23 11:39:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jan 23 11:39:28 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: On 2008-01-23, at 12:08, Richard Nelson wrote: > Before any C++ purists complain, let me note that std::string does > not have a virtual destructor and hence we can never add any member > variables or implement a non-trivial destructor in LLString. It > serves merely as a convenient wrapper for std::string that tests > for the null char* case, as Steve mentioned, and provides some > handy functions (e.g. case-insensitive string comparison) that > would otherwise require boilerplate code. [speechless] What kind of object oriented language doesn't make this kind of thing virtually transparent? From richard at lindenlab.com Wed Jan 23 12:53:03 2008 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jan 23 12:54:17 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: My final bit of clarification. LLString, as Phoenix said, used to be a hand-rolled resizable string. Once we decided to use std::string I stepped in to completely replace all existing uses of LLString. I did this by changing LLString over to inherit from std::string, reimplementing it's methods in terms of std::string, and one by one replacing calls to LLString::ll_custom_method to the std equivalent, with the goal of adding a final "typedef std::string LLString" or a simple search and replace to finish the conversion process. Sounded good in theory, but of course there was a hitch, the NULL assignment issue in this case. In retrospect I should have added something like ll_safe_string at that point in time and completed the process, but it had moved beyond what I could do with a simple search and replace, so I stopped there, perhaps unwisely. So that's where we stand today, a bunch of code that relies on an almost deprecated class. In case anyone was still considering writing new code that uses LLStrings... I think it would make sense to complete the process by finding all char* to LLString conversions and using ll_safe_string instead. R. On Wed, 23 Jan 2008 11:15:42 -0800, Phoenix wrote: > wow, I've never seen so many Lindens reply on a single thread. Guess > it shows you what makes a c++ nerd's ears perk. :) > > Years ago, before open source, in the long ago time, there was > LLString. It was a very basic string implementation based on NULL > terminated char* which would dynamically resize on every operation. > After secretly using standard containers in our code base for a while > (they used to be forbidden according to our coding standards) to > prove they worked on all of our platforms, I began replacing all > instances of char* APIs with a std::string replacement and typically > using std::string and std::ostringstream for using and building strings. > > This worked all right, but std::string has, as noted by Steve and in > my humble opinion, at least one fatal flaw -- constructing a > std::string with NULL crashes. The most mechanical transition to > reduce crashes was to replace all instances of std::string with > LLString and magically the crashes disappear. > > Sadly, the LLString class is not a good use of inheritance and > introduces overhead when working with many c++ libraries -- even our > own. To make matters worse, at least one method does not work with > narrow and wide characters. All new APIs should be using std::string, > but the habit of using LLString is hard to break. > > Personally, I always use std::string, and wrap char* and c APIs with > ll_safe_string which is prototyped as: > > /** > * @brief Return a string constructed from in without crashing if the > * pointer is NULL. > */ > std::string ll_safe_string(const char* in); > > > What we cold really use is an LLString that provided native utf-8 > support like gtk's ustring. > > > On 2008-01-23, at 10:08, Richard Nelson wrote: >> Keep in mind that LLString derives from std::string and can be used >> anywhere a std::string is. But, as Steve notes, you can't >> arbitrarily convert a reference to a std::string to a reference to >> a LLString, so any conversion back to LLString will involve a copy. >> >> Before any C++ purists complain, let me note that std::string does >> not have a virtual destructor and hence we can never add any member >> variables or implement a non-trivial destructor in LLString. It >> serves merely as a convenient wrapper for std::string that tests >> for the null char* case, as Steve mentioned, and provides some >> handy functions (e.g. case-insensitive string comparison) that >> would otherwise require boilerplate code. >> >> Note that all of the custom functions are implemented as statics, >> and not member functions. This is to support the ultimate goal of >> having LLString simply be a namespace for string helper functions >> that operate on std::strings. >> >> R. >> >> On Wed, 23 Jan 2008 08:52:22 -0800, Steve Linden >> wrote: >> >>> Correct, LLString exists specifically to protect against passing a >>> NULL char* to a function that takes a const std::string&. C++ will >>> quietly attempt to convert the NULL char* into a std::string >>> causing a crash. >>> >>> e.g. >>> >>> foo (const std::string& s) >>> { >>> } >>> bar (const char* c) >>> { >>> foo(c); // crashes if c is NULL >>> } >>> main() >>> { >>> const char* s = fetchSomeString(); // returns NULL if it fails >>> foo(s); // crash! >>> } >>> >>> Note: we -still- have thousands of char arrays and char*'s in the >>> code, and this pattern exists all over the place, especially in >>> the UI code. We are actively working on eliminating this pattern. >>> Once we do, we can safely replace LLString with std::string. >>> >>> Because of the expense of converting a std::string to a LLString, >>> we try to use LLString anywhere we will pass it as a std::string. >>> However, in the grand scheme of things this is unlikely to be a >>> significant performance bottleneck so we are not as paranoid about >>> it as we might be. >>> >>> -Steve >>> >>> Dave Parks wrote: >>>> I believe the point of LLString is to protect against NULL >>>> pointer assignments. It's legacy from a time when we used char* >>>> strings and began mixing in std::string. Assigning a standard >>>> string to NULL dereferences NULL, causing a crash. LLString >>>> protects against this by checking for NULL on assignment for >>>> char* strings. >>>> >>>> Alissa Sabre wrote: >>>>> I have a question. >>>>> >>>>> SL viewer uses two data types LLString and std::string, that are >>>>> almost identical. They are sometimes intermixed. LLString to >>>>> std::string conversion is by a simple upcasting, but the opposit >>>>> is by >>>>> a deep copy through a constructor that requires some overhead. >>>>> >>>>> What is the purpose of LLString? In case it has some, then the >>>>> next >>>>> question is why LL uses both LLString and std::string? (Cf. LL >>>>> never >>>>> uses C++ bool type.) >>>>> >>>>> Assuming there is a good reason to use both LLString and >>>>> std::string >>>>> in SL viewer, what is the criteria (or guidelines) to choose from >>>>> LLString and std::string? >>>>> >>>>> Alissa Sabre >>>>> -------------------------------------- >>>>> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar >>>>> http://pr.mail.yahoo.co.jp/toolbar/ >>>>> _______________________________________________ >>>>> Click here to unsubscribe or manage your list subscription: >>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>>> >>>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From tateru.nino at gmail.com Wed Jan 23 19:21:49 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jan 23 19:23:37 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: <4798044D.4070809@gmail.com> Argent Stonecutter wrote: > On 2008-01-23, at 12:08, Richard Nelson wrote: >> Before any C++ purists complain, let me note that std::string does >> not have a virtual destructor and hence we can never add any member >> variables or implement a non-trivial destructor in LLString. It >> serves merely as a convenient wrapper for std::string that tests for >> the null char* case, as Steve mentioned, and provides some handy >> functions (e.g. case-insensitive string comparison) that would >> otherwise require boilerplate code. > > [speechless] > > What kind of object oriented language doesn't make this kind of thing > virtually transparent? Virtual destructors were a late entry to the language standard, well after most of the STL was frozen. -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jan 23 19:35:45 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jan 23 19:37:40 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: <47980791.6020708@gmail.com> Argent Stonecutter wrote: > On 2008-01-23, at 12:08, Richard Nelson wrote: >> Before any C++ purists complain, let me note that std::string does >> not have a virtual destructor and hence we can never add any member >> variables or implement a non-trivial destructor in LLString. It >> serves merely as a convenient wrapper for std::string that tests for >> the null char* case, as Steve mentioned, and provides some handy >> functions (e.g. case-insensitive string comparison) that would >> otherwise require boilerplate code. > > [speechless] > > What kind of object oriented language doesn't make this kind of thing > virtually transparent? As an aside, some reading up on what the C++ standards committee (I'd recommend Plauger among others) went through from start to finish is enlightening. Yes, C++ is one of the most widely used languages, and with good reason - but it's interesting to see how interest and architecture groups came close to messing it all up too. This is not to say that SIGs and AWGs are bad. It's more about the process management of them than anything. Before anyone jumps in, I'll take a moment to reiterate that I'm not saying anything bad about anyone or anything. If you're feeling slighted, you've misread, okay? I'll get you a bunny. -- Tateru Nino http://www.massively.com/ From lenglish5 at cox.net Wed Jan 23 19:50:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 23 19:50:08 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <47980791.6020708@gmail.com> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> <47980791.6020708@gmail.com> Message-ID: <47980AEE.4040202@cox.net> Tateru Nino wrote: > > > Argent Stonecutter wrote: >> On 2008-01-23, at 12:08, Richard Nelson wrote: >>> Before any C++ purists complain, let me note that std::string does >>> not have a virtual destructor and hence we can never add any member >>> variables or implement a non-trivial destructor in LLString. It >>> serves merely as a convenient wrapper for std::string that tests for >>> the null char* case, as Steve mentioned, and provides some handy >>> functions (e.g. case-insensitive string comparison) that would >>> otherwise require boilerplate code. >> >> [speechless] >> >> What kind of object oriented language doesn't make this kind of thing >> virtually transparent? > As an aside, some reading up on what the C++ standards committee (I'd > recommend Plauger among others) went through from start to finish is > enlightening. Yes, C++ is one of the most widely used languages, and > with good reason - but it's interesting to see how interest and > architecture groups came close to messing it all up too. > > This is not to say that SIGs and AWGs are bad. It's more about the > process management of them than anything. > > Before anyone jumps in, I'll take a moment to reiterate that I'm not > saying anything bad about anyone or anything. If you're feeling > slighted, you've misread, okay? I'll get you a bunny. > As a proud member of AW Groupies, I can't take offense. The AWG doesn't do enough [yet] to mess things up in the first place. Lawson From alexander.treptow at zweitgeist.com Thu Jan 24 00:49:01 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Jan 24 00:49:14 2008 Subject: [sldev] Compile as installer Message-ID: <479850FD.9000708@zweitgeist.com> How do i compile the viewer as installer (setup.exe)? I use winxp with vc7 / vc2003 and viewer version 1.18.2(1). Thanks for help, alex From robin.cornelius at gmail.com Thu Jan 24 01:20:32 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 24 01:20:35 2008 Subject: [sldev] Compile as installer In-Reply-To: <479850FD.9000708@zweitgeist.com> References: <479850FD.9000708@zweitgeist.com> Message-ID: On Jan 24, 2008 8:49 AM, alexander treptow wrote: > How do i compile the viewer as installer (setup.exe)? > I use winxp with vc7 / vc2003 and viewer version 1.18.2(1). You don't.... well not with what is provided anyway. All is provided is the source code and project files to generate the secondlife viewer runtime. To actually create an installer you require an additional tool, of which there are a great many but i have no idea if any are free or not. Also in most cases an installer is not trivial and requires a bit of setting up to build a working setup.exe that does what you expect. I know others have made there own installers using various methods. They might be able to give further guidance on good tools to use. Also be very careful if you are distributing files, there are a good number of (non linden) files that have licenses that do not permit redistribution; fmod,the voice stuff,the ttf fonts to name a few. So you either have to distribute a "patch" installer that installs in to an existing linden secondlife folder OR build an opensource version of the viewer that has 100% redistributable components. Robin From secret.argent at gmail.com Thu Jan 24 05:19:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 24 05:19:31 2008 Subject: [sldev] Compile as installer In-Reply-To: References: <479850FD.9000708@zweitgeist.com> Message-ID: On 2008-01-24, at 03:20, Robin Cornelius wrote: > Also be very careful if you are distributing files, there are a good > number of (non linden) files that have licenses that do not permit > redistribution; fmod,the voice stuff,the ttf fonts to name a few. Still? Does the Linden version of the GPL explicitly exclude those libraries? If not, you can't legally distribute a binary version of the open source client, since those are not a standard part of the OS it runs on. Not that that's likely to create practical problems, given that it's unlikely Linden Labs will get on your case about it. The FLOSS exception does not appear to cover this, and according to the FSF the fact that they're shared libraries doesn't make a difference: shared libraries are not 'independent and separate works'. From robin.cornelius at gmail.com Thu Jan 24 05:31:03 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 24 05:31:06 2008 Subject: [sldev] Compile as installer In-Reply-To: References: <479850FD.9000708@zweitgeist.com> Message-ID: On Jan 24, 2008 1:19 PM, Argent Stonecutter wrote: > On 2008-01-24, at 03:20, Robin Cornelius wrote: > > Also be very careful if you are distributing files, there are a good > > number of (non linden) files that have licenses that do not permit > > redistribution; fmod,the voice stuff,the ttf fonts to name a few. > > Still? > Ah, not in the source bundle. The Non free stuff is not bundled at all in source or artwork packages. I was more thinking if one was building a complete windows installer, unless steps are taken to specifically use free components there are dependencies that are not distributable and are not standard OS components so you would end up with an installer that required the user to go and install FMOD or whatever on their own, which is far from ideal for an installer. From alexander.treptow at zweitgeist.com Thu Jan 24 05:52:34 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Jan 24 05:52:42 2008 Subject: [sldev] Re: SLDev Digest, Vol 13, Issue 70 In-Reply-To: <20080124131932.BE58441B23B@stupor.lindenlab.com> References: <20080124131932.BE58441B23B@stupor.lindenlab.com> Message-ID: <47989822.30103@zweitgeist.com> > You don't.... well not with what is provided anyway. All is provided > is the source code and project files to generate the secondlife viewer > runtime. To actually create an installer you require an additional > tool, of which there are a great many but i have no idea if any are > free or not. Also in most cases an installer is not trivial and > requires a bit of setting up to build a working setup.exe that does > what you expect. Ok i tried using my executable by copying it to the SL directory and it works, so i think i dont need an installer, it will be much easier only to extract the exe to that folder thanks and greets, alex From lenglish5 at cox.net Thu Jan 24 07:39:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jan 24 07:39:52 2008 Subject: [sldev] Compile as installer In-Reply-To: References: <479850FD.9000708@zweitgeist.com> Message-ID: <4798B145.9020204@cox.net> Argent Stonecutter wrote: > On 2008-01-24, at 03:20, Robin Cornelius wrote: >> Also be very careful if you are distributing files, there are a good >> number of (non linden) files that have licenses that do not permit >> redistribution; fmod,the voice stuff,the ttf fonts to name a few. > > Still? > > Does the Linden version of the GPL explicitly exclude those libraries? > If not, you can't legally distribute a binary version of the open > source client, since those are not a standard part of the OS it runs > on. Not that that's likely to create practical problems, given that > it's unlikely Linden Labs will get on your case about it. > > The FLOSS exception does not appear to cover this, and according to > the FSF the fact that they're shared libraries doesn't make a > difference: shared libraries are not 'independent and separate works'. The FSF is full of it too. You have no control over which shared libraries are distributed and used with what. It would be like creating a copyright notice that you can't put a notebook full of notes in an arbitrary binder and sell it because you don't like the copyright on the contents of the rest of the binder, even though the notes can be sold separately, next to each other. Lawson From tlang303 at gmail.com Thu Jan 24 07:51:02 2008 From: tlang303 at gmail.com (Tobias Lang) Date: Thu Jan 24 07:51:05 2008 Subject: [sldev] Compile as installer In-Reply-To: <4798B145.9020204@cox.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> Message-ID: <66bc8ec50801240751w5e3d915fq3533c52842c898d@mail.gmail.com> Hi, besides all issues of licensing, you can easily create a "setup.exe". Just install the Nullsoft Scriptable installer (http://nsis.sf.net) and run "secondlife setup build agni.bat". This batch then calls the "viewer_manifest.py" python scripts which creates automatically the installer script for NSIS and runs it. For every library or custom file you like to ship, make sure that you include it in the viewer_manifest.py. I hope this answers the question. -Tobi On Jan 24, 2008 10:39 AM, Lawson English wrote: > Argent Stonecutter wrote: > > On 2008-01-24, at 03:20, Robin Cornelius wrote: > >> Also be very careful if you are distributing files, there are a good > >> number of (non linden) files that have licenses that do not permit > >> redistribution; fmod,the voice stuff,the ttf fonts to name a few. > > > > Still? > > > > Does the Linden version of the GPL explicitly exclude those libraries? > > If not, you can't legally distribute a binary version of the open > > source client, since those are not a standard part of the OS it runs > > on. Not that that's likely to create practical problems, given that > > it's unlikely Linden Labs will get on your case about it. > > > > The FLOSS exception does not appear to cover this, and according to > > the FSF the fact that they're shared libraries doesn't make a > > difference: shared libraries are not 'independent and separate works'. > > The FSF is full of it too. You have no control over which shared > libraries are distributed and used with what. It would be like creating > a copyright notice that you can't put a notebook full of notes in an > arbitrary binder and sell it because you don't like the copyright on the > contents of the rest of the binder, even though the notes can be sold > separately, next to each other. > > 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/20080124/70dbe9ec/attachment.htm From alexander.treptow at zweitgeist.com Thu Jan 24 08:00:49 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Thu Jan 24 08:00:59 2008 Subject: [sldev] Camera drawing radius for objects Message-ID: <4798B631.6080704@zweitgeist.com> There is one parameter, constant or vairable that indicates what attachments or maybe other objects are drawn. It is a radius around the camera. I've edited it, i think about 3 month ago, and i dont know where to find it yet. Does anyone knows where to find? i'd be very pleased for any help greets, alex From secret.argent at gmail.com Thu Jan 24 10:32:36 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 24 10:32:36 2008 Subject: [sldev] Compile as installer In-Reply-To: <4798B145.9020204@cox.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> Message-ID: <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> On 2008-01-24, at 09:39, Lawson English wrote: > Argent Stonecutter wrote: >> Does the Linden version of the GPL explicitly exclude those >> libraries? If not, you can't legally distribute a binary version >> of the open source client, since those are not a standard part of >> the OS it runs on. Not that that's likely to create practical >> problems, given that it's unlikely Linden Labs will get on your >> case about it. >> The FLOSS exception does not appear to cover this, and according >> to the FSF the fact that they're shared libraries doesn't make a >> difference: shared libraries are not 'independent and separate >> works'. > > The FSF is full of it too. I can't really disagree, but people who use the GPL do. More importantly, they've gotten real life lawyers to agree with their interpretation and gotten cases settled over it (like, in the GNU MP library case, and Korn's UNIX compatibility package for Windows). > You have no control over which shared libraries are distributed and > used with what. No, but you do have control over what include files and libraries you link with to create your GPLed binary. The FSF's argument is that if you are going to link a GPLed product with a non-GPLed API, *even if* it's using a shared library, you're creating a derived work. If there's a GPLed (or in the case of SL, any FOSS) implementation of the library that's ABI compatible, you can link with that and then use any other shared library at run time. > It would be like creating a copyright notice that you can't put a > notebook full of notes in an arbitrary binder and sell it because > you don't like the copyright on the contents of the rest of the > binder, even though the notes can be sold separately, next to each > other. That's basically what the GPL is all about. That's pretty much the whole difference between the GPL and the LGPL. Early drafts of teh GPL3 went even further than this. If LL explicitly listed the packages THEY ship as an exception, then the issue would never come up. From gigstaggart at gmail.com Thu Jan 24 19:30:31 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jan 24 19:30:37 2008 Subject: [sldev] Camera drawing radius for objects In-Reply-To: <4798B631.6080704@zweitgeist.com> References: <4798B631.6080704@zweitgeist.com> Message-ID: <479957D7.8030805@gmail.com> alexander treptow wrote: > There is one parameter, constant or vairable that indicates what > attachments or maybe other objects are drawn. It is a radius around the > camera. I've edited it, i think about 3 month ago, and i dont know where > to find it yet. Does anyone knows where to find? The far clip plane can be accessed via a debug setting. The draw distance in the regular options is nearly equivalent to the far clip, with some subtle differences. -Jason From gigstaggart at gmail.com Thu Jan 24 19:43:14 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jan 24 19:43:17 2008 Subject: [sldev] Compile as installer In-Reply-To: <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> Message-ID: <47995AD2.6050604@gmail.com> Argent Stonecutter wrote: > If LL explicitly listed the packages THEY ship as an exception, then the > issue would never come up. Argent is right. If you use the strict interpretations of copyright law (that is supported by precedent) then it is impossible to distribute the client legally, if it will eventually utilize fmod, KDU, or vivox. The only way to legally distribute the client is to not use (and not allow the use of) any dependency that isn't in the FLOSS exception. This is one reason I've been beating on the whole "get rid of all proprietary dependencies" drum for a long while now. The only good news is that it would be Linden Lab's place to sue you for such a violation, and it's pretty unlikely that they would (at this point in time at least, but it's not a good situation for the long run). -Jason From gigstaggart at gmail.com Thu Jan 24 19:46:02 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jan 24 19:46:06 2008 Subject: [sldev] Compile as installer In-Reply-To: <47995AD2.6050604@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> Message-ID: <47995B7A.3040406@gmail.com> Jason Giglio wrote: > Argent Stonecutter wrote: >> If LL explicitly listed the packages THEY ship as an exception, then >> the issue would never come up. > > Argent is right. If you use the strict interpretations of copyright law > (that is supported by precedent) then it is impossible to distribute the > client legally, if it will eventually utilize fmod, KDU, or vivox. Sorry to reply to myself, but I just remembered vivox is a separate binary that would probably be OK here. Fmod and KDU are still problematic. -Jason From secret.argent at gmail.com Thu Jan 24 20:03:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jan 24 20:03:32 2008 Subject: [sldev] Compile as installer In-Reply-To: <47995AD2.6050604@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> Message-ID: On 2008-01-24, at 21:43, Jason Giglio wrote: > Argent Stonecutter wrote: >> If LL explicitly listed the packages THEY ship as an exception, >> then the issue would never come up. > > Argent is right. If you use the strict interpretations of > copyright law (that is supported by precedent) then it is > impossible to distribute the client legally, if it will eventually > utilize fmod, KDU, or vivox. Or Quicktime on Windows (it's allowed by the GPL2 on OSX, since it's part of the OS). > This is one reason I've been beating on the whole "get rid of all > proprietary dependencies" drum for a long while now. That would work as well. > The only good news is that it would be Linden Lab's place to sue > you for such a violation, and it's pretty unlikely that they would > (at this point in time at least, but it's not a good situation for > the long run). Indeed. From johan.j.janssen at philips.com Fri Jan 25 00:39:43 2008 From: johan.j.janssen at philips.com (Janssen, Johan j) Date: Fri Jan 25 00:41:53 2008 Subject: [sldev] Building a debug build in VS2005 Message-ID: Hello folks, I've been trying to get a debug build in VS2005 of the second life viewer going for a while now, but I'm running into a brick wall regarding the embedded webbrowser (llmozlib) and XUL.dll. The debug version of XUL.dll that is in the lib package refers to MSVCR71d.dll (VS2003), and somewhere deep down in MSVCR71d it asserts on a heap corruption error. I figured it might be a conflict between the VS2005 llmozlib and the VS2003 runtime loaded by XUL, so I tried putting the release version of XUL.dll in place of the debug version because the release version works fine, but when loading it the viewer complains about a missing entry points in XUL.dll, NSGlue_Assertion and NSGlue_Warning. So far I haven't been able to get a hold of the XUL library so I can recompile it myself against VS2005. Has anyone managed to get the SL viewer going in VS2005 in debug mode? Do the problems I'm mentioning sound familiar? And how can I resolve these problems? Thanks in advance, Johan Janssen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080125/ca23d4d3/attachment.htm From alexander.treptow at zweitgeist.com Fri Jan 25 03:16:29 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Jan 25 03:16:44 2008 Subject: [sldev] Compile as installer In-Reply-To: <20080124200016.5B76841B44F@stupor.lindenlab.com> References: <20080124200016.5B76841B44F@stupor.lindenlab.com> Message-ID: <4799C50D.5040806@zweitgeist.com> Hi tobi, this should solve the problem. the script creates a packaged folder with a runable version of SL. I installed NSIS but it doesn't generates the "setup.exe". The packaged folder only contains app_settings, character, fonts, skins, my own folder, the llkdu.dll and my executeable. So it seems to work fine without all the other libs, like fmod. I dont know why the python script doesnt generates an .nsi file. as long as there is none it couldnt be started ^^ But thanks for help, now i can distribute a package that could be run separately to SL and dont have to copy my files in its directory. But SL needs to be installed on the system previously, because without installer there are not all needed folders in the user directory of windows to run the programm successfully (ERROR: Invalid name for LLDir::setLindenUserDir) greets, alex > Hi, > besides all issues of licensing, you can easily create a "setup.exe". Just > install the Nullsoft Scriptable installer (http://nsis.sf.net) and run > "secondlife setup build agni.bat". This batch then calls the > "viewer_manifest.py" python scripts which creates automatically the > installer script for NSIS and runs it. For every library or custom file you > like to ship, make sure that you include it in the viewer_manifest.py. > > I hope this answers the question. > -Tobi From alexander.treptow at zweitgeist.com Fri Jan 25 03:19:02 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Jan 25 03:19:14 2008 Subject: [sldev] Camera drawing radius for objects In-Reply-To: <479957D7.8030805@gmail.com> References: <4798B631.6080704@zweitgeist.com> <479957D7.8030805@gmail.com> Message-ID: <4799C5A6.2020009@zweitgeist.com> >> There is one parameter, constant or vairable that indicates what >> attachments or maybe other objects are drawn. It is a radius around >> the camera. I've edited it, i think about 3 month ago, and i dont >> know where to find it yet. Does anyone knows where to find? > The far clip plane can be accessed via a debug setting. The draw > distance in the regular options is nearly equivalent to the far clip, > with some subtle differences. > > -Jason hi jason i think it was the draw distance i edited but what about the subtile differences? thanks for help, alex From alissa_sabre at yahoo.co.jp Thu Jan 24 20:31:28 2008 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Fri Jan 25 05:49:59 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: Message-ID: <1saids5sPbkw3ds9s0cL116r.alissa_sabre@yahoo.co.jp> Thank you Lindens for much detailed explanations! > So that's where we stand today, a bunch of code that relies on an almost > deprecated class. In case anyone was still considering writing new code > that uses LLStrings... > > I think it would make sense to complete the process by finding all char* > to LLString conversions and using ll_safe_string instead. In short, the recommended uses of std::string and LLString *now* are, in my understanding: - New codes should use std::string and avoid LLSting as much as possible. Use ll_safe_string() if you are converting from char * that can be a NULL. - Replace LLString objects with std::string if you are modifying existing codes and the changes are straightforward, also using ll_safe_string(). - Code updates only to replace LLString is not desired for the moment, however. - We can keep using static member functions of LLString. Correct me if I'm wrong. I have an additional comment. I think there are two totally separate cases that a NULL pointer is passed to LLString(char const *). Case (1) is the programming mistake, e.g., passing a NULL indicating an error to LLString(char const *) without testing for a possibility of the error. Case (2) is the intended uses of a NULL as a _string_containing_nothing_. Case (2) is fine, but the case (1) is a bug. Even though LLString(NULL) doesn't crash at that point, the program should have tested the return value from the possibility of an error and should behave appropriately. I'm afraid simply going on with an emply string makes the viewer instable... Well, isn't it better that the viewer crashes during the QA cycle, than that the viewer misbehave after the release? Blindly enclosing with ll_safe_string() can hide some serious bugs... Based on the consideration above, I suggest adding one more guideline: - Explicitly test NULL pointer return from a function that indicates an error. Don't use ll_safe_string() for the purpose. How about this? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Fri Jan 25 06:32:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 25 06:32:50 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <1saids5sPbkw3ds9s0cL116r.alissa_sabre@yahoo.co.jp> References: <1saids5sPbkw3ds9s0cL116r.alissa_sabre@yahoo.co.jp> Message-ID: On 2008-01-24, at 22:31, alissa_sabre@yahoo.co.jp wrote: > - Explicitly test NULL pointer return from a function that indicates > an error. Don't use ll_safe_string() for the purpose. I heartily endorse this product and or service. From tlang303 at gmail.com Fri Jan 25 06:50:34 2008 From: tlang303 at gmail.com (Tobias Lang) Date: Fri Jan 25 06:50:37 2008 Subject: [sldev] Compile as installer In-Reply-To: <4799C50D.5040806@zweitgeist.com> References: <20080124200016.5B76841B44F@stupor.lindenlab.com> <4799C50D.5040806@zweitgeist.com> Message-ID: <66bc8ec50801250650md60bd82t9277623e503e9ceb@mail.gmail.com> Hi Alex, it works for me. It is most likely a path problem in your case. Please make sure that every dll is in newview and in ""../../libraries/i686-win32/lib_release" That's the safest way to do it, since some dll get copied from the lib folder others from newview. You can see that is viewer_manifest.py very well. Also, the NSIS installer gets called out of the python scripts, so it contains a fixed path name: "NSIS_path = 'C:\\Program Files\\NSIS\\makensis.exe'" change it, or change your NSIS installer. -Tobi On Jan 25, 2008 6:16 AM, alexander treptow wrote: > Hi tobi, > this should solve the problem. the script creates a packaged folder with > a runable version of SL. I installed NSIS but it doesn't generates the > "setup.exe". > The packaged folder only contains app_settings, character, fonts, skins, > my own folder, the llkdu.dll and my executeable. So it seems to work > fine without all the other libs, like fmod. > > I dont know why the python script doesnt generates an .nsi file. as long > as there is none it couldnt be started ^^ > > But thanks for help, now i can distribute a package that could be run > separately to SL and dont have to copy my files in its directory. But SL > needs to be installed on the system previously, because without > installer there are not all needed folders in the user directory of > windows to run the programm successfully (ERROR: Invalid name for > LLDir::setLindenUserDir) > > greets, > alex > > Hi, > > besides all issues of licensing, you can easily create a "setup.exe". > Just > > install the Nullsoft Scriptable installer (http://nsis.sf.net) and run > > "secondlife setup build agni.bat". This batch then calls the > > "viewer_manifest.py" python scripts which creates automatically the > > installer script for NSIS and runs it. For every library or custom file > you > > like to ship, make sure that you include it in the viewer_manifest.py. > > > > I hope this answers the question. > > -Tobi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080125/384e9716/attachment.htm From dzonatas at dzonux.net Fri Jan 25 08:50:30 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 25 08:48:54 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> Message-ID: <479A1356.7090206@dzonux.net> Phoenix wrote: > Personally, I always use std::string, and wrap char* and c APIs with > ll_safe_string which is prototyped as: > > /** > * @brief Return a string constructed from in without crashing if the > * pointer is NULL. > */ > std::string ll_safe_string(const char* in); > I find it odd not to use a namespace with C++. An example with namespace is LL::safe_string(), but the function is ll_safe_string() without the namespace. If there is inertia to update code, then perhaps add in the effect of the namespace to make it easier for non LL namespaces to exist in the open source instead of forcing it all in one global namespace. > >> >> On Wed, 23 Jan 2008 08:52:22 -0800, Steve Linden >> wrote: >> >>> Correct, LLString exists specifically to protect against passing a >>> NULL char* to a function that takes a const std::string&. C++ will >>> quietly attempt to convert the NULL char* into a std::string causing >>> a crash. >>> >>> e.g. >>> >>> foo (const std::string& s) >>> { >>> } >>> bar (const char* c) >>> { >>> foo(c); // crashes if c is NULL >>> } >>> main() >>> { >>> const char* s = fetchSomeString(); // returns NULL if it fails >>> foo(s); // crash! >>> } >>> >>> Note: we -still- have thousands of char arrays and char*'s in the >>> code, and this pattern exists all over the place, especially in the >>> UI code. We are actively working on eliminating this pattern. Once >>> we do, we can safely replace LLString with std::string. That is not only a compiler bug, but it is also a programmer bug as well. The compiler (especially MSVS) allows one to break the rules of distinct types when it comes to char*. Perhaps, it was placed in the compiler to allow easy movement from C to C++, but it is truly a bad programmer bit. The fact that the compiler didn't error at compiler-time on "foo(s)" is the gotcha. Just because the compiler doesn't error at compile-time on it doesn't mean that it is written correctly! The fix would be to add this: foo(const char* s) { foo( ll_safe_string( s ) ) ; } With strictness of distinct types, the compiler will choose the the foo(char*) version when it encounters "foo(s)" in main(). With this extra function being defined, it would be correct for the compiler to complain about unresolved references or detect that foo(const char*s) was not defined. In fact, in a cross-compile environment we find this strictness is enabled: http://jira.secondlife.com/browse/VWR-186 Hence, the compiler really shouldn't try to convert char* automatically to std::string by default. It should error. (And, now you know the pain of why it shouldn't -- the crashes.) Didn't mean to derail this conversation about LLString, but I noticed this came up in the agenda: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2008-01-17 From phoenix at secondlife.com Fri Jan 25 09:11:25 2008 From: phoenix at secondlife.com (Phoenix) Date: Fri Jan 25 09:11:14 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <1saids5sPbkw3ds9s0cL116r.alissa_sabre@yahoo.co.jp> References: <1saids5sPbkw3ds9s0cL116r.alissa_sabre@yahoo.co.jp> Message-ID: <3DC7A344-2ACE-4B41-8455-6702E302ED2C@secondlife.com> On 2008-01-24, at 20:31, alissa_sabre@yahoo.co.jp wrote: > In short, the recommended uses of std::string and LLString *now* are, > in my understanding: > > - New codes should use std::string and avoid LLSting as much as > possible. Use ll_safe_string() if you are converting from char * > that can be a NULL. > > - Replace LLString objects with std::string if you are modifying > existing codes and the changes are straightforward, also using > ll_safe_string(). > > - Code updates only to replace LLString is not desired for the moment, > however. > > - We can keep using static member functions of LLString. > - Explicitly test NULL pointer return from a function that indicates > an error. Don't use ll_safe_string() for the purpose. > > How about this? I too endorse this product and or service. -------------- 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/20080125/ac708bc1/PGP.pgp From phoenix at secondlife.com Fri Jan 25 09:17:02 2008 From: phoenix at secondlife.com (Phoenix) Date: Fri Jan 25 09:16:25 2008 Subject: [sldev] Uses of LLString and std::string ? In-Reply-To: <479A1356.7090206@dzonux.net> References: <1L54dw6uardv4ds4ds4ed4G.alissa_sabre@yahoo.co.jp> <47976C7A.5040204@lindenlab.com> <479770C6.1010601@lindenlab.com> <479A1356.7090206@dzonux.net> Message-ID: <20638256-407B-487B-BB76-72A42D91C4CF@secondlife.com> On 2008-01-25, at 08:50, Dzonatas wrote: > Phoenix wrote: >> /** >> * @brief Return a string constructed from in without crashing if the >> * pointer is NULL. >> */ >> std::string ll_safe_string(const char* in); >> > > I find it odd not to use a namespace with C++. An example with > namespace is LL::safe_string(), but the function is ll_safe_string > () without the namespace. If there is inertia to update code, then > perhaps add in the effect of the namespace to make it easier for > non LL namespaces to exist in the open source instead of forcing it > all in one global namespace. I also find it odd, but we started this whole thing on Visual Studio 6. I'm not a windows guru but I recall it had a bad STL and poor to non-existent support for namespaces. This of course could be just a made up memory based on my wary stance towards microsoft products and the fact that most of the developers working on it at the time were more comfortable in c than c++. -------------- 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/20080125/4af6e824/PGP.pgp From tom at cornish-pasty.com Fri Jan 25 09:48:00 2008 From: tom at cornish-pasty.com (Thomas Rowland) Date: Fri Jan 25 09:48:05 2008 Subject: [sldev] Building a debug build in VS2005 In-Reply-To: Message-ID: <001101c85f7a$6ef64020$6f281a52@tomhome> Its been a long time since I have even bothered to pay much attention to the mails I get from the list let alone download and compile a source release and to be honest I cant be bothering with the mess that is the viewer source and compiling it with vc8 just now. Back in June 07 there are a handful of emails regarding the debug in vc8 of 1.17.2.0, which I managed to get working. I had to disable llmozlib back then. Also I added to Linker\Input\Ignore in the newview properties, putting in msvcrt and libcmt. Perhaps that and the archive for June 2007 is help. -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Janssen, Johan j Sent: 25 January 2008 08:40 To: sldev@lists.secondlife.com Subject: [sldev] Building a debug build in VS2005 Hello folks, I've been trying to get a debug build in VS2005 of the second life viewer going for a while now, but I'm running into a brick wall regarding the embedded webbrowser (llmozlib) and XUL.dll. The debug version of XUL.dll that is in the lib package refers to MSVCR71d.dll (VS2003), and somewhere deep down in MSVCR71d it asserts on a heap corruption error. I figured it might be a conflict between the VS2005 llmozlib and the VS2003 runtime loaded by XUL, so I tried putting the release version of XUL.dll in place of the debug version because the release version works fine, but when loading it the viewer complains about a missing entry points in XUL.dll, NSGlue_Assertion and NSGlue_Warning. So far I haven't been able to get a hold of the XUL library so I can recompile it myself against VS2005. Has anyone managed to get the SL viewer going in VS2005 in debug mode? Do the problems I'm mentioning sound familiar? And how can I resolve these problems? Thanks in advance, Johan Janssen No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date: 23/01/2008 17:47 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080125/841becce/attachment-0001.htm From rdw at lindenlab.com Fri Jan 25 10:38:05 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Fri Jan 25 10:50:16 2008 Subject: [sldev] Compile as installer In-Reply-To: <4799C50D.5040806@zweitgeist.com> References: <20080124200016.5B76841B44F@stupor.lindenlab.com> <4799C50D.5040806@zweitgeist.com> Message-ID: <479A2C8D.4030906@lindenlab.com> alexander treptow wrote: > Hi tobi, > this should solve the problem. the script creates a packaged folder > with a runable version of SL. I installed NSIS but it doesn't > generates the "setup.exe". > The packaged folder only contains app_settings, character, fonts, > skins, my own folder, the llkdu.dll and my executeable. So it seems to > work fine without all the other libs, like fmod. > > I dont know why the python script doesnt generates an .nsi file. as > long as there is none it couldnt be started ^^ It does, actually, but deletes it to avoid mistakes like someone checking in the generated file. Here's the code that does the nsis part (at line 330 of indra/newview/viewer_manifest.py): self.replace_in("installers/windows/installer_template.nsi", tempfile, { "%%VERSION%%":version_vars, "%%GRID_VARS%%":grid_vars_template % substitution_strings, "%%INSTALL_FILES%%":self.nsi_file_commands(True), "%%DELETE_FILES%%":self.nsi_file_commands(False)}) NSIS_path = 'C:\\Program Files\\NSIS\\makensis.exe' self.run_command('"' + proper_windows_path(NSIS_path) + '" ' + self.dst_path_of(tempfile)) self.remove(self.dst_path_of(tempfile)) If you comment out that last line, it'll leave the generated nsi file around. Probably room for a debug flag here or something. Might want to watch the script's output because it will print any error messages coming from running nsis. -RYaN From gigstaggart at gmail.com Fri Jan 25 11:27:19 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jan 25 11:27:23 2008 Subject: [sldev] Camera drawing radius for objects In-Reply-To: <4799C5A6.2020009@zweitgeist.com> References: <4798B631.6080704@zweitgeist.com> <479957D7.8030805@gmail.com> <4799C5A6.2020009@zweitgeist.com> Message-ID: <479A3817.5030406@gmail.com> alexander treptow wrote: > hi jason > i think it was the draw distance i edited but what about the subtile > differences? I think the main difference is that merely adjusting the far clip won't change the radius of things that are updated from the server, just the raw rendering range. -Jason From robla at lindenlab.com Fri Jan 25 11:45:01 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 25 11:50:03 2008 Subject: [sldev] Compile as installer In-Reply-To: <47995AD2.6050604@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> Message-ID: <479A3C3D.8080203@lindenlab.com> On 1/24/08 7:43 PM, Jason Giglio wrote: > Argent Stonecutter wrote: >> If LL explicitly listed the packages THEY ship as an exception, then >> the issue would never come up. > > Argent is right. If you use the strict interpretations of copyright > law (that is supported by precedent) then it is impossible to > distribute the client legally, if it will eventually utilize fmod, > KDU, or vivox. > > The only way to legally distribute the client is to not use (and not > allow the use of) any dependency that isn't in the FLOSS exception. Actually, that's not the only way. One can also get a commercial license from Linden Lab which then allows linking in proprietary libraries. > This is one reason I've been beating on the whole "get rid of all > proprietary dependencies" drum for a long while now. > > The only good news is that it would be Linden Lab's place to sue you > for such a violation, and it's pretty unlikely that they would (at > this point in time at least, but it's not a good situation for the > long run). Having proprietary libraries in there is not part of any nefarious plan to get more commercial licensees, though it does create that pressure for licensees. We haven't been very aggressive about removing proprietary dependencies, and might very well add more in the future. There's a lot of disagreement here at Linden Lab about just how much we should worry about this problem, with one side arguing much as you do here, and the other side arguing that we have an obligation to our user base to provide the best features for the price, regardless of whether or not it passes an open source purity test. I've generally discouraged this type of discussion on the list, but perhaps we're at a point where it makes sense to have a discussion on this topic (a respectful one, please). Should we pass up opportunities to bring great new functionality that would be greatly appreciated by the vast majority of our residents if it means introducing a new proprietary dependency? If we were to get really aggressive about removing proprietary dependencies, wouldn't that hobble us relative to competitors that have no such constraint? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080125/a7df2f5a/signature.pgp From secret.argent at gmail.com Fri Jan 25 12:12:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 25 12:12:50 2008 Subject: [sldev] Compile as installer In-Reply-To: <479A3C3D.8080203@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> Message-ID: <0AB919B0-4F41-47EA-825A-DBF836641068@gmail.com> On 2008-01-25, at 13:45, Rob Lanphier wrote: > Having proprietary libraries in there is not part of any nefarious > plan to get more commercial licensees, though it does create that > pressure for licensees. We haven't been very aggressive about > removing proprietary dependencies, and might very well add more in > the future. There's a lot of disagreement here at Linden Lab about > just how much we should worry about this problem, with one side > arguing much as you do here, and the other side arguing that we > have an obligation to our user base to provide the best features > for the price, regardless of whether or not it passes an open > source purity test. I'm not concerned with it passing an open-source purity test, I'm concerned with the difference between Linden Labs copyright and the actual real-world terms they are enforcing. So there's a third option: rather than remove the commercial libraries, modify the license to explicitly allow them. You could use the LGPL, or you could extend the existing exception or add a new exception to your license to permit third party redistribution of a client that links against the libraries that you distribute with SL (subject, of course, to whatever restrictions the licenses on those libraries enforce). The GPL doesn't permit this, which is why you would need to modify it, but since you've already done so once that shouldn't be out of the question. That would simply make the current de-facto situation explicitly recognized in the open source client license. From robla at lindenlab.com Fri Jan 25 12:25:01 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 25 12:27:04 2008 Subject: [sldev] Proprietary dependencies (Re: Compile as installer) In-Reply-To: <0AB919B0-4F41-47EA-825A-DBF836641068@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <0AB919B0-4F41-47EA-825A-DBF836641068@gmail.com> Message-ID: <479A459D.2000701@lindenlab.com> (sorry, I meant to change the subject line on my first message). On 1/25/08 12:12 PM, Argent Stonecutter wrote: > On 2008-01-25, at 13:45, Rob Lanphier wrote: >> Having proprietary libraries in there is not part of any nefarious >> plan to get more commercial licensees, though it does create that >> pressure for licensees. We haven't been very aggressive about >> removing proprietary dependencies, and might very well add more in >> the future. There's a lot of disagreement here at Linden Lab about >> just how much we should worry about this problem, with one side >> arguing much as you do here, and the other side arguing that we have >> an obligation to our user base to provide the best features for the >> price, regardless of whether or not it passes an open source purity >> test. > > I'm not concerned with it passing an open-source purity test, I'm > concerned with the difference between Linden Labs copyright and the > actual real-world terms they are enforcing. If you're aware of violations of our copyright, you should let us know. Send mail to licensing@lindenlab.com. > So there's a third option: rather than remove the commercial > libraries, modify the license to explicitly allow them. You could use > the LGPL, or you could extend the existing exception or add a new > exception to your license to permit third party redistribution of a > client that links against the libraries that you distribute with SL > (subject, of course, to whatever restrictions the licenses on those > libraries enforce). The GPL doesn't permit this, which is why you > would need to modify it, but since you've already done so once that > shouldn't be out of the question. > > That would simply make the current de-facto situation explicitly > recognized in the open source client license. The problem with that is that it gives someone the opportunity to create a proprietary competitor to Second Life without contributing anything back (financially or to the ecosystem), and would probably be a pretty reckless for us to do business-wise given our market position. Our current model forces one or the other, and doesn't prohibit the creation of a purely open source viewer (in fact, encourages it). Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080125/46957321/signature.pgp From soft at lindenlab.com Fri Jan 25 13:25:17 2008 From: soft at lindenlab.com (Soft) Date: Fri Jan 25 13:25:20 2008 Subject: [sldev] Friday source updates Message-ID: Consider joining the sldev-commits mailing list if you're not on it: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits Until we're in shape to push individual commits, each Friday, I'll push interim releases on several svn branches. The commit messages also include the tarball addresses if you're inclined to fetch source that way: release: (internal development tip - "release" is a funny name) https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000341.html maintenance: (bug fixing branch) https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000338.html maint-ui: (UI- and viewer-centric bug fixing) https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000342.html - Unlike release candidate and release versions, I'm *not* testing builds on all three platforms for these, but I'll be quick to check in build fixes if you reply with them here. If it's more than a one-to-two liner please JIRA it, though. Also unlike RC and release versions, these will not be posted to the wiki, as there will be many of them. - Included in the svn version is a doc/asset_urls.txt file, which can be parsed to automate downloading library and asset tarballs. Any suggestions on the format would be great. Also, if anyone feels ambitious, I'd gladly take in a script that uses those to ease updates - ideally something in python so all three platforms can easily take advantage of one version. - If you file bugs against these, be sure to note the source branch and revision in your JIRA. - If you want a nudge to give it a try, release has the 32-bit Linux voice blob From gigstaggart at gmail.com Fri Jan 25 13:32:03 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jan 25 13:32:06 2008 Subject: [sldev] Proprietary dependencies (Re: Compile as installer) In-Reply-To: <479A459D.2000701@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <0AB919B0-4F41-47EA-825A-DBF836641068@gmail.com> <479A459D.2000701@lindenlab.com> Message-ID: <479A5553.7070500@gmail.com> Rob Lanphier wrote: > If you're aware of violations of our copyright, you should let us know. > Send mail to licensing@lindenlab.com. Every third party viewer violates your copyright: https://wiki.secondlife.com/wiki/Alternate_viewers Just go down that list if you want a list of violators. They all link to Fmod and KDU in violation of the GPL. Do you really intend to shut down all third party viewer development? -Jason From gigstaggart at gmail.com Fri Jan 25 13:39:57 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jan 25 13:40:01 2008 Subject: [sldev] Compile as installer In-Reply-To: <479A3C3D.8080203@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> Message-ID: <479A572D.9020002@gmail.com> Rob Lanphier wrote: > base to provide the best features for the price, regardless of whether > or not it passes an open source purity test. The best feature is the ability for open source people to work on the viewer, unencumbered by these license issues. The price for that is getting rid of proprietary dependencies. It's a pretty simple cost-benefit analysis. How much have these proprietary issues cost you in terms of development you missed out on? It's hard to quantify but I know I've had at least several clients back out after hearing there would be no way for them to legally distribute a client I develop for them without hobbling it in terms of features. -Jason From secret.argent at gmail.com Fri Jan 25 13:57:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jan 25 13:57:58 2008 Subject: [sldev] Re: Proprietary dependencies (Re: Compile as installer) In-Reply-To: <479A459D.2000701@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <0AB919B0-4F41-47EA-825A-DBF836641068@gmail.com> <479A459D.2000701@lindenlab.com> Message-ID: <4685B5D9-25F3-4F5A-97ED-811013AC6806@gmail.com> On 2008-01-25, at 14:25, Rob Lanphier wrote: > If you're aware of violations of our copyright, you should let us > know. Send mail to licensing@lindenlab.com. What I'm trying to figure out is what that actually means. Following the build instructions for the SL viewer doesn't appear to produce a program that's redistributable under the GPL, even if the components that aren't open source are not transferred, even if it required the recipient to have their own copy of the SL client installed and only allowed you to connect to the SL grid. > The problem with that is that it gives someone the opportunity to > create a proprietary competitor to Second Life without contributing > anything back (financially or to the ecosystem), and would probably > be a pretty reckless for us to do business-wise given our market > position. I'm not sure how. The LGPL would, but simply creating an exclusion for the specific components that SL depends on (such as Quicktime on Windows) wouldn't seem to have that effect. From josh at lindenlab.com Fri Jan 25 16:11:36 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jan 25 16:17:43 2008 Subject: [sldev] Linden Lab Release Roadmap Update Message-ID: <479A7AB8.3090904@lindenlab.com> Quick update: * We're tentatively planning 1.19.0 releases for next week - server updates on Tuesday/Wednesday and hopefully a viewer RC0 on Thursday * As predicted, doing the web-based authentication and work to stage the group chat changes over several releases took quite a while to get rock solid. We're finishing up QA on the whole shebang now. * We're putting together the release notes (which is a project in itself) on this whole beastie - should be ready for sharing early next week. There is very little distinction between the "release" development tip (soft just did a code drop for this) and the frozen 1.19.0 branch - the main difference is that we're putting bug fixes into the 1.19.0 branches to keep "release" stable. There are a handful of known UI issues as a result of some code refactoring; they're being tackled before RC0 goes live. (If there's a bug in both release and 1.19.0 that might seem backwards, but an as-yet-untested fix going into release could destabilize all development, whereas an if the bug is a ship-stopper, putting the as-yet-fix-untested into 1.19.0 doesn't make it any less shippable and lets us test it without blocking other developers.) We'll do a source drop of 1.19.0 and port the fixes to "release" and do another drop of that code as soon as we hit a good plateau. From robla at lindenlab.com Fri Jan 25 16:18:43 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 25 16:20:36 2008 Subject: [sldev] Proprietary dependencies [2] (Re: Compile as installer) In-Reply-To: <479A572D.9020002@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> Message-ID: <479A7C63.8060308@lindenlab.com> On 1/25/08 1:39 PM, Jason Giglio wrote: > Rob Lanphier wrote: >> base to provide the best features for the price, regardless of >> whether or not it passes an open source purity test. > > The best feature is the ability for open source people to work on the > viewer, unencumbered by these license issues. The price for that is > getting rid of proprietary dependencies. > > It's a pretty simple cost-benefit analysis. How much have these > proprietary issues cost you in terms of development you missed out on? > > It's hard to quantify but I know I've had at least several clients > back out after hearing there would be no way for them to legally > distribute a client I develop for them without hobbling it in terms of > features. If you were telling them there was no way for them to legally distribute a client you develop for them, you didn't give them the whole story. You probably should have told them "you will need to get a license from Linden Lab to distribute the client". That's a very different thing. That said, I agree that there's a cost-benefit analysis, but I don't see it as simple. First you'd need to quantify the development, and then the value of that development to us and to residents as a whole. It's not entirely clear that the delta in 2007 was so large that we missed out on that much, especially given the fact that early on, we weren't particularly well equipped to deal with a large influx of contribution. At a gut level, I'd much prefer to get rid of proprietary dependencies. If nothing else, it makes my job easier, but I also philosophically prefer that we remove them sooner rather than later. I just don't feel like I yet have a watertight business and community case to make that we should perhaps take steps backwards in features and functionality in order to get rid of those dependencies. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080125/826974b6/signature-0001.pgp From pbossut at kei.com Fri Jan 25 18:04:44 2008 From: pbossut at kei.com (Philippe Bossut) Date: Fri Jan 25 18:04:41 2008 Subject: [sldev] Which code drop to build on Windows with VS 2005 Express? Message-ID: Hi, I'm new to the wonderful world of slviewer coding. I started a week ago and, since I'm more of a Mac developer, started to download and compile the XCode project. I have to say that the process was as painless as can possibly be. In just a matter of hours, I was up and running with my own compiled version of the slviewer, right there on my old iBook G4. Kudos to the folks who wrote and maintain the wiki on the open source portal! Truly excellent :) With that success, I thought I'd switch to Windows since I need to use an SDK that's available only on Windows in that new project I'm starting. I haven't done much Windows development lately so I downloaded the free Visual C++ 2005 Express Edition from MS, and went through the whole details provided in the (again, excellent) wiki. It took me much longer and, after a couple of tweaks that were not documented (but easy to figure out), I got the ReleaseNoOpt target compiled and linked. Alas, I can't run it properly. I first got errors about missing dll and xml (which I simply moved to the exe folder for the time being) but now I get what seems to be a code issue: "ERROR: Invalid getColor control ColorDropShadow" I guess I could figure that one out too but, considering some past comments on that list about issues with vc8, I'm wondering if I'm not just going into a rat hole. May be I'm using the wrong compiler/code drop/target combination. Here's what I'm using: - Visual C++ 2005 Express Edition : should I just go and buy a Pro version? I saw that LL is apparently still using 2003. - RC-1.18.6.4 drop: May be I should be using an older source drop? - ReleaseNoOpt : should I build Release may be? Debug seems to be the hardest to build (I'm building Release right now) Any advice appreciated. Cheers, - Philippe From lenglish5 at cox.net Fri Jan 25 19:05:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jan 25 19:05:19 2008 Subject: [sldev] Proprietary dependencies [2] (Re: Compile as installer) In-Reply-To: <479A7C63.8060308@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> Message-ID: <479AA36D.3020500@cox.net> Rob Lanphier wrote: > [...] > At a gut level, I'd much prefer to get rid of proprietary > dependencies. If nothing else, it makes my job easier, but I also > philosophically prefer that we remove them sooner rather than later. > I just don't feel like I yet have a watertight business and community > case to make that we should perhaps take steps backwards in features > and functionality in order to get rid of those dependencies. > > Rob My own take is that things are so messy in the current client that complaining about this kind of thing is futile anyway. Until the client is factored properly any changes that are made by an inidividual are bandaides on bandaides. They might be expensive, horrible-to-create bandaides, but they are bandaides nonetheless, and the amount spent making them is an order of magnitude more than it needs to be. And once the client IS factored properly, replacing proprietary libraries with open source ones should be reasonably trivial, so either way, its a silly discussion to be having. Lawson From dzonatas at dzonux.net Fri Jan 25 21:27:59 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jan 25 21:26:19 2008 Subject: [sldev] Which code drop to build on Windows with VS 2005 Express? In-Reply-To: References: Message-ID: <479AC4DF.6090302@dzonux.net> Philippe Bossut wrote: > I guess I could figure that one out too but, considering some past > comments on that list about issues with vc8, I'm wondering if I'm not > just going into a rat hole. May be I'm using the wrong compiler/code > drop/target combination. Here's what I'm using: > - Visual C++ 2005 Express Edition : should I just go and buy a Pro > version? I saw that LL is apparently still using 2003. I use the SCons builder with Visual C++ Express 2005. It compiles clean. > - RC-1.18.6.4 drop: May be I should be using an older source drop? If you use the project files, they may be outdated. I've seen updates posted for VS 2005. > - ReleaseNoOpt : should I build Release may be? Debug seems to be > the hardest to build (I'm building Release right now) Sounds like your using the project files. You'll probably have to put the built files into one directory or set your env variables. From dzonatas at dzonux.net Sat Jan 26 06:43:15 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 06:41:39 2008 Subject: [sldev] Proprietary dependencies [2] (Re: Compile as installer) In-Reply-To: <479AA36D.3020500@cox.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> Message-ID: <479B4703.5000607@dzonux.net> Lawson English wrote: > Rob Lanphier wrote: >> [...] >> At a gut level, I'd much prefer to get rid of proprietary >> dependencies. If nothing else, it makes my job easier, but I also >> philosophically prefer that we remove them sooner rather than later. >> I just don't feel like I yet have a watertight business and community >> case to make that we should perhaps take steps backwards in features >> and functionality in order to get rid of those dependencies. >> >> Rob > My own take is that things are so messy in the current client that > complaining about this kind of thing is futile anyway. Until the > client is factored properly any changes that are made by an > inidividual are bandaides on bandaides. What is not clear is why either proprietary or open-source dependencies has any affect of progress of the of the product. This is said with attention being brought to the monolithic design of the client code being bundled as static libraries under one single executable. It has not been made clear to the community why that is being done. Any argument to choose between proprietary or open-source dependency is held back by the reason to keep libraries as static links. We've heard the issue saying that it makes installation easier, but that is all that is being said. If the installation scripts and procedure were made to handle dynamic libraries, the issue of there being a proprietary or open-source library attached become really a non-issue as long as they are dynamically linked. That is one part there. Further, the client code could change separate out its features into different processes or tasks. Surely there is no need to keep every piece of the entire client to run in synchronous fashion under a single CPU. For one, the sound system could be put into another asynchronous process such that it is just passed a URL to play. Is there any example of this being done now, yes, the voice client is a separate asynchronous task, and it sits in its own module separate from the client. That is how regular sound should work also in its own module. Let LL distribute its proprietary module and others distribute the open-source alternative. Between the tasks, there just needs to been an API standard. No more bickering about proprietary dependencies and no more running in circles about saying it makes the installing easier, please. Let's just agree to a standard API. From ts_ryuzo at hotmail.com Sat Jan 26 07:21:31 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sat Jan 26 07:21:34 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: <478261C6.5020609@lindenlab.com> References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: Hi, Just a question. "since the interest list is based solely on size vs. distance for sending prims, occluders are often not sent first" The sieze mentioned in the above statment is file size? Or is it the size of the object or is it the size that prim occupy on the screen? Thanks, Qian Hao> Date: Mon, 7 Jan 2008 09:30:46 -0800> From: davep@lindenlab.com> To: gigstaggart@gmail.com> CC: ts_ryuzo@hotmail.com; sldev@lists.secondlife.com> Subject: Re: [sldev] Improving rendering sequence> > The client sends camera frustum information to the server, and the> server sends the client information about objects that are "interesting"> based on that information. Internally, we refer to this logic as the> "interest list," and it's unfortunately implemented entirely server> side. The gist of our streaming is "stream objects, ask for textures."> Since the network load of a prim is much less than a texture, occlusion> culling saves bandwidth by never requesting texture data for occluded> objects. Unfortunately, since the interest list is based solely on size> vs. distance for sending prims, occluders are often not sent first, so> every texture is visible for at least one frame. It's usually OK,> because the requested amount of a texture to download atrophies quickly> when the texture is not being rendered, lowering its priority as soon as> it is occluded. There may be optimization opportunities in the texture> download prioritizing code.> > > As far as front-to-back rendering goes to reduce overdraw, work has been> done to this end in windlight, but has more to do with changing the> order of specific types of geometry rather than reordering prims. In> windlight, terrain is rendered after prims, sky is rendered last, etc.> Occlusion culling was also rewritten in windlight to use fewer triangles> and fewer "guess" queries, getting rid of the "guess" queue and making> sure that if something is not visible, it's never rendered.> > > The biggest issue with occlusion culling performance is that very few> builds have any significant occluders due to overuse of transparencies> and walls that leak (have cracks between prims). I'd encourage any> builders to take a good look at how professional level designers layout> environments in video games. In "World of Warcraft," for example, there> are no windows, and you can never see the complex items inside a> building from the outside. In "Call of Duty 4," there are plenty of> windows, but you can never see into a window on one side of the building> and out the window on the other side, effectively making every building> an occluder. Compare this to Second Life, where every building has floor> to ceiling windows and no inside walls. Some simple tricks to keep your> windows and not kill performance are to make your windows opaque from> the outside. This is the perception people have of windows in real life,> so doing this will often make a build look "cleaner" or less cluttered.> > > Some builds that play really well with occlusion culling are the> cyberpunk city in Suffugium and the giant cube maze in Q. Let me know if> you know of others.> > > The other major limiting factor for performance in SL is the small batch> size. On average, SL draws about 70 triangles per drawing call. In> theory, increasing that number to 200 triangles per drawing call could> improve rendering performance by 200%. The primary reason the draw size> is so small is because we have to break batches to switch textures and> to sort transparent objects to be rendered in depth order. This is why> people in the graphics world are making such a fuss over "megatexturing"> and similar techniques. These techniques combine all visible textures> into a single large texture so all your geometry can be rendered with a> single draw call. These techniques require artist intervention from the> get go, however, so most are not applicable to SL. The technique that is> applicable is good ol' fashioned texture atlasing, which is merely> combining several textures into a single texture and modifying object> texture coordinates to reference the part of that larger texture that> contains the texture the object was originally referencing. Since> textures in SL are streaming, though, generating atlases for your builds> will result in ugly artifacts as textures load, so the correct solution> is probably something between megatexturing and atlasing, where atlases> are generated on-the-fly by the viewer and tailored to align texture> borders within the atlas along mip borders according to the amount of> the texture that's been downloaded so far.> > > We've (somewhat intentionally) done a very poor job at Linden Lab of> educating builders on how to be performance conscious, which I think> plays a large part in the overall sluggishness of the viewer. This is> part of a philosophy that says it should be possible to build a content> authoring system where artists don't need to care about performance> implications, as the software should just deal with whatever comes its> way appropriately. What we've seen, however, is that people (even> technically minded people) consume as many resources as are available to> them until performance reaches a level they deem is unacceptable, so the> more efficient your renderer becomes, the more ludicrous the demands> become. In SL, this usually means the performance becomes that of the> lowest common denominator in terms of what is acceptable. That is, if> you think performance is important and build a nice house with opaque> window exteriors and few textures, you'll still have a bad experience if> your neighbor thinks a flexi-prim bamboo forest is the bees knees.> > > The free market is winning out here (Otherland sims and similar, managed> estates do better than private estates with no building standards), but> it's slow going, and an initiative to document the best ways to build> beautifully and efficiently is probably in order.> > > Jason Giglio wrote:> > Qian Hao ~ wrote:> > > >> Then my next question is, how does the server know what to send to> >> the client? The server execute a raytracing algorithm? So the client> >> is not the one requesting for object information?> >> > >> > There's a subscription system, I believe controlled by both the client> > and the server.> >> > -Jason> > _______________________________________________> > Click here to unsubscribe or manage your list subscription:> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080126/2169c2c9/attachment-0001.htm From secret.argent at gmail.com Sat Jan 26 11:27:33 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 11:27:44 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479B4703.5000607@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> Message-ID: On 2008-01-26, at 08:43, Dzonatas wrote: > We've heard the issue saying that it makes installation easier, but > that is all that is being said. If the installation scripts and > procedure were made to handle dynamic libraries, the issue of there > being a proprietary or open-source library attached become really a > non-issue as long as they are dynamically linked. The GPL 2 doesn't work that way. The GNU MP library was shipped as a shared library, it still made the final work a derivative work under the GPL. Korn had to change the way he was building GCC for the same reason. It doesn't matter whether the libraries are linked in to the same executable or shipped as shared libraries. > Further, the client code could change separate out its features > into different processes or tasks. Surely there is no need to keep > every piece of the entire client to run in synchronous fashion > under a single CPU. Fifteen years ago I'd agree with you, but threads and lightweight processes do as good a job of that. And whether it's shared libraries or statically linked doesn't change that. On the other hand, pulling components out to separate executable talking through some IPC mechanism does provide a GPL cutout. From secret.argent at gmail.com Sat Jan 26 11:30:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 11:30:41 2008 Subject: [sldev] Improving rendering sequence In-Reply-To: References: <046D098C-33FC-43CB-A2D4-0B7B237F2982@gmail.com> <5C58181F-6B47-403B-B5BF-44D571BF11C9@gmail.com> <47817E5B.9060909@gmail.com> <478261C6.5020609@lindenlab.com> Message-ID: <0337E96D-4B01-4D3E-9E58-62079BC6005D@gmail.com> I was having problems with Windlight so I switched back to the old client, and I notice that loading order *seems* to be different in the two clients after a teleport: closer objects rezzed sooner. So the client does have some ability to effect this. Possibly it's choosing to load textures for closer objects and thus rendering them sooner. From carjay at gmx.net Sat Jan 26 12:45:45 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Jan 26 12:45:48 2008 Subject: [sldev] Friday source updates In-Reply-To: References: Message-ID: <479B9BF9.1050701@gmx.net> Soft wrote: > - If you want a nudge to give it a try, release has the 32-bit Linux voice blob > Nice :) How high are the chances to ever get a 64-bit Linux voice blob binary? (I know I can run the 32 bit executable if I install the necessary library dependencies, my first test was not very successful though but this belongs to a different thread). Regards, Carsten From dzonatas at dzonux.net Sat Jan 26 13:29:58 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 13:28:14 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> Message-ID: <479BA656.5060002@dzonux.net> Argent Stonecutter wrote: > On 2008-01-26, at 08:43, Dzonatas wrote: >> We've heard the issue saying that it makes installation easier, but >> that is all that is being said. If the installation scripts and >> procedure were made to handle dynamic libraries, the issue of there >> being a proprietary or open-source library attached become really a >> non-issue as long as they are dynamically linked. > > The GPL 2 doesn't work that way. The GNU MP library was shipped as a > shared library, it still made the final work a derivative work under > the GPL. Korn had to change the way he was building GCC for the same > reason. It doesn't matter whether the libraries are linked in to the > same executable or shipped as shared libraries. This is the same old argument we have spoke about many time before, and even post the unofficial wiki page about it. What I'm saying here is people should have a choice to which modules goes with the client -- don't have it static built. We make an API for it, and agree on it. If fact, I believe there has been some work on it with LLMedia; for example, but that change is being done internally. > >> Further, the client code could change separate out its features into >> different processes or tasks. Surely there is no need to keep every >> piece of the entire client to run in synchronous fashion under a >> single CPU. > > Fifteen years ago I'd agree with you, but threads and lightweight > processes do as good a job of that. And whether it's shared libraries > or statically linked doesn't change that. > > On the other hand, pulling components out to separate executable > talking through some IPC mechanism does provide a GPL cutout. > Yes. There is nothing stopping you or anyone to plug their TV into their VCR or amplifier of choice, and that is what I'm saying here. That choice does not violate the GPL. From pbossut at kei.com Sat Jan 26 14:21:14 2008 From: pbossut at kei.com (Philippe Bossut) Date: Sat Jan 26 14:21:14 2008 Subject: [sldev] Which code drop to build on Windows with VS 2005 Express? In-Reply-To: <479AC4DF.6090302@dzonux.net> References: <479AC4DF.6090302@dzonux.net> Message-ID: <54197142-7026-4117-8F20-C7CA155BFF8A@kei.com> Hi, Thanks Dzonatas for answering so quickly. It's nice to feel welcome even with the silliest question :) On Jan 25, 2008, at 9:27 PM, Dzonatas wrote: > Sounds like your using the project files. You'll probably have to > put the built files into one directory or set your env variables. Yes, I am using the project files. Your point about them being outdated might be the reason of my problems. I'll give a spin to using SCons builder as you are since it worked for you. If that failed, I'll try checking out more recent project files from svn. Thanks for the tip! Cheers, - Philippe From secret.argent at gmail.com Sat Jan 26 14:23:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 14:23:05 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BA656.5060002@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> Message-ID: <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> On 2008-01-26, at 15:29, Dzonatas wrote: > Argent Stonecutter wrote: >> On 2008-01-26, at 08:43, Dzonatas wrote: >>> We've heard the issue saying that it makes installation easier, >>> but that is all that is being said. If the installation scripts >>> and procedure were made to handle dynamic libraries, the issue of >>> there being a proprietary or open-source library attached become >>> really a non-issue as long as they are dynamically linked. >> >> The GPL 2 doesn't work that way. The GNU MP library was shipped as >> a shared library, it still made the final work a derivative work >> under the GPL. Korn had to change the way he was building GCC for >> the same reason. It doesn't matter whether the libraries are >> linked in to the same executable or shipped as shared libraries. > > This is the same old argument we have spoke about many time before, I'm not sure I understand what you're getting at here, which old argument? Just switching to dynamic linking and loading for fmod wouldn't make a difference, and quicktime is already dynamically loaded but it also makes it a GPL violation to link to it from SL on Windows (it's OK on OS X because it's shipped with the OS). > and even post the unofficial wiki page about it. What I'm saying > here is people should have a choice to which modules goes with the > client -- don't have it static built. We make an API for it, and > agree on it. That only works where there's a fully open source implementation of the code on the other side of the API that satisfies the FOSS exception. Not a stub, something you can actually use, like the BSD MP library or BSD editline. Where there is, this is already a non- issue, because you can build with the open source version. If there was, the open source version could just use that and it wouldn't be a dependency. From lenglish5 at cox.net Sat Jan 26 14:53:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jan 26 14:53:29 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> Message-ID: <479BB9E7.5050008@cox.net> Argent Stonecutter wrote: > On 2008-01-26, at 15:29, Dzonatas wrote: >> Argent Stonecutter wrote: >>> On 2008-01-26, at 08:43, Dzonatas wrote: >>>> We've heard the issue saying that it makes installation easier, but >>>> that is all that is being said. If the installation scripts and >>>> procedure were made to handle dynamic libraries, the issue of there >>>> being a proprietary or open-source library attached become really a >>>> non-issue as long as they are dynamically linked. >>> >>> The GPL 2 doesn't work that way. The GNU MP library was shipped as a >>> shared library, it still made the final work a derivative work under >>> the GPL. Korn had to change the way he was building GCC for the same >>> reason. It doesn't matter whether the libraries are linked in to the >>> same executable or shipped as shared libraries. >> >> This is the same old argument we have spoke about many time before, > > I'm not sure I understand what you're getting at here, which old > argument? Just switching to dynamic linking and loading for fmod > wouldn't make a difference, and quicktime is already dynamically > loaded but it also makes it a GPL violation to link to it from SL on > Windows (it's OK on OS X because it's shipped with the OS). That last is where the whole thing gets silly (if it isn't already). What it means is that it is OK to ship a product that won't work properly (if at all) on a specific system unless it violates a license, and if a person happens to have QuickTime already installed (as many do), the fact Second Life is working properly means that he person has unknowingly violated a license. > >> and even post the unofficial wiki page about it. What I'm saying here >> is people should have a choice to which modules goes with the client >> -- don't have it static built. We make an API for it, and agree on it. > > That only works where there's a fully open source implementation of > the code on the other side of the API that satisfies the FOSS > exception. Not a stub, something you can actually use, like the BSD MP > library or BSD editline. Where there is, this is already a non-issue, > because you can build with the open source version. If there was, the > open source version could just use that and it wouldn't be a dependency. > I think the guiding light there is the fact that Linden Labs, which holds the license in the first place, is already in violation of their own license (according to you), so it would be hard for them to prosecute others for doing what they already do because they DO ship the SL client expecting WIndows users to have it available. Lawson From dzonatas at dzonux.net Sat Jan 26 15:40:03 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 15:38:18 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BB9E7.5050008@cox.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> Message-ID: <479BC4D3.7090408@dzonux.net> >> I'm not sure I understand what you're getting at here, which old >> argument? Just switching to dynamic linking and loading for fmod >> wouldn't make a difference... The point is to not ship fmod or any other open-source package with the client. It wasn't about a replacement library of any sort. As for the license bit, "same old argument" meaning its been on SLDev here many times and there is an unofficial faq on the wiki. My point was not to start another license debate. > > That last is where the whole thing gets silly (if it isn't already). > What it means is that it is OK to ship a product that won't work > properly (if at all) on a specific system unless it violates a > license, and if a person happens to have QuickTime already installed > (as many do), the fact Second Life is working properly means that he > person has unknowingly violated a license. Just give the option to ship the dang client barebones without any proprietary piece to it. In order for that to work, there has to be APIs. The multi-process client would be an example, just the core. > >> >>> and even post the unofficial wiki page about it. What I'm saying >>> here is people should have a choice to which modules goes with the >>> client -- don't have it static built. We make an API for it, and >>> agree on it. >> >> That only works where there's a fully open source implementation of >> the code on the other side of the API that satisfies the FOSS >> exception. Not a stub, something you can actually use, like the BSD >> MP library or BSD editline. Where there is, this is already a >> non-issue, because you can build with the open source version. If >> there was, the open source version could just use that and it >> wouldn't be a dependency. The GPL has nothing written in it to allow or not allow such linkage. Certainly, the GPL doesn't say "hey.. you can't take out that library because it would be a violation!" I think under some people's understanding of the GPL they might as well throw away the memory in their computer because how it tightly works with free software instead of risk a GPL violation. How a message is sent through an ABI, API, or even over the Internet is all the same in the eyes of the GPL. The compile-time linkage or run-time linkage is not the determining factor under the GPL. It could be perfectly fine to link a proprietary library with a GPL program of vice-versa if both of those packages are separate works. That means that when one calls upon the other to do work that their context is not being shared. They may share content all they want. The Internet would come to a sudden legal and traumatic halt if GPL'd software couldn't share content with proprietary software. OK... non-issue. The dependencies here are being shipped with the client. The option not available is to get an LL official build of the client without those dependencies. A client that promotes being able to jack-in your own sound system jut like one can plug their own DVD player onto their entertainment system. Shipping the dependencies with the offical LL build is like DVD players shipping DRM technology that only let you play your movie on certain branded screens. > I think the guiding light there is the fact that Linden Labs, which holds the license in the first place, is already in violation of their own license (according to you), so it would be hard for them to > prosecute others for doing what they already do because they DO ship the SL client expecting WIndows users to have it available. Right, the GPL and many licenses are bound by OSI to be technology neutral. There should be no DRM or force any preference to any proprietary library!!! http://www.opensource.org/docs/definition.php #10 Look at Mozilla, it is open-source. You can buy proprietary add-ons to it. There is no violation there, and they have API linkage. From secret.argent at gmail.com Sat Jan 26 15:56:58 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 15:57:03 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BB9E7.5050008@cox.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> Message-ID: On 2008-01-26, at 16:53, Lawson English wrote: > That last is where the whole thing gets silly (if it isn't > already). What it means is that it is OK to ship a product that > won't work properly (if at all) on a specific system unless it > violates a license, and if a person happens to have QuickTime > already installed (as many do), the fact Second Life is working > properly means that he person has unknowingly violated a license. I think you're misinterpreting what I wrote. If you build SL against Quicktime on Windows, you are creating a derivative work of BOTH the GPLed SL code and Apple's Quicktime for Windows. Whether Quicktime is installed on the destination or not, the GPL does not give you the right to redistribute that derivative work. On OSX this is not a problem because the GPL explicitly contains an exception for components shipped as a standard part of the host operating system. > I think the guiding light there is the fact that Linden Labs, which > holds the license in the first place, is already in violation of > their own license (according to you), Linden Labs is not distributing their compiled code under the GPL. If the open source client did not exist, Linden Labs would still have the right to distribute their own code under whatever terms they want. It's only third parties that are constrained by the GPL here. From secret.argent at gmail.com Sat Jan 26 16:06:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 16:06:37 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BC4D3.7090408@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> Message-ID: On 2008-01-26, at 17:40, Dzonatas wrote: > As for the license bit, "same old argument" meaning its been on > SLDev here many times and there is an unofficial faq on the wiki. The difference is that Rob Linden has commented this time around. > The GPL has nothing written in it to allow or not allow such > linkage. Certainly, the GPL doesn't say "hey.. you can't take out > that library because it would be a violation!" The GPL covers creating derivative works. If you link against a shared library, you are creating a derivative work of that shared library. If that shared library is not licensed in a way that is compatible with the GPL, then you can not distribute the resulting code, unless you create an explicit exception... such as the FOSS exception or the exception for native OS components built into the GPL. > How a message is sent through an ABI, API, or even over the > Internet is all the same in the eyes of the GPL. That is not in fact the case. People have already tried to use shared libraries as cutouts for the GPL, and that doesn't work. > The compile-time linkage or run-time linkage is not the determining > factor under the GPL. I believe I made that point already. > It could be perfectly fine to link a proprietary library with a GPL > program of vice-versa if both of those packages are separate works. They're only separate works if there is a way to create a working executable without linking it against a library that is compatible with the GPL. > Look at Mozilla, it is open-source. You can buy proprietary add-ons > to it. There is no violation there, and they have API linkage. The Mozilla license does not require that the entire derived work be covered by the Mozilla license. If Mozilla was covered by the GPL this would not be possible unless they included an exception. From dzonatas at dzonux.net Sat Jan 26 16:58:29 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 16:56:44 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> Message-ID: <479BD735.3020304@dzonux.net> Argent Stonecutter wrote: > On 2008-01-26, at 17:40, Dzonatas wrote: > >> The GPL has nothing written in it to allow or not allow such linkage. >> Certainly, the GPL doesn't say "hey.. you can't take out that library >> because it would be a violation!" > > The GPL covers creating derivative works. If you link against a shared > library, you are creating a derivative work of that shared library. The act to link against the shared library is not an absolute factor to determine if a derived work exists. > >> The compile-time linkage or run-time linkage is not the determining >> factor under the GPL. > > I believe I made that point already. Your point is not clear because it appears here you agree that a link with a shared library does not always denote a derived work is being made, but... > >> It could be perfectly fine to link a proprietary library with a GPL >> program of vice-versa if both of those packages are separate works. > > They're only separate works if there is a way to create a working > executable without linking it against a library that is compatible > with the GPL. As long as they don't share execution context then they can be linked and still be considered separate works. The GPL, however, does not set an absolute, or cookie-cuter case, for kinds of contexts and how they can or can not work with other contexts. It provides a guideline and uses a 'take-it-to-court' explanation for all other diversions. Take for example Quicktime. It is a library of code being included in headers and object could. It is pretty obvious if one uses any definition from its headers or object code that there will be a derived work. This is true by the sense that actual code from the quicktime header got included into the compiled product. What if one doesn't include Quicktime headers at all. The obvious is then removed. One could say well there is still a compile-time link being shown to the library, but what if it doesn't use any object code from the QuickTime library. This time that "what if" quickly starts to look like "it is not a derived work." Another example, take two programs, one proprietary and one GPL. Let's say the GPL used a socket() to transfer a part of its binary code over to the proprietary program to execute. In effect, it just shared its execution context with the other. There would be a violation here -- but the GPL also has a few intrinsic exceptions, like the system context. Please do explain if a barebone SL client told another module (by http or more directly) to go fetch a sound from the sim and play it, how is the barebones SL client playing that sound? The only API between the barebones SL client and the sound system would be a directive to play a station. If the other module listens for the directive and then plays the tune with fmod, gstreamer, quicktime, or whatever else... how does the barebones client violate the GPL? I think you got the gist of this and understand it but wasn't sure about my point or even question if I understood my own gist. lol From gigstaggart at gmail.com Sat Jan 26 17:13:48 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jan 26 17:13:52 2008 Subject: [sldev] Re: Proprietary dependencies [2] (Re: Compile as installer) In-Reply-To: <479A7C63.8060308@lindenlab.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> Message-ID: <479BDACC.8060809@gmail.com> Rob Lanphier wrote: > If you were telling them there was no way for them to legally distribute > a client you develop for them, you didn't give them the whole story. > You probably should have told them "you will need to get a license from > Linden Lab to distribute the client". That's a very different thing. > I tell them that. Their next question is "how much does this cost"? And I tell them that it's unknown, but probably significant (five figures). I tell them that Linden Lab won't even tell me a price unless I seriously expect to buy one. They stop calling back. > That said, I agree that there's a cost-benefit analysis, but I don't see > it as simple. First you'd need to quantify the development, and then > the value of that development to us and to residents as a whole. It's > not entirely clear that the delta in 2007 was so large that we missed > out on that much, especially given the fact that early on, we weren't > particularly well equipped to deal with a large influx of contribution. > And you are now? http://www.sljirastats.com/generated/open_patches.png You can't quantify what you are missing out on here. Cost isn't just the cost of doing something, it's the cost of not doing it too. I can give you one data point, myself. All I know is that I'd be doing a whole lot more open source client development if it were not set up in a way that makes it entirely unprofitable and unsustainable. > At a gut level, I'd much prefer to get rid of proprietary dependencies. > If nothing else, it makes my job easier, but I also philosophically > prefer that we remove them sooner rather than later. I just don't feel > like I yet have a watertight business and community case to make that we > should perhaps take steps backwards in features and functionality in > order to get rid of those dependencies. It only requires a commitment to making the open source alternative excellent. Right now the two major problems are KDU and Fmod. The community has put you most of the way to replacing those, and Linden Lab has not really done anything to demonstrate a commitment to even using the work the community has done. -Jason From gigstaggart at gmail.com Sat Jan 26 17:18:01 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jan 26 17:18:03 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BD735.3020304@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> Message-ID: <479BDBC9.9040504@gmail.com> Dzonatas wrote: > As long as they don't share execution context then they can be linked > and still be considered separate works. The GPL, however, does not set > an absolute, or cookie-cuter case, for kinds of contexts and how they It doesn't matter what the GPL says on this. It is a question of copyright law, not GPL. And under copyright law, dynamically linked works, whether distributed together or not, have been held to form derivative works. -Jason From dzonatas at dzonux.net Sat Jan 26 17:32:03 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 17:30:17 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BDBC9.9040504@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> <479BDBC9.9040504@gmail.com> Message-ID: <479BDF13.4010102@dzonux.net> Jason Giglio wrote: > Dzonatas wrote: >> As long as they don't share execution context then they can be linked >> and still be considered separate works. The GPL, however, does not >> set an absolute, or cookie-cuter case, for kinds of contexts and how >> they > > It doesn't matter what the GPL says on this. It is a question of > copyright law, not GPL. > > And under copyright law, dynamically linked works, whether distributed > together or not, have been held to form derivative works. > > -Jason > > XML-RPC From secret.argent at gmail.com Sat Jan 26 19:25:39 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 19:25:50 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BD735.3020304@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> Message-ID: <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> On 2008-01-26, at 18:58, Dzonatas wrote: > The act to link against the shared library is not an absolute > factor to determine if a derived work exists. According to the FSF it is. If Linden Labs doesn't agree, then it's up to Linden Labs to say so. They haven't said so. >>> The compile-time linkage or run-time linkage is not the >>> determining factor under the GPL. >> >> I believe I made that point already. > > Your point is not clear because it appears here you agree that a > link with a shared library does not always denote a derived work is > being made, but... No, my point is that it doesn't matter whether it's compile or run time linkage, because unless you're using a shared library technology out of the '80s that uses an explicit manually created jump table you still have to link with a shared library *at compile time* to create the symbol table to load and link *at run time*. That's what makes it a derived work. That doesn't mean that you can't craft a cutout for the GPL. People do it all the time. IPC, network communications, shared files and memory. At one point the GPL3 drafts had explicit sections to cover remote use of web services, because the GPL didn't do the job, and people went nuts, and the FSF backed down... so even teh FSF agrees that cutouts can be made. But just switching from static to shared libraries doesn't do that. And that's the point I'm making. > As long as they don't share execution context then they can be > linked and still be considered separate works. The GPL, however, > does not set an absolute, or cookie-cuter case, for kinds of > contexts and how they can or can not work with other contexts. It > provides a guideline and uses a 'take-it-to-court' explanation for > all other diversions. And when the FSF said "we'll take it to court" for *this specific case* the lawyers and techs on the other side said "we'd probably lose" and settled. Linus Torvalds, on the other hand, has made it clear that HE doesn't consider kernel modules automatically invoking the GPL, depending on what APIs they use. The bottom line is it comes down to what the copyright holder decides to allow. Linden Labs has not said what their position is. I am calling on them to do so. > What if one doesn't include Quicktime headers at all. You're still linking against the library. If you change it so that the Quicktime API is sufficiently tenuous, then you can say "OK, we have a cutout". But that's not what we have *right now*, and it's not what you'd get for FMOD and anything else they use if they just made them shared libraries. There's a lot of work that would have to be done to create those cutouts. And Linden Labs would have to buy into it, otherwise it wouldn't get into the SL client. Linden Labs, again, has not said what their position is. They could do this, sure. They could also extend the FOSS exception to include Quicktime, which would have the same result, and for a lot less effort. But, again, they would have to actually do it. Either way. > I think you got the gist of this and understand it but wasn't sure > about my point or even question if I understood my own gist. lol My point is that no matter what design you're talking about, it's up to Linden Labs to actually make it happen. And they could accomplish the same thing, with less effort and less likelihood of someone figuring out a way to shove something they don't want on the other side of the GPL cutout, by explicitly including *just* the components SL depends on in their GPL exception. Eg: "Linking with the following libraries: * Quicktime * XYZs Quicktime CODEC for FLAC * ABCs Quicktime CODEC for WMA * Adobe FLV Codec ..." But, again, they haven't indicated that this is something they want to see happen. They haven't even explicitly stated their position on the much simpler question of what they consider a derived work to consist of. And that is what this is all about. From dzonatas at dzonux.net Sat Jan 26 19:44:36 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 19:42:50 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> Message-ID: <479BFE24.90206@dzonux.net> Argent Stonecutter wrote: > > But just switching from static to shared libraries doesn't do that. > And that's the point I'm making. I did not suggest to just switch from static to shared. I suggested for a *barebones client* that _doesn't_link_ to the libraries (of concern) for the compiled product. I suggested to create APIs instead of actual linkage. From gigstaggart at gmail.com Sat Jan 26 21:17:22 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jan 26 21:17:24 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BFE24.90206@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> <479BFE24.90206@dzonux.net> Message-ID: <479C13E2.9090403@gmail.com> Dzonatas wrote: > I suggested for a *barebones client* that _doesn't_link_ to the > libraries (of concern) for the compiled product. > > I suggested to create APIs instead of actual linkage. That's fine, but it's much easier for LL to just say "It's OK". -Jason From secret.argent at gmail.com Sat Jan 26 21:57:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jan 26 21:57:54 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: <479BFE24.90206@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> <479BFE24.90206@dzonux.net> Message-ID: On 2008-01-26, at 21:44, Dzonatas wrote: > Argent Stonecutter wrote: >> But just switching from static to shared libraries doesn't do >> that. And that's the point I'm making. > I did not suggest to just switch from static to shared. "We've heard the issue saying that it makes installation easier, but that is all that is being said. If the installation scripts and procedure were made to handle dynamic libraries, the issue of there being a proprietary or open-source library attached become really a non-issue as long as they are dynamically linked." The following paragraph, beginning with "Further, the client code could..." after the line "That is one part there" did not appear to be an essential part of the proposal, because it DID begin with "Further...". So I responded to that separately. That's one part there. Further, that doesn't deal with the main point, the one I'm trying to get back to, which is that Linden Labs has to be a part of any such scheme, and Linden Labs has indicated reluctance to even support a far less ambitious proposal. From dzonatas at dzonux.net Sat Jan 26 22:40:47 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jan 26 22:39:00 2008 Subject: [sldev] Proprietary dependencies In-Reply-To: References: <479850FD.9000708@zweitgeist.com> <4798B145.9020204@cox.net> <4EB6324F-BE97-4EB1-B836-39D51BAD427B@gmail.com> <47995AD2.6050604@gmail.com> <479A3C3D.8080203@lindenlab.com> <479A572D.9020002@gmail.com> <479A7C63.8060308@lindenlab.com> <479AA36D.3020500@cox.net> <479B4703.5000607@dzonux.net> <479BA656.5060002@dzonux.net> <404F98FF-AA25-4357-B08D-54476EF39DF7@gmail.com> <479BB9E7.5050008@cox.net> <479BC4D3.7090408@dzonux.net> <479BD735.3020304@dzonux.net> <10E090B2-AA72-47CB-85EE-2001A6D0EE63@gmail.com> <479BFE24.90206@dzonux.net> Message-ID: <479C276F.3080401@dzonux.net> Argent Stonecutter wrote: >> I did not suggest to just switch from static to shared. > > "We've heard the issue saying that it makes installation easier, but > that is all that is being said. If the installation scripts and > procedure were made to handle dynamic libraries, the issue of there > being a proprietary or open-source library attached become really a > non-issue as long as they are dynamically linked." > > The following paragraph, beginning with "Further, the client code > could..." after the line "That is one part there" did not appear to be > an essential part of the proposal, because it DID begin with > "Further...". So I responded to that separately. > > That's one part there. > > Further, that doesn't deal with the main point, the one I'm trying to > get back to, which is that Linden Labs has to be a part of any such > scheme, and Linden Labs has indicated reluctance to even support a far > less ambitious proposal. =/ Obviously an assumption was made when I said "to handle dynamic libraries" that the "to handle" bit was overlook. I targeted the interface. The client/installation can still be made to handle dynamic libraries without any specific proprietary or open-source library being interfaced. Just the ability to handle them is what I mentioned. For example, I wrote code to handle a standard low-level interface to dynamic shared libraries. It is very simple. It enabled me to isolate SSE code into a library, so that on machines that don't have SSE it would not load, and on machines that have SSE it would load. That FIXES the problem with SSE leaks and improves the features of the client. Why won't LL accept such a patch and instead keep the official client disabled of any SSE code on win32? Part of the scheme you suggest? Go figure? From alexander.treptow at zweitgeist.com Mon Jan 28 03:41:32 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Mon Jan 28 03:41:49 2008 Subject: [sldev] Re: Proprietary dependencies In-Reply-To: <20080127200012.3E2F241B297@stupor.lindenlab.com> References: <20080127200012.3E2F241B297@stupor.lindenlab.com> Message-ID: <479DBF6C.2010906@zweitgeist.com> Is there a complete list of libs that i cant redistribute without a commercial licence? For my edited viewer i dont need quicktime, fmod, llkdu. greets, alex From mattk at electricsheepcompany.com Mon Jan 28 07:24:53 2008 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Mon Jan 28 07:24:54 2008 Subject: [sldev] Re: Proprietary dependencies In-Reply-To: <479DBF6C.2010906@zweitgeist.com> References: <20080127200012.3E2F241B297@stupor.lindenlab.com> <479DBF6C.2010906@zweitgeist.com> Message-ID: <479DF3C5.8060306@electricsheepcompany.com> Alexander, See http://wiki.secondlife.com/wiki/Third_Party_Libraries for a complete list of the third-party libraries and their license status. -Matt alexander treptow wrote: > Is there a complete list of libs that i cant redistribute without a > commercial licence? > > For my edited viewer i dont need quicktime, fmod, llkdu. > > greets, > alex > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From alexander.treptow at zweitgeist.com Mon Jan 28 08:31:18 2008 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Mon Jan 28 08:31:40 2008 Subject: [sldev] Re: Compile as installer In-Reply-To: <20080126002035.B346741B299@stupor.lindenlab.com> References: <20080126002035.B346741B299@stupor.lindenlab.com> Message-ID: <479E0356.5000707@zweitgeist.com> The Installer now works fine, but i dont know how to push the settings_default.xml to the users application directory. And without this it causes LLDir errors. greets, Alex From robla at lindenlab.com Mon Jan 28 18:11:42 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jan 28 18:12:23 2008 Subject: [sldev] Followup on the proprietary dependencies discussion Message-ID: <479E8B5E.1070105@lindenlab.com> Hi all, I just wanted to give everyone a heads-up on this conversation. My motive for kicking up a little dust in this area was to revive the internal conversation in this area, and that is now indeed happening. I also wanted to make sure I wasn't missing anything, and, as it turns out, I had lost sight of a thing or two, so this was productive in that regard as well. Due to the nature of the beast (talking about legal issues), they don't lend themselves well to public discussion. The gist (and the delay) is that we're going to need time to bring our relatively new legal staff up to speed on the issues here. Prior to doing so, if I participated in the conversation here, I'd essentially be doing so without legal counsel, which given the type of conversation, would be rather silly for me to do. So, I'm hoping to put this conversation on ice for a little bit, with hopefully everyone understanding that there's a lot more discussion and forward progress going on behind the scenes than might have happened, say, this time last year. I'm not sure if I'll have anything to report at the January 31 regular OSS meeting, but perhaps we should put this on the agenda for the February 7 meeting in hopes that there will be more to say there. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080128/ea1f0540/signature.pgp From dzonatas at dzonux.net Tue Jan 29 08:14:58 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jan 29 08:12:53 2008 Subject: [sldev] Real Life Ginko Disaster? Message-ID: <479F5102.9010407@dzonux.net> Chavez Urges Withdrawals From U.S. Banks http://biz.yahoo.com/ap/080126/venezuela_alba_summit.html Somehow, I feel this is appropriate for this list... no further comment. From robla at lindenlab.com Tue Jan 29 10:12:52 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jan 29 10:13:25 2008 Subject: [sldev] Thursday agenda Message-ID: <479F6CA4.9020602@lindenlab.com> Hi SignpostMarv, I see you added a few items to this week's agenda: * Encouraging open-source focused conferences to simulcast their events inside Second Life to increase world-wide awareness and attendance * SL Viewer vs SLeek: accessibility for blind/partially sighted users * Linden Lab's adoption of techniques described in 3rd party sources (e.g. not the SL Jira or SL Wiki) Could you elaborate on these points here? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080129/213cf8e3/signature.pgp From me at signpostmarv.name Tue Jan 29 10:55:00 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Jan 29 10:54:48 2008 Subject: [sldev] Re: Thursday agenda In-Reply-To: <479F6CA4.9020602@lindenlab.com> References: <479F6CA4.9020602@lindenlab.com> Message-ID: <479F7684.6000006@signpostmarv.name> Rob Lanphier wrote: > Hi SignpostMarv, > > I see you added a few items to this week's agenda: > > * Encouraging open-source focused conferences to simulcast their > events inside Second Life to increase world-wide awareness and > attendance During last week's meeting, one of the things that was discussed was LL's attendance of open-source related conferences. It would be interesting to discuss what LL and Residents could do to encourage the organisers of such events to simulcast their event in-world (think along the lines of the Open Source display Baba Yamamoto organised for SL4B). > * SL Viewer vs SLeek: accessibility for blind/partially sighted users Recently I've been forced to use SLeek as a means of accessing Second Life- if I use the LL viewer, my system freezes. I found that the text-only interface would be hypothetically superior to the LL viewer in terms of accessibility to blind or partially sighted users. Two reasons why accessibility in SL is important: 1) the Viewer is to SL as Firefox is to the Internet (see the 2007 Open Source Awards: http://radar.oreilly.com/archives/2007/07/oscon_open_sour_1.html ) 2) Most countries have legislation which creates an obligation to service providers that their service be accessible to disabled users. If a company can be sued for having an inaccessible website, this might put them off using SL due to the lack of (perceived or actual) accessibility. > * Linden Lab's adoption of techniques described in 3rd party sources > (e.g. not the SL Jira or SL Wiki) This concern was initially raised via my questions regarding the use of the mapapi.net wiki, but I've expanded it to cover a more general scope: If a Linden comes across a technique that can be applied to Second Life, what factors control whether Linden Lab implements a technique (uBrowser), licenses a technique (fmod ?) or acquires the technique (WindLight) -------------- 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/20080129/97d30be0/smime.bin From robin.cornelius at gmail.com Tue Jan 29 12:03:58 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jan 29 12:04:07 2008 Subject: [sldev] Re: Thursday agenda In-Reply-To: <479F7684.6000006@signpostmarv.name> References: <479F6CA4.9020602@lindenlab.com> <479F7684.6000006@signpostmarv.name> Message-ID: <479F86AE.3050302@gmail.com> SignpostMarv Martin wrote: > > > Rob Lanphier wrote: >> Hi SignpostMarv, >> >> I see you added a few items to this week's agenda: >> * SL Viewer vs SLeek: accessibility for blind/partially sighted users > Recently I've been forced to use SLeek as a means of accessing Second > Life- if I use the LL viewer, my system freezes. > > I found that the text-only interface would be hypothetically superior to > the LL viewer in terms of accessibility to blind or partially sighted > users. > Actually I ran across this the other day :- http://wiki.secondlife.com/wiki/Viewer_App_Cleanup#Lightweight_Client So it must be (or has been) on someone's radar internally. Page seems to be by Mani Linden with no edits since I think there are a whole bunch of reasons for desiring a "light weight" client. Accessibility is a very good one and I think it opens up some interesting design challenges. Although SLeek can be used now with a screen reader etc, it does not give very good scope for interaction with the world. Another good reason for some major re factoring of the client? if the protocol/communications was abstracted from the 3d render engine a light weight or heavy weight top layer could sit on the common foundations? 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/20080129/491dd76f/signature.pgp From sv193702 at ohio.edu Tue Jan 29 12:29:00 2008 From: sv193702 at ohio.edu (Stan Vernier) Date: Tue Jan 29 12:29:18 2008 Subject: [sldev] Object Creation Message-ID: <479F8C8C.2050106@ohio.edu> I'm looking at trying to automatically create an object in game when a message is received from another program. I got the IPC part working, but the actual creation of an object seems to be eluding me. It seems that the current implementation depends on the mouse click to figure out the initial position when its created. I get the feeling that I might be able to fake it by modifying the BOOL add_object(LLPCode,S32,S32,U8) function that is in viewer.cpp. The x, y coord of the mouse click seem to be converted into two LLVector3 values - ray_start_region and ray_end_region. Does anybody know exactly what these vectors are being used for and if this will help? From soft at lindenlab.com Tue Jan 29 12:45:31 2008 From: soft at lindenlab.com (Soft) Date: Tue Jan 29 12:45:33 2008 Subject: [sldev] Windlight source drop Message-ID: I've added Windlight to the automated source drops, which will normally happen Fridays. Subscribe to sldev-commits to see updates weekly at the least. Tarballs linked from the commit messages, for example at the bottom of: https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000349.html Subscribe to the list here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits Fuller information about these drops here: https://lists.secondlife.com/pipermail/sldev/2008-January/007959.html From soft at lindenlab.com Tue Jan 29 14:05:42 2008 From: soft at lindenlab.com (Soft) Date: Tue Jan 29 14:05:44 2008 Subject: [sldev] cmake source drop Message-ID: The cmake branch is now on board for weekly updates as well. First buildable commit for '08: https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000354.html On Jan 29, 2008 2:45 PM, Soft wrote: > I've added Windlight to the automated source drops, which will > normally happen Fridays. Subscribe to sldev-commits to see updates > weekly at the least. > > Tarballs linked from the commit messages, for example at the bottom of: > https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000349.html > > Subscribe to the list here: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > Fuller information about these drops here: > https://lists.secondlife.com/pipermail/sldev/2008-January/007959.html > From babbage at lindenlab.com Tue Jan 29 14:41:40 2008 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Tue Jan 29 14:54:33 2008 Subject: [sldev] Mono Beta Launch Message-ID: We've just launched the beta of Mono in Second Life. More information here: http://blog.secondlife.com/2008/01/29/mono-beta-launch/ Hope to see you all on the beta grid soon, Cheers, Babbage From soft at lindenlab.com Tue Jan 29 15:07:09 2008 From: soft at lindenlab.com (Soft) Date: Tue Jan 29 15:07:12 2008 Subject: [sldev] Re: cmake source drop In-Reply-To: References: Message-ID: Some files are missing on the cmake drop - there will be a follow-up commit On Jan 29, 2008 4:05 PM, Soft wrote: > The cmake branch is now on board for weekly updates as well. First > buildable commit for '08: > https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000354.html > > > On Jan 29, 2008 2:45 PM, Soft wrote: > > I've added Windlight to the automated source drops, which will > > normally happen Fridays. Subscribe to sldev-commits to see updates > > weekly at the least. > > > > Tarballs linked from the commit messages, for example at the bottom of: > > https://lists.secondlife.com/pipermail/sldev-commits/2008-January/000349.html > > > > Subscribe to the list here: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > > > Fuller information about these drops here: > > https://lists.secondlife.com/pipermail/sldev/2008-January/007959.html > > > From Anders at Arnholm.se Wed Jan 30 01:24:08 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jan 30 01:24:17 2008 Subject: [sldev] Friday source updates In-Reply-To: References: Message-ID: <20080130092408.GB22482@arnholm.se> On Fri, Jan 25, 2008 at 03:25:17PM -0600, Soft wrote: > - Included in the svn version is a doc/asset_urls.txt file, which can > be parsed to automate downloading library and asset tarballs. Any > suggestions on the format would be great. Also, if anyone feels > ambitious, I'd gladly take in a script that uses those to ease updates The format looks great, as it's sourcace in bash i can use is directly in my start up make script. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080130/641d769e/attachment.pgp From lenglish5 at cox.net Wed Jan 30 09:12:52 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jan 30 09:12:54 2008 Subject: [sldev] Re: Thursday agenda In-Reply-To: <479F86AE.3050302@gmail.com> References: <479F6CA4.9020602@lindenlab.com> <479F7684.6000006@signpostmarv.name> <479F86AE.3050302@gmail.com> Message-ID: <47A0B014.9040604@cox.net> Robin Cornelius wrote: > SignpostMarv Martin wrote: > >> Rob Lanphier wrote: >> >>> Hi SignpostMarv, >>> >>> I see you added a few items to this week's agenda: >>> > > >>> * SL Viewer vs SLeek: accessibility for blind/partially sighted users >>> >> Recently I've been forced to use SLeek as a means of accessing Second >> Life- if I use the LL viewer, my system freezes. >> >> I found that the text-only interface would be hypothetically superior to >> the LL viewer in terms of accessibility to blind or partially sighted >> users. >> >> > > Actually I ran across this the other day :- > > http://wiki.secondlife.com/wiki/Viewer_App_Cleanup#Lightweight_Client > > So it must be (or has been) on someone's radar internally. Page seems to > be by Mani Linden with no edits since > > I think there are a whole bunch of reasons for desiring a "light weight" > client. Accessibility is a very good one and I think it opens up some > interesting design challenges. Although SLeek can be used now with a > screen reader etc, it does not give very good scope for interaction with > the world. > > Another good reason for some major re factoring of the client? if the > protocol/communications was abstracted from the 3d render engine a light > weight or heavy weight top layer could sit on the common foundations? > > Well, when you lok at the libsl code, which is a John Hurliman creation, it is dependent at the lowest levels on John's understanding of things. If he is unavailable for some reason, people have to use his code as the documentation for how things work, just as they do with the Linden Lab client right now. The only REAL solution is to separately document the protocols and base any new implementation directly on those. If the documentation isn't correct or if the protocols change, then the documentation MUST be changed. The folks at libsl, OpenSim and me, for that matter, can't be expected to re-re-re-reverse-engineer the code every time something changes. In the long run, having a single monolithic library to base things on, whether its for the LL official client, libsl, or OpenSim, should be an option, rather than mandatory. A TRUE lightweight client to handle group IM can be implemented in Python in, at most, only a few hundred lines of exceedingly sloppy Python code--including the code to log-in and establish a permanent presence on the grid--I know, because that is how I am testing my documentation of the protocols having to do with group IM. There's no reason why a java applet used via a webpage or plug-in to a mainstream chat client should have to use libsl or a Linden Lab equivalent to provide group IM to Second Life EXCEPT the lack of genuine documentation. And if Linden Lab is serious about making SL something that can be presented to a standards body, that situation has to change. Lawson From carjay at gmx.net Wed Jan 30 09:52:24 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Jan 30 09:52:31 2008 Subject: [sldev] Re: Thursday agenda In-Reply-To: <479F7684.6000006@signpostmarv.name> References: <479F6CA4.9020602@lindenlab.com> <479F7684.6000006@signpostmarv.name> Message-ID: <47A0B958.1020804@gmx.net> SignpostMarv Martin wrote: >> * SL Viewer vs SLeek: accessibility for blind/partially sighted users > Recently I've been forced to use SLeek as a means of accessing Second > Life- if I use the LL viewer, my system freezes. > > I found that the text-only interface would be hypothetically superior > to the LL viewer in terms of accessibility to blind or partially > sighted users. Searched the net a bit and there seems to be quite some interest in making SL more accessible to people with poor or no sight. http://blindsecondlife.blogspot.com http://www.techpin.com/ibm-project-second-life-accessible-for-blind-people But reading the comment here it seems SL still has some way to go, obviously you cannot even get an account if you cannot see the security image code. http://www.rnib.org.uk/wacblog/case-studies/second-life-what-are-your-thoughts/#comment-30273 Regards, Carsten From bos at lindenlab.com Wed Jan 30 15:03:55 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Jan 30 15:40:10 2008 Subject: [sldev] CMake preview available - please try it out! Message-ID: <47A1025B.9080702@lindenlab.com> Now that Soft has made a public SVN branch of our CMake tree available, it's time to follow up with some details. There should be buildable bits in the SVN tree within the next few minutes. For background and build instructions, see the wiki page: https://wiki.secondlife.com/wiki/CMake Here's a link to the browsable tree: http://svn.secondlife.com/trac/linden/browser/branches/cmake This code is based on our release branch as of about two weeks ago, and it can talk to all the grids I've tried. Please give things a try! Cheers, References: <47A1025B.9080702@lindenlab.com> Message-ID: <47A13429.5070106@dzonux.net> Bryan O'Sullivan wrote: > Please give things a try! > Sure, but first, let me know if you ever gave the SCons version I did a try... any of them. > Cheers, > Sounds like work I could have been hired to do, you know, like to make this CMake builder. I proven by the SCons version I could do it. Thanks for the evidence in my case. =) Certainly would not be as bad as the SSE skinning code where I never did say I could make that faster, but first day on the job the issue was written as "Dzonatas says he has made it faster." I was like , wow, I did? Gosh, I don't think my memory is that bad that I can't remember that being said, but I can't remember it! Oh yes, this is gonna make me look bad if I don't make it faster especially for saying that I did. I've always wonder if the work I did at Linden Lab was really that bad... why has nobody else been able to do it or even attempted it? *cough under breath* damn politicians *cough* Well, shoot, looks like there was more work, like the cmake builder, that LL could have assigned me to do. No worries, when the Judge asks what happen... you know... I can show them this, and that you did everything you can, by all means, to get cmake to work. You knew that there was this SCons version already there, but I wonder how much company money was spent to get cmake to work. Thank you. P.S. I surely shall 'try' it... legally. P.P.S. People ask me, "why do you want to work at LL when you know they treat you that way"... I just say back... "likewise, why do you want to be in-world at Second Life?" From labrat.hb at gmail.com Wed Jan 30 18:43:21 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Jan 30 18:43:23 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A13429.5070106@dzonux.net> References: <47A1025B.9080702@lindenlab.com> <47A13429.5070106@dzonux.net> Message-ID: This list is not the appropriate place for this... please take your constant bitching about not working for Linden Lab elsewhere. On Jan 30, 2008 6:36 PM, Dzonatas wrote: > Bryan O'Sullivan wrote: > > Please give things a try! > > > > Sure, but first, let me know if you ever gave the SCons version I did a > try... any of them. > << extraneous crap removed >> > > Thank you. > > P.S. I surely shall 'try' it... legally. > > P.P.S. People ask me, "why do you want to work at LL when you know they > treat you that way"... I just say back... "likewise, why do you want to > be in-world at Second Life?" > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Wed Jan 30 18:51:51 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jan 30 18:49:35 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: References: <47A1025B.9080702@lindenlab.com> <47A13429.5070106@dzonux.net> Message-ID: <47A137C7.7060308@dzonux.net> Harold Brown wrote: > This list is not the appropriate place for this... please take your > constant bitching about not working for Linden Lab elsewhere. > Mr. Zarold, Now why did I know you were going to reply... Oh yes. We are talking developer crap here. Right on subject of this mail-list. From robin.cornelius at gmail.com Thu Jan 31 01:51:15 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 31 01:49:18 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A1025B.9080702@lindenlab.com> References: <47A1025B.9080702@lindenlab.com> Message-ID: <47A19A13.30704@gmail.com> Bryan O'Sullivan wrote: > Now that Soft has made a public SVN branch of our CMake tree available, > it's time to follow up with some details. There should be buildable > bits in the SVN tree within the next few minutes. > > Please give things a try! > > Do we have a JIRA meta bug for cmake related things? if not i will just go and create one. Hit loads of problems from the start. My favorite so far is:- robin@debian:~/slviewer/cmake/indra$ ./cmake.py --help Usage: cmake.py [options] command Options: -h | --help print this help message --standalone build standalone, without Linden prebuild libraries -t | --type=NAME build type ("debug", "release", or "relwithdebinfo") Commands: build build default target clean delete all build directories (does not affect sources) configure configure project by running cmake If you do not specify a command, the default is "configure". robin@debian:~/slviewer/cmake/indra$ ./cmake.py --standalone Error: option --standalone not recognized Anyway for Debianized builds, i probably will not even use cmake.py and just hit cmake directly with something like cd indra && cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -G 'Unix Makefiles' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE -DSTANDALONE:BOOL=TRUE -DAPR_INCLUDE_DIR:STRING='/usr/include/apr-1.0' -DAPRUTIL_INCLUDE_DIR:STRING='/usr/include/apr-1.0' '/home/robin/slviewer/cmake/indra' Which BTW i have to add in APR_INCLUDE_DIR and APRUTIL_INCLUDE_DIR as cmake told me i had to. But then did nothing with the resultant input as all the .h files that include apr-1/apr.h are static anyway so i still need the same build patches as i did before. Now i have to patch the cmake file (as i did for scons) to stop warnings being treated as errors due to numerous char * implicit castings Arrrrrrggggg /me bangs head on table. From robin.cornelius at gmail.com Thu Jan 31 04:15:58 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 31 04:16:03 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A19A13.30704@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> Message-ID: On Jan 31, 2008 9:51 AM, Robin Cornelius wrote: > Bryan O'Sullivan wrote: > > Now that Soft has made a public SVN branch of our CMake tree available, > > it's time to follow up with some details. There should be buildable > > bits in the SVN tree within the next few minutes. > > > > Please give things a try! > > > > Ok i continue..... running via cmake.py there does not seem to be a way to use openjpeg, in fact setting STANDALONE:BOOL=TRUE does not pull in openjpeg unless you also specify:- -DOPENJPEG_LIBRARY:STRING='/usr/lib/libopenjpeg.so' -DOPENJPEG_INCLUDE_DIR:STRING='/usr/include/' when running cmake directly eg not via cmake.py. This has resulted in a compiled and linked executable, now i just need to find a way to stop automatic packaging of the viewer into a tarball. Which BTW failed, i will try to grab the python backtrace next time. Is there an easy way to disable this? I just want all the files left *alone* as per the scons options RELEASE/RELEASENOOPT, i will packaging them using the debian tools. Really I am after the executable to contain debugging information (symbols anyway) but not as much as a full DEBUG build so i can strip out symbols for the -dbg packages as before under scons. I will dig in myself but if someone knows the way thats helpful. Robin From mattk at electricsheepcompany.com Thu Jan 31 07:56:43 2008 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Jan 31 07:56:39 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A1025B.9080702@lindenlab.com> References: <47A1025B.9080702@lindenlab.com> Message-ID: <47A1EFBB.7070905@electricsheepcompany.com> One issue I found early on in the Windows/Visual Studio 2005 configuration is that the DirectX SDK won't be found if the correct path is in the DXSDK_DIR environment variable, but isn't one of the fallback directories specified in indra/cmake/DirectX.cmake. The fix was simple, but I opened a JIRA issue and attached a patch: https://jira.secondlife.com/browse/VWR-4444 -Matt Bryan O'Sullivan wrote: > Now that Soft has made a public SVN branch of our CMake tree available, > it's time to follow up with some details. There should be buildable > bits in the SVN tree within the next few minutes. > > For background and build instructions, see the wiki page: > > https://wiki.secondlife.com/wiki/CMake > > Here's a link to the browsable tree: > > http://svn.secondlife.com/trac/linden/browser/branches/cmake > > This code is based on our release branch as of about two weeks ago, and > it can talk to all the grids I've tried. > > Please give things a try! > > Cheers, > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From bos at lindenlab.com Thu Jan 31 10:22:38 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jan 31 10:25:03 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A1EFBB.7070905@electricsheepcompany.com> References: <47A1025B.9080702@lindenlab.com> <47A1EFBB.7070905@electricsheepcompany.com> Message-ID: <47A211EE.90100@lindenlab.com> Matt Kimmel wrote: > One issue I found early on in the Windows/Visual Studio 2005 > configuration is that the DirectX SDK won't be found if the correct path > is in the DXSDK_DIR environment variable, but isn't one of the fallback > directories specified in indra/cmake/DirectX.cmake. The fix was simple, > but I opened a JIRA issue and attached a patch: > > https://jira.secondlife.com/browse/VWR-4444 Excellent, thanks! References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> Message-ID: <47A212D0.7080409@lindenlab.com> Robin Cornelius wrote: > in fact setting STANDALONE:BOOL=TRUE does not pull in openjpeg unless > you also specify:- > > -DOPENJPEG_LIBRARY:STRING='/usr/lib/libopenjpeg.so' > -DOPENJPEG_INCLUDE_DIR:STRING='/usr/include/' > > when running cmake directly eg not via cmake.py. That's a bit odd. You can see where it's looking by checking cmake/FindOpenJPEG.cmake and cmake/OpenJPEG.cmake. You might need to add some debug statements there to figure out why it's not being picked up. > This has resulted in a compiled and linked executable, now i just need > to find a way to stop automatic packaging of the viewer into a > tarball. make -C my_build_dir/newview secondlife-bin > Is there an easy way to disable this? You don't need to disable it, it's just the default target. Build the secondlife-bin target explicitly instead, as above, and it won't be picked up. References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A212D0.7080409@lindenlab.com> Message-ID: <47A216AA.1090400@gmail.com> Bryan O'Sullivan wrote: > Robin Cornelius wrote: > >> in fact setting STANDALONE:BOOL=TRUE does not pull in openjpeg unless >> you also specify:- >> >> -DOPENJPEG_LIBRARY:STRING='/usr/lib/libopenjpeg.so' >> -DOPENJPEG_INCLUDE_DIR:STRING='/usr/include/' >> >> when running cmake directly eg not via cmake.py. > > That's a bit odd. You can see where it's looking by checking > cmake/FindOpenJPEG.cmake and cmake/OpenJPEG.cmake. You might need to > add some debug statements there to figure out why it's not being picked up. Hi Bryan, Yes it did seem a bit odd. Must be something about my setup or the way i am calling cmake?. I will try to debug this to find out if its just me or a real bug. Openjpeg is too important. > >> This has resulted in a compiled and linked executable, now i just need >> to find a way to stop automatic packaging of the viewer into a >> tarball. > > make -C my_build_dir/newview secondlife-bin > >> Is there an easy way to disable this? > > You don't need to disable it, it's just the default target. Build the > secondlife-bin target explicitly instead, as above, and it won't be > picked up. > Ah, cool. This is quite elegant now in some ways. I had missed that fact getting lost in following what happens and the code path through cmake. I've almost finished beating cmake into submission ;-) With my cmake tests i have found an issue with the way i apply the gstreamer/openal streaming audio patch. The whole patch probably needs re-factoring so all the streaming stuff is handled in llmedia/ and not in llaudio/ or you end up having dam gstreamer dependencies all over the place. 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/20080131/9b6765c2/signature-0001.pgp From bos at lindenlab.com Thu Jan 31 10:21:12 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jan 31 10:48:11 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A19A13.30704@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> Message-ID: <47A21198.8060509@lindenlab.com> Robin Cornelius wrote: > Do we have a JIRA meta bug for cmake related things? There's VWR-2871: http://jira.secondlife.com/browse/VWR-2871 > Hit loads of problems from the start. Well, yeah. It's a first preview, after all :-) > Anyway for Debianized builds, i probably will not even use cmake.py and > just hit cmake directly That makes a lot of sense. > Which BTW i have to add in APR_INCLUDE_DIR and APRUTIL_INCLUDE_DIR as > cmake told me i had to. But then did nothing with the resultant input as > all the .h files that include apr-1/apr.h are static anyway so i still > need the same build patches as i did before. Don't follow what you're getting at here. > Now i have to patch the cmake file (as i did for scons) to stop warnings > being treated as errors due to numerous char * implicit castings What compiler are you using? > Arrrrrrggggg > > /me bangs head on table. Why don't you file specific bugs, with details so I can reproduce them, and perhaps suggest fixes or patches where you have some ideas. Oh, and I suggest that you put a sock in it with the drama. That way, we can make some progress and not get noses bent out of joint. References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> Message-ID: <47A21C35.2000605@gmail.com> Bryan O'Sullivan wrote: > Robin Cornelius wrote: > >> Do we have a JIRA meta bug for cmake related things? > > There's VWR-2871: > > http://jira.secondlife.com/browse/VWR-2871 Ok we can tag anything we find on there as a related task/subtask etc. > >> Hit loads of problems from the start. > > Well, yeah. It's a first preview, after all :-) My issues are normally caused by wanting to do things the debian way so that's to be expected too. > >> Which BTW i have to add in APR_INCLUDE_DIR and APRUTIL_INCLUDE_DIR as >> cmake told me i had to. But then did nothing with the resultant input >> as all the .h files that include apr-1/apr.h are static anyway so i >> still need the same build patches as i did before. > > Don't follow what you're getting at here. Well the issue i have is that the apr header files are in /usr/include/apr-1.0 and not apr-1 (or visa-versa, i forget right now) on Debian systems. I though when cmake started asking for APR_INCLUDE_DIR it was going to use this variable as a location to look for the APR Include files, but alias it does not and the apr headers are coded as they always were. Now i am not sure if its possible to directly use APR_INCLUDE_DIR as a subustition for #include ${APR_INCLUDE_DIR}/apr.h etc... > >> Now i have to patch the cmake file (as i did for scons) to stop >> warnings being treated as errors due to numerous char * implicit castings > > What compiler are you using? Yea i know, its not the version you use internally, i always use latest gcc on debain unstable which on this machine is now 4.2.3. This is a know issue with gcc and the source code anyway and nothing to do with cmake directly. What would be nice is a way of modifying the gcc flags so that -Werror can be turned off if desired, not sure if this is a good idea or not? it would save me patching cmake files. I would love to be able to build with out any patching of the build files, i think we are a *long* way forward now as there were numerous patches i was applying to scons and manifest.pl. Which are now all dropped. Currently the only patches I need are to remove the -Werror gcc flag, to add in the openal libraries to llaudio/ and to add in gstreamer stuff where its needed as a fall out of openal patch. And as openal is a new feature this is to be expected. -------------- 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/20080131/d1b58ed0/signature.pgp From phoenix at secondlife.com Thu Jan 31 11:35:41 2008 From: phoenix at secondlife.com (Phoenix) Date: Thu Jan 31 11:35:25 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A21C35.2000605@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> Message-ID: <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> On 2008-01-31, at 11:06, Robin Cornelius wrote: >>> Hit loads of problems from the start. >> >> Well, yeah. It's a first preview, after all :-) > > My issues are normally caused by wanting to do things the debian > way so > that's to be expected too. Thanks for jumping on this Robin. The cmake team here is dedicated to delivering a build system that works for everyone as long as they are willing to run cmake. If you want to provide cmake.py patches which, through a command line option or command, do nearly everything necessary to set up a debianized build tree, we will probably roll it into our future releases. Patches to the find apr script will also be welcome. :) -------------- 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/20080131/f4dea5fe/PGP.pgp From dale at daleglass.net Thu Jan 31 11:45:32 2008 From: dale at daleglass.net (Dale Glass) Date: Thu Jan 31 11:45:43 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A1025B.9080702@lindenlab.com> References: <47A1025B.9080702@lindenlab.com> Message-ID: <200801312045.37982.dale@daleglass.net> On Thursday 31 January 2008 00:03:55 Bryan O'Sullivan wrote: > Now that Soft has made a public SVN branch of our CMake tree available, > it's time to follow up with some details. There should be buildable > bits in the SVN tree within the next few minutes. Very cool, thanks :-) Found a few problems so far. If cmake.py fails to work the first time, it refuses to run again: http://jira.secondlife.com/browse/VWR-4446 Also some arguments aren't documented or handled (--standalone) correctly. I submitted a patch here: http://jira.secondlife.com/browse/VWR-4447 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080131/b52a66a8/attachment.pgp From bos at lindenlab.com Thu Jan 31 12:08:43 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jan 31 12:08:57 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A21C35.2000605@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> Message-ID: <47A22ACB.5050109@lindenlab.com> Robin Cornelius wrote: > Well the issue i have is that the apr header files are in > /usr/include/apr-1.0 and not apr-1 (or visa-versa, i forget right now) > on Debian systems. I though when cmake started asking for > APR_INCLUDE_DIR it was going to use this variable as a location to look > for the APR Include files, but alias it does not and the apr headers are > coded as they always were. Perhaps there's a problem with the FindAPR.cmake file. I *think* that modifying APR_INCLUDE_DIR ought to work. > What would be nice is a way of modifying the gcc flags so that -Werror > can be turned off if desired, not sure if this is a good idea or not? I'd rather fix the causes of the errors. Quite often, gcc's warnings are worth paying attention to. References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> Message-ID: <47A23EA1.70700@lindenlab.com> Bryan O'Sullivan wrote: >> Which BTW i have to add in APR_INCLUDE_DIR and APRUTIL_INCLUDE_DIR as >> cmake told me i had to. But then did nothing with the resultant input >> as all the .h files that include apr-1/apr.h are static anyway so i >> still need the same build patches as i did before. > > Don't follow what you're getting at here. OK, I followed up on this by installing Ubuntu 7.10 and trying a standalone build. Sure enough, we expect the APR headers to live in a directory named apr-1, but Debian has changed this directory location to apr-1.0. I think what I'll do is what our source to remove the apr-1 prefix, and change the FindAPR.cmake file to look in /usr/include/apr-1 and /usr/include/apr-1.0. Does this seem reasonable to you? References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <47A22ACB.5050109@lindenlab.com> Message-ID: <47A24008.5080700@gmail.com> Bryan O'Sullivan wrote: >> What would be nice is a way of modifying the gcc flags so that -Werror >> can be turned off if desired, not sure if this is a good idea or not? > > I'd rather fix the causes of the errors. Quite often, gcc's warnings > are worth paying attention to. Agreed gcc's warnings are always worth looking at, but In this case they are string conversions warnings. warning: deprecated conversion from string constant to ?char*? and deprecated conversion from string constant to ?gchar*? Yes fixing the warnings would be great, but its a massive patching operation to remove or cast all the constant strings. Due to the number of files effected I suspect this will have to be an internal operation as any patch will be out of date almost instantly. In 95% of cases its just adding a (cont *) cast to constant strings, or making better use of std::string. I believe someone at the labs said they were looking at this but it became a lower priority than other things happening. There are some cases where a simple (const *) does not solve the issue but probably a wholesale conversion to std::string solves these anyway. The solution in this case may be (if gcc allows) to suppress the specific warning? We know why its caused, older gcc's do not even show it. Perhaps we can just mask it, ideally i would like it a a non-fatal warning with other warnings fatal but that's probably over optimistic of gcc. 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/20080131/16beca92/signature.pgp From bos at lindenlab.com Thu Jan 31 13:41:27 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jan 31 13:42:17 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A24008.5080700@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <47A22ACB.5050109@lindenlab.com> <47A24008.5080700@gmail.com> Message-ID: <47A24087.3030707@lindenlab.com> Robin Cornelius wrote: > The solution in this case may be (if gcc allows) to suppress the > specific warning? Yep, I think so. I have g++-4.2 now on Ubuntu, so I should be able to cook something up for this. References: <479850FD.9000708@zweitgeist.com> <479A459D.2000701@lindenlab.com> <479A5553.7070500@gmail.com> Message-ID: <200801312322.25975.dale@daleglass.net> On Friday 25 January 2008 22:32:03 Jason Giglio wrote: > Rob Lanphier wrote: > > If you're aware of violations of our copyright, you should let us > > know. Send mail to licensing@lindenlab.com. > > Every third party viewer violates your copyright: > > https://wiki.secondlife.com/wiki/Alternate_viewers > > Just go down that list if you want a list of violators. > > They all link to Fmod and KDU in violation of the GPL. Huh? LL allows that by their "GPL exception". LL as the copyright holder is free to dictate their terms, including "GPL, with these exceptions". > > Do you really intend to shut down all third party viewer development? That's a bit overdramatic, it wouldn't. KDU isn't necessary, OpenJPEG already works. Fmod isn't strictly necessary either, for instance it doesn't work on AMD64. So when I release my 64 bit Linux version it'll have neither KDU, nor Fmod. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080131/0cf0bbd0/attachment.pgp From robin.cornelius at gmail.com Thu Jan 31 14:45:55 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jan 31 14:46:15 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> Message-ID: <47A24FA3.1060200@gmail.com> Phoenix wrote: > > On 2008-01-31, at 11:06, Robin Cornelius wrote: >>>> Hit loads of problems from the start. >>> >>> Well, yeah. It's a first preview, after all :-) >> >> My issues are normally caused by wanting to do things the debian way so >> that's to be expected too. > > Thanks for jumping on this Robin. > > The cmake team here is dedicated to delivering a build system that works > for everyone as long as they are willing to run cmake. If you want to > provide cmake.py patches which, through a command line option or > command, do nearly everything necessary to set up a debianized build > tree, we will probably roll it into our future releases. > > Patches to the find apr script will also be welcome. :) I am not sure that we need cmake to go as far as making Debian packages, that would be the same on windows as it rolling the installer too. As long as it produces all the binaries correctly and ideally without patching the build code that's great. But there are probably a few extra steps that could be done for linux users :- 1) arp headers, BOS is on the case :-) appears to be a Debian (Ubuntu?) issue. 2) -Werror, again caused by newer GCC's warning on string conversions from string constants to char *. Suggestion, short term suppress the warning. 3) openjpeg headers On debian they seem to be going to just /usr/include/openjpeg.h and not /usr/include/openjpeg/opejpeg.h, one line patch in /linden/indra/llimagej2coj/llimagej2coj.cpp. Sounds like an easy cmake patch :-) Things become less important after this and less to do with the build environment. 4) App Read only data. Linux FSH and certainly Debian policy says that application read only data should live in /usr/share/application_name/. This is a simple patch to linden/indra/llvfs/lldir_linux.cpp to change - mAppRODataDir = tmp_str; + mAppRODataDir = "/usr/share/secondlife"; Windows and Mac tend to keep their data and applications together, unless you start using (windows) documents and settings/user/application data/..... but most apps just install in program files/app_name and mac keeps its stuff together in a different way. So this is a linux only thing and only effects those who want a direct install. Any one just building a replacment secondlife-bin or a tarball does not want to be bothered by this and this is also only applicable if you are going to package or install directly. It might be nice to be able to adjust this variable from the build line for packagers and default to what it is currently for others. I don't think this is necessary however, a patch really is not a problem and is not really related to the cmake side of things here. With 1,2 and 3 done things just build now, any additional patching is viewer source code changes and outside the scope of the cmake effort. The only additional thing would be an install make target? this is getting close to rolling an installer but on the other hand this is a standard thing for a linux application compiling from source to do. With 4 above implemented a simple "make install" could drop the data in /usr/share/secondlife/ and the binary in /usr/bin/ for example. A compiling user could then use a wrapper make script to create a .deb .rpm etc but this is never what a proper distributor of a .deb or rpm would do as the package would need fine tuning that could not be provided by that system. It also seems a bit silly having the packaging handled upstream as then any little tweaks to meet debian policy for example, would require upstream patching/development time/ QA process. All of which is unnecessary if the packaging is just handled by the packager. I think what i am saying again is that if we can build cleanly without patching then jobs done for cmake, but a couple of little "debian" or "redhat" specific fixes (to move data locations etc) are no worries and just things that are expected. 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/20080131/a8f4fa6c/signature.pgp From phoenix at secondlife.com Thu Jan 31 15:10:54 2008 From: phoenix at secondlife.com (Phoenix) Date: Thu Jan 31 15:09:44 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A24FA3.1060200@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> <47A24FA3.1060200@gmail.com> Message-ID: <68575E63-639C-4406-A7D4-F3AFB3A20058@secondlife.com> On 2008-01-31, at 14:45, Robin Cornelius wrote: > It also seems a bit silly having the packaging handled upstream as > then > any little tweaks to meet debian policy for example, would require > upstream patching/development time/ QA process. All of which is > unnecessary if the packaging is just handled by the packager. > > I think what i am saying again is that if we can build cleanly without > patching then jobs done for cmake, but a couple of little "debian" or > "redhat" specific fixes (to move data locations etc) are no worries > and > just things that are expected. Short reply: ok, we'll focus on the upstream issues. :) Longer reply: We are using cmake to target build environments that developers already use. That way, if you like makefiles then we'll give you makefiles, if you like vs2008 then we'll give you vs2008 solution files, etc. Debian system image is as good of a 'developer environment' as any other but the debian tools for building debs already handles most of the grief. We would not focus on that specific configuration unless it was a contribution which we would gladly maintain but occasionally break. -------------- 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/20080131/024d01bb/PGP.pgp From dzonatas at dzonux.net Thu Jan 31 15:19:01 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jan 31 15:16:40 2008 Subject: [sldev] Proprietary dependencies (Re: Compile as installer) In-Reply-To: <200801312322.25975.dale@daleglass.net> References: <479850FD.9000708@zweitgeist.com> <479A459D.2000701@lindenlab.com> <479A5553.7070500@gmail.com> <200801312322.25975.dale@daleglass.net> Message-ID: <47A25765.6010300@dzonux.net> Dale Glass wrote: > LL as the copyright holder is free to dictate their terms, including "GPL, > with these exceptions". > ...to an extent. The GPLv3 makes it more clear the intent of the GPLv2. Businesses that stay with the GPLv2 instead of switching to GPLv3 do stay there because their exceptions don't agree with the GPLv3. There was a period of time that businesses thought that the exceptions were the right thing to do, but we find that many took over-advantage of the GPLv2 terms (or holes). Consider that the GPLv3 makes the intent more clear, the exceptions put on GPLv2 can become a liability. Who is it try it in court, however. From seg at haxxed.com Thu Jan 31 17:57:20 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jan 31 17:57:26 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A24FA3.1060200@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> <47A24FA3.1060200@gmail.com> Message-ID: <1201831040.3505.4.camel@localhost> On Thu, 2008-01-31 at 22:45 +0000, Robin Cornelius wrote: > 4) App Read only data. Linux FSH and certainly Debian policy says that > application read only data should live in /usr/share/application_name/. > This is a simple patch to linden/indra/llvfs/lldir_linux.cpp to change > - mAppRODataDir = tmp_str; > + mAppRODataDir = "/usr/share/secondlife"; > > Windows and Mac tend to keep their data and applications together, > unless you start using (windows) documents and settings/user/application > data/..... but most apps just install in program files/app_name and mac > keeps its stuff together in a different way. So this is a linux only > thing and only effects those who want a direct install. Any one just > building a replacment secondlife-bin or a tarball does not want to be > bothered by this and this is also only applicable if you are going to > package or install directly. > > It might be nice to be able to adjust this variable from the build line > for packagers and default to what it is currently for others. I don't > think this is necessary however, a patch really is not a problem and is > not really related to the cmake side of things here. Actually this is exactly the kind of crap I was hoping cmake would fix. Seeing as cmake has an actual install system that takes care of exactly this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080131/9aa69b51/attachment-0001.pgp From kamilion at gmail.com Thu Jan 31 21:07:13 2008 From: kamilion at gmail.com (Kamilion) Date: Thu Jan 31 21:07:17 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A24FA3.1060200@gmail.com> References: <47A1025B.9080702@lindenlab.com> <47A19A13.30704@gmail.com> <47A21198.8060509@lindenlab.com> <47A21C35.2000605@gmail.com> <9047E449-BF4C-46CC-9751-EF03A90DBE60@secondlife.com> <47A24FA3.1060200@gmail.com> Message-ID: On Jan 31, 2008 2:45 PM, Robin Cornelius wrote: > I am not sure that we need cmake to go as far as making Debian packages, > that would be the same on windows as it rolling the installer too. As > long as it produces all the binaries correctly and ideally without > patching the build code that's great. If I'm not mistaken, isn't there an existing target to roll a full NSIS installer on windows anyway? Personally, I use ubuntu 7.10 and Hardy Alpha 8.04 -- Often times I have serious problems trying to get newer packages working on the older system. My laptop runs 7.10 due to it's atheros wifi, and 8.04 doesn't seem to support ath5k yet. My desktop runs 8.04. Most of the packages for 8.04 won't install on 7.10 due to library issues. Case in point, Firefox 3b2: I ended up having to find a PPA overlay to get a copy of FF3b2 for 7.10 on the laptop. I would rather not have to track down and rely on a PPA overlay for all of the unstable SL releases and I also would prefer avoiding the tarball-extracted-in-homedir approach I currently must use. I would very much like the option to generate full .deb packages directly from the source tree. Distros like Ubuntu will lag behind for up to 6 months on packages as they move through Debian's QA, then through Debian Sid, then Ubuntu will pick it up and include it in a dev release until it finally filters through down to the stable. This is fine for versions like 1.18.5.3 which was released in november and have hung around on the grid for a while, but we've got three MAJOR projects all gunning to be included in a release tree this year: Windlight, Havok4 and Mono. I seriously doubt debian or ubuntu will bother to spend the time releasing the RCs, beta grid viewers, firstlooks, or other minor releases that would vastly increase the tester user base on linux and allow bugs, quirks, and issues to be discovered quickly. It also opens the path down the road for Linden Labs to generate their own .deb repository which we can just add to our sources list, which solves autoupdate on debian-flavored linux by deferring it to the package manager. Gentoo mostly handles it themselves by running the build directly, and I'm not quite sure how Fedora goes about things as I havn't used a redhat release since 4.2. Plainly, it allows us hacker types to generate custom .deb packages for all the 3rd party viewer 'hacks' that float around like nicholaz's real easy. Perhaps a secondlife-deb target in addition to secondlife-bin target? In closing, I think this would be a good ability to have, when it can be completed; but it is a convenience issue, so just take your time. It would be nice to have before the april release of ubuntu 8.04, though. Bryan & Phoenix, Thanks for all your work on getting CMAKE available to the rest of us. It's much appreciated, even if some people are getting bent out of shape over some issues. Ubuntu and Debian are going to be big issues in 2008, as more and more normal people start moving over to linux, and Dell, Walmart and other general-public-friendly chains sell more and more linux-based systems. Plan on it ;) -- Kamilion