From robin.cornelius at gmail.com Fri Feb 1 00:58:10 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Feb 1 00:58:13 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: 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 Feb 1, 2008 5:07 AM, Kamilion wrote: > 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? Really? ok if the package supports the NSIS installer then we should support other installers too. I had missed that. > > 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. The thing is, *if* we have a make install target for linux that respects FSH data locations etc, its trivial to build debs or RPMS, the checkinstall command will roll a DEB or RPM based on a make install target and no additional effort is required, we just need to make install target to "do the right thing" > > 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. Well that would be cool to have the Lindens run a repository save my bandwidth. There are subtitle issues though. llmozlib is a PITA. I try to package it as a separate shared library, this is fine on Debian but some Ubuntus have a broken firefox build and its not possible to install xulrunner-dev and firefox as theres a conflict. I suppose the answer here is to to what the Lindens do now and roll llmozlib with the slviewer-bin then there is no such dependency. This would be fine for a linden release and probably be benifical if different RC's, betas etc possibly use different llmozlibs? The other issue is that there would need to be some way of specificy the "application name" on the build line too. So that the target does not necessarly get called secondlife-bin but can be renamed by the user secondlife-windlight-r1234-bin etc.. AND the /usr/share/secondlife folder would also need to be the same that way multiple parallel installations can happen. > > 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? I would vote firstly for a make install target, then this can be a wrapped with a very simple additional target on top to create a secondlife-deb or a secondlife-rpm Kamilion: You make a very good argument for a secondlife-deb target. Robin From tofu.linden at lindenlab.com Fri Feb 1 01:53:33 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri Feb 1 01:53:41 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: 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: <47A2EC1D.5090807@lindenlab.com> Robin Cornelius wrote: > This would be fine for a linden release and probably be benifical if > different RC's, betas etc possibly use different llmozlibs? Yes, indeed, it's fairly common for different branches to use different llmozlibs (and a few times a year, different branches use different underlying Mozilla versions too). -Tofu From tofu.linden at lindenlab.com Fri Feb 1 02:51:39 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri Feb 1 03:06:16 2008 Subject: [sldev] OpenJPEG 1.3? Message-ID: <47A2F9BB.7060303@lindenlab.com> Hi folks, Is OpenJPEG 1.3 considered good? I noticed that there are a few crash-fixes in OpenJPEG svn since 1.3 was released, so I'm mildly inclined to wait for 1.3.1 before upgrading the version we use with SL. Thanks. -Tofu From robin.cornelius at gmail.com Fri Feb 1 03:13:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Feb 1 03:13:40 2008 Subject: [sldev] OpenJPEG 1.3? In-Reply-To: <47A2F9BB.7060303@lindenlab.com> References: <47A2F9BB.7060303@lindenlab.com> Message-ID: On Feb 1, 2008 10:51 AM, Tofu Linden wrote: > Hi folks, > Is OpenJPEG 1.3 considered good? I noticed that there are a few > crash-fixes in OpenJPEG svn since 1.3 was released, so I'm mildly > inclined to wait for 1.3.1 before upgrading the version we > use with SL. Its been running well for me, and i've had no issues reported back to me from my package users. I'm stuck with the fact that I have an AMD64 and 1.2 is unusable on that. If there is a 1.3.1 release coming soon that has additional crash fixes then this may be a good reason to wait but if the ojp team are not going to push a release for 6 months then i would say go to 1.3 sooner rather than later. Others may have different experiences. :-) From hud at zurich.ibm.com Fri Feb 1 05:37:10 2008 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Feb 1 05:36:40 2008 Subject: [sldev] Linden Lab Release Roadmap Update In-Reply-To: <479A7AB8.3090904@lindenlab.com> References: <479A7AB8.3090904@lindenlab.com> Message-ID: <47A32086.3070508@zurich.ibm.com> Joshua Bell wrote: > 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. joshua, quick question then: will 1.19.0 then still be able to do web-based authentication? and will it then include the grid= parameter to the secondlife:/// URI? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From soft at lindenlab.com Fri Feb 1 08:37:13 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 1 08:37:24 2008 Subject: [sldev] Friday source updates Message-ID: Ten branches updated. Release (tip): http://svn.secondlife.com/svn/linden/release/ Projects and point: http://svn.secondlife.com/svn/linden/branches/ 1.18.5 was nothing major, just some translation updates that hadn't pushed before. See the commit messages/contents for details on the others on the sldev-commits list. The Mono and Havok viewer changes are coming. I'm trimming them down to patches you can apply to other trees. They don't warrant full drops. From poppy at lindenlab.com Fri Feb 1 10:29:26 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Fri Feb 1 10:48:22 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <1201831040.3505.4.camel@localhost> 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> <1201831040.3505.4.camel@localhost> Message-ID: <47A36506.9070507@lindenlab.com> Callum Lerwick wrote: >> 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. I can't speak for the others, but I haven't looked into CPack or CTest much yet, and we haven't gotten that far yet. for the uninitiated: http://www.cmake.org/Wiki/CMake#CPack + poppy From bos at lindenlab.com Fri Feb 1 10:31:08 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Feb 1 10:49:28 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: 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: <47A3656C.2070302@lindenlab.com> Kamilion wrote: > If I'm not mistaken, isn't there an existing target to roll a full > NSIS installer on windows anyway? Hmm? > I would very much like the option to generate full .deb packages > directly from the source tree. By all means, jump in and contribute patches, or help Robin's efforts. This isn't something I plan to work on, but it would certainly be nice to have. 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: <1201905843.3505.26.camel@localhost> On Fri, 2008-02-01 at 08:58 +0000, Robin Cornelius wrote: > Well that would be cool to have the Lindens run a repository save my > bandwidth. There are subtitle issues though. llmozlib is a PITA. I try > to package it as a separate shared library, this is fine on Debian but > some Ubuntus have a broken firefox build and its not possible to > install xulrunner-dev and firefox as theres a conflict. I suppose the > answer here is to to what the Lindens do now and roll llmozlib with > the slviewer-bin then there is no such dependency. > This would be fine for a linden release and probably be benifical if > different RC's, betas etc possibly use different llmozlibs? llmozlib is an utter nightmare and is largely the reason my Fedora packaging efforts are completely stalled at this point. I'm really not interested in maintaining a mozilla fork, and I doubt adding another mozilla fork to Fedora will go over well with the Fedora powers that be. Linking with standard xulrunner would be acceptable, but it doesn't sound like LL is interested in officially maintaining this option. Which makes me not want to be stuck trying to maintain it myself. > I would vote firstly for a make install target, then this can be a > wrapped with a very simple additional target on top to create a > secondlife-deb or a secondlife-rpm There is nothing to vote for. cmake supports a unix install target *natively*. I'll implement it myself if I have to. What I want is for my RPM spec to look like this: %build %cmake . make VERBOSE=1 %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT ... Period. -------------- 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/20080201/48f3b818/attachment.pgp From seg at haxxed.com Fri Feb 1 14:59:25 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 1 14:59:33 2008 Subject: [sldev] OpenJPEG 1.3? In-Reply-To: <47A2F9BB.7060303@lindenlab.com> References: <47A2F9BB.7060303@lindenlab.com> Message-ID: <1201906765.3505.34.camel@localhost> On Fri, 2008-02-01 at 10:51 +0000, Tofu Linden wrote: > Hi folks, > Is OpenJPEG 1.3 considered good? I noticed that there are a few > crash-fixes in OpenJPEG svn since 1.3 was released, so I'm mildly > inclined to wait for 1.3.1 before upgrading the version we > use with SL. Try it. There was a crash in a codepath that SL never hits, (multiple tile encoding) which is why I didn't notice it. Also, a bogus patch got merged just before release. It breaks compiling on OSX in particular. I suggest reverting it. Here's my patch: --- OpenJPEG_v1_3/libopenjpeg/opj_malloc.h 2007-12-21 04:19:01.000000000 -0600 +++ trunk/libopenjpeg/opj_malloc.h 2007-10-18 07:26:11.000000000 -0500 @@ -75,9 +75,6 @@ #else /* Not WIN32 */ #if defined(__sun) #define HAVE_MEMALIGN - #elif defined(__GNUC__) - #define HAVE_MEMALIGN - #include /* Linux x86_64 and OSX always align allocations to 16 bytes */ #elif !defined(__amd64__) && !defined(__APPLE__) /* FIXME: Yes, this is a big assumption */ Other than the OSX breakage, it should be fine for SL. -------------- 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/20080201/fba45f5a/attachment.pgp From seg at haxxed.com Fri Feb 1 15:20:44 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 1 15:20:51 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A36506.9070507@lindenlab.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> <1201831040.3505.4.camel@localhost> <47A36506.9070507@lindenlab.com> Message-ID: <1201908044.3505.46.camel@localhost> On Fri, 2008-02-01 at 10:29 -0800, Paul Oppenheim (Poppy Linden) wrote: > Callum Lerwick wrote: > >> 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. > > I can't speak for the others, but I haven't looked into CPack or CTest > much yet, and we haven't gotten that far yet. No, I'm not talking about packaging. I'm talking about the unix install target. The one that installs into an FHS tree, like every other unix build system on the planet has supported for decades. http://www.vtk.org/Wiki/CMake:Install_Commands -------------- 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/20080201/fc4ec228/attachment.pgp From bos at lindenlab.com Fri Feb 1 15:24:01 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Feb 1 15:24:22 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <1201908044.3505.46.camel@localhost> 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> <1201831040.3505.4.camel@localhost> <47A36506.9070507@lindenlab.com> <1201908044.3505.46.camel@localhost> Message-ID: <47A3AA11.3020600@lindenlab.com> Callum Lerwick wrote: > No, I'm not talking about packaging. I'm talking about the unix install > target. Patches welcome. 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> <1201831040.3505.4.camel@localhost> <47A36506.9070507@lindenlab.com> <1201908044.3505.46.camel@localhost> <47A3AA11.3020600@lindenlab.com> Message-ID: <1201908984.3505.51.camel@localhost> On Fri, 2008-02-01 at 15:24 -0800, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > > No, I'm not talking about packaging. I'm talking about the unix install > > target. > > Patches welcome. Gladly. But it appears the cmake branch is based on 1.18.6, which means I have to bite (or dodge) the llmozlib bullet before I can get to this. Bleurgh. -------------- 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/20080201/e6b7267a/attachment.pgp From robla at lindenlab.com Fri Feb 1 16:22:03 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 1 16:22:18 2008 Subject: [sldev] Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <1201905843.3505.26.camel@localhost> 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> <1201905843.3505.26.camel@localhost> Message-ID: <47A3B7AB.6040605@lindenlab.com> On 2/1/08 2:44 PM, Callum Lerwick wrote: > On Fri, 2008-02-01 at 08:58 +0000, Robin Cornelius wrote: > >> Well that would be cool to have the Lindens run a repository save my >> bandwidth. There are subtitle issues though. llmozlib is a PITA. I try >> to package it as a separate shared library, this is fine on Debian but >> some Ubuntus have a broken firefox build and its not possible to >> install xulrunner-dev and firefox as theres a conflict. I suppose the >> answer here is to to what the Lindens do now and roll llmozlib with >> the slviewer-bin then there is no such dependency. >> This would be fine for a linden release and probably be benifical if >> different RC's, betas etc possibly use different llmozlibs? >> > > llmozlib is an utter nightmare and is largely the reason my Fedora > packaging efforts are completely stalled at this point. I'm really not > interested in maintaining a mozilla fork, and I doubt adding another > mozilla fork to Fedora will go over well with the Fedora powers that be. > > Linking with standard xulrunner would be acceptable, but it doesn't > sound like LL is interested in officially maintaining this option. Which > makes me not want to be stuck trying to maintain it myself. > We've been pretty frustrated with llmozlib as well, to be honest, and we're evaluating alternatives. One option that we're considering is Webkit: http://webkit.org/ It's one of many, many things on our plate, and as a result, hasn't gotten a thorough look, though Tofu has done quite a bit of tinkering. We know that it's generally easier to build and get going with than Mozilla, and we understand that rendering to a surface potentially will work better with it, and that the prognosis is much better that we wouldn't need a funky forked version of the code. However, we could probably use some help from someone really, really frustrated with Mozilla to help us out with a deeper investigation. Any volunteers? 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/20080201/ddefe5c9/signature.pgp From skolb at lindenlab.com Fri Feb 1 16:32:04 2008 From: skolb at lindenlab.com (Sam Kolb (Samuel Linden)) Date: Fri Feb 1 16:32:12 2008 Subject: [sldev] Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <47A3B7AB.6040605@lindenlab.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> <1201905843.3505.26.camel@localhost> <47A3B7AB.6040605@lindenlab.com> Message-ID: <47A3BA04.7090900@lindenlab.com> I think it is important to distinguish between LLMozlib and Mozilla here. I am not aware of our frustrations with LLMozlib (the wrapper to Mozilla). We have been frustrated with Mozilla. -Sam Rob Lanphier wrote: > On 2/1/08 2:44 PM, Callum Lerwick wrote: >> On Fri, 2008-02-01 at 08:58 +0000, Robin Cornelius wrote: >> >>> Well that would be cool to have the Lindens run a repository save my >>> bandwidth. There are subtitle issues though. llmozlib is a PITA. I try >>> to package it as a separate shared library, this is fine on Debian but >>> some Ubuntus have a broken firefox build and its not possible to >>> install xulrunner-dev and firefox as theres a conflict. I suppose the >>> answer here is to to what the Lindens do now and roll llmozlib with >>> the slviewer-bin then there is no such dependency. >>> This would be fine for a linden release and probably be benifical if >>> different RC's, betas etc possibly use different llmozlibs? >>> >> >> llmozlib is an utter nightmare and is largely the reason my Fedora >> packaging efforts are completely stalled at this point. I'm really not >> interested in maintaining a mozilla fork, and I doubt adding another >> mozilla fork to Fedora will go over well with the Fedora powers that be. >> >> Linking with standard xulrunner would be acceptable, but it doesn't >> sound like LL is interested in officially maintaining this option. Which >> makes me not want to be stuck trying to maintain it myself. >> > > We've been pretty frustrated with llmozlib as well, to be honest, and > we're evaluating alternatives. One option that we're considering is > Webkit: > http://webkit.org/ > > It's one of many, many things on our plate, and as a result, hasn't > gotten a thorough look, though Tofu has done quite a bit of > tinkering. We know that it's generally easier to build and get going > with than Mozilla, and we understand that rendering to a surface > potentially will work better with it, and that the prognosis is much > better that we wouldn't need a funky forked version of the code. > However, we could probably use some help from someone really, really > frustrated with Mozilla to help us out with a deeper investigation. > Any volunteers? > > Rob > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20080201/8c88239d/attachment.htm From robla at lindenlab.com Fri Feb 1 16:58:59 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 1 16:59:36 2008 Subject: [sldev] Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <47A3BA04.7090900@lindenlab.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> <1201905843.3505.26.camel@localhost> <47A3B7AB.6040605@lindenlab.com> <47A3BA04.7090900@lindenlab.com> Message-ID: <47A3C053.2080902@lindenlab.com> On 2/1/08 4:32 PM, Sam Kolb (Samuel Linden) wrote: > I think it is important to distinguish between LLMozlib and Mozilla > here. I am not aware of our frustrations with LLMozlib (the wrapper > to Mozilla). We have been frustrated with Mozilla. Ooops, very good point Sam. Sorry for the confusion. 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/20080201/9f35283f/signature-0001.pgp From proppy at aminche.com Fri Feb 1 17:06:11 2008 From: proppy at aminche.com (Johan Euphrosine) Date: Fri Feb 1 17:06:14 2008 Subject: [sldev] Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <47A3B7AB.6040605@lindenlab.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> <1201905843.3505.26.camel@localhost> <47A3B7AB.6040605@lindenlab.com> Message-ID: <730b2b9d0802011706t4115ac43q363bc29e1326c0c3@mail.gmail.com> On Feb 2, 2008 1:22 AM, Rob Lanphier wrote: > We've been pretty frustrated with llmozlib as well, to be honest, and > we're evaluating alternatives. One option that we're considering is Webkit: > http://webkit.org/ > > It's one of many, many things on our plate, and as a result, hasn't > gotten a thorough look, though Tofu has done quite a bit of tinkering. > We know that it's generally easier to build and get going with than > Mozilla, and we understand that rendering to a surface potentially will > work better with it, and that the prognosis is much better that we > wouldn't need a funky forked version of the code. However, we could > probably use some help from someone really, really frustrated with > Mozilla to help us out with a deeper investigation. Any volunteers? > Seem there is already some investigation done into rendering webkit in opengl: http://www.atoker.com/blog/2008/01/28/accelerating-webkit-with-openvg/ And I believe rendering to a surface should be easily achievable by using cairo Image backend. Have you get in touch with these very people ? They seems to know that you're intersted into the webkit+opengl thing: quote: "This feature can be used both to acelerate WebKit/GTK+ and in a standalone configuration with only a GLib dependency, as requested by Linden Lab who are looking at integrating WebKit into their virtual 3D environment." -- bou ^ From bill.hoffman at kitware.com Fri Feb 1 18:27:10 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Feb 1 18:26:49 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <1201905843.3505.26.camel@localhost> 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> <1201905843.3505.26.camel@localhost> Message-ID: <47A3D4FE.1070600@kitware.com> Callum Lerwick wrote: > > What I want is for my RPM spec to look like this: > > %build > %cmake . > make VERBOSE=1 %{?_smp_mflags} > > %install > rm -rf $RPM_BUILD_ROOT > make install DESTDIR=$RPM_BUILD_ROOT > Could be: cmake . make cpack -GRPM For that to work you would have to get make install to work first. Once that works the cpack config file is pretty small. -Bill From seg at haxxed.com Sat Feb 2 00:41:39 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 2 00:41:45 2008 Subject: [sldev] Re: Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <47A3B7AB.6040605@lindenlab.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> <1201905843.3505.26.camel@localhost> <47A3B7AB.6040605@lindenlab.com> Message-ID: <1201941699.3505.70.camel@localhost> On Fri, 2008-02-01 at 16:22 -0800, Rob Lanphier wrote: > We've been pretty frustrated with llmozlib as well, to be honest, and > we're evaluating alternatives. One option that we're considering is Webkit: > http://webkit.org/ Hrm. Maybe there's hope then. It appears WebKit is already in Fedora... > It's one of many, many things on our plate, and as a result, hasn't > gotten a thorough look, though Tofu has done quite a bit of tinkering. > We know that it's generally easier to build and get going with than > Mozilla, and we understand that rendering to a surface potentially > will > work better with it, and that the prognosis is much better that we > wouldn't need a funky forked version of the code. However, we could > probably use some help from someone really, really frustrated with > Mozilla to help us out with a deeper investigation. Any volunteers? I already have "Finish OpenAL" and now it seems "work on cmake" on my to do list, among other things... Let it be known that whatever LL goes with, whether it be mozilla or WebKit or something else, in following with Fedora's mantra of "Upstream, upstream, upstream!" I have no interest in introducing a fork of something as big, complex and security critical as a web browser to Fedora. LL must push any necessary changes upstream for this Fedora packaging thing to work out. http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream -------------- 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/20080202/8d95c86c/attachment.pgp From seg at haxxed.com Sat Feb 2 00:55:21 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 2 00:55:34 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A3D4FE.1070600@kitware.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> <1201905843.3505.26.camel@localhost> <47A3D4FE.1070600@kitware.com> Message-ID: <1201942521.3505.78.camel@localhost> On Fri, 2008-02-01 at 21:27 -0500, Bill Hoffman wrote: > Could be: > cmake . > make > cpack -GRPM > > For that to work you would have to get make install to work first. Once > that works the cpack config file is pretty small. Not really useful to me. I'm targeting the official Fedora repo which means the Fedora build system. We maintain a spec in CVS, the build system generates an srpm from the spec in CVS, and that srpm is sent off to the build farm. Auto-generated specs generally do not mesh well with Fedora packaging guidelines and workflow. -------------- 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/20080202/7203a70b/attachment.pgp From robin.cornelius at gmail.com Sat Feb 2 01:03:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Feb 2 01:03:31 2008 Subject: [sldev] Re: Webkit (Re: CMake preview available - please try it out!) In-Reply-To: <1201941699.3505.70.camel@localhost> 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> <1201905843.3505.26.camel@localhost> <47A3B7AB.6040605@lindenlab.com> <1201941699.3505.70.camel@localhost> Message-ID: <47A431D9.7080701@gmail.com> Callum Lerwick wrote: > On Fri, 2008-02-01 at 16:22 -0800, Rob Lanphier wrote: >> We've been pretty frustrated with llmozlib as well, to be honest, and >> we're evaluating alternatives. One option that we're considering is Webkit: >> http://webkit.org/ . > > Let it be known that whatever LL goes with, whether it be mozilla or > WebKit or something else, in following with Fedora's mantra of > "Upstream, upstream, upstream!" I have no interest in introducing a fork > of something as big, complex and security critical as a web browser to > Fedora. LL must push any necessary changes upstream for this Fedora > packaging thing to work out. This will become the same problem to Debian too, although at the moment i seem to be able to use XULrunner, no other distribution does and I think i got lucky there. Also with increasing patching to the mozilla tree llmozlib is moving away from xulrunner so at some point I too will be in the same situation. Debian would never allow a fork of mozilla for something like this, there is too much security team overhead and no using an existing library but forking one creates a security nightmare. Also... are Linden Labs going to watch the mozilla mailing lists, bugtraq etc and rebase and apply all mozilla security warnings into the llmozlib version of mozilla? I suspect not, its a lot of work, and this itself is a major headache, on ALL platforms. 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/20080202/3b65f956/signature.pgp From open at autistici.org Sat Feb 2 07:19:58 2008 From: open at autistici.org (Opensource Obscure) Date: Sat Feb 2 07:20:04 2008 Subject: [sldev] Re: Friday source updates Message-ID: <42df29b8dc6af92ef53677d377057c10@localhost> Hi all I downloaded archives from http://svn.secondlife.com/trac/linden/changeset/214 Then I followed instructions from http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 I'm on a Linux Kubuntu 7.10 system (Nvidia 7300, intel dual core). First compilation failed like this: Processing client-readme.txt => README-linux.txt Processing client-readme-voice.txt => README-linux-voice.txt Traceback (most recent call last): File "newview/viewer_manifest.py", line 547, in main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) File "newview/../lib/python/indra/util/llmanifest.py", line 216, in main wm.do(*args['actions']) File "newview/../lib/python/indra/util/llmanifest.py", line 594, in do self.construct() File "newview/viewer_manifest.py", line 488, in construct super(Linux_i686Manifest, self).construct() File "newview/viewer_manifest.py", line 451, in construct self.path("client-readme-voice.txt","README-linux-voice.txt") File "newview/../lib/python/indra/util/llmanifest.py", line 584, in path self.check_file_exists(src) File "newview/../lib/python/indra/util/llmanifest.py", line 549, in check_file_exists os.path.normpath(os.path.join(os.getcwd(), path)),)) RuntimeError: Path /home/oobscure/Desktop/SL/Clients/1-19-0-Viewer-r79068/linden/indra/newview/linux_tools/client-readme-voice.txt doesn't exist scons: *** [newview/SecondLife_i686_1_19_0_0.tar.bz2] Error 1 scons: building terminated because of errors. Then as a workaround, in newview/viewer_manifest.py file I commented this line: # self.path("client-readme-voice.txt","README-linux-voice.txt") Following compilation ended well and the client is working. Note: I also changed the shortcut to hide/show UI. As per http://jira.secondlife.com/browse/VWR-2085 , you cannot use the default shortcut on Linux because on almost all Linux systems it will switch to the first virtual console. I also made a customized menu where I put the commands I use most often: http://flickr.com/photos/opensourceobscure/2222510323 Opensource Obscure From soft at lindenlab.com Sat Feb 2 09:57:04 2008 From: soft at lindenlab.com (Soft) Date: Sat Feb 2 09:57:07 2008 Subject: [sldev] Re: Friday source updates In-Reply-To: <42df29b8dc6af92ef53677d377057c10@localhost> References: <42df29b8dc6af92ef53677d377057c10@localhost> Message-ID: On Feb 2, 2008 9:19 AM, Opensource Obscure wrote: > > Hi all > > I downloaded archives from > http://svn.secondlife.com/trac/linden/changeset/214 > > Then I followed instructions from > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 > > I'm on a Linux Kubuntu 7.10 system (Nvidia 7300, intel dual core). > > > First compilation failed like this: > > Processing client-readme.txt => README-linux.txt > Processing client-readme-voice.txt => README-linux-voice.txt Thanks - that's fixed in the current 1.19.0 release branch; another sldever pinged me on that as well. From agrimes at speakeasy.net Sat Feb 2 11:18:47 2008 From: agrimes at speakeasy.net (Alan Grimes) Date: Sat Feb 2 10:19:50 2008 Subject: [sldev] x86_64-Linux? Message-ID: <47A4C217.8080405@speakeasy.net> I really think there should be a mainline x86_64 linux client binary published on the web page. the x86_64 architecture has been out for a good four years now and is now supported by virtually all chips on the market today. If there are any incompatibilities, they really should be addressed anyway. -- Ron Paul: A man of Peace. Chemistry.com: A total rip-off. From me at signpostmarv.name Sat Feb 2 12:00:09 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat Feb 2 12:00:16 2008 Subject: [sldev] llMozLib vs Webkit Message-ID: <47A4CBC9.3080503@signpostmarv.name> Just curious, how much longer would HTML on a prim be delayed if LL were to make the decision to use Webkit over the Mozilla-based code ? ~ 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/20080202/39d03a96/smime.bin From anthonyrbundy at gmail.com Sat Feb 2 12:33:37 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sat Feb 2 12:33:43 2008 Subject: [sldev] RC 1.19.0 avialable? In-Reply-To: <47A4CBC9.3080503@signpostmarv.name> References: <47A4CBC9.3080503@signpostmarv.name> Message-ID: <47A4D3A1.40303@gmail.com> I went to the test software section of the website, and it downloaded 1.19.0, but when I ran and tried to log in, it said I needed to download 1.18.6 (4), which is required to log in. Initially I downloaded this because my previous RC said an update was available. Has anyone else had this problem? Anthony Bundy (aka Anthony Reisman) From annagulaev at gmail.com Sat Feb 2 12:37:08 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sat Feb 2 12:37:12 2008 Subject: [sldev] parcel LocalID map? Message-ID: I need a 64x64 map of a region's parcel LocalIDs, and the only way I can think to get it is to make a ParcelPropertiesRequest for each 4x4 grid of interest for which I don't already have data, and use the returned parcel's bitmap to fill in the rest of the parcel on my map so I don't have to make the request again for another 4x4 grid on the same parcel. Still, that's a ParcelPropertiesRequest for every parcel in the region. Is there a more direct way to get this info? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080202/30770d53/attachment.htm From me at signpostmarv.name Sat Feb 2 12:40:27 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat Feb 2 12:40:31 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: References: Message-ID: <47A4D53B.3080409@signpostmarv.name> Getting the parcel data would be useful for LSL and external applications (something I've tried to address with the spec for the hypothetical Region.LLSD format: http://dev.signpostmarv.name/pub/llsd-region-data/region.llsd.xml ) ~ Marv Anna Gulaev wrote: > I need a 64x64 map of a region's parcel LocalIDs, and the only way I > can think to get it is to make a ParcelPropertiesRequest for each 4x4 > grid of interest for which I don't already have data, and use the > returned parcel's bitmap to fill in the rest of the parcel on my map > so I don't have to make the request again for another 4x4 grid on the > same parcel. Still, that's a ParcelPropertiesRequest for every parcel > in the region. > > Is there a more direct way to get this info? > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080202/8f0c1454/smime.bin From soft at lindenlab.com Sat Feb 2 12:42:59 2008 From: soft at lindenlab.com (Soft) Date: Sat Feb 2 12:43:01 2008 Subject: [sldev] x86_64-Linux? In-Reply-To: <47A4C217.8080405@speakeasy.net> References: <47A4C217.8080405@speakeasy.net> Message-ID: On Feb 2, 2008 1:18 PM, Alan Grimes wrote: > I really think there should be a mainline x86_64 linux client binary > published on the web page. the x86_64 architecture has been out for a > good four years now and is now supported by virtually all chips on the > market today. If there are any incompatibilities, they really should be > addressed anyway. There are no incompatibilities. Every mainstream 64-bit Linux distribution supports 32-bit compatibility and offers the set of libraries we require. Presumably you mean you want 64-bit pure code for reasons other than compatibility. But, where's the value in an official binary coming from LL? There's no perceptible speed difference between the 32- and 64-bit Linux viewer builds, based off of Robin's builds at least. The viewer's not taxing the 32-bit address space. We are going to be taxing QA by moving 32-bit Linux from alpha to beta, and they're already spread a little thin. Given that Linux users are a fraction of a percentage of SL, that 64-bit users will be a subset of those, and that there's no measured benefit to the 64-bit pure viewer, it would be much easier to defend more resources going to i18n issues. Please correct me if I'm wrong on any of the above. If I'm missing reasons, I'm glad to be convinced and to help convince my peers. I run a 64-bit viewer myself, but it's because I'm excited about the Fedora and Debian packaging efforts, not for any user benefit. As it stands, continuing to improve the use of openjpeg and openal seems the most profitable use of time for supporting 64-bit pure builds. The Second Life viewer will become something Linux distributions can bundle and compile themselves, including with 64-bit builds. Several of you are doing great work here; it's reasonable to see it happening this quarter at this rate, and I and other Lindens will be happy to help make that happen. From sllists at boroon.dasgupta.ch Sat Feb 2 12:44:33 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Feb 2 12:44:48 2008 Subject: [sldev] RC 1.19.0 avialable? In-Reply-To: <47A4D3A1.40303@gmail.com> References: <47A4CBC9.3080503@signpostmarv.name> <47A4D3A1.40303@gmail.com> Message-ID: <47A4D631.7060500@boroon.dasgupta.ch> Tony schrieb: > I went to the test software section of the website, and it downloaded > 1.19.0, but when I ran and tried to log in, it said I needed to > download 1.18.6 (4), which is required to log in. > Initially I downloaded this because my previous RC said an update was > available. > Has anyone else had this problem? Yeah, looks like: http://forums.secondlife.com/showthread.php?t=238847 Until I saw your list message I wondered what that rant at the forum was all about. (Didn't use RC myself today) There's already a JIRA issue about this: http://jira.secondlife.com/browse/VWR-4486 cheers Boroondas From soft at lindenlab.com Sat Feb 2 12:54:50 2008 From: soft at lindenlab.com (Soft) Date: Sat Feb 2 12:54:51 2008 Subject: [sldev] RC 1.19.0 avialable? In-Reply-To: <47A4D631.7060500@boroon.dasgupta.ch> References: <47A4CBC9.3080503@signpostmarv.name> <47A4D3A1.40303@gmail.com> <47A4D631.7060500@boroon.dasgupta.ch> Message-ID: On Feb 2, 2008 2:44 PM, Boroondas Gupte wrote: > Tony schrieb: > > I went to the test software section of the website, and it downloaded > > 1.19.0, but when I ran and tried to log in, it said I needed to > > download 1.18.6 (4), which is required to log in. > > Initially I downloaded this because my previous RC said an update was > > available. > > Has anyone else had this problem? > Yeah, looks like: http://forums.secondlife.com/showthread.php?t=238847 > > Until I saw your list message I wondered what that rant at the forum was > all about. (Didn't use RC myself today) > There's already a JIRA issue about this: > http://jira.secondlife.com/browse/VWR-4486 Thank you both - I've pushed this to the release Lindens and flagged it with a high priority From jimradford at gmail.com Sat Feb 2 13:06:04 2008 From: jimradford at gmail.com (Jim Radford) Date: Sat Feb 2 13:06:08 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: References: Message-ID: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> Hi Anna, the way we do it in libsl is make a request, when the parcel properties reply comes back fill in as many blanks from the parcel properties bitmap as we can, then continue to make requests on only unfilled spots in the 64x64 map. So for example a sim with a single parcel would only require one request whereas a sim with many would take substantially more requests. The results allow these to be generated in layers fairly efficiently: http://www.flickr.com/photos/21412348@N03/ -- Jim On Feb 2, 2008 12:37 PM, Anna Gulaev wrote: > I need a 64x64 map of a region's parcel LocalIDs, and the only way I can > think to get it is to make a ParcelPropertiesRequest for each 4x4 grid of > interest for which I don't already have data, and use the returned parcel's > bitmap to fill in the rest of the parcel on my map so I don't have to make > the request again for another 4x4 grid on the same parcel. Still, that's a > ParcelPropertiesRequest for every parcel in the region. > > Is there a more direct way to get this info? > > > _______________________________________________ > 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/20080202/ab4caca5/attachment-0001.htm From annagulaev at gmail.com Sat Feb 2 13:52:49 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sat Feb 2 13:52:52 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> References: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> Message-ID: Thanks, Jim. We seem to be doing the same thing. I was hoping I could get a map of the LocalIDs more directly, so I would only have to make a request for parcel data for parcels that look interesting based on size, location and owner info in the parceloverlay. Thanks, Anna On 2/2/08, Jim Radford wrote: > > Hi Anna, > the way we do it in libsl is make a request, when the parcel properties > reply comes back fill in as many blanks from the parcel properties bitmap as > we can, then continue to make requests on only unfilled spots in the 64x64 > map. So for example a sim with a single parcel would only require one > request whereas a sim with many would take substantially more requests. > > The results allow these to be generated in layers fairly efficiently: > http://www.flickr.com/photos/21412348@N03/ > > -- Jim > > On Feb 2, 2008 12:37 PM, Anna Gulaev wrote: > > > I need a 64x64 map of a region's parcel LocalIDs, and the only way I can > > think to get it is to make a ParcelPropertiesRequest for each 4x4 grid of > > interest for which I don't already have data, and use the returned parcel's > > bitmap to fill in the rest of the parcel on my map so I don't have to make > > the request again for another 4x4 grid on the same parcel. Still, that's a > > ParcelPropertiesRequest for every parcel in the region. > > > > Is there a more direct way to get this info? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080202/3659f5e2/attachment.htm From jimradford at gmail.com Sat Feb 2 14:29:23 2008 From: jimradford at gmail.com (Jim Radford) Date: Sat Feb 2 14:29:26 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: <6AE340DF-A188-4FF4-BDCD-7435049ABF31@fastmail.fm> References: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> <6AE340DF-A188-4FF4-BDCD-7435049ABF31@fastmail.fm> Message-ID: <2c77def30802021429k32acb712yac03fde9a5fd409c@mail.gmail.com> Ordinal: Only a few seconds for a full sim, I can map the entire mainland in about 6 hours. I like your maps, one question: why are they not scaled square as a sim would be? The class that generate those layers is something I've been working on and will eventually make its way into libsl. Anna: I'm pretty familiar with that area in the protocol and as far as I am aware there isn't any easier way to do it. But a few seconds per sim to collect the data doesn't seem to be taxing the grid much (we do throttle the packets to help alleviate this) Jim On Feb 2, 2008 1:24 PM, wrote: > Incidentally, how long does that take? A while back, I wrote an LSL > and PHP system which did something rather similar - rather slow, of > course. > > http://ordinalmalaprop.com/simmap/ > > On 2 Feb 2008, at 21:06, Jim Radford wrote: > > > Hi Anna, > > the way we do it in libsl is make a request, when the parcel > > properties reply comes back fill in as many blanks from the parcel > > properties bitmap as we can, then continue to make requests on only > > unfilled spots in the 64x64 map. So for example a sim with a single > > parcel would only require one request whereas a sim with many would > > take substantially more requests. > > > > The results allow these to be generated in layers fairly > > efficiently: http://www.flickr.com/photos/21412348@N03/ > > > > -- Jim > > > > On Feb 2, 2008 12:37 PM, Anna Gulaev wrote: > > I need a 64x64 map of a region's parcel LocalIDs, and the only way I > > can think to get it is to make a ParcelPropertiesRequest for each > > 4x4 grid of interest for which I don't already have data, and use > > the returned parcel's bitmap to fill in the rest of the parcel on my > > map so I don't have to make the request again for another 4x4 grid > > on the same parcel. Still, that's a ParcelPropertiesRequest for > > every parcel in the region. > > > > Is there a more direct way to get this info? > > > > > > _______________________________________________ > > 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/20080202/d3a6502d/attachment.htm From ordinal.malaprop at fastmail.fm Sat Feb 2 14:32:19 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sat Feb 2 14:32:24 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: <2c77def30802021429k32acb712yac03fde9a5fd409c@mail.gmail.com> References: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> <6AE340DF-A188-4FF4-BDCD-7435049ABF31@fastmail.fm> <2c77def30802021429k32acb712yac03fde9a5fd409c@mail.gmail.com> Message-ID: <76C0F18F-8049-4547-8CA5-6F99A22B744F@fastmail.fm> Much faster than using LSL, which takes a few minutes per sim (but then, you'd expect that). Oh, it's not precisely square just to make sure it fits in into small screens :) I didn't find a good balance between text size for the number labels (cell height) and cell width, so it is a bit elongated. On 2 Feb 2008, at 22:29, Jim Radford wrote: > Ordinal: Only a few seconds for a full sim, I can map the entire > mainland in about 6 hours. > I like your maps, one question: why are they not scaled square as a > sim would be? From labrat.hb at gmail.com Sat Feb 2 14:57:48 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Sat Feb 2 14:57:54 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: <76C0F18F-8049-4547-8CA5-6F99A22B744F@fastmail.fm> References: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> <6AE340DF-A188-4FF4-BDCD-7435049ABF31@fastmail.fm> <2c77def30802021429k32acb712yac03fde9a5fd409c@mail.gmail.com> <76C0F18F-8049-4547-8CA5-6F99A22B744F@fastmail.fm> Message-ID: Those overlays would be nice for integrating into the mapAPI. The OpenLayers port i've been working on can support multiple layers of tiles so they could be turned on or off. The Text Layer example would be nice for one (wouldn't need the compass points, just the sim name. On Feb 2, 2008 2:32 PM, wrote: > Much faster than using LSL, which takes a few minutes per sim (but > then, you'd expect that). > > Oh, it's not precisely square just to make sure it fits in into small > screens :) I didn't find a good balance between text size for the > number labels (cell height) and cell width, so it is a bit elongated. > > On 2 Feb 2008, at 22:29, Jim Radford wrote: > > > Ordinal: Only a few seconds for a full sim, I can map the entire > > mainland in about 6 hours. > > I like your maps, one question: why are they not scaled square as a > > sim would be? > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jimradford at gmail.com Sat Feb 2 15:22:33 2008 From: jimradford at gmail.com (Jim Radford) Date: Sat Feb 2 15:22:36 2008 Subject: [sldev] parcel LocalID map? In-Reply-To: References: <2c77def30802021306ncfb9372m2188dd42e297406f@mail.gmail.com> <6AE340DF-A188-4FF4-BDCD-7435049ABF31@fastmail.fm> <2c77def30802021429k32acb712yac03fde9a5fd409c@mail.gmail.com> <76C0F18F-8049-4547-8CA5-6F99A22B744F@fastmail.fm> Message-ID: <2c77def30802021522u3210eac3x4b09692cee90ab1b@mail.gmail.com> Thats how the map class is designed, you can request individual layers or combined layers with whatever data you want. The only issue preventing me from pushing it out into SVN is the image download handling in libsl is broken - it stalls on some images (most notably map layers) So unless I want to generate a base terrain map pragmatically I'll need to fix the image downloading handlers in libsl. As a workaround I currently get the base terrain maps through the MapAPI but that of course does not give me an option to get terrain only, it has objects as well. http://www.flickr.com/photos/21412348@N03/ If you scroll down towards the bottom around Hooper/Mephit you can see the base, with borders, and various layers turned on and off. Jim On Feb 2, 2008 2:57 PM, Harold Brown wrote: > Those overlays would be nice for integrating into the mapAPI. The > OpenLayers port i've been working on can support multiple layers of > tiles so they could be turned on or off. The Text Layer example would > be nice for one (wouldn't need the compass points, just the sim name. > > > > On Feb 2, 2008 2:32 PM, wrote: > > Much faster than using LSL, which takes a few minutes per sim (but > > then, you'd expect that). > > > > Oh, it's not precisely square just to make sure it fits in into small > > screens :) I didn't find a good balance between text size for the > > number labels (cell height) and cell width, so it is a bit elongated. > > > > On 2 Feb 2008, at 22:29, Jim Radford wrote: > > > > > Ordinal: Only a few seconds for a full sim, I can map the entire > > > mainland in about 6 hours. > > > I like your maps, one question: why are they not scaled square as a > > > sim would be? > > > > > > _______________________________________________ > > 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/20080202/871e5def/attachment.htm From email at secondlifepmsands.com Sat Feb 2 16:13:13 2008 From: email at secondlifepmsands.com (email@secondlifePMsands.com) Date: Sat Feb 2 16:13:13 2008 Subject: [sldev] re: RC 1.19.0 available? Message-ID: Anthony, You asked: "Has anyone else had this problem?" PM Reply: Yes, looks like the download process is having some serious trouble right about now. SL Blog describes a tad more. Happened to me also. The main SL homepage is whacked also. ========================= PM Sands SL Consulting Linden Lab Solution Provider Full Service Company secondlifePMsands.com ========================= ------------------------------ Message: 2 Date: Sat, 02 Feb 2008 12:33:37 -0800 From: Tony Subject: [sled] RC 1.19.0 available? To: Sled Message-ID: <47A4D3A1.40303@gmail.com> Content-Type: text/plain; char set=ISO-8859-1; format=flowed I went to the test software section of the website, and it downloaded 1.19.0, but when I ran and tried to log in, it said I needed to download 1.18.6 (4), which is required to log in. Initially I downloaded this because my previous RC said an update was available. Has anyone else had this problem? Anthony Bundy (aka Anthony Riesman) ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080202/63a4ac7e/attachment-0001.htm From dale at daleglass.net Sat Feb 2 18:33:22 2008 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 2 18:33:36 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A1025B.9080702@lindenlab.com> References: <47A1025B.9080702@lindenlab.com> Message-ID: <200802030333.28167.dale@daleglass.net> More issues: http://jira.secondlife.com/browse/VWR-4491 CMake seems to get to the end of the build, but then fails to link xmlrpc-epi for some reason. In fact, cmake.py output seems to imply xmlrpc-epi is not even being looked for. -------------- 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/20080203/449d61cb/attachment.pgp From metaxlr8 at gmail.com Sat Feb 2 23:53:55 2008 From: metaxlr8 at gmail.com (Giulio Prisco) Date: Sat Feb 2 23:54:03 2008 Subject: [sldev] =?windows-1252?q?Forterra=92s_OLIVE_metaverse_platform?= Message-ID: http://metaxlr8.net/index.php/site/forterras_olive_metaverse_platform/ IEEE Spectrum has an article on Forterra Systems' OLIVE metaverse platform: Winner: Make Your Very Own Virtual World with OLIVE - Forterra's OLIVE software makes the business of virtual-world environments real. The article, and the platform, are very interesting?it appears that Forterra has been spending real money to upgrade the There VR engine to a robust high performance metaverse platform (with a hefty price tag), and is beginning to make real money selling it to high profile customers as a simulation and training environment. I look forward to taking a look at OLIVE but I think that a similar platform could also be built on the open source OpenSim code?a reverse-engineered Second Life server platform. Second Life users can learn more about OLIVE this Monday, Feb 4, 2008, at 11:00 SLT (2:00 EST), Robert Bloomfield and Metanomics will host Robert Gehorsam, President of Forterra Systems Inc. -- 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 metaxlr8 at gmail.com Sun Feb 3 01:22:00 2008 From: metaxlr8 at gmail.com (Giulio Prisco) Date: Sun Feb 3 01:22:06 2008 Subject: [sldev] Metaverse platform gambling 1 Message-ID: FYC: http://metaxlr8.net/index.php/site/metaverse_platform_gambling_1/ Very short summary: A small consulting and development company does not have the resources to follow all existing and candidate metaverse platforms and can only bet on one or a very small set. At the moment my preference fluctuates chaotically between OpenCroquet and the open source SL wannabe clone OpenSim (I do not know enough yet about the Sun platform). -- 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 tateru.nino at gmail.com Sun Feb 3 04:00:01 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Feb 3 04:02:20 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: References: Message-ID: <47A5ACC1.5070808@gmail.com> My comment would be... Let's see. "Not relevant to this mailing list" Just off the top of my head, you understand. Giulio Prisco wrote: > FYC: http://metaxlr8.net/index.php/site/metaverse_platform_gambling_1/ > > Very short summary: A small consulting and development company does > not have the resources to follow all existing and candidate metaverse > platforms and can only bet on one or a very small set. At the moment > my preference fluctuates chaotically between OpenCroquet and the open > source SL wannabe clone OpenSim (I do not know enough yet about the > Sun platform). > > -- Tateru Nino http://www.massively.com/ From metaxlr8 at gmail.com Sun Feb 3 07:25:31 2008 From: metaxlr8 at gmail.com (Giulio Prisco) Date: Sun Feb 3 07:25:34 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A5ACC1.5070808@gmail.com> References: <47A5ACC1.5070808@gmail.com> Message-ID: Why? Other metaverse platforms, and in particular those I mention, have features that really should be in Second Life. If, that is, LL want SL to be taken seriously as a business soriented metaverse platform. And of course, I look fwd to seeing such features integrated in SL - but of course that is LL's decision to make. I can tell you that, in Europe, after a brief good press wave before last summer, SL is not taken seriously anymore as a business tool and most firms are more interested in other platforms. Dismissing these concerns as "not relevant" is like that ostrich with its head stuck in the sand in order not to see the dangerous outside world. G. On Feb 3, 2008 1:00 PM, Tateru Nino wrote: > My comment would be... > Let's see. > "Not relevant to this mailing list" > Just off the top of my head, you understand. > > > Giulio Prisco wrote: > > FYC: http://metaxlr8.net/index.php/site/metaverse_platform_gambling_1/ > > > > Very short summary: A small consulting and development company does > > not have the resources to follow all existing and candidate metaverse > > platforms and can only bet on one or a very small set. At the moment > > my preference fluctuates chaotically between OpenCroquet and the open > > source SL wannabe clone OpenSim (I do not know enough yet about the > > Sun platform). > > > > > > -- > Tateru Nino > http://www.massively.com/ > > -- 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 dale at daleglass.net Sun Feb 3 08:10:37 2008 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 3 08:11:01 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: References: <47A5ACC1.5070808@gmail.com> Message-ID: <200802031710.50778.dale@daleglass.net> On Sunday 03 February 2008 16:25:31 Giulio Prisco wrote: > Why? Other metaverse platforms, and in particular those I mention, > have features that really should be in Second Life. What features? > If, that is, LL > want SL to be taken seriously as a business soriented metaverse > platform. And of course, I look fwd to seeing such features integrated > in SL - but of course that is LL's decision to make. What features? You mean "groupware tools, web browsing, spatial VoIP, webcam feeds and collaborative editing of documents in popular office formats"? > > I can tell you that, in Europe, after a brief good press wave before > last summer, SL is not taken seriously anymore as a business tool and > most firms are more interested in other platforms. Dismissing these > concerns as "not relevant" is like that ostrich with its head stuck in > the sand in order not to see the dangerous outside world. What concerns? The problem is that this is the SL *development* mailing list, and you're not directly bringing up any technical subjects. If you think SL really needs a webcam feed then say so directly, and either offer to implement that yourself, or at least explain why is it needed, and what do you think it should look like. IMO it's not very useful to say "SL needs a webcam feed" and leave it at that. As a developer, my interest is in how is that going to work, how will the data be transmitted, what codec and protocols are going to be used, what will be the security implications, whether it will require grid support, etc. -------------- 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/20080203/af8648d8/attachment.pgp From metaxlr8 at gmail.com Sun Feb 3 09:12:24 2008 From: metaxlr8 at gmail.com (Giulio Prisco) Date: Sun Feb 3 09:12:26 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <200802031710.50778.dale@daleglass.net> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> Message-ID: Hi Dale, yes I mean "groupware tools, web browsing, webcam feeds and collaborative editing of documents in popular office formats". (spatial VoIP is already in SL thanks God). Plus other features like full Flash support and integration with the main social nets. I, or you, cannot offer to implement these things ourselves because server-side SL is a closed proprietary system. Some of these features could conceivably be integrated client-side, but a real implementation would require grid support. Also, I would hardly spend time to develop software when _only_ others would benefit financially. I would be interested in contributing real effort to SL development if I could install my own SL server and sell premium services based on it, but the option is not available. So I can only say that some features would be cool, and encourage LL to develop them. I look fwd to contributing to OpenSim, and to SL when (if) the server side will be opensourced. G. On Feb 3, 2008 5:10 PM, Dale Glass wrote: > On Sunday 03 February 2008 16:25:31 Giulio Prisco wrote: > > Why? Other metaverse platforms, and in particular those I mention, > > have features that really should be in Second Life. > What features? > > > If, that is, LL > > want SL to be taken seriously as a business soriented metaverse > > platform. And of course, I look fwd to seeing such features integrated > > in SL - but of course that is LL's decision to make. > What features? > > You mean "groupware tools, web browsing, spatial VoIP, webcam feeds and > collaborative editing of documents in popular office formats"? > > > > > I can tell you that, in Europe, after a brief good press wave before > > last summer, SL is not taken seriously anymore as a business tool and > > most firms are more interested in other platforms. Dismissing these > > concerns as "not relevant" is like that ostrich with its head stuck in > > the sand in order not to see the dangerous outside world. > What concerns? > > The problem is that this is the SL *development* mailing list, and you're > not directly bringing up any technical subjects. > > If you think SL really needs a webcam feed then say so directly, and either > offer to implement that yourself, or at least explain why is it needed, > and what do you think it should look like. > > IMO it's not very useful to say "SL needs a webcam feed" and leave it at > that. As a developer, my interest is in how is that going to work, how > will the data be transmitted, what codec and protocols are going to be > used, what will be the security implications, whether it will require grid > support, etc. > -- 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 elio at magetech.com Sun Feb 3 09:39:59 2008 From: elio at magetech.com (elio@magetech.com) Date: Sun Feb 3 09:40:06 2008 Subject: [sldev] Ban proof client? Message-ID: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> Strange question perhaps, but is anyone aware of a client hack which would make an AV impervious to estate management tools (boot) On several occasions over past few months, I have noticed that AV's I've had to ban DO NOT go away when I add them to the estate banned list. Is this simply an intermittent annoyance for some unknown reason, or a client hack I'll have to develop tools to fight? Thanks From dale at daleglass.net Sun Feb 3 09:52:21 2008 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 3 09:52:34 2008 Subject: [sldev] Ban proof client? In-Reply-To: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> Message-ID: <200802031852.28463.dale@daleglass.net> On Sunday 03 February 2008 18:39:59 elio@magetech.com wrote: > Strange question perhaps, but is anyone aware of a client hack which > would make an AV impervious to estate management tools (boot) > > On several occasions over past few months, I have noticed that AV's I've > had to ban DO NOT go away when I add them to the estate banned list. > > Is this simply an intermittent annoyance for some unknown reason, or a > client hack I'll have to develop tools to fight? PN has their "Shooped Life" (IIRC) viewer which includes a few things like randomizing the MAC on each login, to break bans by MAC. Maybe they came up with something new. If you figure out what it is, I'd really like to see a followup with an explanation. -------------- 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/20080203/95162e6d/attachment-0001.pgp From dale at daleglass.net Sun Feb 3 10:08:20 2008 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 3 10:08:31 2008 Subject: [sldev] Re: Metaverse platform gambling 1 In-Reply-To: References: <200802031710.50778.dale@daleglass.net> Message-ID: <200802031908.25797.dale@daleglass.net> On Sunday 03 February 2008 18:12:24 Giulio Prisco wrote: > Hi Dale, > > yes I mean "groupware tools, web browsing, webcam feeds and > collaborative editing of documents in popular office formats". > (spatial VoIP is already in SL thanks God). Plus other features like > full Flash support and integration with the main social nets. > > I, or you, cannot offer to implement these things ourselves because > server-side SL is a closed proprietary system. Some of these features > could conceivably be integrated client-side, but a real implementation > would require grid support. Groupware tools: I'm not even sure what exactly this means (very fuzzy term), but if you want email, calendars, etc then it's doable without LL's involvement. Just provide your own servers to host it, or develop an interface to an existing provider (if any exist, I'm not familiar with this subject) Web browsing: I don't see why this needs LL's involvement at all. Gecko is already integrated. Really for basic browsing you could take the help window and add an URL bar to it. I'm not sure if Flash would work, but this again needs no server-side changes. Webcam feeds: This is doable already if you want to have avatar to avatar conversations, in a somewhat hackish manner. It would need LL support for usage in group conferencing and such, but nothing prevents an initial implementation of the concept. Collaborative editing of office documents: To be honest, I'm not even sure what that should look like. It sounds like a pretty major project. I'm also not sure whether this fits well in SL at all. Now, collaborative editing as in collaborative building or scripting, without having to give somebody access to all your stuff, that'd be interesting to see. Yes, a closed server limits what can be done, but much can be done already. Of those things, the first two sound fully doable without involving the grid in it. If you're not willing to implement them yourself, you always have the option to hire people to implement them. There are people on this list who could do that for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080203/46cca315/attachment.pgp From anthonyrbundy at gmail.com Sun Feb 3 11:03:06 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Feb 3 11:03:09 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> Message-ID: <47A60FEA.2080901@gmail.com> Have you put these feature requests on the public JIRA? If people go and vote for them there, then they can get on the LL roadmap (or someone else's personal roadmap) to be completed. If nobody votes, then LL is unlikely to implement something few people think is needed. I agree that collaborative stuff will help, but some things can be done in a combination of programs (collaborating in gDocs). A webcam feed system could be setup where streams could be sent to SL already, its just not in a "check a box and it runs" type system. Flash is partially supported, and there is some ability to interact with it, though it doesn't mesh well with the SL system. (try and play with it a bit, it isn't that bad.) As Dale mentioned, web browsing can be implemented with client modifications. Web on a prim is a different story, though it is potentially possible for you to create a system without having server code access. Honestly, in bringing up Olive, I would have thought you would have mentioned the ability to play 3D scenes back, which I think is something that would be cool. That is definitely a feature that couldn't be done without access to the server side code of SL. Spending time to set up a system in SL (through scripts, HTTP calls and your own webserver) would surely benefit you for the above mentioned items since you retain rights to all that you create with that. Not to mention, you don't have to pay anyone a hefty price to get a hold of their server code (Forterra), just to see if you can get to where you want without having to re-write the whole server side anyways! Anthony Reisman Giulio Prisco wrote: > Hi Dale, > > yes I mean "groupware tools, web browsing, webcam feeds and > collaborative editing of documents in popular office formats". > (spatial VoIP is already in SL thanks God). Plus other features like > full Flash support and integration with the main social nets. > > I, or you, cannot offer to implement these things ourselves because > server-side SL is a closed proprietary system. Some of these features > could conceivably be integrated client-side, but a real implementation > would require grid support. > > Also, I would hardly spend time to develop software when _only_ others > would benefit financially. I would be interested in contributing real > effort to SL development if I could install my own SL server and sell > premium services based on it, but the option is not available. So I > can only say that some features would be cool, and encourage LL to > develop them. > > I look fwd to contributing to OpenSim, and to SL when (if) the server > side will be opensourced. > > G. > > On Feb 3, 2008 5:10 PM, Dale Glass wrote: > >> On Sunday 03 February 2008 16:25:31 Giulio Prisco wrote: >> >>> Why? Other metaverse platforms, and in particular those I mention, >>> have features that really should be in Second Life. >>> >> What features? >> >> >>> If, that is, LL >>> want SL to be taken seriously as a business soriented metaverse >>> platform. And of course, I look fwd to seeing such features integrated >>> in SL - but of course that is LL's decision to make. >>> >> What features? >> >> You mean "groupware tools, web browsing, spatial VoIP, webcam feeds and >> collaborative editing of documents in popular office formats"? >> >> >>> I can tell you that, in Europe, after a brief good press wave before >>> last summer, SL is not taken seriously anymore as a business tool and >>> most firms are more interested in other platforms. Dismissing these >>> concerns as "not relevant" is like that ostrich with its head stuck in >>> the sand in order not to see the dangerous outside world. >>> >> What concerns? >> >> The problem is that this is the SL *development* mailing list, and you're >> not directly bringing up any technical subjects. >> >> If you think SL really needs a webcam feed then say so directly, and either >> offer to implement that yourself, or at least explain why is it needed, >> and what do you think it should look like. >> >> IMO it's not very useful to say "SL needs a webcam feed" and leave it at >> that. As a developer, my interest is in how is that going to work, how >> will the data be transmitted, what codec and protocols are going to be >> used, what will be the security implications, whether it will require grid >> support, etc. >> >> > > > > From me at signpostmarv.name Sun Feb 3 11:19:55 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Feb 3 11:19:58 2008 Subject: [sldev] Re: Metaverse platform gambling 1 In-Reply-To: <200802031908.25797.dale@daleglass.net> References: <200802031710.50778.dale@daleglass.net> <200802031908.25797.dale@daleglass.net> Message-ID: <47A613DB.9010405@signpostmarv.name> Dale Glass wrote: > Web browsing: I don't see why this needs LL's involvement at all. Gecko is > already integrated. Really for basic browsing you could take the help > window and add an URL bar to it. I'm not sure if Flash would work, but > this again needs no server-side changes. Last I checked, the help window already had an address bar. -------------- 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/20080203/4f18af23/smime.bin From lenglish5 at cox.net Sun Feb 3 12:20:50 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Feb 3 12:20:51 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> Message-ID: <47A62222.5060702@cox.net> Giulio Prisco wrote: > Hi Dale, > > yes I mean "groupware tools, web browsing, webcam feeds and > collaborative editing of documents in popular office formats". > (spatial VoIP is already in SL thanks God). Plus other features like > full Flash support and integration with the main social nets. > > I, or you, cannot offer to implement these things ourselves because > server-side SL is a closed proprietary system. Some of these features > could conceivably be integrated client-side, but a real implementation > would require grid support. > > Also, I would hardly spend time to develop software when _only_ others > would benefit financially. I would be interested in contributing real > effort to SL development if I could install my own SL server and sell > premium services based on it, but the option is not available. So I > can only say that some features would be cool, and encourage LL to > develop them. > > I look fwd to contributing to OpenSim, and to SL when (if) the server > side will be opensourced. > > G. Er, OpenSim is a opensource 3rd party implementation of the SL protocols. As such, it IS part of Second Life or soon will be, according to LL's own roadmap. And OpenSim, like Croquet, has its own issues: they use non-open or non-standard languages. This limits them in various ways, including scalability (whats the largest Croquet or OpenSim"grid" out there?) and accessibility (how many mono/.net implementations are fast enough/robust enough/open enough to be used as a WAN grid, letalone an internet grid?). And while its certainly true that Linden Lab needs to become more open in its process of exposing its protocols, there are venues for working on that besides SLDEV. AWG/AW Groupies, for example. Lawson From lenglish5 at cox.net Sun Feb 3 12:22:37 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Feb 3 12:22:39 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A60FEA.2080901@gmail.com> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> <47A60FEA.2080901@gmail.com> Message-ID: <47A6228D.7070109@cox.net> Tony wrote: > > Honestly, in bringing up Olive, I would have thought you would have > mentioned the ability to play 3D scenes back, which I think is > something that would be cool. That is definitely a feature that > couldn't be done without access to the server side code of SL. ??? Why do you need to know about the server side of things to play 3D scenes back? Lawson From anthonyrbundy at gmail.com Sun Feb 3 12:49:07 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Feb 3 12:49:09 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A6228D.7070109@cox.net> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> <47A60FEA.2080901@gmail.com> <47A6228D.7070109@cox.net> Message-ID: <47A628C3.4030204@gmail.com> When I mean play the 3D scenes back, I mean the ability to play them and change camera viewpoints during the playback, and be able to stop and play. I would think you would basically want to record the simulator data on objects, agents, texture, particles and such. I suppose some of it could be recorded on the client side, but you would be limited to whatever that particular client could actually see. I wasn't meaning just making a video. From what I've read, Olive has the ability to record a session on their "simulator" that can be played back for a number of viewers. (I'm thinking something like Halo 3's video playback and editing stuff). Lawson English wrote: > Tony wrote: >> >> Honestly, in bringing up Olive, I would have thought you would have >> mentioned the ability to play 3D scenes back, which I think is >> something that would be cool. That is definitely a feature that >> couldn't be done without access to the server side code of SL. > ??? Why do you need to know about the server side of things to play 3D > scenes back? > > > Lawson > From dale at daleglass.net Sun Feb 3 13:43:36 2008 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 3 13:44:00 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <200802030333.28167.dale@daleglass.net> References: <47A1025B.9080702@lindenlab.com> <200802030333.28167.dale@daleglass.net> Message-ID: <200802032243.44131.dale@daleglass.net> On Sunday 03 February 2008 03:33:22 Dale Glass wrote: > More issues: > > http://jira.secondlife.com/browse/VWR-4491 > > CMake seems to get to the end of the build, but then fails to link > xmlrpc-epi for some reason. In fact, cmake.py output seems to imply > xmlrpc-epi is not even being looked for. Ok, figured it out. Problem was: Gentoo doesn't have an xmlrpc-epi ebuild. The third party one installed as libxmlrpc.so, CMake wanted libxmlrpc-epi.so. For some reason CMake thinks xmlrpc-epi is optional, so it goes ahead without it, then linking fails. So I fixed the ebuild to change the library's name, and it builds now. Except now it made the packaging process unhappy: Processing secondlife-stripped => bin/do-not-directly-run-secondlife-bin Processing libxmlrpc.so.0 => None Traceback (most recent call last): File "/home/dale/svk/amd64/cmake/indra/newview/viewer_manifest.py", line 546, in ? main() File "/home/dale/svk/amd64/cmake/indra/newview/../lib/python/indra/util/llmanifest.py", line 219, in main wm.do(*args['actions']) File "/home/dale/svk/amd64/cmake/indra/newview/../lib/python/indra/util/llmanifest.py", line 624, in do self.construct() File "/home/dale/svk/amd64/cmake/indra/newview/viewer_manifest.py", line 540, in construct self.path("libxmlrpc.so.0") File "/home/dale/svk/amd64/cmake/indra/newview/../lib/python/indra/util/llmanifest.py", line 620, in path try_path(os.path.join(self.get_build_prefix(), src)) File "/home/dale/svk/amd64/cmake/indra/newview/../lib/python/indra/util/llmanifest.py", line 608, in try_path self.check_file_exists(src) File "/home/dale/svk/amd64/cmake/indra/newview/../lib/python/indra/util/llmanifest.py", line 572, in check_file_exists raise RuntimeError("Path %s doesn't exist" % ( RuntimeError: Path /home/dale/svk/amd64/cmake/indra/libraries/x86_64-linux/lib_release_client/libxmlrpc.so.0 doesn't exist make[2]: *** [../newview/SecondLife-x86_64-1.18.6.3.tar.bz2] Error 1 make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 make: *** [all] Error 2 So: What should it be, xmlrpc-epi.so or xmlrpc.so? Also even with fixing the ebuild, I get xmlrpc-epi.so.0 (note the .0), which CMake fails to find unless I add a symlink. How do I fix CMake so that it accepts the .0 as well? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080203/260cb33e/attachment.pgp From annagulaev at gmail.com Sun Feb 3 20:03:29 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun Feb 3 20:03:32 2008 Subject: [sldev] force object redraw? Message-ID: Is there a way to force an immediate object redraw? I had thought something like this would work, and I've confirmed that it is being put in the priority queue: gPipeline.markRebuild( object->mDrawable, LLDrawable::REBUILD_ALL, TRUE); but it doesn't redraw. The object will redraw if I select it, and sometimes when the window is obscured and then exposed, and sometimes with a LOD change, but I can't get it to redraw when I want it to. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080203/3ebfdfc4/attachment.htm From davep at lindenlab.com Sun Feb 3 23:18:20 2008 From: davep at lindenlab.com (Dave Parks) Date: Sun Feb 3 23:18:29 2008 Subject: [sldev] force object redraw? In-Reply-To: References: Message-ID: <47A6BC3C.5020108@lindenlab.com> In order for a drawable to be picked up by the render pipeline, it has to pass the occlusion and frustum culling checks (meaning it must exist in a spatial partition) and have valid geometry to draw. The call to markRebuild merely adds it to a queue to be prepared to be drawn, but does not actually cause it to be drawn. markRebuild should only be called if the base geometry of the object has changed (like on an LOD switch). The functions in LLPipeline you are looking for are "updateCull" (figure out what's visible), "stateSort" (last minute preparation for rendering, optimization of render call ordering), and "renderGeom" (running through the various drawpools and issuing OpenGL drawing commands). Anna Gulaev wrote: > Is there a way to force an immediate object redraw? I had thought > something like this would work, and I've confirmed that it is being > put in the priority queue: > > gPipeline.markRebuild( object->mDrawable, LLDrawable::REBUILD_ALL, TRUE); > > but it doesn't redraw. The object will redraw if I select it, and > sometimes when the window is obscured and then exposed, and sometimes > with a LOD change, but I can't get it to redraw when I want it to. > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Mon Feb 4 01:02:56 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Feb 4 01:02:59 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <200802032243.44131.dale@daleglass.net> References: <47A1025B.9080702@lindenlab.com> <200802030333.28167.dale@daleglass.net> <200802032243.44131.dale@daleglass.net> Message-ID: On Feb 3, 2008 9:43 PM, Dale Glass wrote: > > On Sunday 03 February 2008 03:33:22 Dale Glass wrote: > > More issues: > > > > http://jira.secondlife.com/browse/VWR-4491 > > > > CMake seems to get to the end of the build, but then fails to link > > xmlrpc-epi for some reason. In fact, cmake.py output seems to imply > > xmlrpc-epi is not even being looked for. > > Ok, figured it out. Problem was: > > Gentoo doesn't have an xmlrpc-epi ebuild. > > The third party one installed as libxmlrpc.so, CMake wanted > libxmlrpc-epi.so. > > For some reason CMake thinks xmlrpc-epi is optional, so it goes ahead > without it, then linking fails. > Yea i think as (i mentioned on VWR-4491) that XMLRPCEPI_FIND_REQUIRED should be true and this a bug here. > > So: > > What should it be, xmlrpc-epi.so or xmlrpc.so? I would guess xmlrpc-epi.so as there are many other xmlrpc libraries available and it minimisies collision chances with another installed library and it is obvious which xmlrpc library you are looking at. Also this is what the default ./configure make make install scripts generate. As this is not an offical Gentoo pacakge I would see if you can get the packager to update it. > > Also even with fixing the ebuild, I get xmlrpc-epi.so.0 (note the .0), > which CMake fails to find unless I add a symlink. > > How do I fix CMake so that it accepts the .0 as well? You don't This is the correct behavior for shared libraries It is usual on distro based systems to have a lib and a develo pacakge. The lib contains xmlrpc-epi.so.0 which has the so name appended and the develo package contains the headers AND a xmlrpc-epi.so symlink. Applications would build against xmlrpc-epi.so then due to the symlink the binary becomes dependent on xmlrpc-epi.so.0. Regards Robin From annagulaev at gmail.com Mon Feb 4 04:25:56 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Feb 4 04:26:01 2008 Subject: [sldev] force object redraw? In-Reply-To: <47A6BC3C.5020108@lindenlab.com> References: <47A6BC3C.5020108@lindenlab.com> Message-ID: These are drawables that have already been rendered, and updateCull, stateSort and renderGeom are being called after these objects are modified. Still, changes to them are not rendered until they are selected (by right-clicking them). For example, object->mDrawable->setState( LLDrawable::FORCE_INVISIBLE); has no immediate effect, though updateCull, stateSort and renderGeom all happen repeatedly (with every frame, I believe) after this change. I've made appropriate changes to llviewerobject, llviewerobjectlist and pipeline to ensure my changes aren't being undone, and am pretty certain they aren't given that the changes take effect when I select the objects. Through markRebuild, setChanged and updateDrawable I've managed to get the objects to re-render sooner-than-never (with some crashing), but I haven't found a way to get them to render immediately, or even, say, within 10 seconds. That is, I've set a lighthouse invisible but can still see it. I can look at it as long as I like, turn so it's out of my field of view and then back, zoom in on it, etc, and it will not update. Right click it and *poof* it's gone. I can't figure out how to make it *poof* immediately :-) Thanks, Anna On 2/4/08, Dave Parks wrote: > > In order for a drawable to be picked up by the render pipeline, it has > to pass the occlusion and frustum culling checks (meaning it must exist > in a spatial partition) and have valid geometry to draw. The call to > markRebuild merely adds it to a queue to be prepared to be drawn, but > does not actually cause it to be drawn. markRebuild should only be > called if the base geometry of the object has changed (like on an LOD > switch). The functions in LLPipeline you are looking for are > "updateCull" (figure out what's visible), "stateSort" (last minute > preparation for rendering, optimization of render call ordering), and > "renderGeom" (running through the various drawpools and issuing OpenGL > drawing commands). > > > Anna Gulaev wrote: > > Is there a way to force an immediate object redraw? I had thought > > something like this would work, and I've confirmed that it is being > > put in the priority queue: > > > > gPipeline.markRebuild( object->mDrawable, LLDrawable::REBUILD_ALL, > TRUE); > > > > but it doesn't redraw. The object will redraw if I select it, and > > sometimes when the window is obscured and then exposed, and sometimes > > with a LOD change, but I can't get it to redraw when I want it to. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080204/bb579688/attachment-0001.htm From dale at daleglass.net Mon Feb 4 06:11:18 2008 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 4 06:11:34 2008 Subject: [sldev] Re: CMake preview available - please try it out! In-Reply-To: References: <47A1025B.9080702@lindenlab.com> <200802032243.44131.dale@daleglass.net> Message-ID: <200802041511.28251.dale@daleglass.net> On Monday 04 February 2008 10:02:56 Robin Cornelius wrote: > I would guess xmlrpc-epi.so as there are many other xmlrpc libraries > available and it minimisies collision chances with another installed > library and it is obvious which xmlrpc library you are looking at. > > Also this is what the default ./configure make make install scripts > generate. Actually no, the xmlrpc-epi-0.51 package I have generates a libxmlrpc.so.0.0.3 > It is usual on distro based systems to have a lib and a develo > pacakge. The lib contains xmlrpc-epi.so.0 which has the so name > appended and the develo package contains the headers AND a > xmlrpc-epi.so symlink. Applications would build against xmlrpc-epi.so > then due to the symlink the binary becomes dependent on > xmlrpc-epi.so.0. The actual name generated is libxmlrpc-epi.so.0.0.3. ldconfig then symlinks that to libxmlrpc-epi.so.0. But CMake is looking libxmlrpc-epi.so. So how do I either convince ldconfig to make a libxmlrpc-epi.so, or CMake to use the .0? > > Regards > > Robin -------------- 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/20080204/99153300/attachment.pgp From robin.cornelius at gmail.com Mon Feb 4 06:22:58 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Feb 4 06:23:01 2008 Subject: [sldev] Re: CMake preview available - please try it out! In-Reply-To: <200802041511.28251.dale@daleglass.net> References: <47A1025B.9080702@lindenlab.com> <200802032243.44131.dale@daleglass.net> <200802041511.28251.dale@daleglass.net> Message-ID: On Feb 4, 2008 2:11 PM, Dale Glass wrote: > On Monday 04 February 2008 10:02:56 Robin Cornelius wrote: > > I would guess xmlrpc-epi.so as there are many other xmlrpc libraries > > available and it minimisies collision chances with another installed > > library and it is obvious which xmlrpc library you are looking at. > > > > Also this is what the default ./configure make make install scripts > > generate. > Actually no, the xmlrpc-epi-0.51 package I have generates a > libxmlrpc.so.0.0.3 Ok you have a SONAME with version, but the package should also create symlinks from :- lrwxrwxrwx 1 root root 22 2008-01-02 15:51 /usr/lib/libxmlrpc-epi.so -> libxmlrpc-epi.so.0.0.3 lrwxrwxrwx 1 root root 22 2008-01-02 15:51 /usr/lib/libxmlrpc-epi.so.0 -> libxmlrpc-epi.so.0.0.3 -rw-r--r-- 1 root root 61040 2007-11-15 12:39 /usr/lib/libxmlrpc-epi.so.0.0.3 Thats what a debian installed xmlrpc-epi and xmlrpc-epi-dev packages produce. > > > It is usual on distro based systems to have a lib and a develo > > pacakge. The lib contains xmlrpc-epi.so.0 which has the so name > > appended and the develo package contains the headers AND a > > xmlrpc-epi.so symlink. Applications would build against xmlrpc-epi.so > > then due to the symlink the binary becomes dependent on > > xmlrpc-epi.so.0. > The actual name generated is libxmlrpc-epi.so.0.0.3. ldconfig then symlinks > that to libxmlrpc-epi.so.0. But CMake is looking libxmlrpc-epi.so. > > So how do I either convince ldconfig to make a libxmlrpc-epi.so, or CMake > to use the .0? > ldconfig should never make the libxmlrpc-epi.so, libtool should be doing this in the build of the library or possibly the packaging could generate the link if its missing (or is possibly not packaging up the missing link). An application at build time should always link against the libxmlrpc-epi.so or you have to rewrite the application build code everytime the library version changes. The quick workaround is to symlink /usr/lib/libxmlrpc-epi.so -> libxmlrpc-epi.so.0.0.3 The correct fix is to mend the package or to generate a -dev package etc. Robin From dale at daleglass.net Mon Feb 4 06:47:29 2008 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 4 06:47:41 2008 Subject: [sldev] Re: CMake preview available - please try it out! In-Reply-To: References: <47A1025B.9080702@lindenlab.com> <200802041511.28251.dale@daleglass.net> Message-ID: <200802041547.35972.dale@daleglass.net> On Monday 04 February 2008 15:22:58 Robin Cornelius wrote: > ldconfig should never make the libxmlrpc-epi.so, libtool should be > doing this in the build of the library or possibly the packaging could > generate the link if its missing (or is possibly not packaging up the > missing link). > > An application at build time should always link against the > libxmlrpc-epi.so or you have to rewrite the application build code > everytime the library version changes. > > The quick workaround is to symlink /usr/lib/libxmlrpc-epi.so -> > libxmlrpc-epi.so.0.0.3 > > The correct fix is to mend the package or to generate a -dev package > etc. Aha, thanks :-) That explains it Will fix the package then (there's no -dev packages in Gentoo) > Robin -------------- 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/20080204/47a85bc2/attachment.pgp From bos at lindenlab.com Mon Feb 4 10:07:22 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Feb 4 10:07:29 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <1201908984.3505.51.camel@localhost> 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> <1201831040.3505.4.camel@localhost> <47A36506.9070507@lindenlab.com> <1201908044.3505.46.camel@localhost> <47A3AA11.3020600@lindenlab.com> <1201908984.3505.51.camel@localhost> Message-ID: <47A7545A.4030201@lindenlab.com> Callum Lerwick wrote: > Gladly. But it appears the cmake branch is based on 1.18.6, which means > I have to bite (or dodge) the llmozlib bullet before I can get to this. You can turn off use of llmozlib easily, if that's what you want to do: just run ccmake and toggle the option. References: <47A1025B.9080702@lindenlab.com> <200802030333.28167.dale@daleglass.net> <200802032243.44131.dale@daleglass.net> Message-ID: <47A75595.2020902@lindenlab.com> Robin Cornelius wrote: > Yea i think as (i mentioned on VWR-4491) that XMLRPCEPI_FIND_REQUIRED > should be true and this a bug here. I turned on the _REQUIRED options for all libraries last week. References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> Message-ID: <47A768D6.8020303@watson.ibm.com> Giulio Prisco wrote: > yes I mean "groupware tools, web browsing, webcam feeds and > collaborative editing of documents in popular office formats". > (spatial VoIP is already in SL thanks God). Plus other features like > full Flash support and integration with the main social nets. > > I, or you, cannot offer to implement these things ourselves because > server-side SL is a closed proprietary system. Some of these features > could conceivably be integrated client-side, but a real implementation > would require grid support. > > Also, I would hardly spend time to develop software when _only_ others > would benefit financially. I would be interested in contributing real > effort to SL development if I could install my own SL server and sell > premium services based on it, but the option is not available. So I > can only say that some features would be cool, and encourage LL to > develop them. You may be thinking about things the wrong way. Some of these things may require server support, but not necessarily server-side SL. The Vivox voice chat is a good example. It runs as a separate process, communicating with separate servers, remains closed source, and could be a separate revenue stream when they offer premium services. If you set up your own server for the groupware tool of your choice and implement its client functionality in the SL viewer, you don't have to care about SL servers. Some of the things you're asking for aren't even well defined. What does "integration with the main social nets" mean. I assume you mean sites like MySpace, but what would that look like in a 3D virtual world? Mike From poppy at lindenlab.com Mon Feb 4 11:53:09 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Feb 4 11:56:32 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A768D6.8020303@watson.ibm.com> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> <47A768D6.8020303@watson.ibm.com> Message-ID: <47A76D25.3050009@lindenlab.com> Mike Monkowski wrote: > Some of the things you're asking for aren't even well defined. What > does "integration with the main social nets" mean. I assume you mean > sites like MySpace, but what would that look like in a 3D virtual world? probably like this: http://www.facebook.com/apps/application.php?id=10242435556 + poppy From monkowsk at watson.ibm.com Mon Feb 4 12:25:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Feb 4 12:25:27 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A76D25.3050009@lindenlab.com> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> <47A768D6.8020303@watson.ibm.com> <47A76D25.3050009@lindenlab.com> Message-ID: <47A774B2.6090606@watson.ibm.com> Paul Oppenheim (Poppy Linden) wrote: > Mike Monkowski wrote: > >> Some of the things you're asking for aren't even well defined. What >> does "integration with the main social nets" mean. I assume you mean >> sites like MySpace, but what would that look like in a 3D virtual world? > > probably like this: > > http://www.facebook.com/apps/application.php?id=10242435556 > > + poppy That looks like SecondLife in a 2D Facebook world, but it's a start. Mike From davep at lindenlab.com Mon Feb 4 17:12:31 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Feb 4 17:12:01 2008 Subject: [sldev] force object redraw? In-Reply-To: References: <47A6BC3C.5020108@lindenlab.com> Message-ID: <47A7B7FF.5080909@lindenlab.com> Check out the code for "hide selected." It does what you want. There is an implicit call to markRebuild on selection/deselection. I believe the FORCE_INVISIBLE flag is totally ignored for prims in the render pipeline, but works for trees, avatars, terrain, and water. Anna Gulaev wrote: > These are drawables that have already been rendered, and updateCull, > stateSort and renderGeom are being called after these objects are > modified. Still, changes to them are not rendered until they are > selected (by right-clicking them). > > For example, > > object->mDrawable->setState( LLDrawable::FORCE_INVISIBLE); > > has no immediate effect, though updateCull, stateSort and renderGeom > all happen repeatedly (with every frame, I believe) after this change. > I've made appropriate changes to llviewerobject, llviewerobjectlist > and pipeline to ensure my changes aren't being undone, and am pretty > certain they aren't given that the changes take effect when I select > the objects. > > Through markRebuild, setChanged and updateDrawable I've managed to get > the objects to re-render sooner-than-never (with some crashing), but I > haven't found a way to get them to render immediately, or even, say, > within 10 seconds. > > That is, I've set a lighthouse invisible but can still see it. I can > look at it as long as I like, turn so it's out of my field of view and > then back, zoom in on it, etc, and it will not update. Right click it > and *poof* it's gone. I can't figure out how to make it *poof* > immediately :-) > > Thanks, > Anna > > On 2/4/08, *Dave Parks* > wrote: > > In order for a drawable to be picked up by the render pipeline, it has > to pass the occlusion and frustum culling checks (meaning it must > exist > in a spatial partition) and have valid geometry to draw. The call to > markRebuild merely adds it to a queue to be prepared to be drawn, but > does not actually cause it to be drawn. markRebuild should only be > called if the base geometry of the object has changed (like on an LOD > switch). The functions in LLPipeline you are looking for are > "updateCull" (figure out what's visible), "stateSort" (last minute > preparation for rendering, optimization of render call ordering), and > "renderGeom" (running through the various drawpools and issuing OpenGL > drawing commands). > > > Anna Gulaev wrote: > > Is there a way to force an immediate object redraw? I had thought > > something like this would work, and I've confirmed that it is being > > put in the priority queue: > > > > gPipeline.markRebuild( object->mDrawable, > LLDrawable::REBUILD_ALL, TRUE); > > > > but it doesn't redraw. The object will redraw if I select it, and > > sometimes when the window is obscured and then exposed, and > sometimes > > with a LOD change, but I can't get it to redraw when I want it to. > > From anthonyrbundy at gmail.com Mon Feb 4 17:16:24 2008 From: anthonyrbundy at gmail.com (Tony) Date: Mon Feb 4 17:16:24 2008 Subject: [sldev] 1.19.0 and quicktime Message-ID: <47A7B8E8.7060908@gmail.com> I wondered if anyone else has had this issue, or if I'm missing something. I updated to 1.19.0 and when it loaded, I got the Quicktime warning saying I need to update Quicktime. I had already updated Quicktime when the previous RC came out, so I thought I was already OK. I checked and my version is 7.3.1. When I click "check for updates" in QT, the only option is to download BOTH Quicktime and iTunes (usually when Quicktime needs the update, I have the option to just download QT). I am running this on a PC, so I'm curious if there is a difference between the Mac and PC versioning of QT... I don't really want to install iTunes Anthony Reisman From skolb at lindenlab.com Mon Feb 4 17:16:37 2008 From: skolb at lindenlab.com (Sam Kolb (Samuel Linden)) Date: Mon Feb 4 17:16:44 2008 Subject: [sldev] llMozLib vs Webkit In-Reply-To: <47A4CBC9.3080503@signpostmarv.name> References: <47A4CBC9.3080503@signpostmarv.name> Message-ID: <47A7B8F5.8060004@lindenlab.com> Marv, It is really impossible to make that determination without spending some time evaluating that development path. Webkit shows promise, but also the potential to have some of the same pitfalls as Mozilla. The underlying Media API we will deliver with the forthcoming Parcel Media release will make implementing a separate media renderer that much easier. It doesn't really make sense to delay this release to implement a webkit solution when that isn't really the point of the project. Once the new API is out, we can then begin exploring other options for HTML rendering. -Sam SignpostMarv Martin wrote: > Just curious, how much longer would HTML on a prim be delayed if LL > were to make the decision to use Webkit over the Mozilla-based code ? > > ~ Marv > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From annagulaev at gmail.com Mon Feb 4 18:26:40 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Feb 4 18:26:44 2008 Subject: [sldev] force object redraw? In-Reply-To: <47A7B7FF.5080909@lindenlab.com> References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> Message-ID: On 2/4/08, Dave Parks wrote: > > Check out the code for "hide selected." It does what you want. There > is an implicit call to markRebuild on selection/deselection. I believe Setting "Hide Selected" causes three things to happen: 1) stateSort exits without doing anything for selected objects 2) the object loop in renderForSelect skips selected objects 3) registerFace exits without doing anything for selected objects So I added my should-by-invisible condition to these three places, and an explicit call to markRebuild at the time the object is flagged to be invisible, and...no joy. It acts axactly as it did when I was using invisibility. The object does not go invisible until it is selected. I believe the selection code is setting some state that is picked up by the render code to mean "re-render this". I just don't know what that state is. the FORCE_INVISIBLE flag is totally ignored for prims in the render > pipeline, but works for trees, avatars, terrain, and water. I believe it's the other way around. My invisibility was working (after a select) on prims but not on trees, ground or water. Thanks, Anna Anna Gulaev wrote: > > These are drawables that have already been rendered, and updateCull, > > stateSort and renderGeom are being called after these objects are > > modified. Still, changes to them are not rendered until they are > > selected (by right-clicking them). > > > > For example, > > > > object->mDrawable->setState( LLDrawable::FORCE_INVISIBLE); > > > > has no immediate effect, though updateCull, stateSort and renderGeom > > all happen repeatedly (with every frame, I believe) after this change. > > I've made appropriate changes to llviewerobject, llviewerobjectlist > > and pipeline to ensure my changes aren't being undone, and am pretty > > certain they aren't given that the changes take effect when I select > > the objects. > > > > Through markRebuild, setChanged and updateDrawable I've managed to get > > the objects to re-render sooner-than-never (with some crashing), but I > > haven't found a way to get them to render immediately, or even, say, > > within 10 seconds. > > > > That is, I've set a lighthouse invisible but can still see it. I can > > look at it as long as I like, turn so it's out of my field of view and > > then back, zoom in on it, etc, and it will not update. Right click it > > and *poof* it's gone. I can't figure out how to make it *poof* > > immediately :-) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080204/0448dd57/attachment.htm From ts_ryuzo at hotmail.com Mon Feb 4 18:46:44 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Mon Feb 4 18:46:45 2008 Subject: [sldev] Area of prim on screen Message-ID: Hi, Is there any ways to determine how much area a primitive occupy on the screen coordinates? Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/dc057a72/attachment.htm From davep at lindenlab.com Mon Feb 4 18:49:22 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Feb 4 18:49:23 2008 Subject: [sldev] force object redraw? In-Reply-To: References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> Message-ID: <47A7CEB2.4010907@lindenlab.com> If "registerFace" is called and does nothing, then there is no way for the object to be drawn. That's where the object faces are added to the render batches that the graphics engine uses for issuing OpenGL commands. Here's the whole pipeline: - markRebuild puts the object into LLPipeline's build queue - LLPipeline calls updateGeom on objects in the queue, time slicing for non priority updates - In the latest windlight build, an object's updateGeom must explicitly request a spatial group render batch rebuild by calling LLSpatialGroup::dirtyGeom - Visible spatial groups are determined in updateCull - LLSpatialGroup::rebuildGeom is called from LLPipeline::postSort - in LLVOVolumePartition::rebuildGeom, render batches (instances of LLDrawInfo) are built and registerFace is called for every face added to a batch - Pigs fly - render batches are sorted by texture/matrix/distance - LLPipeline::renderGeom runs through the drawpools and render passes which issue drawing calls. Anna Gulaev wrote: > On 2/4/08, *Dave Parks* wrote: > > Check out the code for "hide selected." It does what you want. There > is an implicit call to markRebuild on selection/deselection. I > believe > > > Setting "Hide Selected" causes three things to happen: > 1) stateSort exits without doing anything for selected objects > 2) the object loop in renderForSelect skips selected objects > 3) registerFace exits without doing anything for selected objects > > So I added my should-by-invisible condition to these three places, and > an explicit call to markRebuild at the time the object is flagged to > be invisible, and...no joy. It acts axactly as it did when I was using > invisibility. The object does not go invisible until it is selected. > From davep at lindenlab.com Mon Feb 4 19:11:45 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Feb 4 19:11:13 2008 Subject: [sldev] Area of prim on screen In-Reply-To: References: Message-ID: <47A7D3F1.707@lindenlab.com> See LLVOVolume::getTextureVirtualSize There you will find an approximation of pixel area for each face for the purposes of texture decoding. If you want a quick peek at the values, just use the "Face Area" info display (Client->rendering->info displays->face area). Qian Hao ~ wrote: > Hi, > > Is there any ways to determine how much area a primitive occupy on the > screen coordinates? > > Qian Hao > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From ts_ryuzo at hotmail.com Mon Feb 4 19:15:50 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Mon Feb 4 19:15:53 2008 Subject: [sldev] Finished sending prims? Message-ID: Hi, Is there any way to know when the server has finished sending the primitives for a scene. When my avatar is not moving. Regards, Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/89855885/attachment.htm From Harleen at comcast.net Mon Feb 4 19:17:21 2008 From: Harleen at comcast.net (Harleen Gretzky) Date: Mon Feb 4 19:17:25 2008 Subject: [sldev] 1.19.0 and quicktime References: <47A7B8E8.7060908@gmail.com> Message-ID: <0c8b01c867a5$9f4e6940$6869a8c0@PJRIII.local> The latest version of Quicktime for Windows is 7.4 and can be found at http://www.apple.com/quicktime/download/. ----- Original Message ----- From: "Tony" To: "Second Life Developer Mailing List" Sent: Monday, February 04, 2008 8:16 PM Subject: [sldev] 1.19.0 and quicktime >I wondered if anyone else has had this issue, or if I'm missing something. > I updated to 1.19.0 and when it loaded, I got the Quicktime warning saying > I need to update Quicktime. > I had already updated Quicktime when the previous RC came out, so I > thought I was already OK. > I checked and my version is 7.3.1. When I click "check for updates" in QT, > the only option is to download BOTH Quicktime and iTunes (usually when > Quicktime needs the update, I have the option to just download QT). > > I am running this on a PC, so I'm curious if there is a difference between > the Mac and PC versioning of QT... > > I don't really want to install iTunes > > Anthony Reisman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From davep at lindenlab.com Mon Feb 4 20:00:46 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Feb 4 20:02:28 2008 Subject: [sldev] Finished sending prims? In-Reply-To: References: Message-ID: <47A7DF6E.9060206@lindenlab.com> Not that I know of. You could probably watch the delta on the number of LLViewerObjects that exist in LLViewerObjectList. Qian Hao ~ wrote: > Hi, > > Is there any way to know when the server has finished sending the > primitives for a scene. When my avatar is not moving. > > Regards, > Qian Hao > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From hud at zurich.ibm.com Tue Feb 5 00:18:23 2008 From: hud at zurich.ibm.com (Dr Scofield) Date: Tue Feb 5 00:17:55 2008 Subject: [sldev] Metaverse platform gambling 1 In-Reply-To: <47A768D6.8020303@watson.ibm.com> References: <47A5ACC1.5070808@gmail.com> <200802031710.50778.dale@daleglass.net> <47A768D6.8020303@watson.ibm.com> Message-ID: <47A81BCF.5050403@zurich.ibm.com> Mike Monkowski wrote: > Giulio Prisco wrote: >> yes I mean "groupware tools, web browsing, webcam feeds and >> collaborative editing of documents in popular office formats". >> (spatial VoIP is already in SL thanks God). Plus other features like >> full Flash support and integration with the main social nets. >> >> I, or you, cannot offer to implement these things ourselves because >> server-side SL is a closed proprietary system. Some of these features >> could conceivably be integrated client-side, but a real implementation >> would require grid support. >> >> Also, I would hardly spend time to develop software when _only_ others >> would benefit financially. I would be interested in contributing real >> effort to SL development if I could install my own SL server and sell >> premium services based on it, but the option is not available. So I >> can only say that some features would be cool, and encourage LL to >> develop them. use OpenSim --- it's not as polished as the LL SL servers, but it's open source, making incredible progress and already is quite useful. and you'd invest your time in something you and others would profit from. cheers, dr scofield -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield From annagulaev at gmail.com Tue Feb 5 01:23:11 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Feb 5 01:23:13 2008 Subject: [sldev] force object redraw? In-Reply-To: <47A7CEB2.4010907@lindenlab.com> References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> <47A7CEB2.4010907@lindenlab.com> Message-ID: On 2/4/08, Dave Parks wrote: > > If "registerFace" is called and does nothing, then there is no way for > the object to be drawn. As I said, these are objects that were previously drawn. Perhaps instead of looking for a way to not draw them I should be looking for a way to un-draw them? - markRebuild puts the object into LLPipeline's build queue > - LLPipeline calls updateGeom on objects in the queue, time slicing for > non priority updates > - In the latest windlight build, an object's updateGeom must explicitly > request a spatial group render batch rebuild by calling > LLSpatialGroup::dirtyGeom I'm not using the latest windlight build, but I tried this, anyway. Took the code right out of the windlight viewer. At first I made it conditional on my needs-to-be-invisible condition, and seeing no effect I just made it unconditional. Confirmed with the debugger that it's being called. No change. Dirtying the geometry does not result in an immediate redraw. - Visible spatial groups are determined in updateCull > - LLSpatialGroup::rebuildGeom is called from LLPipeline::postSort > - in LLVOVolumePartition::rebuildGeom, render batches (instances of > LLDrawInfo) are built and registerFace is called for every face added to > a batch > - Pigs fly > - render batches are sorted by texture/matrix/distance Maybe selected geometry has priority? I can look at that, but I'm not hopeful. There are objects on my screen that should be invisible that don't disappear *ever* until I select them. - LLPipeline::renderGeom runs through the drawpools and render passes > which issue drawing calls. Would you mind if I added this to the currently-blank description of the pipeline in the wiki? Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/b1ae8ca2/attachment.htm From marinekelley at gmail.com Tue Feb 5 02:50:51 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Tue Feb 5 02:50:54 2008 Subject: [sldev] Finished sending prims? In-Reply-To: References: Message-ID: <9e52a8c10802050250s648de156ocb7eed950378d8eb@mail.gmail.com> 2008/2/5, Qian Hao ~ : > > Hi, > > Is there any way to know when the server has finished sending the > primitives for a scene. When my avatar is not moving. > > Regards, > Qian Hao > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > Hi, as far as I know the avatar is "frozen" during logon, while your progress bar is still filling up. When it reaches about half-way the avatar is able to hear and starts receiving prims (especially its own attachments, in which scripts are set to running again, but there is no particular priority), but cannot move nor chat. When the progress bar goes away you are usually able to see most of the scene but the sim is still sending you prims. There is no way to check it has finished sending them (of course), but there is a simple atomic way to check your avatar is in "frozen state" or "available". This snippet comes from newview/viewer.cpp @1907 : if (gViewerWindow->mWindow->getVisible() && gViewerWindow->getActive() && !gViewerWindow->mWindow->getMinimized() && LLStartUp::getStartupState() == STATE_STARTED && !gViewerWindow->getShowProgress() && !gFocusMgr.focusLocked()) { } Hope this helps. Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/0c916e66/attachment.htm From annagulaev at gmail.com Tue Feb 5 03:37:47 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Feb 5 03:37:52 2008 Subject: [sldev] force object redraw? In-Reply-To: References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> <47A7CEB2.4010907@lindenlab.com> Message-ID: On 2/5/08, Anna Gulaev wrote: > > On 2/4/08, Dave Parks wrote: > > > > If "registerFace" is called and does nothing, then there is no way for > > the object to be drawn. > > > As I said, these are objects that were previously drawn. Perhaps instead > of looking for a way to not draw them I should be looking for a way to > un-draw them? > I've done one better than that. Before registerFace, the face list is built in rebuildGeom. After the face list is cleared there's a loop that rebuilds it. There's a conditional in there to skip invisible objects. I added the condition for my invisible objects. Verified that the condition is triggered; that is, faces for these objects never even get added to the face list. Not added, not registered. Still, the objects persist until selected. Sortof. In the current state of my code (skipping objects as HideSelected does, not adding invisible faces to the face list, dirtying geometry for invisible objects) objects that are very large and near the camera do eventually disappear. In about 10 seconds. Objects that are less that very large (lets say house-sized) never disappear unless the avatar collides with them. That is, a lighthouse-sized object will eventually disappear. A house-sized object will not. And we aren't talking large distances, either. We're talking house-sized objects at a range of 20m, which render much larger than the avatar. Even they do not receive enough priority to re-draw. Ever. So, it seems to be an unrealistic priority problem, with objects that shouldn't even have faces to render. There is apparently still some positive action that I must take to remove geometry that has already been rendered. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/cf640a19/attachment-0001.htm From annagulaev at gmail.com Tue Feb 5 03:44:23 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Feb 5 03:44:27 2008 Subject: [sldev] visual muting Message-ID: Is anyone interested in visual muting? If so, please take a look at the thread "force object redraw?". I am unable to remove objects from the screen once they've already been rendered. Has anyone run into this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/f180a64c/attachment.htm From sldev at free.fr Tue Feb 5 08:39:06 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Feb 5 08:39:17 2008 Subject: [sldev] Sources for v1.19.0.RC0 please Message-ID: <20080205173906.28ec0709.sldev@free.fr> Greetings, Once again, the sources are not published together with the binaries... :-( Could you please publish the sources for v1.19.0.RC0 on the Wiki (there are sources for beta-1.19.0.76838, dating back from january, but no sources for the RC0) ? From mail at bernhardrode.de Tue Feb 5 03:53:09 2008 From: mail at bernhardrode.de (Bernhard Rode) Date: Tue Feb 5 09:05:27 2008 Subject: [sldev] SLVoice / Vivox Replacement Message-ID: <47A84E25.4070509@bernhardrode.de> Hello to the list, I just read the Wiki about SL Voice and the Vivox Client. I wonder if there are any plans / projects out there to replace the SLVoice Vivox client. As far as I understand the current situation, it should be possible to use any external SIP gateway which is able to set up Sessions. I mean their are many open sourced sip projects out there, which may be used. Thanks in advance, Bernhard Rode From dale at daleglass.net Tue Feb 5 09:38:22 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 09:38:34 2008 Subject: [sldev] visual muting In-Reply-To: References: Message-ID: <200802051838.27788.dale@daleglass.net> On Tuesday 05 February 2008 12:44:23 Anna Gulaev wrote: > Is anyone interested in visual muting? If so, please take a look at the > thread "force object redraw?". I am unable to remove objects from the > screen once they've already been rendered. Has anyone run into this? I think Able Whitman did that already. I've not heard of his progress for some time though, so maybe ask him how is his code going. -------------- 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/20080205/b0c07fe1/attachment.pgp From soft at lindenlab.com Tue Feb 5 10:45:32 2008 From: soft at lindenlab.com (Soft) Date: Tue Feb 5 10:45:35 2008 Subject: [sldev] Art and Library tarball handling Message-ID: Right now, for automated drops I'm uploading new art and library tarballs to go with each svn drop, and my script puts the internal branch and revision in the name. Most of the time, these support tarballs don't change however. Often, they're even the same across branches. Would it make sense to replace the branch and version with the md5 sum for these tarballs? Obviously this would make it tough to tell which tarball goes with which version without referring to the commit messages or doc/asset_urls.txt in the source drops. The onus would be on the downloader to keep track with scripts, or by making named subdirectories to contain the tarballs. Is this a problem? From soft at lindenlab.com Tue Feb 5 10:46:41 2008 From: soft at lindenlab.com (Soft) Date: Tue Feb 5 10:46:44 2008 Subject: [sldev] Sources for v1.19.0.RC0 please In-Reply-To: <20080205173906.28ec0709.sldev@free.fr> References: <20080205173906.28ec0709.sldev@free.fr> Message-ID: On Feb 5, 2008 10:39 AM, Henri Beauchamp wrote: > Greetings, > > Once again, the sources are not published together with the binaries... :-( > > Could you please publish the sources for v1.19.0.RC0 on the Wiki (there > are sources for beta-1.19.0.76838, dating back from january, but no > sources for the RC0) ? I'll prep a set at this specific revision. From davep at lindenlab.com Tue Feb 5 10:54:33 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Feb 5 10:54:46 2008 Subject: [sldev] force object redraw? In-Reply-To: References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> <47A7CEB2.4010907@lindenlab.com> Message-ID: <47A8B0E9.7020708@lindenlab.com> There is apparently still some positive action that I must take to remove geometry that has already been rendered. If rebuildGeom is called on the spatial group of a particular prim and that prim's faces are not added to a LLDrawInfo for rendering, that prim won't be drawn. rebuildGeom is called on every visible spatial group that's flagged as GEOM_DIRTY. I'm not sure where the disconnect is here, but that's the way it works. You're grasping at straws with all this "unrealistic priority" stuff. That's not the way real-time rendering works. Every object you see is getting drawn every frame, but the information used to draw it is updated only occasionally in rebuildGeom. The occasional rebuild you're seeing is more indicative of some scripted object that periodically changes color or texture, or something that moves and stops repeatedly. Maybe you're only calling dirtyGeom for the root prim? Every prim is treated as its own object by the renderer (one instance of LLViewerObject and LLDrawable per prim), so this concept of a "lighthouse" is less than useful. See if you can get it to work with a single prim, then link two prims together and try to get it to work then. Make on of the prims transparent and see if it still works. There is an info display that shows the spatial groups and highlights calls to rebuildGeom (client->render->info display->octree). From davep at lindenlab.com Tue Feb 5 10:58:13 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Feb 5 10:58:44 2008 Subject: [sldev] visual muting In-Reply-To: <200802051838.27788.dale@daleglass.net> References: <200802051838.27788.dale@daleglass.net> Message-ID: <47A8B1C5.6050204@lindenlab.com> I just finished visual muting for avatars using impostors (muting an avatar strips them of attachments and renders them as a solid grey silhouetted impostor that only updates every 16 frames). It passed QA and should go into release next week. I wasn't aware of Able Whitman's work. Is there a PJIRA? Dale Glass wrote: > On Tuesday 05 February 2008 12:44:23 Anna Gulaev wrote: > >> Is anyone interested in visual muting? If so, please take a look at the >> thread "force object redraw?". I am unable to remove objects from the >> screen once they've already been rendered. Has anyone run into this? >> > > I think Able Whitman did that already. > > I've not heard of his progress for some time though, so maybe ask him how > is his code going. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Feb 5 11:01:44 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 5 11:01:55 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <47A84E25.4070509@bernhardrode.de> References: <47A84E25.4070509@bernhardrode.de> Message-ID: <47A8B297.7030303@watson.ibm.com> The voice client code in the SL viewer is pretty localized, so it shouldn't be too difficult to separate the code into an abstract layer that interacts with the viewer GUI controls and a specific layer that implements the particular message formats for the associated "SLVoice" process. I haven't heard of anyone working on that yet, but if the Vivox code remains closed source, there will be a lot of incentive to do it. LL has indicated their hopes to make the voice client open source, but I haven't seen any progress in that direction yet. Mike Bernhard Rode wrote: > Hello to the list, > I just read the Wiki about SL Voice and the Vivox Client. > > I wonder if there are any plans / projects out there to replace the > SLVoice Vivox client. > > As far as I understand the current situation, it should be possible to > use any external SIP gateway which is able to set up Sessions. > > I mean their are many open sourced sip projects out there, which may be > used. From soft at lindenlab.com Tue Feb 5 11:06:53 2008 From: soft at lindenlab.com (Soft) Date: Tue Feb 5 11:06:54 2008 Subject: [sldev] Sources for v1.19.0.RC0 please In-Reply-To: References: <20080205173906.28ec0709.sldev@free.fr> Message-ID: On Feb 5, 2008 12:46 PM, Soft wrote: > On Feb 5, 2008 10:39 AM, Henri Beauchamp wrote: > > Greetings, > > > > Once again, the sources are not published together with the binaries... :-( > > > > Could you please publish the sources for v1.19.0.RC0 on the Wiki (there > > are sources for beta-1.19.0.76838, dating back from january, but no > > sources for the RC0) ? > > I'll prep a set at this specific revision. The set from Sunday's source drop match the release - I've added those to the download page. From monkowsk at watson.ibm.com Tue Feb 5 11:11:07 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 5 11:11:12 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B1C5.6050204@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> Message-ID: <47A8B4CB.2010602@watson.ibm.com> Dave Parks wrote: > I just finished visual muting for avatars using impostors (muting an > avatar strips them of attachments and renders them as a solid grey > silhouetted impostor that only updates every 16 frames). Why avatar impostors instead of LOD? It looks like LOD processing is already there and it's just a matter of tuning it. Given the rather ugly appearance of imposters, there must be some advantage. Mike From dale at daleglass.net Tue Feb 5 11:14:37 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 11:14:53 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B1C5.6050204@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> Message-ID: <200802052014.42907.dale@daleglass.net> On Tuesday 05 February 2008 19:58:13 Dave Parks wrote: > I just finished visual muting for avatars using impostors (muting an > avatar strips them of attachments and renders them as a solid grey > silhouetted impostor that only updates every 16 frames). It passed QA > and should go into release next week. I wasn't aware of Able Whitman's > work. Is there a PJIRA? I searched a bit, it seems there isn't. Though he released a viewer with the feature, and there is a source patch with the changes: http://ablewhitman.org/viewer/ -------------- 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/20080205/326f9060/attachment.pgp From dale at daleglass.net Tue Feb 5 11:29:10 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 11:29:24 2008 Subject: [sldev] Art and Library tarball handling In-Reply-To: References: Message-ID: <200802052029.17793.dale@daleglass.net> On Tuesday 05 February 2008 19:45:32 Soft wrote: > Would it make sense to replace the branch and version with the md5 sum > for these tarballs? Obviously this would make it tough to tell which > tarball goes with which version without referring to the commit > messages or doc/asset_urls.txt in the source drops. The onus would be > on the downloader to keep track with scripts, or by making named > subdirectories to contain the tarballs. Is this a problem? You mean that instead of say: SLASSET_ART=http://secondlife.com/developers/opensource/downloads/2008/02/slviewer-artwork-Branch_1-19-0-Viewer-r79209.zip It'd be something like: SLASSET_ART=http://secondlife.com/developers/opensource/downloads/2008/02/slviewer-artwork-c0387ba22f8ae20b2b70995e2f0289cf.zip ? That sounds good to me, I track it with scripts already anyway. I plan to publish these soon for general usage as soon as I'm sure there's nothing stupid in there. If I may make a suggestion, could you provide tarred version of the artwork? ZIP tools on Linux lack the very useful --strip-components tar argument, which makes it easier to work with source directories that aren't called 'linden'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080205/9268757a/attachment.pgp From robla at lindenlab.com Tue Feb 5 11:30:28 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 5 11:30:41 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B1C5.6050204@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> Message-ID: <47A8B954.8030504@lindenlab.com> (cc'ing Able, since he hasn't been active on the list in a little while) On 2/5/08 10:58 AM, Dave Parks wrote: > I just finished visual muting for avatars using impostors (muting an > avatar strips them of attachments and renders them as a solid grey > silhouetted impostor that only updates every 16 frames). It passed QA > and should go into release next week. I wasn't aware of Able > Whitman's work. Is there a PJIRA? Yup: http://jira.secondlife.com/browse/VWR-1017 I don't believe he's submitted any patches to us, but he has a separate prototype viewer he's been working on. http://ablewhitman.org/viewer/ 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/20080205/1d6e9ece/signature.pgp From tulla at lindenlab.com Tue Feb 5 11:39:20 2008 From: tulla at lindenlab.com (Eric M. Tulla) Date: Tue Feb 5 11:39:34 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B4CB.2010602@watson.ibm.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> Message-ID: <47A8BB68.9080100@lindenlab.com> Mike Monkowski wrote: > Dave Parks wrote: >> I just finished visual muting for avatars using impostors (muting an >> avatar strips them of attachments and renders them as a solid grey >> silhouetted impostor that only updates every 16 frames). > > Why avatar impostors instead of LOD? It looks like LOD processing is > already there and it's just a matter of tuning it. Given the rather > ugly appearance of imposters, there must be some advantage. > > Mike > Using impostors for visual muting allows you to display a muted avatar using only 2 triangles (a billboard) with minimal pre-computation, while still somewhat preserving form. Using LOD would require greater overhead for the actual muting and less of a performance gain, especially if you want to preserve shape (even with a really low LOD you'll still be drawing many, many more triangles per frame). From tulla at lindenlab.com Tue Feb 5 11:41:16 2008 From: tulla at lindenlab.com (Eric M. Tulla) Date: Tue Feb 5 11:41:47 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B4CB.2010602@watson.ibm.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> Message-ID: <47A8BBDC.8080706@lindenlab.com> Mike Monkowski wrote: > Dave Parks wrote: >> I just finished visual muting for avatars using impostors (muting an >> avatar strips them of attachments and renders them as a solid grey >> silhouetted impostor that only updates every 16 frames). > > Why avatar impostors instead of LOD? It looks like LOD processing is > already there and it's just a matter of tuning it. Given the rather > ugly appearance of imposters, there must be some advantage. > > Mike Using impostors for visual muting allows you to display a muted avatar using only 2 triangles (a billboard) with minimal pre-computation, while still preserving form. Using LOD would require greater overhead for the actual muting and less of a performance gain, especially if you want to preserve shape (even with a really low LOD you'll still be drawing many, many more triangles per frame). From gigstaggart at gmail.com Tue Feb 5 12:01:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 5 12:01:58 2008 Subject: [sldev] Finished sending prims? In-Reply-To: <9e52a8c10802050250s648de156ocb7eed950378d8eb@mail.gmail.com> References: <9e52a8c10802050250s648de156ocb7eed950378d8eb@mail.gmail.com> Message-ID: <47A8C0B3.4030703@gmail.com> Marine Kelley wrote: > Hi, as far as I know the avatar is "frozen" during logon, while your > progress bar is still filling up. When it reaches about half-way the I'm pretty sure that's on a simple timer though, it doesn't really relate to the completeness of the scene. There was a recent question about weird interactions with tweaking this timer value, though. From davep at lindenlab.com Tue Feb 5 12:03:15 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Feb 5 12:02:49 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B954.8030504@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B954.8030504@lindenlab.com> Message-ID: <47A8C103.60006@lindenlab.com> Oh, good. Since my muting only applies to avatars, this won't conflict at all. The jira already contains an excellent discussion of the pros/cons of making muted objects invisible, so let's not repeat those concerns here. Suffice to say, such a change should include a "Muted Object" entry in the beacon menu so you can see the objects you've muted. Rob Lanphier wrote: > (cc'ing Able, since he hasn't been active on the list in a little while) > > On 2/5/08 10:58 AM, Dave Parks wrote: >> I just finished visual muting for avatars using impostors (muting an >> avatar strips them of attachments and renders them as a solid grey >> silhouetted impostor that only updates every 16 frames). It passed >> QA and should go into release next week. I wasn't aware of Able >> Whitman's work. Is there a PJIRA? > > Yup: http://jira.secondlife.com/browse/VWR-1017 > > I don't believe he's submitted any patches to us, but he has a > separate prototype viewer he's been working on. > http://ablewhitman.org/viewer/ > > Rob > > > From dale at daleglass.net Tue Feb 5 12:09:24 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 12:09:36 2008 Subject: [sldev] visual muting In-Reply-To: <47A8BBDC.8080706@lindenlab.com> References: <47A8B4CB.2010602@watson.ibm.com> <47A8BBDC.8080706@lindenlab.com> Message-ID: <200802052109.29891.dale@daleglass.net> On Tuesday 05 February 2008 20:41:16 Eric M. Tulla wrote: > Using impostors for visual muting allows you to display a muted avatar > using only 2 triangles (a billboard) with minimal pre-computation, while > still preserving form. Using LOD would require greater overhead for the > actual muting and less of a performance gain, especially if you want to > preserve shape (even with a really low LOD you'll still be drawing many, > many more triangles per frame). The problem I see with that is that my reason for wanting to visually mute somebody is that I don't want to see them, because they're say, wearing a mature attachment in a PG area. I've had plans for some time to do some related work and will get back to it as soon as I finish some more urgent pending things. But my basic idea is to make the viewer fully mute avatars and all their stuff that are banned on the parcel the user is standing on. The current situation is that if you ban somebody they still can hang around the ban border and play sounds, use particles, etc. My plan is to mute banned people completely. Make them fully invisible, including the avatar, attachments, sounds, any objects they own and particle effects. -------------- 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/20080205/e2cf8a4d/attachment.pgp From tulla at lindenlab.com Tue Feb 5 12:28:38 2008 From: tulla at lindenlab.com (Eric M. Tulla) Date: Tue Feb 5 12:28:53 2008 Subject: [sldev] visual muting In-Reply-To: <200802052109.29891.dale@daleglass.net> References: <47A8B4CB.2010602@watson.ibm.com> <47A8BBDC.8080706@lindenlab.com> <200802052109.29891.dale@daleglass.net> Message-ID: <47A8C6F6.7070909@lindenlab.com> Dale Glass wrote: > On Tuesday 05 February 2008 20:41:16 Eric M. Tulla wrote: > >> Using impostors for visual muting allows you to display a muted avatar >> using only 2 triangles (a billboard) with minimal pre-computation, while >> still preserving form. Using LOD would require greater overhead for the >> actual muting and less of a performance gain, especially if you want to >> preserve shape (even with a really low LOD you'll still be drawing many, >> many more triangles per frame). >> > > The problem I see with that is that my reason for wanting to visually mute > somebody is that I don't want to see them, because they're say, wearing a > mature attachment in a PG area. > > I've had plans for some time to do some related work and will get back to > it as soon as I finish some more urgent pending things. > > But my basic idea is to make the viewer fully mute avatars and all their > stuff that are banned on the parcel the user is standing on. The current > situation is that if you ban somebody they still can hang around the ban > border and play sounds, use particles, etc. > > My plan is to mute banned people completely. Make them fully invisible, > including the avatar, attachments, sounds, any objects they own and > particle effects. > Dave's solution handles this. His description to this list of the implementation specifically mentions that visually muting an avatar renders them into an impostor without attachments or textures (just a grey shape). So even though they wouldn't be fully invisible, you shouldn't be able to see anything offensive or performance intensive being rendered for visually muted avatars. This is actually preferable, since the server will still be calculating physics collisions between you and all avatars (visually muted or not), so making them fully invisible would have potential consequences on the ease with which you can move around a scene. From dale at daleglass.net Tue Feb 5 12:39:05 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 12:39:28 2008 Subject: [sldev] visual muting In-Reply-To: <47A8C6F6.7070909@lindenlab.com> References: <200802052109.29891.dale@daleglass.net> <47A8C6F6.7070909@lindenlab.com> Message-ID: <200802052139.22861.dale@daleglass.net> On Tuesday 05 February 2008 21:28:38 Eric M. Tulla wrote: > Dave's solution handles this. His description to this list of the > implementation specifically mentions that visually muting an avatar > renders them into an impostor without attachments or textures (just a > grey shape). So even though they wouldn't be fully invisible, you > shouldn't be able to see anything offensive or performance intensive > being rendered for visually muted avatars. This is actually preferable, > since the server will still be calculating physics collisions between > you and all avatars (visually muted or not), so making them fully > invisible would have potential consequences on the ease with which you > can move around a scene. Ahh, d'oh. I should have read better ^_^;; Though it wouldn't cause issues for what I'm planning anyway, since my idea is to hide avatars banned on the parcel the user is on. That means that they can't collide with you in the first place. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080205/3499d597/attachment.pgp From annagulaev at gmail.com Tue Feb 5 12:41:03 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Feb 5 12:41:08 2008 Subject: [sldev] force object redraw? In-Reply-To: <47A8B0E9.7020708@lindenlab.com> References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> <47A7CEB2.4010907@lindenlab.com> <47A8B0E9.7020708@lindenlab.com> Message-ID: On 2/5/08, Dave Parks wrote: > > so this concept of a "lighthouse" is less than useful. The lighthouse isn't a concept; it's an object in Baileya :-) http://www.vengeancestudio.com/otherpics/mute01.jpg It and the houses behind it have been my test subjects. I've also used one of my own properties as a test, as nearly everything on it is unlinked: http://www.vengeancestudio.com/otherpics/mute03.jpg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080205/ad54797b/attachment.htm From me at hamncheeseomlet.com Tue Feb 5 13:06:00 2008 From: me at hamncheeseomlet.com (Hamncheese) Date: Tue Feb 5 13:06:22 2008 Subject: [sldev] visual muting In-Reply-To: <47A8C6F6.7070909@lindenlab.com> References: <47A8B4CB.2010602@watson.ibm.com> <47A8BBDC.8080706@lindenlab.com><200802052109.29891.dale@daleglass.net> <47A8C6F6.7070909@lindenlab.com> Message-ID: <52ABEE03734142ED948C28BB8D62C6D2@DreamStream> > implementation specifically mentions that visually muting an avatar > renders them into an impostor without attachments or textures (just a grey > shape). And how is this different from what happens today? Looks like you don't have to do anything. Most of the time anyway the normal SL client shows me gray and attachments hidden up my nether parts . ;) From seg at haxxed.com Tue Feb 5 13:20:26 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Feb 5 13:20:37 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47A7545A.4030201@lindenlab.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> <1201831040.3505.4.camel@localhost> <47A36506.9070507@lindenlab.com> <1201908044.3505.46.camel@localhost> <47A3AA11.3020600@lindenlab.com> <1201908984.3505.51.camel@localhost> <47A7545A.4030201@lindenlab.com> Message-ID: <1202246426.3505.98.camel@localhost> On Mon, 2008-02-04 at 10:07 -0800, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > > Gladly. But it appears the cmake branch is based on 1.18.6, which means > > I have to bite (or dodge) the llmozlib bullet before I can get to this. > > You can turn off use of llmozlib easily, if that's what you want to > do: > just run ccmake and toggle the option. Well yes, last I tried, I was able to compile without llmozlib. But it left me with a client unable to log in and thus useless. Was "classic login" re-introduced to 1.18.6 or is that in 1.19? -------------- 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/20080205/86401720/attachment.pgp From monkowsk at watson.ibm.com Tue Feb 5 13:36:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 5 13:37:09 2008 Subject: Avatar imposters; was: [sldev] visual muting In-Reply-To: <47A8BB68.9080100@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> <47A8BB68.9080100@lindenlab.com> Message-ID: <47A8D6F9.5090804@watson.ibm.com> I'm sorry. I wasn't specifically asking about muting. It's just that this thread reminded me of my reaction to the imposters in WindLight. I should have renamed the subject. I realize that the imposters used very few resources, but they look really bad and there doesn't seem to be any gradation. A fully rendered avatar suddenly transforms into a coarsely pixellated billboard. It would seem that a progression through lower LOD before jumping to billboards would be less disruptive. Hmmm. Or do I see this because I'm using the alt-zoom camera and the transition to imposters is based on my avatar location, not the camera location? Mike Eric M. Tulla wrote: > Mike Monkowski wrote: > >> Dave Parks wrote: >> >>> I just finished visual muting for avatars using impostors (muting an >>> avatar strips them of attachments and renders them as a solid grey >>> silhouetted impostor that only updates every 16 frames). >> >> >> Why avatar impostors instead of LOD? It looks like LOD processing is >> already there and it's just a matter of tuning it. Given the rather >> ugly appearance of imposters, there must be some advantage. >> >> Mike >> > Using impostors for visual muting allows you to display a muted avatar > using only 2 triangles (a billboard) with minimal pre-computation, while > still somewhat preserving form. Using LOD would require greater > overhead for the actual muting and less of a performance gain, > especially if you want to preserve shape (even with a really low LOD > you'll still be drawing many, many more triangles per frame). > From dale at daleglass.net Tue Feb 5 13:40:04 2008 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 5 13:40:14 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <1202246426.3505.98.camel@localhost> References: <47A1025B.9080702@lindenlab.com> <47A7545A.4030201@lindenlab.com> <1202246426.3505.98.camel@localhost> Message-ID: <200802052240.08882.dale@daleglass.net> On Tuesday 05 February 2008 22:20:26 Callum Lerwick wrote: > Well yes, last I tried, I was able to compile without llmozlib. But it > left me with a client unable to log in and thus useless. Was "classic > login" re-introduced to 1.18.6 or is that in 1.19? 1.19. 1.18.6 still has the web stuff, and still doesn't work for me even with mozlib. It gets stuck with "loading..." half-visible in the upper left corner. -------------- 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/20080205/1f2f8adc/attachment.pgp From tulla at lindenlab.com Tue Feb 5 13:42:45 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi)) Date: Tue Feb 5 13:43:02 2008 Subject: Avatar imposters; was: [sldev] visual muting In-Reply-To: <47A8D6F9.5090804@watson.ibm.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> <47A8BB68.9080100@lindenlab.com> <47A8D6F9.5090804@watson.ibm.com> Message-ID: <47A8D855.5030904@lindenlab.com> Have you tried playing with the "avatar detail" slider? It also controls the distance at which impostoring occurs, allowing you to tune it's use to whatever performance / visual quality tradeoff you personally are willing to make. You can also still turn them off completely if you don't like them at all. Mike Monkowski wrote: > I'm sorry. I wasn't specifically asking about muting. It's just that > this thread reminded me of my reaction to the imposters in WindLight. > I should have renamed the subject. > > I realize that the imposters used very few resources, but they look > really bad and there doesn't seem to be any gradation. A fully > rendered avatar suddenly transforms into a coarsely pixellated > billboard. It would seem that a progression through lower LOD before > jumping to billboards would be less disruptive. > > Hmmm. Or do I see this because I'm using the alt-zoom camera and the > transition to imposters is based on my avatar location, not the camera > location? > > Mike From secret.argent at gmail.com Tue Feb 5 14:04:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 5 14:05:08 2008 Subject: [sldev] Proprietary dependencies (Re: Compile as installer) In-Reply-To: <47A25765.6010300@dzonux.net> References: <479850FD.9000708@zweitgeist.com> <479A459D.2000701@lindenlab.com> <479A5553.7070500@gmail.com> <200801312322.25975.dale@daleglass.net> <47A25765.6010300@dzonux.net> Message-ID: <8308FD08-6090-498C-807C-1D53FF8237AE@gmail.com> On 2008-01-31, at 17:19, Dzonatas wrote: > ...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). I don't like the implication that the exceptions were or are a mistake. They may still be the right thing to do. If you didn't meen to imply that they were a mistake, I apologize, but that's how it reads to me. Don't forget, they're also allowed to specify "GPL3, with these exceptions" or even "GPL3 or GPL2, as appropriate, with exceptions". From davep at lindenlab.com Tue Feb 5 14:11:26 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Feb 5 14:12:38 2008 Subject: Avatar imposters; was: [sldev] visual muting In-Reply-To: <47A8D855.5030904@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> <47A8BB68.9080100@lindenlab.com> <47A8D6F9.5090804@watson.ibm.com> <47A8D855.5030904@lindenlab.com> Message-ID: <47A8DF0E.6000804@lindenlab.com> Adjusting the resolution of the impostor based on screen area is still on my todo list. Right now, all avatar impostors are 128x256 regardless of how big they are on the screen, which is what's causing the ugly. Eric M. Tulla (BigPapi) wrote: > Have you tried playing with the "avatar detail" slider? It also > controls the distance at which impostoring occurs, allowing you to > tune it's use to whatever performance / visual quality tradeoff you > personally are willing to make. You can also still turn them off > completely if you don't like them at all. > > Mike Monkowski wrote: >> I'm sorry. I wasn't specifically asking about muting. It's just >> that this thread reminded me of my reaction to the imposters in >> WindLight. I should have renamed the subject. >> >> I realize that the imposters used very few resources, but they look >> really bad and there doesn't seem to be any gradation. A fully >> rendered avatar suddenly transforms into a coarsely pixellated >> billboard. It would seem that a progression through lower LOD before >> jumping to billboards would be less disruptive. >> >> Hmmm. Or do I see this because I'm using the alt-zoom camera and the >> transition to imposters is based on my avatar location, not the >> camera location? >> >> Mike > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Tue Feb 5 14:38:52 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 5 14:39:06 2008 Subject: [sldev] visual muting In-Reply-To: <47A8B4CB.2010602@watson.ibm.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> Message-ID: <47A8E57C.8030104@gmail.com> Mike Monkowski wrote: > Why avatar impostors instead of LOD? It looks like LOD processing is > already there and it's just a matter of tuning it. Given the rather > ugly appearance of imposters, there must be some advantage. > Have you ever seen a low LOD avatar up close? They are much more ugly. Stuff of nightmares. -Jason From secret.argent at gmail.com Tue Feb 5 14:52:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 5 14:52:08 2008 Subject: Avatar imposters; was: [sldev] visual muting In-Reply-To: <47A8DF0E.6000804@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> <47A8BB68.9080100@lindenlab.com> <47A8D6F9.5090804@watson.ibm.com> <47A8D855.5030904@lindenlab.com> <47A8DF0E.6000804@lindenlab.com> Message-ID: On 2008-02-05, at 16:11, Dave Parks wrote: > Adjusting the resolution of the impostor based on screen area is > still on my todo list. Right now, all avatar impostors are 128x256 > regardless of how big they are on the screen, which is what's > causing the ugly. Alpha blending on the edges would help too. :) From seg at haxxed.com Tue Feb 5 14:52:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Feb 5 14:52:39 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <47A84E25.4070509@bernhardrode.de> References: <47A84E25.4070509@bernhardrode.de> Message-ID: <1202251948.3505.102.camel@localhost> On Tue, 2008-02-05 at 12:53 +0100, Bernhard Rode wrote: > Hello to the list, > I just read the Wiki about SL Voice and the Vivox Client. > > I wonder if there are any plans / projects out there to replace the > SLVoice Vivox client. > > As far as I understand the current situation, it should be possible to > use any external SIP gateway which is able to set up Sessions. > > I mean their are many open sourced sip projects out there, which may be > used. It would appear that slvoice is already 99% open source. The patent-encumbered codec is the big showstopper. -------------- 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/20080205/8d04c772/attachment.pgp From tateru.nino at gmail.com Tue Feb 5 15:36:08 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Feb 5 15:38:33 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <1202251948.3505.102.camel@localhost> References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> Message-ID: <47A8F2E8.1010306@gmail.com> Callum Lerwick wrote: > On Tue, 2008-02-05 at 12:53 +0100, Bernhard Rode wrote: > >> Hello to the list, >> I just read the Wiki about SL Voice and the Vivox Client. >> >> I wonder if there are any plans / projects out there to replace the >> SLVoice Vivox client. >> >> As far as I understand the current situation, it should be possible to >> use any external SIP gateway which is able to set up Sessions. >> >> I mean their are many open sourced sip projects out there, which may be >> used. >> > > It would appear that slvoice is already 99% open source. The > patent-encumbered codec is the big showstopper. Was there not also an issue with the documentation licensing? Or was that resolved? I don't quite recall. -- Tateru Nino http://www.massively.com/ From monkowsk at watson.ibm.com Tue Feb 5 15:42:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 5 15:42:42 2008 Subject: Avatar imposters; was: [sldev] visual muting In-Reply-To: <47A8D855.5030904@lindenlab.com> References: <200802051838.27788.dale@daleglass.net> <47A8B1C5.6050204@lindenlab.com> <47A8B4CB.2010602@watson.ibm.com> <47A8BB68.9080100@lindenlab.com> <47A8D6F9.5090804@watson.ibm.com> <47A8D855.5030904@lindenlab.com> Message-ID: <47A8F46A.3050208@watson.ibm.com> Eric M. Tulla (BigPapi) wrote: > Have you tried playing with the "avatar detail" slider? I'm an engineer. Of course I played with the slider. :-) I pushed it all the way to both ends just to see what happens. I was curious from an engineering standpoint. I asked about LOD because it doesn't seem to be fully utilized in SL. For example, avatar_head.llm is 1,598K and avatar_head_1.llm is only 8K and some of the morphs don't appear in the lower LOD file. I would have expected a 100K file or so for LOD 1 and perhaps 10K for LOD 2. Mike From monkowsk at watson.ibm.com Tue Feb 5 15:45:44 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 5 15:46:23 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <1202251948.3505.102.camel@localhost> References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> Message-ID: <47A8F528.1010001@watson.ibm.com> Callum Lerwick wrote: > It would appear that slvoice is already 99% open source. Huh!? Where? Mike From tinacloud at gmx.de Tue Feb 5 16:20:48 2008 From: tinacloud at gmx.de (Zi Ree) Date: Tue Feb 5 16:20:55 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM Message-ID: <200802060120.49058.tinacloud@gmx.de> Hello Developers! I have submitted a patch to Jira that adds a click action to names in Chat and Group IMs, opening an IM session to the user and enabling a right-click menu that lets you open the resident's profile or offer them a teleport. https://jira.secondlife.com/browse/VWR-4204 Internally it adds a new SLURL type with the following properties: slresident://First%20Last/UUID/ UUID may be omitted, the code will read the UUID from the name cache then. Please have a look at the code and comment. I'd really love to see this in the viewer, because it makes life easier for those, who need to open IMs to people frequently (Mentors on the official Mentor channel, for example). Thanks, everyone! Zi From soft at lindenlab.com Tue Feb 5 16:44:33 2008 From: soft at lindenlab.com (Soft) Date: Tue Feb 5 16:44:37 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <47A8F2E8.1010306@gmail.com> References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> <47A8F2E8.1010306@gmail.com> Message-ID: On Feb 5, 2008 5:36 PM, Tateru Nino wrote: > > Was there not also an issue with the documentation licensing? Or was > that resolved? I don't quite recall. The vendor had a restrictive clause controlling who could look at the voice documentation. We insisted that be removed as soon as sldevers pointed it out. From me at signpostmarv.name Tue Feb 5 18:04:30 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Feb 5 18:04:30 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802060120.49058.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> Message-ID: <47A915AE.3000502@signpostmarv.name> The UUID seems redundant. I'm guessing you could type in slresident://Torley%20Linden/83b3987f-9520-4275-8efe-3ac13dd3f635 which would send IMs to me :-P Wouldn't it be better to have secondlife:///app/83b3987f-9520-4275-8efe-3ac13dd3f635/im to fit with the secondlife://app/83b3987f-9520-4275-8efe-3ac13dd3f635/about syntax ? Zi Ree wrote: > Hello Developers! > > I have submitted a patch to Jira that adds a click action to names in Chat and > Group IMs, opening an IM session to the user and enabling a right-click menu > that lets you open the resident's profile or offer them a teleport. > > https://jira.secondlife.com/browse/VWR-4204 > > Internally it adds a new SLURL type with the following properties: > > slresident://First%20Last/UUID/ > > UUID may be omitted, the code will read the UUID from the name cache then. > > Please have a look at the code and comment. I'd really love to see this in the > viewer, because it makes life easier for those, who need to open IMs to > people frequently (Mentors on the official Mentor channel, for example). > > Thanks, everyone! > Zi > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080206/bbb5b1b6/smime.bin From secret.argent at gmail.com Tue Feb 5 18:32:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 5 18:33:21 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <47A915AE.3000502@signpostmarv.name> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> Message-ID: <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> It would be even better to have secondlife://something.secondlife.com/ something... From tateru.nino at gmail.com Tue Feb 5 23:35:27 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Feb 5 23:37:54 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> <47A8F2E8.1010306@gmail.com> Message-ID: <47A9633F.3070307@gmail.com> Soft wrote: > On Feb 5, 2008 5:36 PM, Tateru Nino wrote: > >> Was there not also an issue with the documentation licensing? Or was >> that resolved? I don't quite recall. >> > > The vendor had a restrictive clause controlling who could look at the > voice documentation. We insisted that be removed as soon as sldevers > pointed it out. > > Ah, glad to hear. I might take another look at that documentation now. -- Tateru Nino http://www.massively.com/ From seg at haxxed.com Tue Feb 5 23:47:23 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Feb 5 23:47:35 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> Message-ID: <1202284044.3505.105.camel@localhost> On Tue, 2008-02-05 at 20:32 -0600, Argent Stonecutter wrote: > It would be even better to have secondlife://something.secondlife.com/ > something... What, to increase load on the DNS servers? -------------- 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/20080206/4dba0c47/attachment.pgp From me at signpostmarv.name Wed Feb 6 00:51:01 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Feb 6 00:50:59 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> Message-ID: <47A974F5.9050604@signpostmarv.name> Exactly what purpose would this serve ? Argent Stonecutter wrote: > It would be even better to have > secondlife://something.secondlife.com/something... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080206/18be1297/smime.bin From secret.argent at gmail.com Wed Feb 6 06:06:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 6 06:06:37 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <1202284044.3505.105.camel@localhost> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> <46E2190F-8178-4C43-96C2-572848089BCD@gmail.com> <1202284044.3505.105.camel@localhost> Message-ID: <6FA34E62-B236-473F-8F05-1571CEC24C95@gmail.com> On 2008-02-06, at 01:47, Callum Lerwick wrote: > On Tue, 2008-02-05 at 20:32 -0600, Argent Stonecutter wrote: >> It would be even better to have secondlife:// >> something.secondlife.com/ >> something... > What, to increase load on the DNS servers? I nearly imagine that it makes no difference whether the name of the server SL uses to complete the request is hardcoded in the client or encoded in the URL, it has to look it up regardless. The advantage to encoding it in the URL is that it would allow one to search for secondlife://something.dragaera.com/something/Marish%20eChala as easily as secondlife://something.secondlife.com/something/Torley% 20Linden. :) From soft at lindenlab.com Wed Feb 6 06:22:30 2008 From: soft at lindenlab.com (Soft) Date: Wed Feb 6 06:22:34 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm Message-ID: If you've got something raised on the list that wants closure, please consider adding it to the Thursday 2pm open source meeting agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From soft at lindenlab.com Wed Feb 6 10:44:35 2008 From: soft at lindenlab.com (Soft) Date: Wed Feb 6 10:44:39 2008 Subject: [sldev] Visual Studio build change Message-ID: If you're using Visual Studio for your builds, you now need to add cygwin to your Visual Studio path. It no longer relies on a hard-coded cygwin location. In VS2003 this is at tools->options->projects->vc++ directories, "show directories for: executable files." Here, add c:\cygwin\bin or local equivalent. I suggest adding it to the very bottom of the list so cygwin binaries don't supercede Windows commands with the same name. From tinacloud at gmx.de Wed Feb 6 13:23:48 2008 From: tinacloud at gmx.de (Zi Ree) Date: Wed Feb 6 13:24:04 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <47A915AE.3000502@signpostmarv.name> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> Message-ID: <200802062223.48509.tinacloud@gmx.de> Am Mittwoch 06 Februar 2008 schrieb SignpostMarv Martin: > The UUID seems redundant. I'm guessing you could type in The idea was to have either the UUID or the name, since in the source code there are two scenarios possible. So you would have slresident://first%20last// or slresident:///UUID ... But I'm all for a better solution, as long as it doesn't overly complicate things. The patch should stay simple and straightforward. Zi From josh at lindenlab.com Wed Feb 6 13:25:02 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Feb 6 13:26:17 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <200802052240.08882.dale@daleglass.net> References: <47A1025B.9080702@lindenlab.com> <47A7545A.4030201@lindenlab.com> <1202246426.3505.98.camel@localhost> <200802052240.08882.dale@daleglass.net> Message-ID: <47AA25AE.6080205@lindenlab.com> Dale Glass wrote: > On Tuesday 05 February 2008 22:20:26 Callum Lerwick wrote: > >> Well yes, last I tried, I was able to compile without llmozlib. But it >> left me with a client unable to log in and thus useless. Was "classic >> login" re-introduced to 1.18.6 or is that in 1.19? >> > > 1.19. > > 1.18.6 still has the web stuff, and still doesn't work for me even with > mozlib. It gets stuck with "loading..." half-visible in the upper left > corner. > Just an explicit reminder: 1.18.6 is a dead, abandoned branch. It won't ever be released as-is, and no further work or code drops will be done for it. 1.19 is where the fun is now. :) From kelly at lindenlab.com Wed Feb 6 14:12:50 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Feb 6 14:13:22 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802062223.48509.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> <47A915AE.3000502@signpostmarv.name> <200802062223.48509.tinacloud@gmx.de> Message-ID: <47AA30E2.3040100@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080206/4c38c706/attachment.htm From me at signpostmarv.name Wed Feb 6 14:14:51 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Feb 6 14:14:49 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802062309.24114.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> <200802062223.48509.tinacloud@gmx.de> <47AA2DCF.9080506@signpostmarv.name> <200802062309.24114.tinacloud@gmx.de> Message-ID: <47AA315B.4060105@signpostmarv.name> Probably no documentation, but there is secondlife:///app/teleport//[[[]///?] secondlife:///app/place//about (i think) secondlife:///app/resident//about The basic gist for non-teleportation is: secondlife:///app/// Zi Ree wrote: > Am Mittwoch 06 Februar 2008 schriebst du: > > >> Current practice is to use secondlife:///app//tag >> Inventing a new URI scheme doesn't seem necesary- why separate the >> syntax for IMing from the syntax for bringing up the profile ? >> >> Also, there's little reason why you couldn't do >> secondlife:///app//im *and* secondlife:///app//about >> > > Ok, I will try that. Is there any documentation on this that is easily > accessible? Because if there is an existing, working scheme, I'm more than > happy to use it. > > Zi > > -------------- 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/20080206/cfae4f60/smime.bin From me at signpostmarv.name Wed Feb 6 14:27:10 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Feb 6 14:27:30 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802060120.49058.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> Message-ID: <47AA343E.4080609@signpostmarv.name> I did some jiggery-pokery on the JIRA issue since the URI scheme bit is something I suggested almost a year ago. Zi Ree wrote: > Internally it adds a new SLURL type with the following properties: > > slresident://First%20Last/UUID/ > -------------- 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/20080206/12de966d/smime.bin From sldev at free.fr Wed Feb 6 14:29:17 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Feb 6 14:50:17 2008 Subject: [sldev] Sources for the latest Firstlook/Windlight please ! Message-ID: <20080206232917.31335d83.sldev@free.fr> Still waiting for them to be published on the Wiki... :-( From annagulaev at gmail.com Wed Feb 6 15:27:51 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Wed Feb 6 15:27:55 2008 Subject: [sldev] force object redraw? In-Reply-To: References: <47A6BC3C.5020108@lindenlab.com> <47A7B7FF.5080909@lindenlab.com> <47A7CEB2.4010907@lindenlab.com> Message-ID: On 2/5/08, Anna Gulaev wrote: > > Still, the objects persist until selected. Sortof. > I think I have a better handle on what's happening. My make-invisible code is being triggered by ObjectUpdate events. Apparently there's an ObjectUpdate triggered when you select things, and this is why the timing of the becoming-invisible varried from session to session. Sometimes it happened immediately on right-click, sometimes a second or so ofter selecting, and sometimes on deselect. I think it was just a matter of the timing of the ObjectUpdate. Why didn't the first ObjectUpdate--the one that placed the object in the first place--trigger invisibility? Well, my region scanner is creating junk data. I think I have a ghost for each correctly scanned region. I don't know yet if this is a result of scanning before data is available, or because I'm straddling a border of a sim that is winking in and out (Hyles), or becuase of a bug in my region scanner. But curiously, the ObjectUpdate that correctly triggers invisibility happens after the scanner is receiving proper data. It has nothing to do with selection, other than it being selection that triggers the ObjectUpdate at a time when it will work. Anyway, I tuned the stalled-update timer for my region scanner, and now invisibility is being triggered somewhat faster. I think the first scan is failing (and maybe this is the source of my bad maps), and now it retries sooner. It still takes distressingly long to scan the region for parcel data. Thank you, Dave, for your help. Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080206/be500eeb/attachment-0001.htm From kamilion at gmail.com Wed Feb 6 18:22:37 2008 From: kamilion at gmail.com (Kamilion) Date: Wed Feb 6 18:22:45 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802060120.49058.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> Message-ID: On Feb 5, 2008 4:20 PM, Zi Ree wrote: > Hello Developers! > > I have submitted a patch to Jira that adds a click action to names in Chat and > Group IMs, opening an IM session to the user and enabling a right-click menu > that lets you open the resident's profile or offer them a teleport. > > https://jira.secondlife.com/browse/VWR-4204 > > Internally it adds a new SLURL type with the following properties: > > slresident://First%20Last/UUID/ > > UUID may be omitted, the code will read the UUID from the name cache then. > > Please have a look at the code and comment. I'd really love to see this in the > viewer, because it makes life easier for those, who need to open IMs to > people frequently (Mentors on the official Mentor channel, for example). > > Thanks, everyone! > Zi I took a look at your patch, and I was quite happy to see getUUIDbyName! Looks like you've partially implemented one of my JIRAs... http://jira.secondlife.com/browse/VWR-3596 The only thing your patch is missing to match VWR-3596 is two Menu entrys: Offer Calling Card & Add to Conference Chat. Also, the context menu should be added to users in the userlist sidebar in Group IM sessions & Near Me. I could probably hack up some XUI for your patch, but I'm lost for the C++ side. How much work would it be for you to add the C++ side? From lenglish5 at cox.net Wed Feb 6 20:12:30 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Feb 6 20:12:33 2008 Subject: [sldev] Command for GUI window testing Message-ID: <47AA852E.9030905@cox.net> Its been several months since I worked on the client. Is there still support for a GUI test window? There used to be a hot key available at the splashscreen before login, but either its been taken out (I get crashing type behavior) or I'm using the wrong hot key. Could someone remind me of what it is, if it still exists? Thanks. Lawson From labrat.hb at gmail.com Wed Feb 6 20:22:18 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Feb 6 20:22:25 2008 Subject: [sldev] Command for GUI window testing In-Reply-To: <47AA852E.9030905@cox.net> References: <47AA852E.9030905@cox.net> Message-ID: ctrl-t or command-t for Mac On Feb 6, 2008 8:12 PM, Lawson English wrote: > Its been several months since I worked on the client. Is there still > support for a GUI test window? There used to be a hot key available at > the splashscreen before login, but either its been taken out (I get > crashing type behavior) or I'm using the wrong hot key. > > Could someone remind me of what it is, if it still exists? > > > Thanks. > > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From annagulaev at gmail.com Wed Feb 6 20:57:08 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Wed Feb 6 20:57:11 2008 Subject: [sldev] Command for GUI window testing In-Reply-To: References: <47AA852E.9030905@cox.net> Message-ID: It crashes for me, too. LLFolderView::draw(): if (gToolDragAndDrop->hasMouseCapture()) gToolDragAndDrop is null. Anna On 2/6/08, Harold Brown wrote: > > ctrl-t or command-t for Mac > > On Feb 6, 2008 8:12 PM, Lawson English wrote: > > Its been several months since I worked on the client. Is there still > > support for a GUI test window? There used to be a hot key available at > > the splashscreen before login, but either its been taken out (I get > > crashing type behavior) or I'm using the wrong hot key. > > > > Could someone remind me of what it is, if it still exists? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080206/c8a070c8/attachment.htm From lenglish5 at cox.net Wed Feb 6 23:13:38 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Feb 6 23:13:40 2008 Subject: [sldev] Command for GUI window testing In-Reply-To: References: <47AA852E.9030905@cox.net> Message-ID: <47AAAFA2.3080907@cox.net> Wondering if that is a Mac-specific issue or an issue having to do with the new web login page... Anna Gulaev wrote: > It crashes for me, too. > > LLFolderView::draw(): > > if (gToolDragAndDrop->hasMouseCapture()) > > gToolDragAndDrop is null. > > Anna > > On 2/6/08, *Harold Brown* wrote: > > ctrl-t or command-t for Mac > > On Feb 6, 2008 8:12 PM, Lawson English wrote: > > Its been several months since I worked on the client. Is there still > > support for a GUI test window? There used to be a hot key > available at > > the splashscreen before login, but either its been taken out (I get > > crashing type behavior) or I'm using the wrong hot key. > > > > Could someone remind me of what it is, if it still exists? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Thu Feb 7 02:21:05 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Feb 7 02:21:08 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: <47AA25AE.6080205@lindenlab.com> References: <47A1025B.9080702@lindenlab.com> <47A7545A.4030201@lindenlab.com> <1202246426.3505.98.camel@localhost> <200802052240.08882.dale@daleglass.net> <47AA25AE.6080205@lindenlab.com> Message-ID: On Feb 6, 2008 9:25 PM, Joshua Bell wrote: > > Dale Glass wrote: > > On Tuesday 05 February 2008 22:20:26 Callum Lerwick wrote: > > > >> Well yes, last I tried, I was able to compile without llmozlib. But it > >> left me with a client unable to log in and thus useless. Was "classic > >> login" re-introduced to 1.18.6 or is that in 1.19? > >> > > > > 1.19. > > > > 1.18.6 still has the web stuff, and still doesn't work for me even with > > mozlib. It gets stuck with "loading..." half-visible in the upper left > > corner. > > > Just an explicit reminder: 1.18.6 is a dead, abandoned branch. It won't > ever be released as-is, and no further work or code drops will be done > for it. > > 1.19 is where the fun is now. :) > Is the cmake branch tracking 1.19 at all or doing its own thing?, i noticed a whole new bunch of artwork with the build so I am assuming it has moved on from its initial roots in 1.18.6 will this continue until merge or will this just be used to test out the cmake code? Robin From matthew.dowd at hotmail.co.uk Thu Feb 7 03:26:08 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Feb 7 03:26:10 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: <47A8F528.1010001@watson.ibm.com> References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> <47A8F528.1010001@watson.ibm.com> Message-ID: >> It would appear that slvoice is already 99% open source. > > Huh!? Where? The Vivox SDK (and hence SLVoice) per se is not opensource. However, it looks like the Vivox SDK is basically an API layer over OpenSource SIP stack layers, and OpenSource 3D sound spatialisation libraries (OpenAL) - I think there is a full list of all the components on the wiki. According to the About box in the SL viewer, the codec in use is "Polycom Siren 14 (ITU-T Rec G.772.1 Annex C)" for which there is a reference implementation at http://www.itu.int/rec/T-REC-G.722.1-200505-I/en So, I suspect it is mainly time and energy which are the barriers to a full open source replacement. Matthew _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From tinacloud at gmx.de Thu Feb 7 12:16:25 2008 From: tinacloud at gmx.de (Zi Ree) Date: Thu Feb 7 12:16:31 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <47AA30E2.3040100@lindenlab.com> References: <200802060120.49058.tinacloud@gmx.de> <200802062223.48509.tinacloud@gmx.de> <47AA30E2.3040100@lindenlab.com> Message-ID: <200802072116.25464.tinacloud@gmx.de> Am Mittwoch 06 Februar 2008 schriebst du: (sorry for strange quote formatting but HTML mail is not easy to handle) > It really sounds like this belongs in the same > framework as some of the 'new search' features.? In other words, as has > already been suggested, it should be at > secondlife:///app/ I know there is already > one for showing profiles: > secondlife:///app/agent/0e346d8b-4433-4d66-a6b0-fd37083abc4c/about and I > think it is pretty straight forward to add new ones. Thanks for clarifying, Kelly. I didn't find any documentation on these URLs so I went for my own approach. But I will definitely look into making it fit this scheme. > The code for that one is at the top of llfloateravatarinfo.cpp in the > class LLAgentHandler : public LLCommandHandler.? It would make sense > for the IM code to be implemented similarly.? I personally think that > name -> uuid translation should happen outside the url scheme, that > to keep the interface as clean as possible there shouldn't be a > secondlife:///app/agent/kelly%20linden/ option.? Force the requesting code > to figure out the uuid > first.? Just my opinion though. :) Personally, I would always prefer the UUID over the name as well. So I can try to change the patch to use this. If - and I really mean *if* - I ever get 1.19.0 to build ... :/ It seems you have to re-learn the building process with each new version of the viewer. There's always something else breaking at the linking stage :( > ?- Kelly Zi From monkowsk at watson.ibm.com Thu Feb 7 13:34:29 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Feb 7 13:34:35 2008 Subject: [sldev] SLVoice / Vivox Replacement In-Reply-To: References: <47A84E25.4070509@bernhardrode.de> <1202251948.3505.102.camel@localhost> <47A8F528.1010001@watson.ibm.com> Message-ID: <47AB7965.8050308@watson.ibm.com> Yeah, but without the actual SLVoice.exe source, the pieces are just pieces, they're not SLVoice. Which is to say that it wouldn't be that hard to replace all of the Vivox implementation, but it would be nice to be able to modify parts of it without having to do a complete rewrite. But, as you say, the barriers are mainly time and money, so when someone decides that the hope for open source SLVoice is in vain, then a replacement will be built. Mike Matthew Dowd wrote: > >>>It would appear that slvoice is already 99% open source. >> >>Huh!? Where? > > > The Vivox SDK (and hence SLVoice) per se is not opensource. However, it looks like the Vivox SDK is basically an API layer over OpenSource SIP stack layers, and OpenSource 3D sound spatialisation libraries (OpenAL) - I think there is a full list of all the components on the wiki. > > According to the About box in the SL viewer, the codec in use is "Polycom Siren 14 (ITU-T Rec G.772.1 Annex C)" for which there is a reference implementation at http://www.itu.int/rec/T-REC-G.722.1-200505-I/en > > So, I suspect it is mainly time and energy which are the barriers to a full open source replacement. > > Matthew From soft at lindenlab.com Thu Feb 7 17:12:37 2008 From: soft at lindenlab.com (Soft) Date: Thu Feb 7 17:12:39 2008 Subject: [sldev] Latest windlight builds out of the tin Message-ID: The latest windlight (see sldev-commits mailing list) builds out of the tin on all three platforms, minus gcc-4 issues that will be fixed when next merging from release. Now would be an awesome time to see how it behaves and hurl any build-issue JIRAs our way. From robin.cornelius at gmail.com Fri Feb 8 02:44:50 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Feb 8 02:44:54 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: References: Message-ID: On Feb 8, 2008 1:12 AM, Soft wrote: > The latest windlight (see sldev-commits mailing list) builds out of > the tin on all three platforms, minus gcc-4 issues that will be fixed > when next merging from release. > > Now would be an awesome time to see how it behaves and hurl any > build-issue JIRAs our way. Build seems at least as fine as 1.19.0.0 did, i apply my same (build) patch set all of which I think cmake branch fixes anyway. Running is a different issue, i get an ASSERT on newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is an uninitialized config variable. And it told me my graphics card is pants and no longer up to minimum specification too :-(, which it probably is on my laptop. Robin From Anders at Arnholm.se Fri Feb 8 03:33:35 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Fri Feb 8 03:34:02 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: References: Message-ID: <20080208113335.GH22141@arnholm.se> On Fri, Feb 08, 2008 at 10:44:50AM +0000, Robin Cornelius wrote: > On Feb 8, 2008 1:12 AM, Soft wrote: > > The latest windlight (see sldev-commits mailing list) builds out of > > the tin on all three platforms, minus gcc-4 issues that will be fixed > > when next merging from release. > > > > Now would be an awesome time to see how it behaves and hurl any > > build-issue JIRAs our way. > > Build seems at least as fine as 1.19.0.0 did, i apply my same (build) > patch set all of which I think cmake branch fixes anyway. > > Running is a different issue, i get an ASSERT on > newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is > an uninitialized config variable. Looks like this is tha same as my JIRA VWR-3721. -- 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/20080208/65ed207c/attachment.pgp From soft at lindenlab.com Fri Feb 8 03:37:09 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 8 03:37:11 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: <20080208113335.GH22141@arnholm.se> References: <20080208113335.GH22141@arnholm.se> Message-ID: On Feb 8, 2008 5:33 AM, Anders Arnholm wrote: > On Fri, Feb 08, 2008 at 10:44:50AM +0000, Robin Cornelius wrote: > > On Feb 8, 2008 1:12 AM, Soft wrote: > > > The latest windlight (see sldev-commits mailing list) builds out of > > > the tin on all three platforms, minus gcc-4 issues that will be fixed > > > when next merging from release. > > > > > > Now would be an awesome time to see how it behaves and hurl any > > > build-issue JIRAs our way. > > > > Build seems at least as fine as 1.19.0.0 did, i apply my same (build) > > patch set all of which I think cmake branch fixes anyway. > > > > Running is a different issue, i get an ASSERT on > > newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is > > an uninitialized config variable. > > Looks like this is tha same as my JIRA VWR-3721. It is. The problem was actually a missing xml. That's fixed in the drop coming in this morning's batch, which should appear in an hour or so. From robin.cornelius at gmail.com Fri Feb 8 03:42:06 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Feb 8 03:42:10 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: References: <20080208113335.GH22141@arnholm.se> Message-ID: On Feb 8, 2008 11:37 AM, Soft wrote: > On Feb 8, 2008 5:33 AM, Anders Arnholm wrote: > > On Fri, Feb 08, 2008 at 10:44:50AM +0000, Robin Cornelius wrote: > > > On Feb 8, 2008 1:12 AM, Soft wrote: > > > > The latest windlight (see sldev-commits mailing list) builds out of > > > > the tin on all three platforms, minus gcc-4 issues that will be fixed > > > > when next merging from release. > > > > > > > > Now would be an awesome time to see how it behaves and hurl any > > > > build-issue JIRAs our way. > > > > > > Build seems at least as fine as 1.19.0.0 did, i apply my same (build) > > > patch set all of which I think cmake branch fixes anyway. > > > > > > Running is a different issue, i get an ASSERT on > > > newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is > > > an uninitialized config variable. > > > > Looks like this is tha same as my JIRA VWR-3721. > > It is. The problem was actually a missing xml. That's fixed in the > drop coming in this morning's batch, which should appear in an hour or > so. > Cool, i've worked around it for 5 minutes anyway. I've also noticed there don't seem to be any default environmental settings in the tarballs. My windlight world is very very dark, and there are no presets for sky or water. In fact in app_settings/windlight there is one file but on an official linden release there is a whole bunch of stuff which if i copy to my build makes everything ok. Robin From soft at lindenlab.com Fri Feb 8 03:55:50 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 8 03:55:53 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: <20080208113335.GH22141@arnholm.se> References: <20080208113335.GH22141@arnholm.se> Message-ID: On Feb 8, 2008 5:33 AM, Anders Arnholm wrote: > On Fri, Feb 08, 2008 at 10:44:50AM +0000, Robin Cornelius wrote: > > On Feb 8, 2008 1:12 AM, Soft wrote: > > > The latest windlight (see sldev-commits mailing list) builds out of > > > the tin on all three platforms, minus gcc-4 issues that will be fixed > > > when next merging from release. > > > > > > Now would be an awesome time to see how it behaves and hurl any > > > build-issue JIRAs our way. > > > > Build seems at least as fine as 1.19.0.0 did, i apply my same (build) > > patch set all of which I think cmake branch fixes anyway. > > > > Running is a different issue, i get an ASSERT on > > newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is > > an uninitialized config variable. > > Looks like this is tha same as my JIRA VWR-3721. Oops - I think you meant VWR-4675 From soft at lindenlab.com Fri Feb 8 03:57:51 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 8 03:57:54 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: References: <20080208113335.GH22141@arnholm.se> Message-ID: On Feb 8, 2008 5:42 AM, Robin Cornelius wrote: > > On Feb 8, 2008 11:37 AM, Soft wrote: > > On Feb 8, 2008 5:33 AM, Anders Arnholm wrote: > > > On Fri, Feb 08, 2008 at 10:44:50AM +0000, Robin Cornelius wrote: > > > > On Feb 8, 2008 1:12 AM, Soft wrote: > > > > > The latest windlight (see sldev-commits mailing list) builds out of > > > > > the tin on all three platforms, minus gcc-4 issues that will be fixed > > > > > when next merging from release. > > > > > > > > > > Now would be an awesome time to see how it behaves and hurl any > > > > > build-issue JIRAs our way. > > > > > > > > Build seems at least as fine as 1.19.0.0 did, i apply my same (build) > > > > patch set all of which I think cmake branch fixes anyway. > > > > > > > > Running is a different issue, i get an ASSERT on > > > > newview/lldrawpoolwlsky.cpp(177) because i assume star_brightness is > > > > an uninitialized config variable. > > > > > > Looks like this is tha same as my JIRA VWR-3721. > > > > It is. The problem was actually a missing xml. That's fixed in the > > drop coming in this morning's batch, which should appear in an hour or > > so. > > > > Cool, i've worked around it for 5 minutes anyway. > > I've also noticed there don't seem to be any default environmental > settings in the tarballs. My windlight world is very very dark, and > there are no presets for sky or water. In fact in > app_settings/windlight there is one file but on an official linden > release there is a whole bunch of stuff which if i copy to my build > makes everything ok. Right, that's it exactly. I've built this set out of a clean checkout with app settings and all wiped, and it looks fine on Linux and Windows. Mac should be fine too. From robin.cornelius at gmail.com Fri Feb 8 06:47:37 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Feb 8 06:47:40 2008 Subject: [sldev] Latest windlight builds out of the tin In-Reply-To: References: <20080208113335.GH22141@arnholm.se> Message-ID: On Feb 8, 2008 11:57 AM, Soft wrote: > Right, that's it exactly. > > I've built this set out of a clean checkout with app settings and all > wiped, and it looks fine on Linux and Windows. Mac should be fine too. > Ack, the linux standalone build of windlight (+ me wee patches) is looking good ;-) For the record i'm applying the following patches for a minimum build on a standalone configuration :- * VWR-2488 (fixed in cmake branch) * VWR-2739 (fixed in cmake branch) * VWR-3813 (debian uses newer gtk than lindens) * an expat.h headers location fix (fixed in cmake branch) * an arp.h headers location patch (fixed in cmake branch) * some fudging of my shared library llmozlib * VWR-3480 c-ares v 1.5.1 workaround * openjpeg.h location patch (fixed in cmake branch) *VWR-1853, use linux fonts patch to avoid copyright/nonfree fonts (we still need sensible linux free fallback fonts that work out of the box). All these issues effect builds on all branches anyway, except cmake, which fixes a few. Some header locations are Debian only as well. I apply other patches too, but these above are minimum to enable build and login to world. Robin From thomas.shikami at online.de Fri Feb 8 09:11:00 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Fri Feb 8 09:11:05 2008 Subject: [sldev] Ban proof client? In-Reply-To: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> Message-ID: <47AC8D24.4040900@online.de> elio@magetech.com wrote: > Strange question perhaps, but is anyone aware of a client hack which would > make an AV impervious to estate management tools (boot) > no, there is no way for a client to prevent forced teleports, it would rather be disconnected > On several occasions over past few months, I have noticed that AV's I've > had to ban DO NOT go away when I add them to the estate banned list. > > Is this simply an intermittent annoyance for some unknown reason, or a > client hack I'll have to develop tools to fight? > The reason for this is well known, if the home simulator of an avatar is not available, banning an avatar on the estate ban list doesn't teleport them home, neither kicking the user from estate works. The thing that works it to teleport home from the region tab of the estate tools, it will then send the avatar to on of the info hubs From sldev at free.fr Fri Feb 8 09:15:40 2008 From: sldev at free.fr (Henri Beauchamp) Date: Fri Feb 8 09:15:51 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! Message-ID: <20080208181540.3c097f5d.sldev@free.fr> It is really hard, these days to publish alternative viewers, because the sources for the released versions by LL are NOT made available. Please, do publish the sources for the released versions (RC and Windlight as well) ! The week-end is coming, which is the best time for us open source folks to patch and compile... and I fear this week-end will be again fruitless. :-( From lenglish5 at cox.net Fri Feb 8 09:17:13 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Feb 8 09:17:21 2008 Subject: [BUG]Re: [sldev] Command for GUI window testing In-Reply-To: <47AAAFA2.3080907@cox.net> References: <47AA852E.9030905@cox.net> <47AAAFA2.3080907@cox.net> Message-ID: <47AC8E99.7070901@cox.net> Can anyone confirm that this is either a Mac only issue, or that it affects PCs and Linux as well? I'll write it up as a jira for Mac-only but it seems likely that PC's should be affected also, unless its another one of those odd #def issues where the wrong bit of code has been commented out for a specific platform. Lawson Lawson English wrote: > Wondering if that is a Mac-specific issue or an issue having to do > with the new web login page... > > Anna Gulaev wrote: >> It crashes for me, too. >> >> LLFolderView::draw(): >> >> if (gToolDragAndDrop->hasMouseCapture()) >> >> gToolDragAndDrop is null. >> >> Anna >> >> On 2/6/08, *Harold Brown* wrote: >> >> ctrl-t or command-t for Mac >> >> On Feb 6, 2008 8:12 PM, Lawson English wrote: >> > Its been several months since I worked on the client. Is there >> still >> > support for a GUI test window? There used to be a hot key >> available at >> > the splashscreen before login, but either its been taken out (I >> get >> > crashing type behavior) or I'm using the wrong hot key. >> > >> > Could someone remind me of what it is, if it still exists? >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Anders at Arnholm.se Fri Feb 8 09:20:28 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Fri Feb 8 09:22:51 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: <20080208181540.3c097f5d.sldev@free.fr> References: <20080208181540.3c097f5d.sldev@free.fr> Message-ID: <47AC8F5C.8010000@Arnholm.se> Henri Beauchamp skrev: > It is really hard, these days to publish alternative viewers, because > the sources for the released versions by LL are NOT made available. > > Please, do publish the sources for the released versions (RC and Windlight > as well) ! > > The week-end is coming, which is the best time for us open source folks > to patch and compile... and I fear this week-end will be again fruitless. > :-( I know your frustration, but a light is that tah latest svn drop of windlight finallly makes a viewer that can connect and run without crashing. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From labrat.hb at gmail.com Fri Feb 8 09:25:58 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Feb 8 09:26:01 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: <20080208181540.3c097f5d.sldev@free.fr> References: <20080208181540.3c097f5d.sldev@free.fr> Message-ID: Well, considering they are now following a policy of making sure that the sources released to Open Source developers will actually compile and result in a working build on all three platforms. I'd expect their to be delays in the release of the code. Now I'm sure they could go back to the old method of just dumping a source package... but I'm sure we would be hearing all about how it doesn't build right or is missing files. Of the two options. I think I can live with the waiting a day or two. If your clients are getting locked out due to a version check. You need to change the channel your client reports to SL (which you should have already been doing since it isn't an official build) On Feb 8, 2008 9:15 AM, Henri Beauchamp wrote: > It is really hard, these days to publish alternative viewers, because > the sources for the released versions by LL are NOT made available. > > Please, do publish the sources for the released versions (RC and Windlight > as well) ! > > The week-end is coming, which is the best time for us open source folks > to patch and compile... and I fear this week-end will be again fruitless. > :-( > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tulla at lindenlab.com Fri Feb 8 09:43:57 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi)) Date: Fri Feb 8 09:44:07 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: References: <20080208181540.3c097f5d.sldev@free.fr> Message-ID: <47AC94DD.8020107@lindenlab.com> Harold Brown wrote: > If your clients are getting locked out due to a version check. You > need to change the channel your client reports to SL (which you should > have already been doing since it isn't an official build) > Yes, if you are building your own version that is different in any way, please change the channel. Otherwise some of our report generating tools will have incorrect data in them. :) Thanks! From tinacloud at gmx.de Fri Feb 8 11:26:49 2008 From: tinacloud at gmx.de (Zi Ree) Date: Fri Feb 8 11:26:53 2008 Subject: [sldev] [Patch] Clicking on names in Chat/Group IM In-Reply-To: <200802072116.25464.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> <47AA30E2.3040100@lindenlab.com> <200802072116.25464.tinacloud@gmx.de> Message-ID: <200802082026.49386.tinacloud@gmx.de> Am Donnerstag 07 Februar 2008 schrieb Zi Ree: New patch on Jira https://jira.secondlife.com/browse/VWR-4204 This one applies to 1.19.0 release candidate. I changed the way it works to use the URL schemes: secondlife:///app/agent//about - Opens Profile secondlife:///app/agent//im - Opens IM secondlife:///app/agent//lure - Offers Teleport Please comment :) Especially on how best to verify a UUID. Thanks for the useful hints on the previous patch! Zi! From robla at lindenlab.com Fri Feb 8 11:39:26 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 8 11:39:37 2008 Subject: [sldev] Documenting secondlife: protocol scheme (Re: [Patch] Clicking on names in Chat/Group IM) In-Reply-To: <200802072116.25464.tinacloud@gmx.de> References: <200802060120.49058.tinacloud@gmx.de> <200802062223.48509.tinacloud@gmx.de> <47AA30E2.3040100@lindenlab.com> <200802072116.25464.tinacloud@gmx.de> Message-ID: <47ACAFEE.3030307@lindenlab.com> Any volunteers for documenting the secondlife: URI scheme based on this thread? In poking around, this seems like the most appropriate place to put this (or at least link to it): http://wiki.secondlife.com/wiki/SLURL ..but of course there are many places where inbound links would be appropriate (such as the "Protocol" page) Rob On 2/7/08 12:16 PM, Zi Ree wrote: > Am Mittwoch 06 Februar 2008 schriebst du: > > (sorry for strange quote formatting but HTML mail is not easy to handle) > > >> It really sounds like this belongs in the same >> framework as some of the 'new search' features. In other words, as has >> already been suggested, it should be at >> secondlife:///app/ I know there is already >> one for showing profiles: >> secondlife:///app/agent/0e346d8b-4433-4d66-a6b0-fd37083abc4c/about and I >> think it is pretty straight forward to add new ones. >> > > Thanks for clarifying, Kelly. I didn't find any documentation on these URLs so > I went for my own approach. But I will definitely look into making it fit > this scheme. > > >> The code for that one is at the top of llfloateravatarinfo.cpp in the >> class LLAgentHandler : public LLCommandHandler. It would make sense >> for the IM code to be implemented similarly. I personally think that >> name -> uuid translation should happen outside the url scheme, that >> to keep the interface as clean as possible there shouldn't be a >> secondlife:///app/agent/kelly%20linden/ option. Force the requesting code >> to figure out the uuid >> first. Just my opinion though. :) >> > > Personally, I would always prefer the UUID over the name as well. So I can try > to change the patch to use this. If - and I really mean *if* - I ever get > 1.19.0 to build ... :/ It seems you have to re-learn the building process > with each new version of the viewer. There's always something else breaking > at the linking stage :( > > >> - Kelly >> > > Zi > _______________________________________________ > 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/20080208/f5593fac/signature.pgp From soft at lindenlab.com Fri Feb 8 12:00:23 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 8 12:00:25 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: <20080208181540.3c097f5d.sldev@free.fr> References: <20080208181540.3c097f5d.sldev@free.fr> Message-ID: On Feb 8, 2008 11:15 AM, Henri Beauchamp wrote: > It is really hard, these days to publish alternative viewers, because > the sources for the released versions by LL are NOT made available. > > Please, do publish the sources for the released versions (RC and Windlight > as well) ! > > The week-end is coming, which is the best time for us open source folks > to patch and compile... and I fear this week-end will be again fruitless. > :-( Henri, please grab the tarballes linked at the bottom of this commit message: https://lists.secondlife.com/pipermail/sldev-commits/2008-February/000405.html Right now, the RC branches are the only ones that get tested on all platforms. We're working to get QA in on testing the source drops that happen closest to first look releases, but we're not there yet. If you're tracking anything but RCs, you'll do better to watch the sldev-commits mailing list than the wiki page. From ettore_pasquini at 3dconnexion.com Fri Feb 8 12:03:25 2008 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Fri Feb 8 12:03:42 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: Message-ID: I for one prefer the new method as well. Source releases compile much smoother now than before: waiting a few days is totally worth that. About RC1: isn't it sufficient to just do a svn update on Branch_1-19-0-Viewer ? I noticed the version number increased from 1.19.0.0 (rev 220) to 1.19.0.1 (rev 228) Ettore On 2/8/08 9:25 AM, "Harold Brown" wrote: > Well, considering they are now following a policy of making sure that > the sources released to Open Source developers will actually compile > and result in a working build on all three platforms. I'd expect > their to be delays in the release of the code. > > Now I'm sure they could go back to the old method of just dumping a > source package... but I'm sure we would be hearing all about how it > doesn't build right or is missing files. > > Of the two options. I think I can live with the waiting a day or two. > If your clients are getting locked out due to a version check. You > need to change the channel your client reports to SL (which you should > have already been doing since it isn't an official build) > > On Feb 8, 2008 9:15 AM, Henri Beauchamp wrote: >> It is really hard, these days to publish alternative viewers, because >> the sources for the released versions by LL are NOT made available. >> >> Please, do publish the sources for the released versions (RC and Windlight >> as well) ! >> >> The week-end is coming, which is the best time for us open source folks >> to patch and compile... and I fear this week-end will be again fruitless. >> :-( >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- http://www.3dconnexion.com/ From soft at lindenlab.com Fri Feb 8 12:04:34 2008 From: soft at lindenlab.com (Soft) Date: Fri Feb 8 12:04:47 2008 Subject: [sldev] Ban proof client? In-Reply-To: <47AC8D24.4040900@online.de> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> Message-ID: On Feb 8, 2008 11:11 AM, Thomas Shikami wrote: > > > The reason for this is well known, if the home simulator of an avatar is > not available, banning an avatar on the estate ban list doesn't teleport > them home, neither kicking the user from estate works. The thing that > works it to teleport home from the region tab of the estate tools, it > will then send the avatar to on of the info hubs First I've heard - do you know if there's a JIRA for this? I'll import it directly if there is - it sounds exploitable. From lenglish5 at cox.net Fri Feb 8 12:54:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Feb 8 12:54:57 2008 Subject: [BUG]Re: [sldev] Command for GUI window testing In-Reply-To: <47AC8E99.7070901@cox.net> References: <47AA852E.9030905@cox.net> <47AAAFA2.3080907@cox.net> <47AC8E99.7070901@cox.net> Message-ID: <47ACC19F.20204@cox.net> And so I did: https://jira.secondlife.com/browse/VWR-4726 Ctrl-T/Cmd-T no longer evokes a test GUI floater at startup screen Expected behavior: Cntrol-T or CMD-T at login screen would evoke a test GUI floater, allowing one to test GUI elements without having to take the time to log in Actual behavior: varies by platform, but the floater doesn't seem to appear in any of them. Lawson English wrote: > Can anyone confirm that this is either a Mac only issue, or that it > affects PCs and Linux as well? > > I'll write it up as a jira for Mac-only but it seems likely that PC's > should be affected also, unless its another one of those odd #def > issues where the wrong bit of code has been commented out for a > specific platform. > > Lawson > > > Lawson English wrote: >> Wondering if that is a Mac-specific issue or an issue having to do >> with the new web login page... >> >> Anna Gulaev wrote: >>> It crashes for me, too. >>> >>> LLFolderView::draw(): >>> >>> if (gToolDragAndDrop->hasMouseCapture()) >>> >>> gToolDragAndDrop is null. >>> >>> Anna >>> >>> On 2/6/08, *Harold Brown* wrote: >>> >>> ctrl-t or command-t for Mac >>> >>> On Feb 6, 2008 8:12 PM, Lawson English wrote: >>> > Its been several months since I worked on the client. Is there >>> still >>> > support for a GUI test window? There used to be a hot key >>> available at >>> > the splashscreen before login, but either its been taken out >>> (I get >>> > crashing type behavior) or I'm using the wrong hot key. >>> > >>> > Could someone remind me of what it is, if it still exists? >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> 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 bos at lindenlab.com Fri Feb 8 13:10:06 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Feb 8 13:10:56 2008 Subject: [sldev] CMake preview available - please try it out! In-Reply-To: References: <47A1025B.9080702@lindenlab.com> <47A7545A.4030201@lindenlab.com> <1202246426.3505.98.camel@localhost> <200802052240.08882.dale@daleglass.net> <47AA25AE.6080205@lindenlab.com> Message-ID: <47ACC52E.6030807@lindenlab.com> Robin Cornelius wrote: > Is the cmake branch tracking 1.19 at all or doing its own thing? It tracks our release branch. References: <47A84E25.4070509@bernhardrode.de> Message-ID: <47ACC698.1000808@watson.ibm.com> Bernhard Rode wrote: > Hello to the list, > I just read the Wiki about SL Voice and the Vivox Client. > > I wonder if there are any plans / projects out there to replace the > SLVoice Vivox client. > > As far as I understand the current situation, it should be possible to > use any external SIP gateway which is able to set up Sessions. > > I mean their are many open sourced sip projects out there, which may be > used. On Wikipedia ( http://en.wikipedia.org/wiki/Comparison_of_VoIP_software ) I see two open source VoIP systems listed that run on MS Windows, Mac OSX, and Linux: Coccinella and WengoPhone, but Coccinella ( http://thecoccinella.org/ ) doesn't look like a VoIP system. So it looks like WengoPhone ( http://www.openwengo.org/ ) is the only cross platform open source system. Are you aware of others? Any experience with WengoPhone? Mike From annagulaev at gmail.com Fri Feb 8 14:07:14 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri Feb 8 14:07:17 2008 Subject: [BUG]Re: [sldev] Command for GUI window testing In-Reply-To: <47AC8E99.7070901@cox.net> References: <47AA852E.9030905@cox.net> <47AAAFA2.3080907@cox.net> <47AC8E99.7070901@cox.net> Message-ID: It is not a Mac-only issue. The report I posted was from running it on a PC. On 2/8/08, Lawson English wrote: > > Can anyone confirm that this is either a Mac only issue, or that it > affects PCs and Linux as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080208/19cbbabf/attachment.htm From tateru.nino at gmail.com Fri Feb 8 23:26:18 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Feb 8 23:28:52 2008 Subject: [sldev] Ban proof client? In-Reply-To: References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> Message-ID: <47AD559A.2020803@weblogsinc.com> Soft wrote: > On Feb 8, 2008 11:11 AM, Thomas Shikami wrote: > >> The reason for this is well known, if the home simulator of an avatar is >> not available, banning an avatar on the estate ban list doesn't teleport >> them home, neither kicking the user from estate works. The thing that >> works it to teleport home from the region tab of the estate tools, it >> will then send the avatar to on of the info hubs >> > > First I've heard - do you know if there's a JIRA for this? I'll import > it directly if there is - it sounds exploitable. > I know a number of people who sent this in via the exploit reporting mechanism in the pre-PJIRA days. I know I've assumed that as a result it was already in *your* JIRA. -- Tateru Nino http://www.massively.com/ From sldev at free.fr Sat Feb 9 00:26:41 2008 From: sldev at free.fr (Henri Beauchamp) Date: Sat Feb 9 00:26:43 2008 Subject: [sldev] Sources, please ! Windlight 79185 and v1.19.0.RC1still not published ! In-Reply-To: References: <20080208181540.3c097f5d.sldev@free.fr> Message-ID: <20080209092641.74d8a02c.sldev@free.fr> On Fri, 8 Feb 2008 14:00:23 -0600, Soft wrote: > On Feb 8, 2008 11:15 AM, Henri Beauchamp wrote: > > It is really hard, these days to publish alternative viewers, because > > the sources for the released versions by LL are NOT made available. > > > > Please, do publish the sources for the released versions (RC and Windlight > > as well) ! > > > > The week-end is coming, which is the best time for us open source folks > > to patch and compile... and I fear this week-end will be again fruitless. > > :-( > > Henri, please grab the tarballes linked at the bottom of this commit message: > https://lists.secondlife.com/pipermail/sldev-commits/2008-February/000405.html > > Right now, the RC branches are the only ones that get tested on all > platforms. We're working to get QA in on testing the source drops that > happen closest to first look releases, but we're not there yet. If > you're tracking anything but RCs, you'll do better to watch the > sldev-commits mailing list than the wiki page. The problem is that with this method, I can't know what commit corresponds to the _official_ release (official RC, official Windlight) and may end up picking up the wrong tarballs: my alternative viewer is supposed (and so far proved) to have less bugs than LL's, and I don't want to end up with more bugs because I picked up the wrong commit in the SVN (either an older one with less bug fixed or a newer one with new bugs)... So, could you at least make a commit for each official release in each branch (including WL and RC) and then tell us on this list and/or on the Wiki which commit corresponds to which release, please ? Henri. http://sldev.free.fr/ From gbrandon at gmail.com Sat Feb 9 04:51:09 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Sat Feb 9 04:51:11 2008 Subject: [sldev] Inventory Predicament Message-ID: Inventory Predicament It started a few months ago... After letting the ~13,500 items of my inventory fetch, opening the texture picker or resident picker, or opening a second inventory window, would cause my viewer to freeze. Everything was fine until a certain amount of inventory fetching was done. Also, if I didn't clear my cache before attempting to log in again, the freeze would happen during the login process. So I got in the habit of hitting the 'clear cache' button every time after logging in, to make sure I didn't have to run the viewer twice next time I wanted to log in. And I got in the habit of not being able to use the texture picker and resident picker. Being a lowly Basic member, I don't have access to support, so I filed a JIRA issue, but of course the issue was unique to me, so I eventually marked it "more information needed" and closed it. In connection with a viewer exploit involving inventory transfers, I had the opportunity of a generous Linden taking a look at my inventory, and he removed some troublesome top-level folders. But the problems never went away. Several months passed :O Tonight I had the opportunity to try the Second Inventory viewer. It turned out to be alot more featured than I expected. But when I loaded my 'Objects' folder, it threw about 100 dialogs saying I had a bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was not a folder. Now, I had a UUID. In the Second Life viewer's cache folder, there's a .gz file with a text file inside for caching your inventory. I decided to search the file for that UUID and see if I could figure out what was up. The first occurrence was: inv_category 0 { cat_id ce5da405-26d2-4004-a01c-56a3ced4d68a parent_id d2ed5dee-3801-46f6-8d8a-1f01133b2673 type category pref_type object name Objects| owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 version 11395 } That's my Objects folder. And indeed, all of the objects inside had it as their parent_id. But since the Second Life viewer and Second Inventory were, in fact, able to show all the items in my Objects folder, that didn't make sense of anything to me. I kept looking, and eventually found this item: inv_item 0 { item_id ce5da405-26d2-4004-a01c-56a3ced4d68a parent_id ce5da405-26d2-4004-a01c-56a3ced4d68a permissions 0 { base_mask 7fffffff owner_mask 7fffffff group_mask 00000000 everyone_mask 00000000 next_owner_mask 00082000 creator_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 last_owner_id 00000000-0000-0000-0000-000000000000 group_id 00000000-0000-0000-0000-000000000000 } asset_id 00000000-0000-0000-0000-000000000000 type object inv_type object flags 00000000 sale_info 0 { sale_type not sale_price 10 } name Object| desc (No Description)| creation_date 1195342436 } Amazing, it has the same UUID as the folder it's in, and must be the problem item. So I loaded up the Second Life viewer, fetched my inventory, and did a search for "Object." Unfortunately, I couldn't see the object. So, at this point, being an overenthusiastic slproxy user, I start thinking maybe I can figure out how to delete an inventory item by injecting a packet, and hopefully it doesn't work by UUID alone. I look through http://wiki.secondlife.com/wiki/Category:Messages for messages having to do with inventory, and log them while doing some tests with moving and deleting inventory items. I find I have two options: RemoveInventoryItem http://wiki.secondlife.com/wiki/RemoveInventoryItem Purge a single inventory item, given its UUID. MoveInventoryItem http://wiki.secondlife.com/wiki/MoveInventoryItem Move an inventory item, given its UUID, to another folder, given its UUID, with an optional new name. Since RemoveInventoryItem takes only a UUID, I'm too nervous to use it right away with a UUID that represents both the problem item and my Objects folder, even though there is a separate message, RemoveInventoryFolder, for purging a folder. I mean, behind-the-scenes, what if the database operation just uses the UUID alone, and purges my Objects folder >_< And obviously, the UUID is enough to cause problems with the viewer. So I use slproxy to send a MoveInventoryItem packet condemning ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder. [4:04] Analyst: failed to inject fix: Object reference not set to an instance of an object. I guess it won't let me inject the packet without it mentioning the NewName parameter, and I'm not sure if using an empty string will have the desired effect, so I add NewName = TROUBLE to the packet and inject again. No feedback... No item visibly in my Trash... I right-click my Trash and empty it, and verify that the viewer sent a PurgeInventoryDescendents packet, for purging its contents. God, I hope I did it! Clicked the clear cache button, logged out, logged back in, and let my inventory fetch. I am relieved to see I still have an Objects folder, with objects in it. I rez some of them while waiting for the fetching to be over. The fetching is over. I create an object and click the Texture box... the viewer stops... But after about five seconds... IT WORKS!! THE TEXTURE PICKER!! How I'd missed it ;__; I close and open the texture picker again and again! I use New Window on my inventory... it takes about 15 seconds, but it worked! I open the parcel options and click Add next to the ban list... after six seconds, it worked!! Finally, I logged out without clicking 'clear cache' first, and log back in. Z-O-M-G, I am logged in and I already have everything fetched. I am hugging slproxy. So my question is, how did this happen? :D Can we fix the bug in the viewer that made this SUCH a problem? And is there any danger of my Objects folder being garbage-collected, now? ;__; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/dab85fda/attachment.htm From timelessprototype at gmail.com Sat Feb 9 05:24:37 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Sat Feb 9 05:24:32 2008 Subject: [sldev] Inventory Predicament In-Reply-To: References: Message-ID: <47ADA995.50208@gmail.com> Wow, very cool. My Timeless Prototype avatar is no longer usable, I have missing assets and whenever a friend comes online (regardless of notify option) it locks up the SL viewer for about 5 seconds (ie. absolutely nothing moves on the screen, not even the mouse). With the number of friends I have it's impossible to do anything with this fault. All other applications are fine, even SL voice continues happily whilst this happens. I too am on a basic account with no phone support. I've managed to log on and do some very basic maintenance, even though extremely painful, but I'm afraid it's the end of SL for me unless this can get fixed. The problem only started with the latest Windlight and RC viewers. The "stable" viewer has other issues for me, such as the huge delay whilst logging on, resulting in a nice faceplant and failure to load my avatar. My alts log on just fine, no issues whatsoever with those. I refuse to buy a sim just so I can report a fault with my one avatar's inventory via phone. Just like you, Jira has proved absolutely useless to me for reporting a bug that relates only to my situation. - Timeless Brandon Lockaby wrote: > Inventory Predicament > > It started a few months ago... After letting the ~13,500 items of my > inventory fetch, opening the texture picker or resident picker, or > opening a second inventory window, would cause my viewer to freeze. > Everything was fine until a certain amount of inventory fetching was > done. Also, if I didn't clear my cache before attempting to log in > again, the freeze would happen during the login process. So I got in > the habit of hitting the 'clear cache' button every time after logging > in, to make sure I didn't have to run the viewer twice next time I > wanted to log in. And I got in the habit of not being able to use the > texture picker and resident picker. > > Being a lowly Basic member, I don't have access to support, so I filed > a JIRA issue, but of course the issue was unique to me, so I > eventually marked it "more information needed" and closed it. > > In connection with a viewer exploit involving inventory transfers, I > had the opportunity of a generous Linden taking a look at my > inventory, and he removed some troublesome top-level folders. But the > problems never went away. > > Several months passed :O > > Tonight I had the opportunity to try the Second Inventory viewer. It > turned out to be alot more featured than I expected. But when I > loaded my 'Objects' folder, it threw about 100 dialogs saying I had a > bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was not > a folder. > > Now, I had a UUID. > > In the Second Life viewer's cache folder, there's a key>.gz file with a text file inside for caching your inventory. I > decided to search the file for that UUID and see if I could figure out > what was up. The first occurrence was: > > inv_category 0 > { > cat_id ce5da405-26d2-4004-a01c-56a3ced4d68a > parent_id d2ed5dee-3801-46f6-8d8a-1f01133b2673 > type category > pref_type object > name Objects| > owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 > version 11395 > } > > That's my Objects folder. And indeed, all of the objects inside had > it as their parent_id. But since the Second Life viewer and Second > Inventory were, in fact, able to show all the items in my Objects > folder, that didn't make sense of anything to me. I kept looking, and > eventually found this item: > > inv_item 0 > { > item_id ce5da405-26d2-4004-a01c-56a3ced4d68a > parent_id ce5da405-26d2-4004-a01c-56a3ced4d68a > permissions 0 > { > base_mask 7fffffff > owner_mask 7fffffff > group_mask 00000000 > everyone_mask 00000000 > next_owner_mask 00082000 > creator_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 > owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 > last_owner_id 00000000-0000-0000-0000-000000000000 > group_id 00000000-0000-0000-0000-000000000000 > } > asset_id 00000000-0000-0000-0000-000000000000 > type object > inv_type object > flags 00000000 > sale_info 0 > { > sale_type not > sale_price 10 > } > name Object| > desc (No Description)| > creation_date 1195342436 > } > > Amazing, it has the same UUID as the folder it's in, and must be the > problem item. So I loaded up the Second Life viewer, fetched my > inventory, and did a search for "Object." > > Unfortunately, I couldn't see the object. > > So, at this point, being an overenthusiastic slproxy user, I start > thinking maybe I can figure out how to delete an inventory item by > injecting a packet, and hopefully it doesn't work by UUID alone. I > look through http://wiki.secondlife.com/wiki/Category:Messages for > messages having to do with inventory, and log them while doing some > tests with moving and deleting inventory items. > > I find I have two options: > > RemoveInventoryItem > http://wiki.secondlife.com/wiki/RemoveInventoryItem > Purge a single inventory item, given its UUID. > > MoveInventoryItem > http://wiki.secondlife.com/wiki/MoveInventoryItem > Move an inventory item, given its UUID, to another folder, given its > UUID, with an optional new name. > > Since RemoveInventoryItem takes only a UUID, I'm too nervous to use it > right away with a UUID that represents both the problem item and my > Objects folder, even though there is a separate message, > RemoveInventoryFolder, for purging a folder. I mean, > behind-the-scenes, what if the database operation just uses the UUID > alone, and purges my Objects folder >_< And obviously, the UUID is > enough to cause problems with the viewer. > > So I use slproxy to send a MoveInventoryItem packet condemning > ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder. > > [4:04] Analyst: failed to inject fix: Object reference not set to an > instance of an object. > > I guess it won't let me inject the packet without it mentioning the > NewName parameter, and I'm not sure if using an empty string will have > the desired effect, so I add NewName = TROUBLE to the packet and > inject again. > > No feedback... No item visibly in my Trash... > > I right-click my Trash and empty it, and verify that the viewer sent a > PurgeInventoryDescendents packet, for purging its contents. God, I > hope I did it! > > Clicked the clear cache button, logged out, logged back in, and let my > inventory fetch. I am relieved to see I still have an Objects folder, > with objects in it. I rez some of them while waiting for the fetching > to be over. > > The fetching is over. I create an object and click the Texture box... > the viewer stops... > > But after about five seconds... IT WORKS!! THE TEXTURE PICKER!! How > I'd missed it ;__; I close and open the texture picker again and > again! I use New Window on my inventory... it takes about 15 seconds, > but it worked! I open the parcel options and click Add next to the > ban list... after six seconds, it worked!! > > Finally, I logged out without clicking 'clear cache' first, and log > back in. Z-O-M-G, I am logged in and I already have everything > fetched. I am hugging slproxy. > > So my question is, how did this happen? :D > > Can we fix the bug in the viewer that made this SUCH a problem? > > And is there any danger of my Objects folder being garbage-collected, > now? ;__; > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gbrandon at gmail.com Sat Feb 9 05:30:55 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Sat Feb 9 05:30:58 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADA995.50208@gmail.com> References: <47ADA995.50208@gmail.com> Message-ID: There's more... for the first time with 1.19, I have a friends list! :O -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/c339fcb4/attachment.htm From timelessprototype at gmail.com Sat Feb 9 05:48:50 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Sat Feb 9 05:48:46 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADAA44.5060308@weblogsinc.com> References: <47ADA995.50208@gmail.com> <47ADAA44.5060308@weblogsinc.com> Message-ID: <47ADAF42.1070103@gmail.com> Tateru, you're my official life saver! Forever in your debt. I moved all my chat logs (~32MB) to an archive folder, logged on and re-enabled all chat log options. I can now function without the screen freezes in Windlight viewer (don't really care about the other viewers). Thank you. Thank you. Thank you. XD - Timeless Tateru Nino wrote: > > > Timeless Prototype wrote: >> Wow, very cool. >> >> My Timeless Prototype avatar is no longer usable, I have missing >> assets and whenever a friend comes online (regardless of notify >> option) it locks up the SL viewer for about 5 seconds (ie. absolutely >> nothing moves on the screen, not even the mouse). With the number of >> friends I have it's impossible to do anything with this fault. All >> other applications are fine, even SL voice continues happily whilst >> this happens. > Just wondering - do you have chat-logging enabled, and where're the > log files going to? I had a problem with lockups when friends went > online/offline and when certain people sent me an IM. Turned out that > in the wake of a power-flutter at some point, the chat/IM log files > had been left in a locked state. > > I've also seen degenerate behavior when the system is trying to log to > an inaccessible path. >> >> I too am on a basic account with no phone support. I've managed to >> log on and do some very basic maintenance, even though extremely >> painful, but I'm afraid it's the end of SL for me unless this can get >> fixed. The problem only started with the latest Windlight and RC >> viewers. The "stable" viewer has other issues for me, such as the >> huge delay whilst logging on, resulting in a nice faceplant and >> failure to load my avatar. My alts log on just fine, no issues >> whatsoever with those. >> >> I refuse to buy a sim just so I can report a fault with my one >> avatar's inventory via phone. Just like you, Jira has proved >> absolutely useless to me for reporting a bug that relates only to my >> situation. >> >> - Timeless >> >> Brandon Lockaby wrote: >>> Inventory Predicament >>> >>> It started a few months ago... After letting the ~13,500 items of >>> my inventory fetch, opening the texture picker or resident picker, >>> or opening a second inventory window, would cause my viewer to >>> freeze. Everything was fine until a certain amount of inventory >>> fetching was done. Also, if I didn't clear my cache before >>> attempting to log in again, the freeze would happen during the login >>> process. So I got in the habit of hitting the 'clear cache' button >>> every time after logging in, to make sure I didn't have to run the >>> viewer twice next time I wanted to log in. And I got in the habit >>> of not being able to use the texture picker and resident picker. >>> >>> Being a lowly Basic member, I don't have access to support, so I >>> filed a JIRA issue, but of course the issue was unique to me, so I >>> eventually marked it "more information needed" and closed it. >>> >>> In connection with a viewer exploit involving inventory transfers, I >>> had the opportunity of a generous Linden taking a look at my >>> inventory, and he removed some troublesome top-level folders. But >>> the problems never went away. >>> >>> Several months passed :O >>> >>> Tonight I had the opportunity to try the Second Inventory viewer. >>> It turned out to be alot more featured than I expected. But when I >>> loaded my 'Objects' folder, it threw about 100 dialogs saying I had >>> a bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was >>> not a folder. >>> >>> Now, I had a UUID. >>> >>> In the Second Life viewer's cache folder, there's a >> key>.gz file with a text file inside for caching your inventory. I >>> decided to search the file for that UUID and see if I could figure >>> out what was up. The first occurrence was: >>> >>> inv_category 0 >>> { >>> cat_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>> parent_id d2ed5dee-3801-46f6-8d8a-1f01133b2673 >>> type category >>> pref_type object >>> name Objects| >>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>> version 11395 >>> } >>> >>> That's my Objects folder. And indeed, all of the objects inside had >>> it as their parent_id. But since the Second Life viewer and Second >>> Inventory were, in fact, able to show all the items in my Objects >>> folder, that didn't make sense of anything to me. I kept looking, >>> and eventually found this item: >>> >>> inv_item 0 >>> { >>> item_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>> parent_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>> permissions 0 >>> { >>> base_mask 7fffffff >>> owner_mask 7fffffff >>> group_mask 00000000 >>> everyone_mask 00000000 >>> next_owner_mask 00082000 >>> creator_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>> last_owner_id 00000000-0000-0000-0000-000000000000 >>> group_id 00000000-0000-0000-0000-000000000000 >>> } >>> asset_id 00000000-0000-0000-0000-000000000000 >>> type object >>> inv_type object >>> flags 00000000 >>> sale_info 0 >>> { >>> sale_type not >>> sale_price 10 >>> } >>> name Object| >>> desc (No Description)| >>> creation_date 1195342436 >>> } >>> >>> Amazing, it has the same UUID as the folder it's in, and must be the >>> problem item. So I loaded up the Second Life viewer, fetched my >>> inventory, and did a search for "Object." >>> >>> Unfortunately, I couldn't see the object. >>> >>> So, at this point, being an overenthusiastic slproxy user, I start >>> thinking maybe I can figure out how to delete an inventory item by >>> injecting a packet, and hopefully it doesn't work by UUID alone. I >>> look through http://wiki.secondlife.com/wiki/Category:Messages for >>> messages having to do with inventory, and log them while doing some >>> tests with moving and deleting inventory items. >>> >>> I find I have two options: >>> >>> RemoveInventoryItem >>> http://wiki.secondlife.com/wiki/RemoveInventoryItem >>> Purge a single inventory item, given its UUID. >>> >>> MoveInventoryItem >>> http://wiki.secondlife.com/wiki/MoveInventoryItem >>> Move an inventory item, given its UUID, to another folder, given its >>> UUID, with an optional new name. >>> >>> Since RemoveInventoryItem takes only a UUID, I'm too nervous to use >>> it right away with a UUID that represents both the problem item and >>> my Objects folder, even though there is a separate message, >>> RemoveInventoryFolder, for purging a folder. I mean, >>> behind-the-scenes, what if the database operation just uses the UUID >>> alone, and purges my Objects folder >_< And obviously, the UUID is >>> enough to cause problems with the viewer. >>> >>> So I use slproxy to send a MoveInventoryItem packet condemning >>> ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder. >>> >>> [4:04] Analyst: failed to inject fix: Object reference not set to >>> an instance of an object. >>> >>> I guess it won't let me inject the packet without it mentioning the >>> NewName parameter, and I'm not sure if using an empty string will >>> have the desired effect, so I add NewName = TROUBLE to the packet >>> and inject again. >>> >>> No feedback... No item visibly in my Trash... >>> >>> I right-click my Trash and empty it, and verify that the viewer sent >>> a PurgeInventoryDescendents packet, for purging its contents. God, >>> I hope I did it! >>> >>> Clicked the clear cache button, logged out, logged back in, and let >>> my inventory fetch. I am relieved to see I still have an Objects >>> folder, with objects in it. I rez some of them while waiting for >>> the fetching to be over. >>> >>> The fetching is over. I create an object and click the Texture >>> box... the viewer stops... >>> >>> But after about five seconds... IT WORKS!! THE TEXTURE PICKER!! >>> How I'd missed it ;__; I close and open the texture picker again >>> and again! I use New Window on my inventory... it takes about 15 >>> seconds, but it worked! I open the parcel options and click Add >>> next to the ban list... after six seconds, it worked!! >>> >>> Finally, I logged out without clicking 'clear cache' first, and log >>> back in. Z-O-M-G, I am logged in and I already have everything >>> fetched. I am hugging slproxy. >>> >>> So my question is, how did this happen? :D >>> >>> Can we fix the bug in the viewer that made this SUCH a problem? >>> >>> And is there any danger of my Objects folder being >>> garbage-collected, now? ;__; >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From timelessprototype at gmail.com Sat Feb 9 05:52:07 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Sat Feb 9 05:52:02 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADAF42.1070103@gmail.com> References: <47ADA995.50208@gmail.com> <47ADAA44.5060308@weblogsinc.com> <47ADAF42.1070103@gmail.com> Message-ID: <47ADB007.3010809@gmail.com> Oh, I spoke too soon. I noticed it freeze again, so I re-enabled online notifications to see. And sure enough, when friends log in it freezes again. - Timeless Timeless Prototype wrote: > Tateru, you're my official life saver! Forever in your debt. > > I moved all my chat logs (~32MB) to an archive folder, logged on and > re-enabled all chat log options. I can now function without the screen > freezes in Windlight viewer (don't really care about the other viewers). > > Thank you. Thank you. Thank you. XD > > - Timeless > > Tateru Nino wrote: >> >> >> Timeless Prototype wrote: >>> Wow, very cool. >>> >>> My Timeless Prototype avatar is no longer usable, I have missing >>> assets and whenever a friend comes online (regardless of notify >>> option) it locks up the SL viewer for about 5 seconds (ie. >>> absolutely nothing moves on the screen, not even the mouse). With >>> the number of friends I have it's impossible to do anything with >>> this fault. All other applications are fine, even SL voice continues >>> happily whilst this happens. >> Just wondering - do you have chat-logging enabled, and where're the >> log files going to? I had a problem with lockups when friends went >> online/offline and when certain people sent me an IM. Turned out that >> in the wake of a power-flutter at some point, the chat/IM log files >> had been left in a locked state. >> >> I've also seen degenerate behavior when the system is trying to log >> to an inaccessible path. >>> >>> I too am on a basic account with no phone support. I've managed to >>> log on and do some very basic maintenance, even though extremely >>> painful, but I'm afraid it's the end of SL for me unless this can >>> get fixed. The problem only started with the latest Windlight and RC >>> viewers. The "stable" viewer has other issues for me, such as the >>> huge delay whilst logging on, resulting in a nice faceplant and >>> failure to load my avatar. My alts log on just fine, no issues >>> whatsoever with those. >>> >>> I refuse to buy a sim just so I can report a fault with my one >>> avatar's inventory via phone. Just like you, Jira has proved >>> absolutely useless to me for reporting a bug that relates only to my >>> situation. >>> >>> - Timeless >>> >>> Brandon Lockaby wrote: >>>> Inventory Predicament >>>> >>>> It started a few months ago... After letting the ~13,500 items of >>>> my inventory fetch, opening the texture picker or resident picker, >>>> or opening a second inventory window, would cause my viewer to >>>> freeze. Everything was fine until a certain amount of inventory >>>> fetching was done. Also, if I didn't clear my cache before >>>> attempting to log in again, the freeze would happen during the >>>> login process. So I got in the habit of hitting the 'clear cache' >>>> button every time after logging in, to make sure I didn't have to >>>> run the viewer twice next time I wanted to log in. And I got in >>>> the habit of not being able to use the texture picker and resident >>>> picker. >>>> >>>> Being a lowly Basic member, I don't have access to support, so I >>>> filed a JIRA issue, but of course the issue was unique to me, so I >>>> eventually marked it "more information needed" and closed it. >>>> >>>> In connection with a viewer exploit involving inventory transfers, >>>> I had the opportunity of a generous Linden taking a look at my >>>> inventory, and he removed some troublesome top-level folders. But >>>> the problems never went away. >>>> >>>> Several months passed :O >>>> >>>> Tonight I had the opportunity to try the Second Inventory viewer. >>>> It turned out to be alot more featured than I expected. But when I >>>> loaded my 'Objects' folder, it threw about 100 dialogs saying I had >>>> a bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was >>>> not a folder. >>>> >>>> Now, I had a UUID. >>>> >>>> In the Second Life viewer's cache folder, there's a >>> key>.gz file with a text file inside for caching your inventory. I >>>> decided to search the file for that UUID and see if I could figure >>>> out what was up. The first occurrence was: >>>> >>>> inv_category 0 >>>> { >>>> cat_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> parent_id d2ed5dee-3801-46f6-8d8a-1f01133b2673 >>>> type category >>>> pref_type object >>>> name Objects| >>>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> version 11395 >>>> } >>>> >>>> That's my Objects folder. And indeed, all of the objects inside >>>> had it as their parent_id. But since the Second Life viewer and >>>> Second Inventory were, in fact, able to show all the items in my >>>> Objects folder, that didn't make sense of anything to me. I kept >>>> looking, and eventually found this item: >>>> >>>> inv_item 0 >>>> { >>>> item_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> parent_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> permissions 0 >>>> { >>>> base_mask 7fffffff >>>> owner_mask 7fffffff >>>> group_mask 00000000 >>>> everyone_mask 00000000 >>>> next_owner_mask 00082000 >>>> creator_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> last_owner_id 00000000-0000-0000-0000-000000000000 >>>> group_id 00000000-0000-0000-0000-000000000000 >>>> } >>>> asset_id 00000000-0000-0000-0000-000000000000 >>>> type object >>>> inv_type object >>>> flags 00000000 >>>> sale_info 0 >>>> { >>>> sale_type not >>>> sale_price 10 >>>> } >>>> name Object| >>>> desc (No Description)| >>>> creation_date 1195342436 >>>> } >>>> >>>> Amazing, it has the same UUID as the folder it's in, and must be >>>> the problem item. So I loaded up the Second Life viewer, fetched >>>> my inventory, and did a search for "Object." >>>> >>>> Unfortunately, I couldn't see the object. >>>> >>>> So, at this point, being an overenthusiastic slproxy user, I start >>>> thinking maybe I can figure out how to delete an inventory item by >>>> injecting a packet, and hopefully it doesn't work by UUID alone. I >>>> look through http://wiki.secondlife.com/wiki/Category:Messages for >>>> messages having to do with inventory, and log them while doing some >>>> tests with moving and deleting inventory items. >>>> >>>> I find I have two options: >>>> >>>> RemoveInventoryItem >>>> http://wiki.secondlife.com/wiki/RemoveInventoryItem >>>> Purge a single inventory item, given its UUID. >>>> >>>> MoveInventoryItem >>>> http://wiki.secondlife.com/wiki/MoveInventoryItem >>>> Move an inventory item, given its UUID, to another folder, given >>>> its UUID, with an optional new name. >>>> >>>> Since RemoveInventoryItem takes only a UUID, I'm too nervous to use >>>> it right away with a UUID that represents both the problem item and >>>> my Objects folder, even though there is a separate message, >>>> RemoveInventoryFolder, for purging a folder. I mean, >>>> behind-the-scenes, what if the database operation just uses the >>>> UUID alone, and purges my Objects folder >_< And obviously, the >>>> UUID is enough to cause problems with the viewer. >>>> >>>> So I use slproxy to send a MoveInventoryItem packet condemning >>>> ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder. >>>> >>>> [4:04] Analyst: failed to inject fix: Object reference not set to >>>> an instance of an object. >>>> >>>> I guess it won't let me inject the packet without it mentioning the >>>> NewName parameter, and I'm not sure if using an empty string will >>>> have the desired effect, so I add NewName = TROUBLE to the packet >>>> and inject again. >>>> >>>> No feedback... No item visibly in my Trash... >>>> >>>> I right-click my Trash and empty it, and verify that the viewer >>>> sent a PurgeInventoryDescendents packet, for purging its contents. >>>> God, I hope I did it! >>>> >>>> Clicked the clear cache button, logged out, logged back in, and let >>>> my inventory fetch. I am relieved to see I still have an Objects >>>> folder, with objects in it. I rez some of them while waiting for >>>> the fetching to be over. >>>> >>>> The fetching is over. I create an object and click the Texture >>>> box... the viewer stops... >>>> >>>> But after about five seconds... IT WORKS!! THE TEXTURE PICKER!! >>>> How I'd missed it ;__; I close and open the texture picker again >>>> and again! I use New Window on my inventory... it takes about 15 >>>> seconds, but it worked! I open the parcel options and click Add >>>> next to the ban list... after six seconds, it worked!! >>>> >>>> Finally, I logged out without clicking 'clear cache' first, and log >>>> back in. Z-O-M-G, I am logged in and I already have everything >>>> fetched. I am hugging slproxy. >>>> >>>> So my question is, how did this happen? :D >>>> >>>> Can we fix the bug in the viewer that made this SUCH a problem? >>>> >>>> And is there any danger of my Objects folder being >>>> garbage-collected, now? ;__; >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sllists at boroon.dasgupta.ch Sat Feb 9 06:05:35 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Feb 9 06:06:00 2008 Subject: [sldev] Inventory Predicament In-Reply-To: References: Message-ID: <47ADB32F.1030808@boroon.dasgupta.ch> Brandon Lockaby schrieb: > Inventory Predicament > [...] =-O > > So my question is, how did this happen? :D One possibility (though probably the most unlikely one) would be an UUID collision. See http://en.wikipedia.org/wiki/UUID#Random_UUID_probability_of_duplicates. > > Can we fix the bug in the viewer that made this SUCH a problem? That can probably not be answered before its cause is found. Which might be impossible to find without a repro of the bug. But even if this individual bug has been fixed, more with similar consequences will remain (or newly be introduced), so I'd wish the conceptual bug here being fixed by e.g. implementing WEB-302 . In my opinion, it would be all right that LL doesn't (always) fix free accounts, if they gave the account holders the power and tools to fix them themselves. It would reduce the alt accounts just created because the original account got unusable. I don't know what the cost of maintaining an additional account is versus giving web access to the fix scripts, but I guess such a one time effort (per fix script) could pay off quite quick for issues that affect enough residents. cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/cac5a5ec/attachment.htm From tateru.nino at gmail.com Sat Feb 9 06:07:59 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Feb 9 06:10:34 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADAF42.1070103@gmail.com> References: <47ADA995.50208@gmail.com> <47ADAA44.5060308@weblogsinc.com> <47ADAF42.1070103@gmail.com> Message-ID: <47ADB3BF.4020707@gmail.com> No extra charge :) Glad it worked! Timeless Prototype wrote: > Tateru, you're my official life saver! Forever in your debt. > > I moved all my chat logs (~32MB) to an archive folder, logged on and > re-enabled all chat log options. I can now function without the screen > freezes in Windlight viewer (don't really care about the other viewers). > > Thank you. Thank you. Thank you. XD > > - Timeless > > Tateru Nino wrote: >> >> >> Timeless Prototype wrote: >>> Wow, very cool. >>> >>> My Timeless Prototype avatar is no longer usable, I have missing >>> assets and whenever a friend comes online (regardless of notify >>> option) it locks up the SL viewer for about 5 seconds (ie. >>> absolutely nothing moves on the screen, not even the mouse). With >>> the number of friends I have it's impossible to do anything with >>> this fault. All other applications are fine, even SL voice continues >>> happily whilst this happens. >> Just wondering - do you have chat-logging enabled, and where're the >> log files going to? I had a problem with lockups when friends went >> online/offline and when certain people sent me an IM. Turned out that >> in the wake of a power-flutter at some point, the chat/IM log files >> had been left in a locked state. >> >> I've also seen degenerate behavior when the system is trying to log >> to an inaccessible path. >>> >>> I too am on a basic account with no phone support. I've managed to >>> log on and do some very basic maintenance, even though extremely >>> painful, but I'm afraid it's the end of SL for me unless this can >>> get fixed. The problem only started with the latest Windlight and RC >>> viewers. The "stable" viewer has other issues for me, such as the >>> huge delay whilst logging on, resulting in a nice faceplant and >>> failure to load my avatar. My alts log on just fine, no issues >>> whatsoever with those. >>> >>> I refuse to buy a sim just so I can report a fault with my one >>> avatar's inventory via phone. Just like you, Jira has proved >>> absolutely useless to me for reporting a bug that relates only to my >>> situation. >>> >>> - Timeless >>> >>> Brandon Lockaby wrote: >>>> Inventory Predicament >>>> >>>> It started a few months ago... After letting the ~13,500 items of >>>> my inventory fetch, opening the texture picker or resident picker, >>>> or opening a second inventory window, would cause my viewer to >>>> freeze. Everything was fine until a certain amount of inventory >>>> fetching was done. Also, if I didn't clear my cache before >>>> attempting to log in again, the freeze would happen during the >>>> login process. So I got in the habit of hitting the 'clear cache' >>>> button every time after logging in, to make sure I didn't have to >>>> run the viewer twice next time I wanted to log in. And I got in >>>> the habit of not being able to use the texture picker and resident >>>> picker. >>>> >>>> Being a lowly Basic member, I don't have access to support, so I >>>> filed a JIRA issue, but of course the issue was unique to me, so I >>>> eventually marked it "more information needed" and closed it. >>>> >>>> In connection with a viewer exploit involving inventory transfers, >>>> I had the opportunity of a generous Linden taking a look at my >>>> inventory, and he removed some troublesome top-level folders. But >>>> the problems never went away. >>>> >>>> Several months passed :O >>>> >>>> Tonight I had the opportunity to try the Second Inventory viewer. >>>> It turned out to be alot more featured than I expected. But when I >>>> loaded my 'Objects' folder, it threw about 100 dialogs saying I had >>>> a bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was >>>> not a folder. >>>> >>>> Now, I had a UUID. >>>> >>>> In the Second Life viewer's cache folder, there's a >>> key>.gz file with a text file inside for caching your inventory. I >>>> decided to search the file for that UUID and see if I could figure >>>> out what was up. The first occurrence was: >>>> >>>> inv_category 0 >>>> { >>>> cat_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> parent_id d2ed5dee-3801-46f6-8d8a-1f01133b2673 >>>> type category >>>> pref_type object >>>> name Objects| >>>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> version 11395 >>>> } >>>> >>>> That's my Objects folder. And indeed, all of the objects inside >>>> had it as their parent_id. But since the Second Life viewer and >>>> Second Inventory were, in fact, able to show all the items in my >>>> Objects folder, that didn't make sense of anything to me. I kept >>>> looking, and eventually found this item: >>>> >>>> inv_item 0 >>>> { >>>> item_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> parent_id ce5da405-26d2-4004-a01c-56a3ced4d68a >>>> permissions 0 >>>> { >>>> base_mask 7fffffff >>>> owner_mask 7fffffff >>>> group_mask 00000000 >>>> everyone_mask 00000000 >>>> next_owner_mask 00082000 >>>> creator_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> owner_id 97b817dc-5dd3-498a-bdd2-5644d0aa8fb4 >>>> last_owner_id 00000000-0000-0000-0000-000000000000 >>>> group_id 00000000-0000-0000-0000-000000000000 >>>> } >>>> asset_id 00000000-0000-0000-0000-000000000000 >>>> type object >>>> inv_type object >>>> flags 00000000 >>>> sale_info 0 >>>> { >>>> sale_type not >>>> sale_price 10 >>>> } >>>> name Object| >>>> desc (No Description)| >>>> creation_date 1195342436 >>>> } >>>> >>>> Amazing, it has the same UUID as the folder it's in, and must be >>>> the problem item. So I loaded up the Second Life viewer, fetched >>>> my inventory, and did a search for "Object." >>>> >>>> Unfortunately, I couldn't see the object. >>>> >>>> So, at this point, being an overenthusiastic slproxy user, I start >>>> thinking maybe I can figure out how to delete an inventory item by >>>> injecting a packet, and hopefully it doesn't work by UUID alone. I >>>> look through http://wiki.secondlife.com/wiki/Category:Messages for >>>> messages having to do with inventory, and log them while doing some >>>> tests with moving and deleting inventory items. >>>> >>>> I find I have two options: >>>> >>>> RemoveInventoryItem >>>> http://wiki.secondlife.com/wiki/RemoveInventoryItem >>>> Purge a single inventory item, given its UUID. >>>> >>>> MoveInventoryItem >>>> http://wiki.secondlife.com/wiki/MoveInventoryItem >>>> Move an inventory item, given its UUID, to another folder, given >>>> its UUID, with an optional new name. >>>> >>>> Since RemoveInventoryItem takes only a UUID, I'm too nervous to use >>>> it right away with a UUID that represents both the problem item and >>>> my Objects folder, even though there is a separate message, >>>> RemoveInventoryFolder, for purging a folder. I mean, >>>> behind-the-scenes, what if the database operation just uses the >>>> UUID alone, and purges my Objects folder >_< And obviously, the >>>> UUID is enough to cause problems with the viewer. >>>> >>>> So I use slproxy to send a MoveInventoryItem packet condemning >>>> ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder. >>>> >>>> [4:04] Analyst: failed to inject fix: Object reference not set to >>>> an instance of an object. >>>> >>>> I guess it won't let me inject the packet without it mentioning the >>>> NewName parameter, and I'm not sure if using an empty string will >>>> have the desired effect, so I add NewName = TROUBLE to the packet >>>> and inject again. >>>> >>>> No feedback... No item visibly in my Trash... >>>> >>>> I right-click my Trash and empty it, and verify that the viewer >>>> sent a PurgeInventoryDescendents packet, for purging its contents. >>>> God, I hope I did it! >>>> >>>> Clicked the clear cache button, logged out, logged back in, and let >>>> my inventory fetch. I am relieved to see I still have an Objects >>>> folder, with objects in it. I rez some of them while waiting for >>>> the fetching to be over. >>>> >>>> The fetching is over. I create an object and click the Texture >>>> box... the viewer stops... >>>> >>>> But after about five seconds... IT WORKS!! THE TEXTURE PICKER!! >>>> How I'd missed it ;__; I close and open the texture picker again >>>> and again! I use New Window on my inventory... it takes about 15 >>>> seconds, but it worked! I open the parcel options and click Add >>>> next to the ban list... after six seconds, it worked!! >>>> >>>> Finally, I logged out without clicking 'clear cache' first, and log >>>> back in. Z-O-M-G, I am logged in and I already have everything >>>> fetched. I am hugging slproxy. >>>> >>>> So my question is, how did this happen? :D >>>> >>>> Can we fix the bug in the viewer that made this SUCH a problem? >>>> >>>> And is there any danger of my Objects folder being >>>> garbage-collected, now? ;__; >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> > > From d3adlyc0d3c at gmail.com Sat Feb 9 06:17:25 2008 From: d3adlyc0d3c at gmail.com (adam davis) Date: Sat Feb 9 06:17:30 2008 Subject: [sldev] Inventory Predicament In-Reply-To: References: Message-ID: <87ceb0390802090617k58ce00a3g34b14118059a479e@mail.gmail.com> Hey all this is d3adlyc0d3c, I heard you Brandon mention the Second Inventory viewer which I just wrote about at the Second Life Herald at http://foo.secondlifeherald.com/slh/2008/02/second-inventor.html I would like any information on this that you have. Rumors are circulating that this software has similiar functionality to copybot and that it has been used to steal prims,etc,etc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/46d71b0f/attachment-0001.htm From d3adlyc0d3c at gmail.com Sat Feb 9 06:24:55 2008 From: d3adlyc0d3c at gmail.com (adam davis) Date: Sat Feb 9 06:24:58 2008 Subject: [sldev] Inventory Predicament In-Reply-To: References: Message-ID: <87ceb0390802090624h5c6d573fqe5850e004dab9bd9@mail.gmail.com> Hey guys, don't get all quiet on me now. Some of you may have heard of me, I'm an ex-griefer and actually not a bad guy. I left that stuff behind for more productive pastimes. I am interested in this viewer. The article was based alot on other people's experiences with it and unfortunately I haven't gotten anyone whose used it to speak with me about it. We don't have alot of facts and Pixeleen was convinced that it was a scam initially, I was pretty sure it's another intellectual property theft tool. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/3b90d29b/attachment.htm From timelessprototype at gmail.com Sat Feb 9 06:44:45 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Sat Feb 9 06:44:40 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <87ceb0390802090624h5c6d573fqe5850e004dab9bd9@mail.gmail.com> References: <87ceb0390802090624h5c6d573fqe5850e004dab9bd9@mail.gmail.com> Message-ID: <47ADBC5D.8040200@gmail.com> Well, I for one, am buying it _right now_ to backup my work (originals) to my alts so I can continue functioning. Top marks for the linkage. - Timeless adam davis wrote: > > Hey guys, don't get all quiet on me now. Some of you may have heard of > me, I'm an ex-griefer and actually not a bad guy. I left that stuff > behind for more productive pastimes. I am interested in this viewer. > The article was based alot on other people's experiences with it and > unfortunately I haven't gotten anyone whose used it to speak with me > about it. We don't have alot of facts and Pixeleen was convinced that > it was a scam initially, I was pretty sure it's another intellectual > property theft tool. > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Sat Feb 9 06:46:44 2008 From: soft at lindenlab.com (Soft) Date: Sat Feb 9 06:46:47 2008 Subject: [sldev] Ban proof client? In-Reply-To: <47AD559A.2020803@weblogsinc.com> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> <47AD559A.2020803@weblogsinc.com> Message-ID: On Feb 9, 2008 1:26 AM, Tateru Nino wrote: > > Soft wrote: > > On Feb 8, 2008 11:11 AM, Thomas Shikami wrote: > > > >> The reason for this is well known, if the home simulator of an avatar is > >> not available, banning an avatar on the estate ban list doesn't teleport > >> them home, neither kicking the user from estate works. The thing that > >> works it to teleport home from the region tab of the estate tools, it > >> will then send the avatar to on of the info hubs > >> > > > > First I've heard - do you know if there's a JIRA for this? I'll import > > it directly if there is - it sounds exploitable. > > > I know a number of people who sent this in via the exploit reporting > mechanism in the pre-PJIRA days. I know I've assumed that as a result it > was already in *your* JIRA. All evidence suggests that they too assumed the other guy was handling it. If you're ever in doubt, please consider reporting. A duplicate security mail or JIRA is much less trouble than an unreported issue. Our triage processes are very good at weeding these out. From tateru.nino at gmail.com Sat Feb 9 09:48:46 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Feb 9 09:51:22 2008 Subject: [sldev] Ban proof client? In-Reply-To: References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> <47AD559A.2020803@weblogsinc.com> Message-ID: <47ADE77E.9060504@gmail.com> Soft wrote: > On Feb 9, 2008 1:26 AM, Tateru Nino wrote: > >> Soft wrote: >> >>> On Feb 8, 2008 11:11 AM, Thomas Shikami wrote: >>> >>> >>>> The reason for this is well known, if the home simulator of an avatar is >>>> not available, banning an avatar on the estate ban list doesn't teleport >>>> them home, neither kicking the user from estate works. The thing that >>>> works it to teleport home from the region tab of the estate tools, it >>>> will then send the avatar to on of the info hubs >>>> >>>> >>> First I've heard - do you know if there's a JIRA for this? I'll import >>> it directly if there is - it sounds exploitable. >>> >>> >> I know a number of people who sent this in via the exploit reporting >> mechanism in the pre-PJIRA days. I know I've assumed that as a result it >> was already in *your* JIRA. >> > > All evidence suggests that they too assumed the other guy was handling it. > > If you're ever in doubt, please consider reporting. A duplicate > security mail or JIRA is much less trouble than an unreported issue. > Our triage processes are very good at weeding these out. > > This reminds me of Phoenix discovering that there were vehicle border crossing problems back in 1Q2006. "Golly. How long has _that_ been going on?" :) From candide.lemay at gmail.com Sat Feb 9 10:16:03 2008 From: candide.lemay at gmail.com (Candide LeMay) Date: Sat Feb 9 10:16:05 2008 Subject: [sldev] Ban proof client? In-Reply-To: <47ADE77E.9060504@gmail.com> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> <47AD559A.2020803@weblogsinc.com> <47ADE77E.9060504@gmail.com> Message-ID: On Feb 9, 2008 6:48 PM, Tateru Nino wrote: > This reminds me of Phoenix discovering that there were vehicle border > crossing problems back in 1Q2006. > "Golly. How long has _that_ been going on?" :) > or the (late) discovery that attachment keys change after teleport *mumbles about eating your own dogfood* From seg at haxxed.com Sat Feb 9 10:39:08 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 9 10:39:16 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADBC5D.8040200@gmail.com> References: <87ceb0390802090624h5c6d573fqe5850e004dab9bd9@mail.gmail.com> <47ADBC5D.8040200@gmail.com> Message-ID: <1202582348.7567.11.camel@localhost> On Sat, 2008-02-09 at 14:44 +0000, Timeless Prototype wrote: > Well, I for one, am buying it _right now_ to backup my work (originals) > to my alts so I can continue functioning. > > Top marks for the linkage. Buy... it... ? You're getting ripped off. They're right though. As long as LL's asset servers are not 100% reliable, and we all know they're not, it is insane to trust them. This is all the more reason to implement "Save As..." into slviewer itself. Why does some asshole deserve 30 euros for something that should have been in the client from the start? (And is probably just 10 lines of code on top of libsecondlife. BSD license FTW...) (Attn Luskwood: I have nothing to do with Second Inventory. So lick me.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080209/721b8fde/attachment.pgp From seg at haxxed.com Sat Feb 9 10:52:33 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 9 10:52:37 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADA995.50208@gmail.com> References: <47ADA995.50208@gmail.com> Message-ID: <1202583153.7567.20.camel@localhost> On Sat, 2008-02-09 at 13:24 +0000, Timeless Prototype wrote: > whenever a friend comes online (regardless of notify option) it > locks up the SL viewer for about 5 seconds (ie. absolutely nothing moves > on the screen, not even the mouse). With the number of friends I have > it's impossible to do anything with this fault. All other applications > are fine, even SL voice continues happily whilst this happens. Has anyone looked in to this now long standing bug? Is there a Jira for this? This would be an example of something difficult to fix due to not being easily reproducible in a controlled manner. -------------- 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/20080209/660c3ead/attachment.pgp From gbrandon at gmail.com Sat Feb 9 12:24:18 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Sat Feb 9 12:24:21 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADB32F.1030808@boroon.dasgupta.ch> References: <47ADB32F.1030808@boroon.dasgupta.ch> Message-ID: I don't have a clue how to repro the condition that created that item, but I do think I can create an item in my inventory with an arbitrary UUID. If I remember correctly, when I tried using RezObject with the UUID of an item that wasn't in my inventory, I would get an AlertMessage and a busted inventory item would be created with that UUID. Worth noting I started having the issue *before* I ever played with slproxy though, and I'm quite sure I never tried it using the UUID of my Objects folder (; I'm kind of tempted to write an app to parse an inventory cache and look for such a problem item. I'll suggest the idea to the Second Inventory guy, too, since he was aware of my problem, and I've shared some other ideas with him. Speaking of Second Inventory, I think some of you are being too hard on it. It respects permissions, just like any other viewer that isn't banned by name from the grid, and I was surprised by its feature depth. I think it was the product of some of the most work anyone's ever done on a libsecondlife client. For comparison, it looks like it was alot more work than SLeek. That said, before buying that, I would try the xml import/export functionality of testclient which is freely available with libsecondlife. I haven't tried it, myself -- it may not work, but I'd say it's worth a try since it's so free :D I don't think it has the ability to back up your entire inventory in one operation, though. I'm sorry to hear about the trouble you're having, Timeless :( -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080209/5d5d8af4/attachment.htm From timelessprototype at gmail.com Sat Feb 9 15:10:54 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Sat Feb 9 15:10:46 2008 Subject: [sldev] Inventory Predicament In-Reply-To: References: <47ADB32F.1030808@boroon.dasgupta.ch> Message-ID: <47AE32FE.3090409@gmail.com> Thanks for the sympathy there. I've purchased a copy of Second Inventory, and once the Restore feature is enabled it will totally suit my needs for developing on my alt, backing up and restoring on my main ready for release. Right now at least, I've managed to back up my most precious products I've ever made. Totally offline browsable objects and contents. I'm suitably impressed by the feature set. This stuff is solid gold to me. - Timeless Brandon Lockaby wrote: > I don't have a clue how to repro the condition that created that item, > but I do think I can create an item in my inventory with an arbitrary > UUID. If I remember correctly, when I tried using RezObject with the > UUID of an item that wasn't in my inventory, I would get an > AlertMessage and a busted inventory item would be created with that > UUID. Worth noting I started having the issue *before* I ever played > with slproxy though, and I'm quite sure I never tried it using the > UUID of my Objects folder (; > > I'm kind of tempted to write an app to parse an inventory cache and > look for such a problem item. I'll suggest the idea to the Second > Inventory guy, too, since he was aware of my problem, and I've shared > some other ideas with him. > > Speaking of Second Inventory, I think some of you are being too hard > on it. It respects permissions, just like any other viewer that isn't > banned by name from the grid, and I was surprised by its feature > depth. I think it was the product of some of the most work anyone's > ever done on a libsecondlife client. For comparison, it looks like it > was alot more work than SLeek. > > That said, before buying that, I would try the xml import/export > functionality of testclient which is freely available with > libsecondlife. I haven't tried it, myself -- it may not work, but I'd > say it's worth a try since it's so free :D I don't think it has the > ability to back up your entire inventory in one operation, though. > > I'm sorry to hear about the trouble you're having, Timeless :( > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From thomas.shikami at online.de Sun Feb 10 06:53:03 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Sun Feb 10 06:53:06 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47ADA995.50208@gmail.com> References: <47ADA995.50208@gmail.com> Message-ID: <47AF0FCF.5080207@online.de> Timeless Prototype wrote: > My Timeless Prototype avatar is no longer usable, I have missing > assets and whenever a friend comes online (regardless of notify > option) it locks up the SL viewer for about 5 seconds (ie. absolutely > nothing moves on the screen, not even the mouse). With the number of > friends I have it's impossible to do anything with this fault. All > other applications are fine, even SL voice continues happily whilst > this happens. You probably have the problem described in VWR-4178, there is indeed a very inefficient handling of inventory inside the Second Life viewer that causes freezing and what not. For online friend notifications, they changed the friends list in a way that there are hundrets of online/offline notifications each login and with updating inventory it takes about half a second each update with 25k+ inventory items. If there is really high demand, I'd make a patch that disables the feature of updating the display of calling cards for online so inventory updates don't happen whenever friends login/logoff which is causing the freezes. If someone is interested, there's an embeddable sql database available with a compatible license to GPL. It's called sqlite and it should be able to manage an inventory cache using it much quicker than it's implemented inside the viewer itself, also inventory updates should be done inside a kind of dedicated worker thread and also be asynchronous. Please do, as else my main account would be unusable within some months, too. From secret.argent at gmail.com Sun Feb 10 08:36:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Feb 10 08:36:50 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <47AF0FCF.5080207@online.de> References: <47ADA995.50208@gmail.com> <47AF0FCF.5080207@online.de> Message-ID: <603F3193-7C5F-42ED-BECB-FC43F6CB6817@gmail.com> On 2008-02-10, at 08:53, Thomas Shikami wrote: > You probably have the problem described in VWR-4178, there is > indeed a very inefficient handling of inventory inside the Second > Life viewer that causes freezing and what not. For online friend > notifications, they changed the friends list in a way that there > are hundrets of online/offline notifications each login and with > updating inventory it takes about half a second each update with 25k > + inventory items. If there is really high demand, I'd make a patch > that disables the feature of updating the display of calling cards > for online so inventory updates don't happen whenever friends login/ > logoff which is causing the freezes. Hold on, you mean they update the appearance of calling cards in your inventory when friends are only by actually updating your inventory? In real time? Do they do that for stuff you're wearing as well? That's insane. > If someone is interested, there's an embeddable sql database > available with a compatible license to GPL. For SL it doesn't actually have to be GPL-compatible, it just has to be FOSS. From thomas.shikami at online.de Sun Feb 10 16:31:31 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Sun Feb 10 16:31:34 2008 Subject: [sldev] Inventory Predicament In-Reply-To: <603F3193-7C5F-42ED-BECB-FC43F6CB6817@gmail.com> References: <47ADA995.50208@gmail.com> <47AF0FCF.5080207@online.de> <603F3193-7C5F-42ED-BECB-FC43F6CB6817@gmail.com> Message-ID: <47AF9763.6040504@online.de> Argent Stonecutter wrote: > Hold on, you mean they update the appearance of calling cards in your > inventory when friends are only by actually updating your inventory? > In real time? Do they do that for stuff you're wearing as well? > > That's insane. Well, the update doesn't happen server side, just client side. It seems that scanning through big inventory inside the viewer when opening inventory, selecting residents for ban/access/group invites or texture pickers cause a scan in inventory. This scan seems to take some seconds on the viewer that causes it to stall networking. I think the inventory system inside the viewer needs a refresh, refactoring or freshup to either happen asynchronously or faster. I prefer the asynchronous handling of inventory. For those who like to test it, please do so with 100k+ inventory items in those algorithms. That's about three times the maximum inventory size I've seen so far. From mrfrans at gmail.com Sun Feb 10 16:52:50 2008 From: mrfrans at gmail.com (Frans) Date: Sun Feb 10 16:52:52 2008 Subject: [sldev] Ban proof client? In-Reply-To: <47ADE77E.9060504@gmail.com> References: <50181.76.24.24.86.1202060399.squirrel@webmail.magetech.com> <47AC8D24.4040900@online.de> <47AD559A.2020803@weblogsinc.com> <47ADE77E.9060504@gmail.com> Message-ID: <7765f2c60802101652r4637b95ey3d65f74c7bfd87c7@mail.gmail.com> > This reminds me of Phoenix discovering that there were vehicle border > crossing problems back in 1Q2006. > "Golly. How long has _that_ been going on?" :) > Hahaha. I remember that fondly. Even blogged about it way back when I was still a young Frans. ;) http://secondslog.blogspot.com/2006/03/community-team-roundtable-march-2006.html -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080211/60c35dbf/attachment.htm From monkowsk at watson.ibm.com Mon Feb 11 10:49:40 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Feb 11 10:49:50 2008 Subject: [sldev] Re: [JIRA] Created: (VWR-4794) Babble loop for voice visualization In-Reply-To: <10755251.1202692788848.JavaMail.root@lindenlab1> References: <10755251.1202692788848.JavaMail.root@lindenlab1> Message-ID: <47B098C4.30109@watson.ibm.com> I've added a "New Feature" to the JIRA with the patch files, but I can't figure out how to mark it as "Patch Attached." I know how to do it for bugs, but that option doesn't seem to be available for features. I know that reports with patches get more attention than those without. Anyone know how to do it? Also, do "New Feature" reports get triaged? What's the route to getting them incorporated into the official release? (The Linden contribution agreement is in the mail.) At one time this was one of the "Linden Lab Bounties," http://wiki.secondlife.com/wiki/Talk:Linden_Lab_Bounties so I expect someone might be interested in it. Mike Mm Alder (JIRA) wrote: > Babble loop for voice visualization > ----------------------------------- > > Key: VWR-4794 > URL: http://jira.secondlife.com/browse/VWR-4794 > Project: 1. Second Life Viewer - VWR > Issue Type: New Feature > Components: Voice > Affects Versions: 1.19.0 Release Candidate > Reporter: Mm Alder > Attachments: avatar_lad.patchfile, FL77495.patchfile, RC79209.patchfile > > This code adds rudimentary lip sync for voice chat. > > There is a patchfile for the WindLight FirstLook viewer (FL77495.patchfile) > and one for the ReleaseCandidate viewer (RC79208.patchfile). The difference > is due to a non-functional edit in the WindLight branch. > > There is also a patchfile for character\avatar_lad.xml (avatar_lad.patchfile) > and a replacement file for character\avatar_head.llm > > The avatar_lad.xml and avatar_head.llm files are compatible with the standard > viewer, and the modified viewer works without changing these, but not as well. > > See the documentation at http://wiki.secondlife.com/wiki/User:Mm_Alder/LipSync > for a description of the functionality. From q at lindenlab.com Mon Feb 11 15:24:14 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon Feb 11 15:25:29 2008 Subject: [sldev] Notifications redesign Message-ID: <47B0D91E.9060402@lindenlab.com> Hi, folks. We're about to embark on a project to redesign the way that notifications and alerts work in the SL client. I wanted to tell people that we're looking at it and give you a chance to get in your two cents while it's still early. Notifications and Alerts are the boxes that pop up on external events, from the little temporary ones in the lower right corner to the things that warn you when someone wants to take money from you. They have several problems that need a redesign and reimplementation. These include: * Code shortcomings: o Group notifications and Notifications have two separate code paths for very similar behavior + there's some awkward code to make them more similar + they fight with each other for priority display, and in certain weird instances could cause viewer to crash o Alerts can't take server-side parameters and still be translatable * UI shortcomings: o The way alerts and notifications stack up is highly confusing, especially for new residents o Too many different places on screen to look for messages o They could use a new graphical appearance, particularly to be compatible with http://wiki.secondlife.com/wiki/Dazzle o Too much detail up front for new users -- would be nice to allow summary / detail levels o Reduce the potential for griefing through scripted object notifications o No differentiation between system (Linden)-created notifications and resident created/initiated notifications o The discoverability is low on how to scroll through Active Notifications; or dismiss Passive ones early (Did you know you can?) * Functionality shortcomings: o No history- so if a notification is missed it can not be recovered + If the client is exited or crashes with active notifications they are lost along with attached inventory o No way to get additional information from a passive notification o No hyperlinks in notifications With that in mind, my intent is to: 1) Redesign the API for notifications and alerts. First, we'll unify the call structure so that all notifications and alerts go through a single unified call looking something vaguely like: NotificationSystem::displayNotification(string notificationname, LLSD data) This first pass will simply unify the call structure and the input XML files so that all notifications go through this path. That change should only be of interest to the people working in the source; there will be essentially no user-visible changes from that change. 2) Next is to unify the rendering process so as to eliminate the old LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also change the rendering so that we'll only render the "top" notification(s) in the queue, rather than rendering them all. This will also give us an improved ability to scroll back and forth through the list of pending notifications. There will be some user-visible changes at this point to bring out some new features in the API and make the existing notifications fit with the evolving look and feel of the UI. But my intent is that they'll be relatively minor and noncontroversial. 3) Then we'll want to do a full revisit of the rendering code for notifications which will almost certainly change the way they work in ways that should improve usability and reduce the potential for griefing. Our Resident Experience team will be developing a unified design for the system, and as they design it we'll want to bounce it off people here in advance before we code it. In the long run (which -- fair warning -- is several months away), we hope to have a notification code path that is comprehensible, extensible, localizable, and unified, as well as a UI that is attractive and works well. So we'd dearly love your constructive feedback, in particular if you think there are additional considerations I haven't mentioned. Thanks, Q From ramzi at lindenlab.com Mon Feb 11 15:44:27 2008 From: ramzi at lindenlab.com (Ramzi) Date: Mon Feb 11 15:44:33 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: <47B0DDDB.2020308@lindenlab.com> Also appearing in jira: https://jira.secondlife.com/browse/VWR-4832 . That may be the best place to structure feedback and discussion! I will try to link various earlier feature requests that relate to the current shortcomings that Q did a great job to articulate. best, Ramzi Linden Project Manager Q Linden wrote: > Hi, folks. We're about to embark on a project to redesign the way that > notifications and alerts work in the SL client. I wanted to tell > people that we're looking at it and give you a chance to get in your > two cents while it's still early. > > Notifications and Alerts are the boxes that pop up on external events, > from the little temporary ones in the lower right corner to the things > that warn you when someone wants to take money from you. They have > several problems that need a redesign and reimplementation. These > include: > > * Code shortcomings: > o Group notifications and Notifications have two separate > code paths for very similar behavior > + there's some awkward code to make them more similar > + they fight with each other for priority display, and > in certain weird instances could cause viewer to crash > o Alerts can't take server-side parameters and still be > translatable > * UI shortcomings: > o The way alerts and notifications stack up is highly > confusing, especially for new residents > o Too many different places on screen to look for messages > o They could use a new graphical appearance, particularly to > be compatible with http://wiki.secondlife.com/wiki/Dazzle > o Too much detail up front for new users -- would be nice to > allow summary / detail levels > o Reduce the potential for griefing through scripted object > notifications > o No differentiation between system (Linden)-created > notifications and resident created/initiated notifications > o The discoverability is low on how to scroll through Active > Notifications; or dismiss Passive ones early (Did you know you can?) > * Functionality shortcomings: > o No history- so if a notification is missed it can not be > recovered > + If the client is exited or crashes with active > notifications they are lost along with attached inventory > o No way to get additional information from a passive > notification > o No hyperlinks in notifications > > With that in mind, my intent is to: > > 1) Redesign the API for notifications and alerts. First, we'll unify > the call structure so that all notifications and alerts go through a > single unified call looking something vaguely like: > NotificationSystem::displayNotification(string > notificationname, LLSD data) > This first pass will simply unify the call structure and the input XML > files so that all notifications go through this path. That change > should only be of interest to the people working in the source; there > will be essentially no user-visible changes from that change. > > 2) Next is to unify the rendering process so as to eliminate the old > LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also > change the rendering so that we'll only render the "top" > notification(s) in the queue, rather than rendering them all. This > will also give us an improved ability to scroll back and forth through > the list of pending notifications. There will be some user-visible > changes at this point to bring out some new features in the API and > make the existing notifications fit with the evolving look and feel of > the UI. But my intent is that they'll be relatively minor and > noncontroversial. > > 3) Then we'll want to do a full revisit of the rendering code for > notifications which will almost certainly change the way they work in > ways that should improve usability and reduce the potential for > griefing. Our Resident Experience team will be developing a unified > design for the system, and as they design it we'll want to bounce it > off people here in advance before we code it. > > In the long run (which -- fair warning -- is several months away), we > hope to have a notification code path that is comprehensible, > extensible, localizable, and unified, as well as a UI that is > attractive and works well. > > So we'd dearly love your constructive feedback, in particular if you > think there are additional considerations I haven't mentioned. > > Thanks, > > Q > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gbrandon at gmail.com Mon Feb 11 16:56:27 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Feb 11 16:56:30 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: Interesting and a bit exciting, thanks for the words! I want to add something: The way I dream of the dialogs, you could view a list box of all of them, and select one or more at a time... that way, if someone griefs you with 5 dialogs, you can view the list, select all 50 at once and close them or whatever. Just a thought... Keep up the good work! <3 On Feb 11, 2008 6:24 PM, Kent Quirk (Q Linden) wrote: > Hi, folks. We're about to embark on a project to redesign the way that > notifications and alerts work in the SL client. I wanted to tell people > that we're looking at it and give you a chance to get in your two cents > while it's still early. > > Notifications and Alerts are the boxes that pop up on external events, > from the little temporary ones in the lower right corner to the things > that warn you when someone wants to take money from you. They have > several problems that need a redesign and reimplementation. These include: > > * Code shortcomings: > o Group notifications and Notifications have two separate code > paths for very similar behavior > + there's some awkward code to make them more similar > + they fight with each other for priority display, and > in certain weird instances could cause viewer to crash > o Alerts can't take server-side parameters and still be > translatable > * UI shortcomings: > o The way alerts and notifications stack up is highly > confusing, especially for new residents > o Too many different places on screen to look for messages > o They could use a new graphical appearance, particularly to > be compatible with http://wiki.secondlife.com/wiki/Dazzle > o Too much detail up front for new users -- would be nice to > allow summary / detail levels > o Reduce the potential for griefing through scripted object > notifications > o No differentiation between system (Linden)-created > notifications and resident created/initiated notifications > o The discoverability is low on how to scroll through Active > Notifications; or dismiss Passive ones early (Did you know you can?) > * Functionality shortcomings: > o No history- so if a notification is missed it can not be > recovered > + If the client is exited or crashes with active > notifications they are lost along with attached inventory > o No way to get additional information from a passive > notification > o No hyperlinks in notifications > > With that in mind, my intent is to: > > 1) Redesign the API for notifications and alerts. First, we'll unify the > call structure so that all notifications and alerts go through a single > unified call looking something vaguely like: > NotificationSystem::displayNotification(string > notificationname, LLSD data) > This first pass will simply unify the call structure and the input XML > files so that all notifications go through this path. That change should > only be of interest to the people working in the source; there will be > essentially no user-visible changes from that change. > > 2) Next is to unify the rendering process so as to eliminate the old > LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also > change the rendering so that we'll only render the "top" notification(s) > in the queue, rather than rendering them all. This will also give us an > improved ability to scroll back and forth through the list of pending > notifications. There will be some user-visible changes at this point to > bring out some new features in the API and make the existing > notifications fit with the evolving look and feel of the UI. But my > intent is that they'll be relatively minor and noncontroversial. > > 3) Then we'll want to do a full revisit of the rendering code for > notifications which will almost certainly change the way they work in > ways that should improve usability and reduce the potential for > griefing. Our Resident Experience team will be developing a unified > design for the system, and as they design it we'll want to bounce it off > people here in advance before we code it. > > In the long run (which -- fair warning -- is several months away), we > hope to have a notification code path that is comprehensible, > extensible, localizable, and unified, as well as a UI that is attractive > and works well. > > So we'd dearly love your constructive feedback, in particular if you > think there are additional considerations I haven't mentioned. > > Thanks, > > Q > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080211/665514cf/attachment.htm From mrfrans at gmail.com Mon Feb 11 17:13:03 2008 From: mrfrans at gmail.com (Frans) Date: Mon Feb 11 17:13:06 2008 Subject: [sldev] Notifications redesign In-Reply-To: References: <47B0D91E.9060402@lindenlab.com> Message-ID: <7765f2c60802111713p4b664873mb72f99ad8941de10@mail.gmail.com> I'm looking forward to it as well. Like Brandon I have been thinking of a list box as well, to manage notes. On Feb 12, 2008 1:56 AM, Brandon Lockaby wrote: > Interesting and a bit exciting, thanks for the words! > > I want to add something: > > The way I dream of the dialogs, you could view a list box of all of them, > and select one or more at a time... that way, if someone griefs you with 5 > dialogs, you can view the list, select all 50 at once and close them or > whatever. > > Just a thought... Keep up the good work! <3 -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080212/732c63cd/attachment-0001.htm From secret.argent at gmail.com Mon Feb 11 17:24:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Feb 11 17:24:51 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> Well, speaking as someone who has been doing control system development for years, notifications (we call them alarms) are a Big Deal. Typically in a control system you can: * View current (unacknowledged) alarms in a list. * View individual alarm details. * Review recent acknowledged or unacknowledged alarms. * Filter alarms. * Acknowledge individual alarms, all displayed alarms (subject to filter), all non-critical alarms, and all alarms of an individual class. I have long wished that computer software for desktops had these kinds of tools, rather than just displaying each individual notification as a separate dialog box. In SL, where you can have many many pending notification (unacknowledged alarms) this is even more critical. From robla at lindenlab.com Mon Feb 11 18:01:45 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 11 18:01:55 2008 Subject: [sldev] Re: [JIRA] Created: (VWR-4794) Babble loop for voice visualization In-Reply-To: <47B098C4.30109@watson.ibm.com> References: <10755251.1202692788848.JavaMail.root@lindenlab1> <47B098C4.30109@watson.ibm.com> Message-ID: <47B0FE09.2030501@lindenlab.com> On 2/11/08 10:49 AM, Mike Monkowski wrote: > I've added a "New Feature" to the JIRA with the patch files, but I > can't figure out how to mark it as "Patch Attached." I know how to do > it for bugs, but that option doesn't seem to be available for > features. I know that reports with patches get more attention than > those without. Anyone know how to do it? Yeah, it's under the "Advanced" tab as you're filing/editing the issue. I tucked away several of the oft-misused fields into that tab when I reconfigured things in December. > Also, do "New Feature" reports get triaged? What's the route to > getting them incorporated into the official release? (The Linden > contribution agreement is in the mail.) At one time this was one of > the "Linden Lab Bounties," > http://wiki.secondlife.com/wiki/Talk:Linden_Lab_Bounties so I expect > someone might be interested in it. Patches generally show up on the Monday triage list, and any feature that has a patch associated with it is a welcome agenda item for the open source meeting on Thursday, as well. https://wiki.secondlife.com/wiki/Bug_triage https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080211/26b7ffbd/signature.pgp From robla at lindenlab.com Mon Feb 11 18:05:52 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 11 18:06:04 2008 Subject: [sldev] Re: [JIRA] Created: (VWR-4794) Babble loop for voicevisualization In-Reply-To: <47B0FE09.2030501@lindenlab.com> References: <10755251.1202692788848.JavaMail.root@lindenlab1><47B098C4.30109@watson.ibm.com> <47B0FE09.2030501@lindenlab.com> Message-ID: <47B0FF00.1020001@lindenlab.com> One other thing: thanks! This looks like a really cool contribution. Rob On 2/11/08 6:01 PM, Rob Lanphier wrote: > On 2/11/08 10:49 AM, Mike Monkowski wrote: >> I've added a "New Feature" to the JIRA with the patch files, but I >> can't figure out how to mark it as "Patch Attached." I know how to >> do it for bugs, but that option doesn't seem to be available for >> features. I know that reports with patches get more attention than >> those without. Anyone know how to do it? > Yeah, it's under the "Advanced" tab as you're filing/editing the > issue. I tucked away several of the oft-misused fields into that tab > when I reconfigured things in December. > >> Also, do "New Feature" reports get triaged? What's the route to >> getting them incorporated into the official release? (The Linden >> contribution agreement is in the mail.) At one time this was one of >> the "Linden Lab Bounties," >> http://wiki.secondlife.com/wiki/Talk:Linden_Lab_Bounties so I expect >> someone might be interested in it. > > Patches generally show up on the Monday triage list, and any feature > that has a patch associated with it is a welcome agenda item for the > open source meeting on Thursday, as well. > https://wiki.secondlife.com/wiki/Bug_triage > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > Rob > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080211/a842f464/signature.pgp From tateru.nino at gmail.com Mon Feb 11 18:12:40 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Feb 11 18:15:18 2008 Subject: [sldev] Notifications redesign In-Reply-To: <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> Message-ID: <47B10098.7050406@weblogsinc.com> Undockable Notifications tab in the communicate window, accompanied by an onscreen indicator to show that there are pending notifications? Argent Stonecutter wrote: > Well, speaking as someone who has been doing control system > development for years, notifications (we call them alarms) are a Big > Deal. > > Typically in a control system you can: > > * View current (unacknowledged) alarms in a list. > * View individual alarm details. > * Review recent acknowledged or unacknowledged alarms. > * Filter alarms. > * Acknowledge individual alarms, all displayed alarms (subject to > filter), all non-critical alarms, and all alarms of an individual class. > > I have long wished that computer software for desktops had these kinds > of tools, rather than just displaying each individual notification as > a separate dialog box. In SL, where you can have many many pending > notification (unacknowledged alarms) this is even more critical. > > _______________________________________________ > 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 secret.argent at gmail.com Mon Feb 11 20:14:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Feb 11 20:14:21 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B10098.7050406@weblogsinc.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B10098.7050406@weblogsinc.com> Message-ID: On 2008-02-11, at 20:12, Tateru Nino wrote: > Undockable Notifications tab in the communicate window, accompanied > by an onscreen indicator to show that there are pending notifications? That sounds good. Perhaps with an email style layout, list of pending notifications on the left, and the current notification on the right? From email at secondlifepmsands.com Mon Feb 11 21:03:10 2008 From: email at secondlifepmsands.com (email@secondlifePMsands.com) Date: Mon Feb 11 21:03:08 2008 Subject: [sldev] Re: Notifications redesign In-Reply-To: <20080212011308.F1EAC41B336@stupor.lindenlab.com> References: <20080212011308.F1EAC41B336@stupor.lindenlab.com> Message-ID: I look forward to using the planned features you described. Sounds great. Thanks Q. 1 cent: Would be helpful to me (for lesser important group notifications, etc) if I could use some sort of roll out (auto hide) dock to organize hud gadgets (+button link to ll provided mySLmail page), (+ button to backup inventory to my local drive) ?err, sorry for the escalating expectations. (wait, my favorite button would be a button that would send an electric jolt every time that guy kept replying to this mail list a month ago to be removed, then he would get more angry when he would not be removed by the fictional python mail list admin ?to clarify, I would like a button that is able to go back in time and zap that guy) o:0 (and another button to go forward in time and thwart out of office auto replies to this mail list). =========================? ? PM Sands?? SL Consulting Linden Lab Solution Provider Full Service Company secondlifePMsands.com? ========================= Message: 1 Date: Mon, 11 Feb 2008 18:24:14 -0500 From: "Kent Quirk (Q Linden)" Subject: [sldev] Notifications redesign To: Second Life Developer Mailing List Message-ID: <47B0D91E.9060402@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, folks. We're about to embark on a project to redesign the way that notifications and alerts work in the SL client. I wanted to tell people that we're looking at it and give you a chance to get in your two cents while it's still early. Notifications and Alerts are the boxes that pop up on external events, from the little temporary ones in the lower right corner to the things that warn you when someone wants to take money from you. They have several problems that need a redesign and reimplementation. These include: * Code shortcomings: o Group notifications and Notifications have two separate code paths for very similar behavior + there's some awkward code to make them more similar + they fight with each other for priority display, and in certain weird instances could cause viewer to crash o Alerts can't take server-side parameters and still be translatable * UI shortcomings: o The way alerts and notifications stack up is highly confusing, especially for new residents o Too many different places on screen to look for messages o They could use a new graphical appearance, particularly to be compatible with http://wiki.secondlife.com/wiki/Dazzle o Too much detail up front for new users -- would be nice to allow summary / detail levels o Reduce the potential for griefing through scripted object notifications o No differentiation between system (Linden)-created notifications and resident created/initiated notifications o The discoverability is low on how to scroll through Active Notifications; or dismiss Passive ones early (Did you know you can?) * Functionality shortcomings: o No history- so if a notification is missed it can not be recovered + If the client is exited or crashes with active notifications they are lost along with attached inventory o No way to get additional information from a passive notification o No hyperlinks in notifications With that in mind, my intent is to: 1) Redesign the API for notifications and alerts. First, we'll unify the call structure so that all notifications and alerts go through a single unified call looking something vaguely like: NotificationSystem::displayNotification(string notificationname, LLSD data) This first pass will simply unify the call structure and the input XML files so that all notifications go through this path. That change should only be of interest to the people working in the source; there will be essentially no user-visible changes from that change. 2) Next is to unify the rendering process so as to eliminate the old LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also change the rendering so that we'll only render the "top" notification(s) in the queue, rather than rendering them all. This will also give us an improved ability to scroll back and forth through the list of pending notifications. There will be some user-visible changes at this point to bring out some new features in the API and make the existing notifications fit with the evolving look and feel of the UI. But my intent is that they'll be relatively minor and noncontroversial. 3) Then we'll want to do a full revisit of the rendering code for notifications which will almost certainly change the way they work in ways that should improve usability and reduce the potential for griefing. Our Resident Experience team will be developing a unified design for the system, and as they design it we'll want to bounce it off people here in advance before we code it. In the long run (which -- fair warning -- is several months away), we hope to have a notification code path that is comprehensible, extensible, localizable, and unified, as well as a UI that is attractive and works well. So we'd dearly love your constructive feedback, in particular if you think there are additional considerations I haven't mentioned. Thanks, Q From timelessprototype at gmail.com Mon Feb 11 23:40:08 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Mon Feb 11 23:39:53 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: <47B14D58.3090209@gmail.com> Hi * No way to temporarily hide/minimize or move the notification out the way (goes for dialogs too). * Online notifications - option to disable the notification (as there is now) and a further option to prevent online/offline notifications from locking up my client. * Make sure that keyboard users can do everything in SL without a mouse and likewise, vice versa. The rest of what you're saying sounds awesome. - Timeless Kent Quirk (Q Linden) wrote: > Hi, folks. We're about to embark on a project to redesign the way that > notifications and alerts work in the SL client. I wanted to tell > people that we're looking at it and give you a chance to get in your > two cents while it's still early. > > Notifications and Alerts are the boxes that pop up on external events, > from the little temporary ones in the lower right corner to the things > that warn you when someone wants to take money from you. They have > several problems that need a redesign and reimplementation. These > include: > > * Code shortcomings: > o Group notifications and Notifications have two separate > code paths for very similar behavior > + there's some awkward code to make them more similar > + they fight with each other for priority display, and > in certain weird instances could cause viewer to crash > o Alerts can't take server-side parameters and still be > translatable > * UI shortcomings: > o The way alerts and notifications stack up is highly > confusing, especially for new residents > o Too many different places on screen to look for messages > o They could use a new graphical appearance, particularly to > be compatible with http://wiki.secondlife.com/wiki/Dazzle > o Too much detail up front for new users -- would be nice to > allow summary / detail levels > o Reduce the potential for griefing through scripted object > notifications > o No differentiation between system (Linden)-created > notifications and resident created/initiated notifications > o The discoverability is low on how to scroll through Active > Notifications; or dismiss Passive ones early (Did you know you can?) > * Functionality shortcomings: > o No history- so if a notification is missed it can not be > recovered > + If the client is exited or crashes with active > notifications they are lost along with attached inventory > o No way to get additional information from a passive > notification > o No hyperlinks in notifications > > With that in mind, my intent is to: > > 1) Redesign the API for notifications and alerts. First, we'll unify > the call structure so that all notifications and alerts go through a > single unified call looking something vaguely like: > NotificationSystem::displayNotification(string > notificationname, LLSD data) > This first pass will simply unify the call structure and the input XML > files so that all notifications go through this path. That change > should only be of interest to the people working in the source; there > will be essentially no user-visible changes from that change. > > 2) Next is to unify the rendering process so as to eliminate the old > LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also > change the rendering so that we'll only render the "top" > notification(s) in the queue, rather than rendering them all. This > will also give us an improved ability to scroll back and forth through > the list of pending notifications. There will be some user-visible > changes at this point to bring out some new features in the API and > make the existing notifications fit with the evolving look and feel of > the UI. But my intent is that they'll be relatively minor and > noncontroversial. > > 3) Then we'll want to do a full revisit of the rendering code for > notifications which will almost certainly change the way they work in > ways that should improve usability and reduce the potential for > griefing. Our Resident Experience team will be developing a unified > design for the system, and as they design it we'll want to bounce it > off people here in advance before we code it. > > In the long run (which -- fair warning -- is several months away), we > hope to have a notification code path that is comprehensible, > extensible, localizable, and unified, as well as a UI that is > attractive and works well. > > So we'd dearly love your constructive feedback, in particular if you > think there are additional considerations I haven't mentioned. > > Thanks, > > Q > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From bboomslang at googlemail.com Tue Feb 12 07:10:42 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Tue Feb 12 07:10:49 2008 Subject: [sldev] Notifications redesign In-Reply-To: References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B10098.7050406@weblogsinc.com> Message-ID: <347b550f0802120710u6eeed5nf4c55c9a4c91de65@mail.gmail.com> On 2/12/08, Argent Stonecutter wrote: > On 2008-02-11, at 20:12, Tateru Nino wrote: > > Undockable Notifications tab in the communicate window, accompanied > > by an onscreen indicator to show that there are pending notifications? > That sounds good. Perhaps with an email style layout, list of pending > notifications on the left, and the current notification on the right? And please, please, please make unacknowledged notifications/alarms persistent over sessions. Just keep them in a clientside table and merge unacknowledged ones into the notification window on next login. There is nothing more irritating then crashing right on login before you can ack or nack the notifications ... bye, Barney From ordinal.malaprop at fastmail.fm Tue Feb 12 08:04:59 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Feb 12 08:05:15 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: A packet injection exploit was demonstrated to me recently, which could send arbitrary blue box announcements to somebody else (not the usual llDialog boxes, the top-right and bottom-right ones). I don't actually know how this works apart from using some libsl component to add outgoing packets - this really isn't my area of expertise - but it does. Is this known about? On 11 Feb 2008, at 23:24, Kent Quirk (Q Linden) wrote: > Hi, folks. We're about to embark on a project to redesign the way > that notifications and alerts work in the SL client. I wanted to > tell people that we're looking at it and give you a chance to get in > your two cents while it's still early. > > Notifications and Alerts are the boxes that pop up on external > events, from the little temporary ones in the lower right corner to > the things that warn you when someone wants to take money from you. > They have several problems that need a redesign and > reimplementation. These include: > > * Code shortcomings: > o Group notifications and Notifications have two separate > code paths for very similar behavior > + there's some awkward code to make them more similar > + they fight with each other for priority display, and > in certain weird instances could cause viewer to crash > o Alerts can't take server-side parameters and still be > translatable > * UI shortcomings: > o The way alerts and notifications stack up is highly > confusing, especially for new residents > o Too many different places on screen to look for messages > o They could use a new graphical appearance, particularly to > be compatible with http://wiki.secondlife.com/wiki/Dazzle > o Too much detail up front for new users -- would be nice to > allow summary / detail levels > o Reduce the potential for griefing through scripted object > notifications > o No differentiation between system (Linden)-created > notifications and resident created/initiated notifications > o The discoverability is low on how to scroll through Active > Notifications; or dismiss Passive ones early (Did you know you can?) > * Functionality shortcomings: > o No history- so if a notification is missed it can not be > recovered > + If the client is exited or crashes with active > notifications they are lost along with attached inventory > o No way to get additional information from a passive > notification > o No hyperlinks in notifications > > With that in mind, my intent is to: > > 1) Redesign the API for notifications and alerts. First, we'll unify > the call structure so that all notifications and alerts go through a > single unified call looking something vaguely like: > NotificationSystem::displayNotification(string > notificationname, LLSD data) > This first pass will simply unify the call structure and the input > XML files so that all notifications go through this path. That > change should only be of interest to the people working in the > source; there will be essentially no user-visible changes from that > change. > > 2) Next is to unify the rendering process so as to eliminate the old > LLNotifyBox, LLGroupNotifyBox, and LLAlertDialog classes. We'll also > change the rendering so that we'll only render the "top" > notification(s) in the queue, rather than rendering them all. This > will also give us an improved ability to scroll back and forth > through the list of pending notifications. There will be some user- > visible changes at this point to bring out some new features in the > API and make the existing notifications fit with the evolving look > and feel of the UI. But my intent is that they'll be relatively > minor and noncontroversial. > > 3) Then we'll want to do a full revisit of the rendering code for > notifications which will almost certainly change the way they work > in ways that should improve usability and reduce the potential for > griefing. Our Resident Experience team will be developing a unified > design for the system, and as they design it we'll want to bounce it > off people here in advance before we code it. > > In the long run (which -- fair warning -- is several months away), > we hope to have a notification code path that is comprehensible, > extensible, localizable, and unified, as well as a UI that is > attractive and works well. > > So we'd dearly love your constructive feedback, in particular if you > think there are additional considerations I haven't mentioned. > > Thanks, > > Q > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Tue Feb 12 08:05:39 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 12 08:05:52 2008 Subject: [sldev] Notifications redesign In-Reply-To: <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> Message-ID: <47B1C3D3.3050106@gmail.com> Argent Stonecutter wrote: > Well, speaking as someone who has been doing control system development > for years, notifications (we call them alarms) are a Big Deal. You bet. My only concern with this unified manager is that communication of severity becomes a little trickier. If we flood it with every "failed to rez because your camera wasn't pointing at the floor just right", or "you entered a different region version"... people will just ignore it. I look forward to your input there, I know management of severity of messages is big in industrial engineering. -Jason From sv193702 at ohio.edu Tue Feb 12 09:27:52 2008 From: sv193702 at ohio.edu (Stan Vernier) Date: Tue Feb 12 09:35:35 2008 Subject: [sldev] finding out the uuid of a newly created object Message-ID: <47B1D718.4040105@ohio.edu> I'm trying to automatically create an object and then retain control of it so that I can add a texture, color, etc. I currently know how to manipulate an object given a handle of it via LLViewerObject and I know how to simulate a message to create an object with custom size/shape. But I don't know how to merge these two together. Creation of the object doesn't seem to have a way to retain a reference to the object without the edit window or something similar in place. Is there a global list that contains visible objects that I can look through, or would I be able to somehow create an event for when a new object is created? From secret.argent at gmail.com Tue Feb 12 09:49:56 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 12 09:50:10 2008 Subject: [sldev] Notifications redesign In-Reply-To: <347b550f0802120710u6eeed5nf4c55c9a4c91de65@mail.gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B10098.7050406@weblogsinc.com> <347b550f0802120710u6eeed5nf4c55c9a4c91de65@mail.gmail.com> Message-ID: On 2008-02-12, at 09:10, Barney Boomslang wrote: > And please, please, please make unacknowledged notifications/alarms > persistent over sessions. Just keep them in a clientside table and > merge unacknowledged ones into the notification window on next login. Oh, christ, yes. And do that for scripts you're editing as well (while I'm wishing). From secret.argent at gmail.com Tue Feb 12 09:59:28 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 12 09:59:38 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B1C3D3.3050106@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> Message-ID: <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> On 2008-02-12, at 10:05, Jason Giglio wrote: > My only concern with this unified manager is that communication of > severity becomes a little trickier. That's also something that is really big. Normally critical alarms are bubbled to the top of the list, and you often can't bulk-ack critical ones (so you use "ack all" to get rid of the non-critical alarms). You can also have multiple windows, panes, or tabs and you may have to take some special action to even bring up non-critical alarm displays while critical ones are unacknowledged. Critical alerts would be ones that could cost you money. The alarm log should probably go into chat log (and by the way I like having the URL of teleports in the chat log, that's an easy and clever way to handle teleport history... though that should really be a secondlife: URL and not a SLURL). For events that aren't acked, the slider in the corner is fine but after they're shown they should ALL go into chat history. Chat history should have a button to hide/show chat from events and objects, like it has hide/show mute now. From teravus at gmail.com Tue Feb 12 09:42:47 2008 From: teravus at gmail.com (Teravus Ovares) Date: Tue Feb 12 10:41:12 2008 Subject: [sldev] finding out the uuid of a newly created object In-Reply-To: <47B1D718.4040105@ohio.edu> References: <47B1D718.4040105@ohio.edu> Message-ID: <34cc66250802120942w2af01314vcc7d7c2d3400c2ac@mail.gmail.com> When you create an object, you get a full object update with flags that include the CreateSelected flag "0x00000002". I'm not sure how to do it within the client source, however, the protocol allows for you to be able to locate the object you created with the CreateSelected flag in the object flags. -Teravus On 2/12/08, Stan Vernier wrote: > > I'm trying to automatically create an object and then retain control of > it so that I can add a texture, color, etc. I currently know how to > manipulate an object given a handle of it via LLViewerObject and I know > how to simulate a message to create an object with custom size/shape. > But I don't know how to merge these two together. Creation of the > object doesn't seem to have a way to retain a reference to the object > without the edit window or something similar in place. Is there a > global list that contains visible objects that I can look through, or > would I be able to somehow create an event for when a new object is > created? > _______________________________________________ > 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/20080212/30d0e815/attachment.htm From sv193702 at ohio.edu Tue Feb 12 11:23:44 2008 From: sv193702 at ohio.edu (Stan Vernier) Date: Tue Feb 12 11:59:43 2008 Subject: [sldev] finding out the uuid of a newly created object In-Reply-To: <34cc66250802120942w2af01314vcc7d7c2d3400c2ac@mail.gmail.com> References: <47B1D718.4040105@ohio.edu> <34cc66250802120942w2af01314vcc7d7c2d3400c2ac@mail.gmail.com> Message-ID: <47B1F240.3060101@ohio.edu> Sounds like a good place to start looking. Thanks for the tip. Teravus Ovares wrote: > When you create an object, you get a full object update with flags > that include the CreateSelected flag "0x00000002". I'm not sure how > to do it within the client source, however, the protocol allows for > you to be able to locate the object you created with the > CreateSelected flag in the object flags. > -Teravus > > > On 2/12/08, *Stan Vernier* > wrote: > > I'm trying to automatically create an object and then retain > control of > it so that I can add a texture, color, etc. I currently know how to > manipulate an object given a handle of it via LLViewerObject and I > know > how to simulate a message to create an object with custom size/shape. > But I don't know how to merge these two together. Creation of the > object doesn't seem to have a way to retain a reference to the object > without the edit window or something similar in place. Is there a > global list that contains visible objects that I can look through, or > would I be able to somehow create an event for when a new object > is created? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From robla at lindenlab.com Tue Feb 12 14:59:09 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 12 14:59:25 2008 Subject: [sldev] Notifications redesign In-Reply-To: <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> Message-ID: <47B224BD.7010900@lindenlab.com> On 2/12/08 9:59 AM, Argent Stonecutter wrote: > On 2008-02-12, at 10:05, Jason Giglio wrote: >> My only concern with this unified manager is that communication of >> severity becomes a little trickier. > > That's also something that is really big. > > Normally critical alarms are bubbled to the top of the list, and you > often can't bulk-ack critical ones (so you use "ack all" to get rid of > the non-critical alarms). You can also have multiple windows, panes, > or tabs and you may have to take some special action to even bring up > non-critical alarm displays while critical ones are unacknowledged. > > Critical alerts would be ones that could cost you money. > > The alarm log should probably go into chat log (and by the way I like > having the URL of teleports in the chat log, that's an easy and clever > way to handle teleport history... though that should really be a > secondlife: URL and not a SLURL). > > For events that aren't acked, the slider in the corner is fine but > after they're shown they should ALL go into chat history. > > Chat history should have a button to hide/show chat from events and > objects, like it has hide/show mute now. Are there any open source desktop apps (or for that matter, any desktop apps) that handle notifications correctly in your book? Not being snarky...I'm really interested in examples. 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/20080212/f1ca4fc5/signature.pgp From secret.argent at gmail.com Tue Feb 12 17:47:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 12 17:47:49 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B224BD.7010900@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B224BD.7010900@lindenlab.com> Message-ID: <62B8480A-D44F-4AF4-96B1-B11AD2ECFDDA@gmail.com> On 2008-02-12, at 16:59, Rob Lanphier wrote: > Are there any open source desktop apps (or for that matter, any > desktop apps) that handle notifications correctly in your book? I am not aware of any desktop software that handles notifications really well. Ideally this should be handled by the OS, or by a common notification framework like Growl on the Mac. In fact I'd have to say that Growl is about the closest to the right kind of framework to make it possible to really do a good job with notifications on the desktop. The main problem is that alarms in control systems are a log, and desktop operating systems don't integrate notifications and logs at all. Both the Windows event log and UNIX syslog have some potential to be used that way. Of course most of what currently gets logged in either of these have to be treated as non-critical, because if they were critical they'd have called a panic or a system stop instead. :) I certainly don't have all the answers, either, but I am heartened by the fact that you're interested in the question. :) From lenglish5 at cox.net Tue Feb 12 18:57:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Feb 12 18:57:09 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B0D91E.9060402@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> Message-ID: <47B25C82.9060307@cox.net> Kent Quirk (Q Linden) wrote: [...] > In the long run (which -- fair warning -- is several months away), we > hope to have a notification code path that is comprehensible, > extensible, localizable, and unified, as well as a UI that is > attractive and works well. > > So we'd dearly love your constructive feedback, in particular if you > think there are additional considerations I haven't mentioned. > > Thanks, > > Q > > Please do away with the design philosophy that led to the existence of the Dialog flag byte in the ImprovedInstantMessage packet. While you are trying to make the user interface work better, its STILL not a good idea to slave the protocol and the user interface together that way. Consider abstracting things so that different user interfaces done by different companies and individuals might rationally be built on top of the same notification system. Lawson From tateru.nino at gmail.com Tue Feb 12 21:11:34 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Feb 12 21:14:15 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B1C3D3.3050106@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> Message-ID: <47B27C06.5040902@gmail.com> Jason Giglio wrote: > Argent Stonecutter wrote: >> Well, speaking as someone who has been doing control system >> development for years, notifications (we call them alarms) are a Big >> Deal. > > > You bet. > > My only concern with this unified manager is that communication of > severity becomes a little trickier. > > If we flood it with every "failed to rez because your camera wasn't > pointing at the floor just right", or "you entered a different region > version"... people will just ignore it. > > I look forward to your input there, I know management of severity of > messages is big in industrial engineering. > Seems to me there's a fairly firm dividing line already in evidence in message severity: * Messages that do not require any action on your part * Messages that require you to make a choice and respond. 'offers' seem to be about half-way - part informational, and part choice. I'd say they fall clearly into the second category. A third category is administrative notices/alerts from estate managers, grid-monkeys and the like. If it were me - actually when the new system rolls out, I guess it will be me - I'd like to see an option to suppress the informational messages as popups, and have them just run straight to the chat history instead of appearing in the notification floater or popping up. Choice/decision messages I'd like to be able to suppress them popping up, but still have them appear in the notification floater. Administrative alerts, I'd like to still see pop up, appear in the notifications floater, and in the chat history. From rdw at lindenlab.com Tue Feb 12 22:34:56 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Feb 12 22:35:05 2008 Subject: [sldev] Notifications redesign In-Reply-To: <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> Message-ID: <47B28F90.1060505@lindenlab.com> Argent Stonecutter wrote: > The alarm log should probably go into chat log (and by the way I like > having the URL of teleports in the chat log, that's an easy and clever > way to handle teleport history... though that should really be a > secondlife: URL and not a SLURL). > Speaking purely personally, I'd rather we didn't put more into the chat log. I like to use the chat log for, well, chat. I feel like it's almost to the point where I need a perl script just to parse my log and tell me what was said in the last 5 minutes, instead of poking through a jillion friend notifications, voice connection status, etc. Hell, I do use a perl script to generate transcripts for my office hours. Perhaps there could be a distinction between all events that have happened to you and the actual spoken-by-avatars chat history. Or, to propose a pony that is probably needlessly generic, chat log filtering by type. Yes, I know, wah wah wah. Just wanted to throw my two cents in here. Oh and I agree that it should be a secondlife: url. -RYaN From kamilion at gmail.com Tue Feb 12 23:51:30 2008 From: kamilion at gmail.com (Kamilion) Date: Tue Feb 12 23:51:47 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B28F90.1060505@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B28F90.1060505@lindenlab.com> Message-ID: On Feb 12, 2008 10:34 PM, Ryan Williams (Which) wrote: > Speaking purely personally, I'd rather we didn't put more into the chat > log. I like to use the chat log for, well, chat. I feel like it's > almost to the point where I need a perl script just to parse my log and > tell me what was said in the last 5 minutes, instead of poking through a > jillion friend notifications, voice connection status, etc. Why not split all of the non-chat out from Near Me to an Event Log tab? Anything that can be answered via script dialogs should be highlighted like a URL and clickable. [18:32] Kamilion Schnook has offered you "Object". Accept? [YES] [NO] In this example, Kamilion Schnook should be highlighted as a URL (Zi's patches). YES should be highlighted as a URL and accepts the item. NO should be highlighted as a URL and declines the item. Eventually, this could be extended to script dialogs as well, so you could see neat stuff like: [18:33] Object Dialog - Item Server: Please make a selection... [Reset Main] [Reset Monitor] [Reset Display] [Trigger HTTP] [Update Inventory] Clicking on one of the responses will send the reply on the specified dialog channel once, and then dismiss the event as acknowledged so it cannot be replied to a second time. Prefix events with a type. For instance: Voice Notification: Connected to in-world voice channel. Online Notification: Kamilion Schnook is online. Offline Notification: Kamilion Schnook is offline. Estate Message from Kamilion Schnook: Hey guys, you're lagging the sim, triggering a restart in 2 mins. Estate Message from Euphoria Island: Region is restarting in 2 minutes. If you remain in this region, you will be logged off. Inventory Offer: Kamilion Schnook has offered you "Object". Accept? [YES] [NO] Balance Changed: You have paid Kamilion Schnook L$50 for "Object". Balance Changed: Kamilion Schnook has paid you L$5000 for "Euphoria Island Parcel 3" Script Error: Kamilion Schnook's "Object" has generated an error: Stack/Heap Collision Group Membership: You have been removed from the group "Euphoria Estates". Teleport: You have teleported from Euphoria Island II <123,21,22> to Euphoria Island <12,12,620>. URL links should be placed obviously. Groups should bring up the group UI, Object names should link to SLURLs to their position, Avatar names should work like Zi's patch. Any dialog button should be able to be displayed as a text URL. Personally, I'd like to see the L$ spent/received notification move to being a text event versus it's current nature as a Notification dialog. It's really a pain in the butt to pay a vendor then end up clicking Decline on the item offer when you're aiming to dismiss the payment dialog instead. And I can't stress this one enough: Release Keys needs to be moved off into a menu. I've used it intentionally twice in the 3 years I've been inworld, it really doesn't need to be staring me in the face whenever I have my mystitool attached. (Which is always... Teleport history FTW!) Just adding my two cents to the pot. Whoever implements gets to cash-out! ;) --Kamilion From annagulaev at gmail.com Wed Feb 13 00:34:06 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Wed Feb 13 00:34:10 2008 Subject: [sldev] What's so special about grass? Message-ID: Stinkin' weeds :-) I don't seem to be able to keep grass from rendering using the same mechanism that I use for everything else. I removed the RenderType check (which did include grass) and I can then visually mute everyting--prims, ground, sky, trees, you name it--except grass. Is grass not in the global object list? Does it not generate object updates? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080213/a854e5e0/attachment.htm From Celierra at gmail.com Wed Feb 13 00:52:53 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Feb 13 00:52:56 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B28F90.1060505@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B28F90.1060505@lindenlab.com> Message-ID: On Feb 13, 2008 1:34 AM, Ryan Williams (Which) wrote: > Argent Stonecutter wrote: > > The alarm log should probably go into chat log (and by the way I like > > having the URL of teleports in the chat log, that's an easy and clever > > way to handle teleport history... though that should really be a > > secondlife: URL and not a SLURL). > > > Speaking purely personally, I'd rather we didn't put more into the chat > log. I like to use the chat log for, well, chat. I feel like it's > almost to the point where I need a perl script just to parse my log and > tell me what was said in the last 5 minutes, instead of poking through a > jillion friend notifications, voice connection status, etc. Hell, I do > use a perl script to generate transcripts for my office hours. Perhaps > there could be a distinction between all events that have happened to > you and the actual spoken-by-avatars chat history. Or, to propose a > pony that is probably needlessly generic, chat log filtering by type. > > Yes, I know, wah wah wah. Just wanted to throw my two cents in here. > > Oh and I agree that it should be a secondlife: url. > > -RYaN > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > It sounds like we'd want both a chat log and an "event log", where the event log can sometimes be integrated into the chat log if desired (maybe like IMs can be now). And the current usage of the "Near Me" tab seems a bit incongruous with its name - it's logging events too, so it's handling things that aren't necessarily 'near me'. To kill multiple birds with a stone, I might suggest offering 'Communicate' tabs with functions like: - Full history - Nearby chat - Event log (maybe not as part of "Communicate") - All chat (maybe?) The history tab could have the current usage of "Near Me" (chat + all events), while a different tab would now truly mean 'just chat occurring around me'. The event log and "all chat" are complements of each other, though I'm not sure "all chat" would really be so useful (and thus the 'maybe' note). I'm also not sure of how these should be logged. It could be done in one big file; I think a bunch of IM programs use XML for event logging amongst the chat. Or, maybe "all chat" should go into 'chat.txt', and all events into some other file. Cel From sldev at free.fr Wed Feb 13 03:01:48 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Feb 13 03:01:50 2008 Subject: [sldev] Sources for WindLight v1.19.0.79674 ? Message-ID: <20080213120148.7d129cde.sldev@free.fr> As usual, the new Windlight is made available as binaries but the sources are nowhere to be found (neither on the Wiki nor on the TRAC)... Could you please post the sources quickly (today) ? From Anders at Arnholm.se Wed Feb 13 03:14:59 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Feb 13 03:15:22 2008 Subject: [sldev] Sources for WindLight v1.19.0.79674 ? In-Reply-To: <20080213120148.7d129cde.sldev@free.fr> References: <20080213120148.7d129cde.sldev@free.fr> Message-ID: <20080213111459.GP22141@arnholm.se> On Wed, Feb 13, 2008 at 12:01:48PM +0100, Henri Beauchamp wrote: > As usual, the new Windlight is made available as binaries but the sources > are nowhere to be found (neither on the Wiki nor on the TRAC)... I recomend that Linden labs looks over there publishing ruities to secure the quality, if you can't make sure taht the code for the release get out at the same time that the binaries, how can one be sure that one holds the knowleage to reproduce the build? Releasing code should teoretically be a quicker and easier process that the binary build. / 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/20080213/a7515252/attachment.pgp From secret.argent at gmail.com Wed Feb 13 05:29:11 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 13 05:29:35 2008 Subject: [sldev] Notifications redesign In-Reply-To: <47B28F90.1060505@lindenlab.com> References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B28F90.1060505@lindenlab.com> Message-ID: <63D8DE40-7FCD-468F-9187-D0A3677C46FB@gmail.com> On 2008-02-13, at 00:34, Ryan Williams (Which) wrote: > Argent Stonecutter wrote: >> The alarm log should probably go into chat log (and by the way I >> like having the URL of teleports in the chat log, that's an easy >> and clever way to handle teleport history... though that should >> really be a secondlife: URL and not a SLURL). > Speaking purely personally, I'd rather we didn't put more into the > chat log. I understand your consternation, which is why I suggested that a button be added to filter out everything but chat, an endeavor that would be easier in the log itself. Speaking for myself, I must agree with you that filtering by type would be much preferred (and in fact that is typically what one is able to do in real time alarm logs) but I suspect that most users would prefer a simple button to hide the chatter and concentrate on the chat. On the other hand, now that Apple has popularized a rather nice filtering interface in iTunes (and extended it in Spotlight), perhaps it would be worthwhile to make the logs more generic. Define a "log window" that subsumes both chat and IM logs, and add a little "+" button in the corner that allows you to add lines of iTunes smart playlist style filters to them. Oh, and such an interface would not go amiss in the Inventory window as well. :) From zha.ewry at gmail.com Wed Feb 13 05:32:16 2008 From: zha.ewry at gmail.com (Zha Ewry) Date: Wed Feb 13 05:32:20 2008 Subject: [sldev] Notifications redesign In-Reply-To: References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B28F90.1060505@lindenlab.com> Message-ID: <920d7d850802130532p35e30d7gafaedabec959e73c@mail.gmail.com> If I'm reading this correctly, the implication is that the only place to process these would be the event log. Given how fast things sometimes come roaring by, I'm thinking that this would have implications on both the client and sims. Users could end up missing things they cared about, in the scrolling log, and for actionable ones, the sim could end up with that much more stale state to handle. I also, worry, a fair bit about screen real estate. The current scheme, awkward tho it is, keeps it all dense. The non immersive stuff, such as this, the chat box, etc. sometimes overwhelms the core interaction window, and making that worse, is unappealing. ~ Zha On Feb 13, 2008 2:51 AM, Kamilion wrote: > On Feb 12, 2008 10:34 PM, Ryan Williams (Which) wrote: > > Speaking purely personally, I'd rather we didn't put more into the chat > > log. I like to use the chat log for, well, chat. I feel like it's > > almost to the point where I need a perl script just to parse my log and > > tell me what was said in the last 5 minutes, instead of poking through a > > jillion friend notifications, voice connection status, etc. > > Why not split all of the non-chat out from Near Me to an Event Log tab? > Anything that can be answered via script dialogs should be highlighted > like a URL and clickable. > [18:32] Kamilion Schnook has offered you "Object". Accept? [YES] [NO] > In this example, Kamilion Schnook should be highlighted as a URL (Zi's > patches). > YES should be highlighted as a URL and accepts the item. > NO should be highlighted as a URL and declines the item. > > Eventually, this could be extended to script dialogs as well, so you > could see neat stuff like: > [18:33] Object Dialog - Item Server: Please make a selection... [Reset > Main] [Reset Monitor] [Reset Display] [Trigger HTTP] [Update > Inventory] > > Clicking on one of the responses will send the reply on the specified > dialog channel once, and then dismiss the event as acknowledged so it > cannot be replied to a second time. > > > Prefix events with a type. > For instance: > Voice Notification: Connected to in-world voice channel. > Online Notification: Kamilion Schnook is online. > Offline Notification: Kamilion Schnook is offline. > Estate Message from Kamilion Schnook: Hey guys, you're lagging the > sim, triggering a restart in 2 mins. > Estate Message from Euphoria Island: Region is restarting in 2 > minutes. If you remain in this region, you will be logged off. > Inventory Offer: Kamilion Schnook has offered you "Object". Accept? [YES] > [NO] > Balance Changed: You have paid Kamilion Schnook L$50 for "Object". > Balance Changed: Kamilion Schnook has paid you L$5000 for "Euphoria > Island Parcel 3" > Script Error: Kamilion Schnook's "Object" has generated an error: > Stack/Heap Collision > Group Membership: You have been removed from the group "Euphoria Estates". > Teleport: You have teleported from Euphoria Island II <123,21,22> to > Euphoria Island <12,12,620>. > > URL links should be placed obviously. Groups should bring up the group > UI, Object names should link to SLURLs to their position, Avatar names > should work like Zi's patch. Any dialog button should be able to be > displayed as a text URL. > > Personally, I'd like to see the L$ spent/received notification move to > being a text event versus it's current nature as a Notification > dialog. It's really a pain in the butt to pay a vendor then end up > clicking Decline on the item offer when you're aiming to dismiss the > payment dialog instead. > > And I can't stress this one enough: Release Keys needs to be moved off > into a menu. I've used it intentionally twice in the 3 years I've been > inworld, it really doesn't need to be staring me in the face whenever > I have my mystitool attached. (Which is always... Teleport history > FTW!) > > Just adding my two cents to the pot. Whoever implements gets to cash-out! > ;) > --Kamilion > _______________________________________________ > 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/20080213/67f7a9a9/attachment.htm From secret.argent at gmail.com Wed Feb 13 05:57:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 13 05:57:29 2008 Subject: [sldev] Notifications redesign In-Reply-To: References: <47B0D91E.9060402@lindenlab.com> <08647FF8-EA42-4810-ABE1-380F9948A2B1@gmail.com> <47B1C3D3.3050106@gmail.com> <7B2A2BAA-EFDC-48B2-A3E9-61E9F447E74A@gmail.com> <47B28F90.1060505@lindenlab.com> Message-ID: <1736374D-7025-4A23-B8FD-EA42829468C6@gmail.com> On 2008-02-13, at 01:51, Kamilion wrote: > Why not split all of the non-chat out from Near Me to an Event Log > tab? I have mixed feelings about that, lest it suffer the fate of being hidden and ignored, but that would also work well. If it was hidden, the user would get something like the current dialogs. If displayed, the dialogs would be subsumed in the event log. > Anything that can be answered via script dialogs should be highlighted > like a URL and clickable. > [18:32] Kamilion Schnook has offered you "Object". Accept? [YES] [NO] > In this example, Kamilion Schnook should be highlighted as a URL > (Zi's patches). > YES should be highlighted as a URL and accepts the item. > NO should be highlighted as a URL and declines the item. I think, if possible, that these should be buttons (since they are actions) rather than URLS (links), and that once clicked they should go away. The event would perhaps change to: [18:32] Kamilion Schnook has offered you "Object". (18:33 - Accepted) Alternatively, the whole line could be a link that brings up the dialog (or replaces the currently displayed dialog, if there is one). > Eventually, this could be extended to script dialogs as well, so you > could see neat stuff like: > [18:33] Object Dialog - Item Server: Please make a selection... [Reset > Main] [Reset Monitor] [Reset Display] [Trigger HTTP] [Update > Inventory] One issue here is that people use dialogs as menus, and expect the dialog to come up when clicked, and they DO work well for that. In the absence of multiple pending events, then, I believe the dialog interface should remain by default. The existing three chevrons would cycle through unacknowledged dialogs. An additional button opposite "(ignore)" would bring up the event log. Allow me to suggest that the dialog itself be more customizable, perhaps even in XML: llXMLDialog(string title, string message, integer channel); llXMLDialog("Item server", "Reset: