From oz at lindenlab.com Fri Feb 1 08:59:34 2013 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 01 Feb 2013 11:59:34 -0500 Subject: [opensource-dev] LSL commands/parameters for light projectors In-Reply-To: <51091092.4050903@xp2.de> References: <51091092.4050903@xp2.de> Message-ID: <510BF476.60604@lindenlab.com> On 2013-01-30 07:22 , Tillie Ariantho wrote: > Hello, > > > my feature request BUG-1497 (see below) got closed (not applicable). Why that? Do we have so submit working patches for features requests? > > I think my request is pretty valid. > > > > *LSL commands for light projectors* > > Implementation of additional LSL command parameters: > > I would add parameters for llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast: > > Flag: PRIM_CAST_LIGHT > Description: Let the prim with activated point light cast shadows. > Usage: [ PRIM_CAST_LIGHT, key projection_texture, integer fov, integer focus, integer ambiance ] > > Texture, FOV, Focus and Ambiance are already properties of a prim, only they cannot get accessed via scripts yet. > > > > Why can't we set those parameters via scripts? > (caveat... I didn't even see that issue, or have anything to do with closing it, so this is personal speculation...) Whether or not light sources cast shadows is an independent user choice in the viewer, and we already have an option that allows projectors to cast shadows. From darien.caldwell at gmail.com Fri Feb 1 11:05:38 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri, 1 Feb 2013 11:05:38 -0800 Subject: [opensource-dev] LSL commands/parameters for light projectors In-Reply-To: <510BF476.60604@lindenlab.com> References: <51091092.4050903@xp2.de> <510BF476.60604@lindenlab.com> Message-ID: Sure but I don't think that's what the JIRA was about. It's not about forcing people to view shadows from light sources. It's about creators being able to programmically modify the newer light parameters. (see attached picture). Prim lights can be turned on and off, color changed, intensity changed, radius changed, falloff changed, all from a script. So why can't FOV, Focus, Ambiance, and the projected texture be changed too? It really limits the usefulness for products. On Fri, Feb 1, 2013 at 8:59 AM, Oz Linden (Scott Lawrence) wrote: > On 2013-01-30 07:22 , Tillie Ariantho wrote: > > Hello, > > > > > > my feature request BUG-1497 (see below) got closed (not applicable). Why > that? Do we have so submit working patches for features requests? > > > > I think my request is pretty valid. > > > > > > > > *LSL commands for light projectors* > > > > Implementation of additional LSL command parameters: > > > > I would add parameters for llSetLinkPrimitiveParams and > llSetLinkPrimitiveParamsFast: > > > > Flag: PRIM_CAST_LIGHT > > Description: Let the prim with activated point light cast shadows. > > Usage: [ PRIM_CAST_LIGHT, key projection_texture, integer fov, integer > focus, integer ambiance ] > > > > Texture, FOV, Focus and Ambiance are already properties of a prim, only > they cannot get accessed via scripts yet. > > > > > > > > Why can't we set those parameters via scripts? > > > > (caveat... I didn't even see that issue, or have anything to do with > closing it, so this is personal speculation...) > > Whether or not light sources cast shadows is an independent user choice > in the viewer, and we already have an option that allows projectors to > cast shadows. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130201/1beb751d/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: light params.jpg Type: image/jpeg Size: 41205 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130201/1beb751d/attachment-0001.jpg From tillie at xp2.de Fri Feb 1 11:24:09 2013 From: tillie at xp2.de (Tillie Ariantho) Date: Fri, 01 Feb 2013 20:24:09 +0100 Subject: [opensource-dev] LSL commands/parameters for light projectors In-Reply-To: References: <51091092.4050903@xp2.de> <510BF476.60604@lindenlab.com> Message-ID: <510C1659.7070808@xp2.de> Am 01.02.2013 20:05, schrieb Darien Caldwell: > Sure but I don't think that's what the JIRA was about. It's not about forcing people to view shadows from light sources. It's about creators being able to programmically modify the newer light > parameters. (see attached picture). Prim lights can be turned on and off, color changed, intensity changed, radius changed, falloff changed, all from a script. So why can't FOV, Focus, Ambiance, and > the projected texture be changed too? It really limits the usefulness for products. Yep, that was the idea. It's no new feature lightwise, it's just scriptifying what's already there. Tillie From qieniangao at gmail.com Fri Feb 1 12:21:53 2013 From: qieniangao at gmail.com (Qie Niangao) Date: Fri, 1 Feb 2013 15:21:53 -0500 Subject: [opensource-dev] LSL commands/parameters for light projectors Message-ID: Not sure if you can see the jira history for BUG-1497, but it's been linked (correctly) as a duplicate of a very old request, SCR-163. Perhaps the feature is in limbo until it's decided to "protect" the fragile rendering pipeline by neutering scripts in yet another way. > ---------- Forwarded message ---------- > From: Tillie Ariantho > To: opensource-dev at lists.secondlife.com > Cc: > Date: Fri, 01 Feb 2013 20:24:09 +0100 > Subject: Re: [opensource-dev] LSL commands/parameters for light projectors > Am 01.02.2013 20:05, schrieb Darien Caldwell: > >> Sure but I don't think that's what the JIRA was about. It's not about forcing people to view shadows from light sources. It's about creators being able to programmically modify the newer light >> parameters. (see attached picture). Prim lights can be turned on and off, color changed, intensity changed, radius changed, falloff changed, all from a script. So why can't FOV, Focus, Ambiance, and >> the projected texture be changed too? It really limits the usefulness for products. > > Yep, that was the idea. It's no new feature lightwise, it's just scriptifying what's already there. > > Tillie From sitearm at gmail.com Fri Feb 8 17:14:34 2013 From: sitearm at gmail.com (Sitearm) Date: Fri, 8 Feb 2013 19:14:34 -0600 Subject: [opensource-dev] MOSES Office Hours Screenshot 08-Feb-2013; OpenSim => Collada => Unity In-Reply-To: References: Message-ID: ; fyi (Chris Collins: Former Logan Linden, SL Enterprise developer; OpenSim: 2007 open source code version of SL) MOSES Office Hours Screenshot 08-Feb-2013 February 9, 2013 ? sitearm [image: office hours 08-feb-2013_001] *3-D Web* is the set of internet technologies that put user browsers in an online, interactive 3D environment. *Unity* is a cross-platform interactive development environment for games and applications distributed via mobile and web. *COLLADA* is a standard interchange file format for interactive 3D applications. *Hot topic* at today?s MOSES Office Hours was a *demonstration *by Chris Collins of *porting* MOSES *3D regions* from *OpenSim* via *COLLADA* to * Unity*, thus making them *more broadly accessible *by mobile pad and smart phone as well as by web laptop and desktop. *Selected Quotes* *This demonstration shows how we are able to allow collaborative user content to be generated via OpenSim and then distributed to a larger audience via Unity. *(Chris Collins, CEO, Tipodean Technologies) *This work opens access from the federal desktop to more approved networks for support, training, mission rehearsal, and meeting spaces. *(Douglas Maxwell, Science and Technology Manager, U.S. Army Research Lab) See also . http://en.wikipedia.org/wiki/OpenSimulator . http://en.wikipedia.org/wiki/Unity_(game_engine) . http://en.wikipedia.org/wiki/COLLADA . http://www.linkedin.com/in/collinschris . www.linkedin.com/pub/douglas-maxwell/a/79a/546 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130208/623aede0/attachment.htm From Lance.Corrimal at eregion.de Sat Feb 9 02:13:00 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 09 Feb 2013 11:13 +0100 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 Message-ID: <1939512.mTIxeILOt3@sai> hi, does anyone have anything for me about fixing up the source to build with glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses the newer glibc... for details, see BUG-1610 cheers, LC From nickyperian at yahoo.com Sat Feb 9 02:34:09 2013 From: nickyperian at yahoo.com (Nicky Perian) Date: Sat, 9 Feb 2013 02:34:09 -0800 (PST) Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <1939512.mTIxeILOt3@sai> References: <1939512.mTIxeILOt3@sai> Message-ID: <1360406049.87925.YahooMailNeo@web126105.mail.ne1.yahoo.com> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113b0db3effcfdaa3a8d9 >________________________________ > From: Lance Corrimal >To: opensource-dev at lists.secondlife.com >Sent: Saturday, February 9, 2013 4:13 AM >Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 > >hi, > >does anyone have anything for me about fixing up the source to build with >glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses the newer >glibc... > >for details, see BUG-1610 > >cheers, > >LC > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130209/85b44048/attachment.htm From Lance.Corrimal at eregion.de Sat Feb 9 03:00:54 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 09 Feb 2013 12:00:54 +0100 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <1360406049.87925.YahooMailNeo@web126105.mail.ne1.yahoo.com> References: <1939512.mTIxeILOt3@sai> <1360406049.87925.YahooMailNeo@web126105.mail.ne1.yahoo.com> Message-ID: <9196314.k57kYNA0Ai@sai> Thanks... I haven't even gotten that far, my build died way earlier, with a conflicting declaration for siginfo_t, but I got that tackled now. cheers, LC Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: > https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113b0db3 > effcfdaa3a8d9 > >________________________________ > > > > From: Lance Corrimal > > > >To: opensource-dev at lists.secondlife.com > >Sent: Saturday, February 9, 2013 4:13 AM > >Subject: [opensource-dev] BUG-1610: Current development source does not > >build with glibc 2.17 > > > >hi, > > > >does anyone have anything for me about fixing up the source to build with > >glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses the > >newer glibc... > > > >for details, see BUG-1610 > > > >cheers, > > > >LC > > > >_______________________________________________ > >Policies and (un)subscribe information available here: > >http://wiki.secondlife.com/wiki/OpenSource-Dev > >Please read the policies before posting to keep unmoderated posting > >privileges From nickyperian at yahoo.com Sat Feb 9 04:41:10 2013 From: nickyperian at yahoo.com (Nicky Perian) Date: Sat, 9 Feb 2013 04:41:10 -0800 (PST) Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <9196314.k57kYNA0Ai@sai> References: <1939512.mTIxeILOt3@sai> <1360406049.87925.YahooMailNeo@web126105.mail.ne1.yahoo.com> <9196314.k57kYNA0Ai@sai> Message-ID: <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> Would you mark BUG-1610 as a duplicate of OPEN-164? >________________________________ > From: Lance Corrimal >To: opensource-dev at lists.secondlife.com >Sent: Saturday, February 9, 2013 5:00 AM >Subject: Re: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 > >Thanks... I haven't even gotten that far, my build died way earlier, with a >conflicting declaration for siginfo_t, but I got that tackled now. > > >cheers, >LC > >Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: >> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113b0db3 >> effcfdaa3a8d9 >> >________________________________ >> > >> > From: Lance Corrimal >> > >> >To: opensource-dev at lists.secondlife.com >> >Sent: Saturday, February 9, 2013 4:13 AM >> >Subject: [opensource-dev] BUG-1610: Current development source does not >> >build with glibc 2.17 >> > >> >hi, >> > >> >does anyone have anything for me about fixing up the source to build with >> >glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses the >> >newer glibc... >> > >> >for details, see BUG-1610 >> > >> >cheers, >> > >> >LC >> > >> >_______________________________________________ >> >Policies and (un)subscribe information available here: >> >http://wiki.secondlife.com/wiki/OpenSource-Dev >> >Please read the policies before posting to keep unmoderated posting >> >privileges >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130209/d94aeb27/attachment.htm From Lance.Corrimal at eregion.de Sat Feb 9 04:56:56 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 09 Feb 2013 13:56:56 +0100 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> References: <1939512.mTIxeILOt3@sai> <9196314.k57kYNA0Ai@sai> <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> Message-ID: <2911239.KnUf6BSQOn@sai> Am Samstag, 9. Februar 2013, 04:41:10 schrieb Nicky Perian: > Would you mark BUG-1610 as a duplicate of OPEN-164? definitely not. the problem that I had is because glibc 2.17 brings the siginfo_t definition by itself... definitely something else. What I'd think suitable would be a "meta bug" that says "Current source fails to build on newer linux distributions" that would depend on BOTH open-164 and bug-1610 and possibly others. besides, I found two more build breakages on openSUSE 12.3 by now... One might be fixable by just adding the right build requirement tho. cheers, LC > > >________________________________ > > > > From: Lance Corrimal > > > >To: opensource-dev at lists.secondlife.com > >Sent: Saturday, February 9, 2013 5:00 AM > >Subject: Re: [opensource-dev] BUG-1610: Current development source does not > >build with glibc 2.17 > > > >Thanks... I haven't even gotten that far, my build died way earlier, with a > >conflicting declaration for siginfo_t, but I got that tackled now. > > > > > >cheers, > >LC > > > >Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: > >> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113b0 > >> db3 effcfdaa3a8d9 > >> > >> >________________________________ > >> > > >> > From: Lance Corrimal > >> > > >> >To: opensource-dev at lists.secondlife.com > >> >Sent: Saturday, February 9, 2013 4:13 AM > >> >Subject: [opensource-dev] BUG-1610: Current development source does not > >> >build with glibc 2.17 > >> > > >> >hi, > >> > > >> >does anyone have anything for me about fixing up the source to build > >> >with > >> >glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses the > >> >newer glibc... > >> > > >> >for details, see BUG-1610 > >> > > >> >cheers, > >> > > >> >LC > >> > > >> >_______________________________________________ > >> >Policies and (un)subscribe information available here: > >> >http://wiki.secondlife.com/wiki/OpenSource-Dev > >> >Please read the policies before posting to keep unmoderated posting > >> >privileges > > > >_______________________________________________ > >Policies and (un)subscribe information available here: > >http://wiki.secondlife.com/wiki/OpenSource-Dev > >Please read the policies before posting to keep unmoderated posting > >privileges From Lance.Corrimal at eregion.de Sat Feb 9 11:40:12 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 09 Feb 2013 20:40:12 +0100 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <2911239.KnUf6BSQOn@sai> References: <1939512.mTIxeILOt3@sai> <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> <2911239.KnUf6BSQOn@sai> Message-ID: <2186497.Rh0m4OF4Oj@sai> This is where I'm stuck now: [ 363s] /home/abuild/rpmbuild/BUILD/viewer-development/build-linux- i686/lscript/lscript_compile/indra.y.hpp:176: error: previous declaration of 'int yyparse()' with 'C++' linkage [ 363s] /home/abuild/rpmbuild/BUILD/viewer- development/indra/lscript/lscript_compile/indra.l:61: error: conflicts with new declaration with 'C' linkage any ideas? cheers, LC Am Samstag, 9. Februar 2013, 13:56:56 schrieb Lance Corrimal: > Am Samstag, 9. Februar 2013, 04:41:10 schrieb Nicky Perian: > > Would you mark BUG-1610 as a duplicate of OPEN-164? > > definitely not. the problem that I had is because glibc 2.17 brings the > siginfo_t definition by itself... definitely something else. > > What I'd think suitable would be a "meta bug" that says "Current source > fails to build on newer linux distributions" that would depend on BOTH > open-164 and bug-1610 and possibly others. > > > besides, I found two more build breakages on openSUSE 12.3 by now... > One might be fixable by just adding the right build requirement tho. > > cheers, > LC > > > >________________________________ > > > > > > From: Lance Corrimal > > > > > >To: opensource-dev at lists.secondlife.com > > >Sent: Saturday, February 9, 2013 5:00 AM > > >Subject: Re: [opensource-dev] BUG-1610: Current development source does > > >not > > >build with glibc 2.17 > > > > > >Thanks... I haven't even gotten that far, my build died way earlier, with > > >a > > >conflicting declaration for siginfo_t, but I got that tackled now. > > > > > > > > >cheers, > > >LC > > > > > >Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: > > >> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113 > > >> b0 > > >> db3 effcfdaa3a8d9 > > >> > > >> >________________________________ > > >> > > > >> > From: Lance Corrimal > > >> > > > >> >To: opensource-dev at lists.secondlife.com > > >> >Sent: Saturday, February 9, 2013 4:13 AM > > >> >Subject: [opensource-dev] BUG-1610: Current development source does > > >> >not > > >> >build with glibc 2.17 > > >> > > > >> >hi, > > >> > > > >> >does anyone have anything for me about fixing up the source to build > > >> >with > > >> >glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that uses > > >> >the > > >> >newer glibc... > > >> > > > >> >for details, see BUG-1610 > > >> > > > >> >cheers, > > >> > > > >> >LC > > >> > > > >> >_______________________________________________ > > >> >Policies and (un)subscribe information available here: > > >> >http://wiki.secondlife.com/wiki/OpenSource-Dev > > >> >Please read the policies before posting to keep unmoderated posting > > >> >privileges > > > > > >_______________________________________________ > > >Policies and (un)subscribe information available here: > > >http://wiki.secondlife.com/wiki/OpenSource-Dev > > >Please read the policies before posting to keep unmoderated posting > > >privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges From cinder at cinderblocks.biz Sat Feb 9 12:30:01 2013 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Sat, 09 Feb 2013 13:30:01 -0700 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <2186497.Rh0m4OF4Oj@sai> References: <1939512.mTIxeILOt3@sai> <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> <2911239.KnUf6BSQOn@sai> <2186497.Rh0m4OF4Oj@sai> Message-ID: <795B2C3A-8C81-462D-B311-0086773FBF11@cinderblocks.biz> Lance, I use a workaround on OSX Mountain Lion which fails with the same error, and it might work for you too. Patch attached and as follows: --------------------START------------------------------- # HG changeset patch # User Cinder Roxley # Date 1360441583 25200 # Node ID e3673fb4cbfafe3c0a7c2a88851316fb60422254 # Parent 7ccbd027c9b098d42632ae17f281804a0f8a5cb5 Yacc fix for Mountain Lion diff --git a/indra/lscript/lscript_compile/indra.l b/indra/lscript/lscript_compile/indra.l --- a/indra/lscript/lscript_compile/indra.l +++ b/indra/lscript/lscript_compile/indra.l @@ -62,9 +62,9 @@ #define ECHO do { } while (0) #if defined(__cplusplus) -extern "C" { int yylex( void ); } -extern "C" { int yyparse( void ); } -extern "C" { int yyerror(const char *fmt, ...); } +extern int yylex( void ); +extern int yyparse( void ); +extern int yyerror(const char *fmt, ...); #endif %} diff --git a/indra/lscript/lscript_compile/indra.y b/indra/lscript/lscript_compile/indra.y --- a/indra/lscript/lscript_compile/indra.y +++ b/indra/lscript/lscript_compile/indra.y @@ -3,7 +3,7 @@ #include "lscript_tree.h" #ifdef __cplusplus - extern "C" { + extern //"C" { #endif int yylex(void); @@ -21,7 +21,7 @@ #endif #ifdef __cplusplus - } + //} #endif %} ----------------------END----------------------- Kind regards, Cinder Roxley On 9 Feb 2013, at 12:40, Lance Corrimal wrote: > This is where I'm stuck now: > > > [ 363s] /home/abuild/rpmbuild/BUILD/viewer-development/build-linux- > i686/lscript/lscript_compile/indra.y.hpp:176: error: previous > declaration of > 'int yyparse()' with 'C++' linkage > [ 363s] /home/abuild/rpmbuild/BUILD/viewer- > development/indra/lscript/lscript_compile/indra.l:61: error: conflicts > with > new declaration with 'C' linkage > > > > any ideas? > > > cheers, > LC > > > Am Samstag, 9. Februar 2013, 13:56:56 schrieb Lance Corrimal: >> Am Samstag, 9. Februar 2013, 04:41:10 schrieb Nicky Perian: >>> Would you mark BUG-1610 as a duplicate of OPEN-164? >> >> definitely not. the problem that I had is because glibc 2.17 brings >> the >> siginfo_t definition by itself... definitely something else. >> >> What I'd think suitable would be a "meta bug" that says "Current >> source >> fails to build on newer linux distributions" that would depend on >> BOTH >> open-164 and bug-1610 and possibly others. >> >> >> besides, I found two more build breakages on openSUSE 12.3 by now... >> One might be fixable by just adding the right build requirement tho. >> >> cheers, >> LC >> >>>> ________________________________ >>>> >>>> From: Lance Corrimal >>>> >>>> To: opensource-dev at lists.secondlife.com >>>> Sent: Saturday, February 9, 2013 5:00 AM >>>> Subject: Re: [opensource-dev] BUG-1610: Current development source >>>> does >>>> not >>>> build with glibc 2.17 >>>> >>>> Thanks... I haven't even gotten that far, my build died way >>>> earlier, with >>>> a >>>> conflicting declaration for siginfo_t, but I got that tackled now. >>>> >>>> >>>> cheers, >>>> LC >>>> >>>> Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: >>>>> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113 >>>>> b0 >>>>> db3 effcfdaa3a8d9 >>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: Lance Corrimal >>>>>> >>>>>> To: opensource-dev at lists.secondlife.com >>>>>> Sent: Saturday, February 9, 2013 4:13 AM >>>>>> Subject: [opensource-dev] BUG-1610: Current development source >>>>>> does >>>>>> not >>>>>> build with glibc 2.17 >>>>>> >>>>>> hi, >>>>>> >>>>>> does anyone have anything for me about fixing up the source to >>>>>> build >>>>>> with >>>>>> glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that >>>>>> uses >>>>>> the >>>>>> newer glibc... >>>>>> >>>>>> for details, see BUG-1610 >>>>>> >>>>>> cheers, >>>>>> >>>>>> LC >>>>>> >>>>>> _______________________________________________ >>>>>> Policies and (un)subscribe information available here: >>>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>>>> Please read the policies before posting to keep unmoderated >>>>>> posting >>>>>> privileges >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: yacc-hacc.diff Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130209/03df8c4d/attachment.txt From cinder at cinderblocks.biz Sat Feb 9 13:40:21 2013 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Sat, 09 Feb 2013 14:40:21 -0700 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <795B2C3A-8C81-462D-B311-0086773FBF11@cinderblocks.biz> References: <1939512.mTIxeILOt3@sai> <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> <2911239.KnUf6BSQOn@sai> <2186497.Rh0m4OF4Oj@sai> <795B2C3A-8C81-462D-B311-0086773FBF11@cinderblocks.biz> Message-ID: <873A28A9-0E0C-46F7-BFD0-C54E4E758DF8@cinderblocks.biz> Here's a better fix than the other one I posted earlier? Don't use extern "C". ------------START------------- diff --git a/indra/lscript/lscript_compile/indra.l b/indra/lscript/lscript_compile/indra.l --- a/indra/lscript/lscript_compile/indra.l +++ b/indra/lscript/lscript_compile/indra.l @@ -61,11 +61,9 @@ #define ECHO do { } while (0) -#if defined(__cplusplus) -extern "C" { int yylex( void ); } -extern "C" { int yyparse( void ); } -extern "C" { int yyerror(const char *fmt, ...); } -#endif +int yylex( void ); +int yyparse( void ); +int yyerror(const char *fmt, ...); %} diff --git a/indra/lscript/lscript_compile/indra.y b/indra/lscript/lscript_compile/indra.y --- a/indra/lscript/lscript_compile/indra.y +++ b/indra/lscript/lscript_compile/indra.y @@ -2,10 +2,6 @@ #include "linden_common.h" #include "lscript_tree.h" - #ifdef __cplusplus - extern "C" { - #endif - int yylex(void); int yyparse( void ); int yyerror(const char *fmt, ...); @@ -19,10 +15,6 @@ #pragma warning (disable : 4702) // warning C4702: unreachable code #pragma warning( disable : 4065 ) // warning: switch statement contains 'default' but no 'case' labels #endif - - #ifdef __cplusplus - } - #endif %} %union --------------END--------------- Kind regards, Cinder Roxley > On 9 Feb 2013, at 12:40, Lance Corrimal wrote: > >> This is where I'm stuck now: >> >> >> [ 363s] /home/abuild/rpmbuild/BUILD/viewer-development/build-linux- >> i686/lscript/lscript_compile/indra.y.hpp:176: error: previous >> declaration of >> 'int yyparse()' with 'C++' linkage >> [ 363s] /home/abuild/rpmbuild/BUILD/viewer- >> development/indra/lscript/lscript_compile/indra.l:61: error: >> conflicts with >> new declaration with 'C' linkage >> >> >> >> any ideas? >> >> >> cheers, >> LC >> >> >> Am Samstag, 9. Februar 2013, 13:56:56 schrieb Lance Corrimal: >>> Am Samstag, 9. Februar 2013, 04:41:10 schrieb Nicky Perian: >>>> Would you mark BUG-1610 as a duplicate of OPEN-164? >>> >>> definitely not. the problem that I had is because glibc 2.17 brings >>> the >>> siginfo_t definition by itself... definitely something else. >>> >>> What I'd think suitable would be a "meta bug" that says "Current >>> source >>> fails to build on newer linux distributions" that would depend on >>> BOTH >>> open-164 and bug-1610 and possibly others. >>> >>> >>> besides, I found two more build breakages on openSUSE 12.3 by now... >>> One might be fixable by just adding the right build requirement tho. >>> >>> cheers, >>> LC >>> >>>>> ________________________________ >>>>> >>>>> From: Lance Corrimal >>>>> >>>>> To: opensource-dev at lists.secondlife.com >>>>> Sent: Saturday, February 9, 2013 5:00 AM >>>>> Subject: Re: [opensource-dev] BUG-1610: Current development source >>>>> does >>>>> not >>>>> build with glibc 2.17 >>>>> >>>>> Thanks... I haven't even gotten that far, my build died way >>>>> earlier, with >>>>> a >>>>> conflicting declaration for siginfo_t, but I got that tackled now. >>>>> >>>>> >>>>> cheers, >>>>> LC >>>>> >>>>> Am Samstag, 9. Februar 2013, 02:34:09 schrieb Nicky Perian: >>>>>> https://bitbucket.org/NickyP/kokua-3.4.4/commits/22012aa8388a38fb657113 >>>>>> b0 >>>>>> db3 effcfdaa3a8d9 >>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: Lance Corrimal >>>>>>> >>>>>>> To: opensource-dev at lists.secondlife.com >>>>>>> Sent: Saturday, February 9, 2013 4:13 AM >>>>>>> Subject: [opensource-dev] BUG-1610: Current development source >>>>>>> does >>>>>>> not >>>>>>> build with glibc 2.17 >>>>>>> >>>>>>> hi, >>>>>>> >>>>>>> does anyone have anything for me about fixing up the source to >>>>>>> build >>>>>>> with >>>>>>> glibc 2.17? I'm getting ready for openSUSE 12.3 here, and that >>>>>>> uses >>>>>>> the >>>>>>> newer glibc... >>>>>>> >>>>>>> for details, see BUG-1610 >>>>>>> >>>>>>> cheers, >>>>>>> >>>>>>> LC >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Policies and (un)subscribe information available here: >>>>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>>>>> Please read the policies before posting to keep unmoderated >>>>>>> posting >>>>>>> privileges >>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>>> Please read the policies before posting to keep unmoderated >>>>> posting >>>>> privileges >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > [yacc-hacc.diff] From secret.argent at gmail.com Sat Feb 9 14:11:59 2013 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 9 Feb 2013 16:11:59 -0600 Subject: [opensource-dev] BUG-1610: Current development source does not build with glibc 2.17 In-Reply-To: <873A28A9-0E0C-46F7-BFD0-C54E4E758DF8@cinderblocks.biz> References: <1939512.mTIxeILOt3@sai> <1360413670.39341.YahooMailNeo@web126101.mail.ne1.yahoo.com> <2911239.KnUf6BSQOn@sai> <2186497.Rh0m4OF4Oj@sai> <795B2C3A-8C81-462D-B311-0086773FBF11@cinderblocks.biz> <873A28A9-0E0C-46F7-BFD0-C54E4E758DF8@cinderblocks.biz> Message-ID: <47BD5116-CD45-489C-9051-9FBF8CEF06B0@gmail.com> On 2013-02-09, at 15:40, Cinder Roxley wrote: > Here's a better fix than the other one I posted earlier? Don't use > extern "C". That... shouldn't work, unless it's generating C++ code in lex/yacc/bison/whatever. From fuerholz at gmx.net Fri Feb 15 01:54:16 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Fri, 15 Feb 2013 09:54:16 -0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL Message-ID: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ ----------------------------------------------------------- Review request for Viewer. Description ------- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing ------- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130215/742beee8/attachment.htm From sldev at free.fr Fri Feb 15 02:51:57 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 15 Feb 2013 11:51:57 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> References: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130215115157.577b0b2f.sldev@free.fr> On Fri, 15 Feb 2013 09:54:16 -0000, MartinRJ Fayray wrote: I have a similar fix for weeks in the Cool VL Viewer, but it is alas not as simple as that... There's a problem with resizing chid primitives (they don't resize on screen, even when visible). There's a problem with rotating and moving child primitives when they are out of FOV, but fixing it by checking for target rot and position changes like you did also breaks *some* vehicles (when you or another avatar sits on such vehicles, some chil primitives pertaining to this vehicle "stay behind" when the vehicle moves). So, far, I came up with a proper fix for resizing child primitives and an experimental fix for moving/rotating out of FOV child primitives (I'm testing for flagUsePhysics() and not applying the fix when the flag is TRUE, which should exclude vehicles cild prims). By lack of vehicles to test the latter (I don't use vehicles in SL and the couple I got in my inventory are not affected by this bug), I cannot guarantee that it is "final". Here is the code I use, for people interested in experiencing: // Returns "distance" between target destination and resulting xfrom F32 LLDrawable::updateXform(BOOL undamped) { BOOL damped = !undamped; // Position LLVector3 old_pos(mXform.getPosition()); LLVector3 target_pos; if (mXform.isRoot()) { // get root position in your agent's region target_pos = mVObjp->getPositionAgent(); } else { // parent-relative position target_pos = mVObjp->getPosition(); } // Rotation LLQuaternion old_rot(mXform.getRotation()); LLQuaternion target_rot = mVObjp->getRotation(); bool no_target_omega = mVObjp->getAngularVelocity().isExactlyZero(); // Scaling LLVector3 target_scale = mVObjp->getScale(); LLVector3 old_scale = mCurrentScale; LLVector3 dest_scale = target_scale; // Damping F32 dist_squared = 0.f; F32 camdist2 = mDistanceWRTCamera * mDistanceWRTCamera; if (damped && isVisible()) { F32 lerp_amt = llclamp(LLCriticalDamp::getInterpolant(OBJECT_DAMPING_TIME_CONSTANT), 0.f, 1.f); LLVector3 new_pos = lerp(old_pos, target_pos, lerp_amt); dist_squared = dist_vec_squared(new_pos, target_pos); LLQuaternion new_rot = nlerp(lerp_amt, old_rot, target_rot); dist_squared += (1.f - dot(new_rot, target_rot)) * 10.f; LLVector3 new_scale = lerp(old_scale, target_scale, lerp_amt); dist_squared += dist_vec_squared(new_scale, target_scale); if (dist_squared >= MIN_INTERPOLATE_DISTANCE_SQUARED * camdist2 && dist_squared <= MAX_INTERPOLATE_DISTANCE_SQUARED) { // interpolate target_pos = new_pos; target_rot = new_rot; target_scale = new_scale; } else if (no_target_omega) { // snap to final position (only if no target omega is applied) dist_squared = 0.0f; if (getVOVolume() && !isRoot()) { // child prim snapping to some position, needs a rebuild gPipeline.markRebuild(this, LLDrawable::REBUILD_POSITION, TRUE); } } } if (old_scale != target_scale) { // scale change requires immediate rebuild mCurrentScale = target_scale; if (!isRoot() && !isState(LLDrawable::ANIMATED_CHILD)) { setState(LLDrawable::ANIMATED_CHILD); mVObjp->dirtySpatialGroup(); } gPipeline.markRebuild(this, LLDrawable::REBUILD_POSITION, TRUE); } else if (!isRoot() && !mVObjp->getRootEdit()->flagUsePhysics() && (dist_squared > 0.f || old_pos != target_pos || target_rot != old_rot || !no_target_omega)) { // child prim moving relative to parent, tag as needing to be rendered // atomically and rebuild dist_squared = 1.f; // keep this object on the move list if (!isState(LLDrawable::ANIMATED_CHILD)) { setState(LLDrawable::ANIMATED_CHILD); gPipeline.markRebuild(this, LLDrawable::REBUILD_ALL, TRUE); mVObjp->dirtySpatialGroup(); } } else if (!getVOVolume() && !isAvatar()) { movePartition(); } // Update mXform.setPosition(target_pos); mXform.setRotation(target_rot); mXform.setScale(LLVector3(1, 1, 1)); // no scale in drawable transforms (IT'S A RULE!) mXform.updateMatrix(); if (mSpatialBridge) { gPipeline.markMoved(mSpatialBridge, FALSE); } return dist_squared; } Henri. From fuerholz at gmx.net Fri Feb 15 03:29:46 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Fri, 15 Feb 2013 11:29:46 -0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> References: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130215112946.29798.57747@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/#review1299 ----------------------------------------------------------- I just noticed that my fix re-introduces MAINT-2275 Child prims are "left behind" by animated, moving (physical) linksets. I'm looking for a solution. - MartinRJ Fayray On Feb. 15, 2013, 1:54 a.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > ----------------------------------------------------------- > > (Updated Feb. 15, 2013, 1:54 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. > > > Repository: https://bitbucket.org/MartinRJ/bug-840 > > > This addresses bug BUG-840. > https://jira.secondlife.com/browse/BUG-840 > > > Diffs > ----- > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/616/diff/ > > > Testing > ------- > > Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. > > Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. > > Shout something in public chat so that the child prim changes its relative position. > > Turn around so that the test object is in view again. > > Expected result: the prims visibly changed. > > Without this fix, the child prim would not update its position (or rotation). > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130215/d0e88082/attachment.htm From fuerholz at gmx.net Sat Feb 16 10:53:02 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sat, 16 Feb 2013 18:53:02 -0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> References: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ ----------------------------------------------------------- (Updated Feb. 16, 2013, 10:53 a.m.) Review request for Viewer. Description ------- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing (updated) ------- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are "left behind" by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130216/beda08ba/attachment.htm From fuerholz at gmx.net Sat Feb 16 11:44:51 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sat, 16 Feb 2013 19:44:51 -0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ ----------------------------------------------------------- (Updated Feb. 16, 2013, 11:44 a.m.) Review request for Viewer. Changes ------- Successfully tested against: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are "left behind" by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Description ------- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs (updated) ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing ------- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are "left behind" by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130216/a6f691ea/attachment.htm From sldev at free.fr Sat Feb 16 15:58:34 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 17 Feb 2013 00:58:34 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130217005834.b2f6b55f.sldev@free.fr> On Sat, 16 Feb 2013 19:44:51 -0000, MartinRJ Fayray wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > > Review request for Viewer. Yes, it seems to work more or less OK. It however still fails to animate visible small resizing primitives (I saw this first on scripted nipples: the nipples failed to "stiffen" on screen while the prim actually resized and only a change in LOD (zoom-out followed with zoom-in) would update the prim size on screen). To reproduce that bug, create two prims, link them, and in the root prim put this script: integer Expanded = FALSE; default { touch_start(integer n) { vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ PRIM_SIZE ]), 0); Expanded = !Expanded; if (Expanded) { scale.x = 2.0 * scale.y; } else { scale.x = scale.y; } llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]); } } Then wear the resulting object and resize it down to a very small size. Zoom on it and see how the child prim fails to resize when touching the object. To cure that bug you need to replace: LLVector3 vec = mCurrentScale-target_scale; if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED) (which makes no sense whatsoever: only damping interpolations need to be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with: if (old_scale != target_scale) Also, it makes no sense to use dist_vec_squared(old_pos, target_pos) > 0.f || (1.f - dot(old_rot, target_rot)) * 10.f > 0.f in the test you added to fix the out of FOV moving/rotating child prims bug. You simply need to test for changed position and rotation since you don't change the dist_squared variable in that case (this will also avoid having very slow, or very slightly rotating out of FOV prims to fail to update). Attached to this email is the diff I propose to add to your patch. Regards, Henri. -------------- next part -------------- A non-text attachment was scrubbed... Name: diff.txt Type: application/octet-stream Size: 1165 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/47a98df1/attachment.obj From fuerholz at gmx.net Sat Feb 16 16:25:36 2013 From: fuerholz at gmx.net (=?iso-8859-1?Q?Martin_F=FCrholz?=) Date: Sun, 17 Feb 2013 01:25:36 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217005834.b2f6b55f.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal><20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> Message-ID: Hello Henri, first: no I cannot reproduce the issue with small prims. They are resized in a viewer with my fix from <0.01, 0.01, 0.01> (whis is the minimum prim size in the LL viewer) to <0.014, 0.014, 0.014> perfectly, just exactly like in the current SL release viewer. This is my test script I used in a 3-prim object attached to my chest, and it works like a charm without any issue. It works exactly like in the unmodified LL viewer, without issues: integer vis = FALSE; default { state_entry() { llListen(0, "", "", ""); } listen(integer channel, string name, key id, string message) { vis = !vis; if (vis) { llSetLinkPrimitiveParamsFast(2, [PRIM_SIZE, <0.015, 0.015, 0.015>]); llSetLinkPrimitiveParamsFast(3, [PRIM_SIZE, <0.015, 0.015, 0.015>]); } else { llSetLinkPrimitiveParamsFast(2, [PRIM_SIZE, <0.01, 0.01, 0.01>]); llSetLinkPrimitiveParamsFast(3, [PRIM_SIZE, <0.01, 0.01, 0.01>]); } } } Second: as far as I've been told LL does not take code from you from what-ever reason, so it won't be of help if you write or email any extensions to my fix on this list. In the contrary it will make it impossible for me to do any even common-sense changes to it, as LL (as far as I can tell) doesn't accept any changes from people who don't have a CA on file with Linden Lab, even if those changes are fixes of very obvious bugs and even if they are common sense-fixes or even if they are industry-standard. I would like you to contact me directly, instead. This fix is meant as a fix for the LL viewer, and not for your own Third-Party-Viewer. By publishing changes to my fix on the LL mailinglist, this will also mean that I cannot use those changes for the LL viewer, and that seems very counterproductive for me. Tyvm Martin RJ -----Urspr?ngliche Nachricht----- From: Henri Beauchamp Sent: Sunday, February 17, 2013 12:58 AM To: opensource-dev at lists.secondlife.com Cc: MartinRJ Fayray Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL On Sat, 16 Feb 2013 19:44:51 -0000, MartinRJ Fayray wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > > Review request for Viewer. Yes, it seems to work more or less OK. It however still fails to animate visible small resizing primitives (I saw this first on scripted nipples: the nipples failed to "stiffen" on screen while the prim actually resized and only a change in LOD (zoom-out followed with zoom-in) would update the prim size on screen). To reproduce that bug, create two prims, link them, and in the root prim put this script: integer Expanded = FALSE; default { touch_start(integer n) { vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ PRIM_SIZE ]), 0); Expanded = !Expanded; if (Expanded) { scale.x = 2.0 * scale.y; } else { scale.x = scale.y; } llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]); } } Then wear the resulting object and resize it down to a very small size. Zoom on it and see how the child prim fails to resize when touching the object. To cure that bug you need to replace: LLVector3 vec = mCurrentScale-target_scale; if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED) (which makes no sense whatsoever: only damping interpolations need to be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with: if (old_scale != target_scale) Also, it makes no sense to use dist_vec_squared(old_pos, target_pos) > 0.f || (1.f - dot(old_rot, target_rot)) * 10.f > 0.f in the test you added to fix the out of FOV moving/rotating child prims bug. You simply need to test for changed position and rotation since you don't change the dist_squared variable in that case (this will also avoid having very slow, or very slightly rotating out of FOV prims to fail to update). Attached to this email is the diff I propose to add to your patch. Regards, Henri. From fuerholz at gmx.net Sat Feb 16 16:37:58 2013 From: fuerholz at gmx.net (=?iso-8859-1?Q?Martin_F=FCrholz?=) Date: Sun, 17 Feb 2013 01:37:58 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217005834.b2f6b55f.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal><20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> Message-ID: <354D68A42D574DD380C9D1347474908B@MartinPC> Hello again, Henri, I just tested your nipples and they work without issues in a viewer with my fix. But they also do work in the official latest LL viewer release (Second Life 3.4.5 (270263) Feb 12 2013 04:43:00 (Second Life Release)). Martin RJ -----Urspr?ngliche Nachricht----- From: Henri Beauchamp Sent: Sunday, February 17, 2013 12:58 AM To: opensource-dev at lists.secondlife.com Cc: MartinRJ Fayray Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL On Sat, 16 Feb 2013 19:44:51 -0000, MartinRJ Fayray wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > > Review request for Viewer. Yes, it seems to work more or less OK. It however still fails to animate visible small resizing primitives (I saw this first on scripted nipples: the nipples failed to "stiffen" on screen while the prim actually resized and only a change in LOD (zoom-out followed with zoom-in) would update the prim size on screen). To reproduce that bug, create two prims, link them, and in the root prim put this script: integer Expanded = FALSE; default { touch_start(integer n) { vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ PRIM_SIZE ]), 0); Expanded = !Expanded; if (Expanded) { scale.x = 2.0 * scale.y; } else { scale.x = scale.y; } llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]); } } Then wear the resulting object and resize it down to a very small size. Zoom on it and see how the child prim fails to resize when touching the object. To cure that bug you need to replace: LLVector3 vec = mCurrentScale-target_scale; if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED) (which makes no sense whatsoever: only damping interpolations need to be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with: if (old_scale != target_scale) Also, it makes no sense to use dist_vec_squared(old_pos, target_pos) > 0.f || (1.f - dot(old_rot, target_rot)) * 10.f > 0.f in the test you added to fix the out of FOV moving/rotating child prims bug. You simply need to test for changed position and rotation since you don't change the dist_squared variable in that case (this will also avoid having very slow, or very slightly rotating out of FOV prims to fail to update). Attached to this email is the diff I propose to add to your patch. Regards, Henri. From desmoulins.uchi at googlemail.com Sat Feb 16 18:41:38 2013 From: desmoulins.uchi at googlemail.com (Niran) Date: Sun, 17 Feb 2013 03:41:38 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <354D68A42D574DD380C9D1347474908B@MartinPC> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> <354D68A42D574DD380C9D1347474908B@MartinPC> Message-ID: Ah good thing i really dont care about this. I mean , Martin is right , with adding your stuff you are basically preventing it from getting implemented but i have to say its LLs own fault because they insist on this damn CA , really , isnt this OpenSource? doesnt OpenSource mean that basically everyone can openly help with it? i mean why does LL insist on this CA? just so they can say at any given time "this code is ours"?. Seriously this is unnecessary additional work and trouble. I mean imagine the worst case scenario where Henri fixes ALL issues SL ever had , LL couldnt implement those fixes and basically making them unable to ever fix them , because the fixes come from Henri , so everyone would either have to create a whole new fix that does exactly the same but is build completely different or they dont do anything about it at all because there is no other way to fix it (which i highly doubt in most cases) , but you get the idea , LL is basically limited and crippling itself by denying everything from everyone who has no CA. 2013/2/17 Martin F?rholz > Hello again, Henri, > > I just tested your nipples and they work without issues in a viewer with my > fix. But they also do work in the official latest LL viewer release (Second > Life 3.4.5 (270263) Feb 12 2013 04:43:00 (Second Life Release)). > > Martin RJ > > -----Urspr?ngliche Nachricht----- > From: Henri Beauchamp > Sent: Sunday, February 17, 2013 12:58 AM > To: opensource-dev at lists.secondlife.com > Cc: MartinRJ Fayray > Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) > breaks almost every sliding door script in SL > > On Sat, 16 Feb 2013 19:44:51 -0000, MartinRJ Fayray wrote: > > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/616/ > > > > Review request for Viewer. > > Yes, it seems to work more or less OK. It however still fails to animate > visible small resizing primitives (I saw this first on scripted nipples: > the nipples failed to "stiffen" on screen while the prim actually > resized and only a change in LOD (zoom-out followed with zoom-in) would > update the prim size on screen). > > To reproduce that bug, create two prims, link them, and in the root prim > put this script: > > integer Expanded = FALSE; > > default { > touch_start(integer n) { > vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ > PRIM_SIZE ]), 0); > Expanded = !Expanded; > if (Expanded) { > scale.x = 2.0 * scale.y; > } else { > scale.x = scale.y; > } > llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]); > } > } > > Then wear the resulting object and resize it down to a very small size. > Zoom on it and see how the child prim fails to resize when touching the > object. > > To cure that bug you need to replace: > > LLVector3 vec = mCurrentScale-target_scale; > if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED) > > (which makes no sense whatsoever: only damping interpolations need to > be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with: > if (old_scale != target_scale) > > > Also, it makes no sense to use > dist_vec_squared(old_pos, target_pos) > 0.f || > (1.f - dot(old_rot, target_rot)) * 10.f > 0.f > in the test you added to fix the out of FOV moving/rotating child > prims bug. You simply need to test for changed position and rotation > since you don't change the dist_squared variable in that case (this > will also avoid having very slow, or very slightly rotating out of > FOV prims to fail to update). > > Attached to this email is the diff I propose to add to your patch. > > Regards, > > Henri. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/90fae0c0/attachment.htm From tateru.nino at gmail.com Sat Feb 16 19:18:48 2013 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 17 Feb 2013 14:18:48 +1100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> <354D68A42D574DD380C9D1347474908B@MartinPC> Message-ID: <51204C18.10409@gmail.com> On 17/02/2013 1:41 PM, Niran wrote: > Ah good thing i really dont care about this. I mean , Martin is right > , with adding your stuff you are basically preventing it from getting > implemented but i have to say its LLs own fault because they insist on > this damn CA , really , isnt this OpenSource? doesnt OpenSource mean > that basically everyone can openly help with it? Not exactly. Open source means that the source is freely available, and that (subject to certain conditions) can be used in ways which copyright would normally prevent (each open source license specifies the conditions under which the three basic rights of copyright might be relaxed, depending on the license). Not all open source projects accept all contributions made for it. It's common for some to be accepted and some to be rejected - depending on the organisational model. > i mean why does LL insist on this CA? just so they can say at any > given time "this code is ours"?. I cannot speak for the Lab, but I can't envision any other scenario for CAs under most open source project licenses, than allowing for the possibility of a future sale of the code as an unencumbered asset. Now, the presence of the CA system doesn't imply one way or another that the Lab intends to do that at any future point (though I believe it has been done once in the past already) - it's something that lawyers like, though. A lot. > Seriously this is unnecessary additional work and trouble. I mean > imagine the worst case scenario where Henri fixes ALL issues SL ever > had , LL couldnt implement those fixes and basically making them > unable to ever fix them , because the fixes come from Henri , so > everyone would either have to create a whole new fix that does exactly > the same but is build completely different or they dont do anything > about it at all because there is no other way to fix it (which i > highly doubt in most cases) , but you get the idea , LL is basically > limited and crippling itself by denying everything from everyone who > has no CA. That's certainly one way of looking at it - and actually this was done for a while. Fixes were essentially completely reimplemented for the viewer from the ground up with the original contributed work used only to generate time/cost estimates, and perhaps specifications. Yes, I do rather think that the Lab is sort of painting itself into a corner with this, but under the current organisational model for the project, it isn't something anyone else has control over. It's a love-it-or-leave-it sort of situation. Annoying, perhaps, for the bulk of informed SL users, but not really anything to raise actual ire about. > > 2013/2/17 Martin F?rholz > > > Hello again, Henri, > > I just tested your nipples and they work without issues in a > viewer with my > fix. But they also do work in the official latest LL viewer > release (Second > Life 3.4.5 (270263) Feb 12 2013 04:43:00 (Second Life Release)). > > Martin RJ > > -----Urspr?ngliche Nachricht----- > From: Henri Beauchamp > Sent: Sunday, February 17, 2013 12:58 AM > To: opensource-dev at lists.secondlife.com > > Cc: MartinRJ Fayray > Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer > 3.4.2 (Beta) > breaks almost every sliding door script in SL > > On Sat, 16 Feb 2013 19:44:51 -0000, MartinRJ Fayray wrote: > > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/616/ > > > > Review request for Viewer. > > Yes, it seems to work more or less OK. It however still fails to > animate > visible small resizing primitives (I saw this first on scripted > nipples: > the nipples failed to "stiffen" on screen while the prim actually > resized and only a change in LOD (zoom-out followed with zoom-in) > would > update the prim size on screen). > > To reproduce that bug, create two prims, link them, and in the > root prim > put this script: > > integer Expanded = FALSE; > > default { > touch_start(integer n) { > vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ > PRIM_SIZE ]), 0); > Expanded = !Expanded; > if (Expanded) { > scale.x = 2.0 * scale.y; > } else { > scale.x = scale.y; > } > llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]); > } > } > > Then wear the resulting object and resize it down to a very small > size. > Zoom on it and see how the child prim fails to resize when > touching the > object. > > To cure that bug you need to replace: > > LLVector3 vec = mCurrentScale-target_scale; > if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED) > > (which makes no sense whatsoever: only damping interpolations need to > be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with: > if (old_scale != target_scale) > > > Also, it makes no sense to use > dist_vec_squared(old_pos, target_pos) > 0.f || > (1.f - dot(old_rot, target_rot)) * 10.f > 0.f > in the test you added to fix the out of FOV moving/rotating child > prims bug. You simply need to test for changed position and rotation > since you don't change the dist_squared variable in that case (this > will also avoid having very slow, or very slightly rotating out of > FOV prims to fail to update). > > Attached to this email is the diff I propose to add to your patch. > > Regards, > > Henri. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/2d132949/attachment-0001.htm From fuerholz at gmx.net Sat Feb 16 23:25:58 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Sun, 17 Feb 2013 07:25:58 -0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> References: <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130217072558.7850.89136@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/616/ ----------------------------------------------------------- (Updated Feb. 16, 2013, 11:25 p.m.) Review request for Viewer. Changes ------- Did some cleanup. Description ------- Fixes missing childprim- position/rotation-updates when the avatar was 20+m away and didn't have the object in view when it was changed. Repository: https://bitbucket.org/MartinRJ/bug-840 This addresses bug BUG-840. https://jira.secondlife.com/browse/BUG-840 Diffs (updated) ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/616/diff/ Testing ------- Create an object with two prims, add a script with a listener on PUBLIC_CHANNEL and make it change the relative position of the child prim in the listen-event. Move the avatar 20+ m away from the test object, and look in the opposite direction, so that the object is not in view. Shout something in public chat so that the child prim changes its relative position. Turn around so that the test object is in view again. Expected result: the prims visibly changed. Without this fix, the child prim would not update its position (or rotation). This fix has to be tested against the following related bugs: BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL MAINT-2275 [vehiclebug], Child prims are "left behind" by animated, moving physical objects MAINT-1742 [selection], Child object does not update position while selected. MAINT-2247 [selection] Child object does not update rotation while selected. Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/5620b826/attachment.htm From sldev at free.fr Sun Feb 17 01:22:23 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 17 Feb 2013 10:22:23 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> Message-ID: <20130217102223.09f5ade5.sldev@free.fr> On Sun, 17 Feb 2013 01:25:36 +0100, Martin F?rholz wrote: > Hello Henri, > > first: no I cannot reproduce the issue with small prims. They are resized in > a viewer with my fix from <0.01, 0.01, 0.01> (whis is the minimum prim size > in the LL viewer) to <0.014, 0.014, 0.014> perfectly, just exactly like in > the current SL release viewer. I DO CONFIRM THAT THE BUG ***###DOES###*** HAPPEN WITH LL'S LATEST VIEWER V3.4.5.270263 (like it did happen with all former v3.4 and v3.3 viewers: I didn't test older ones). Perhaps you have different settings than mine and not seeing it, but this bug DOES exist ! > Second: > as far as I've been told LL does not take code from you from what-ever > reason, The reason is that I refuse to give to LL my real life (snail-mail) address and phone number for such a puprpose as signing a CA: it is ILLEGAL in France (and EU) to require such private information for such a purpose (the required *private* information is excessive for the purpose: my RL name and signature is all what LL needs): what would LL do with my phone number anyway (that is on red list by the way: only my family and close friends got my phone number !) ? I can't understand half of spoken English (especially when spoken by Americans), and I can't speak it properly (some may find French accent cute in English, but believe me, mine is not cute the least !). LL says it must abide the French (and EU) law by requiring their residents to pay the VAT (this is untrue as well: that law about VAT on Internet was made so that *competiting* EU companies would not be disavantaged in regards on companies not having to charge a VAT, but the law doesn't say that companies *without a comptetion* should charge it !!! Basically, LL's EU customers are paying taxes twice (US taxes, that is included in the price of everything LL charges to residents, *and* EU VAT) !... On the other hand, LL doesn't respect the least laws protecting the privacy of their foreign customers and would like me to go by their, ILLEGAL rules ! Sorry, but no thanks ! > so it won't be of help if you write or email any extensions to my > fix on this list. In the contrary it will make it impossible for me > to do any even common-sense changes to it, as LL (as far as I can > tell) doesn't accept any changes from people who don't have a CA on > file with Linden Lab, even if those changes are fixes of very > obvious bugs and even if they are common sense-fixes or even if > they are industry-standard. A bugfix is NOT copyrightable, unless it would involve a full rewrite or significant change of the whole algorithm: the changes I proposed are TRIVIAL: if you really are anal, you could even change my proposed "if (a != b)" code for "if (a - b != 0)" LOL ! Get **REAL**, please, and stop seeing problems were there is NONE !!! > I would like you to contact me directly, instead. Yes, I know this type of hypocrisy and practiced it several times with Oz so to push nasty crash bug fixes in LL's code: I could also tell another TPV developer in private what bug fixes I found and ask them to pass them to LL... But it's pure hypocrisy and I'm getting TIRED of it all ! Mind you, I was also the one who brought attention on this bug, and in this very list, and even proposed a first (partial) bugfix for it a few weeks ago: https://lists.secondlife.com/pipermail/opensource-dev/2012-December/009424.html https://lists.secondlife.com/pipermail/opensource-dev/2013-January/009450.html Beside, this fix DOES interest other TPVs developers that are NOT compelled to reject my contributions in their viewer, because *their* viewer is not LL's (even if they share the same base): most, if not all TPVs got code that I contributed (and I'm not even speaking about trivial bug fixes) and I keep being asked from time to time for my agreement for adding some GPL patch I made in the past into today's v3-based TPVs (the agreement here is just for the GPL to LGPL change, not for CA stuff). In fact, if you look in LL's viewer contributions.txt file, you will even see my name there... and the list of contributions is not even complete (each time I contributed a patch on the JIRA, I never updated the contributions.txt file myself but let Lindens do it if they felt like it (especially since trivial bug fixes are hardly worth mentioning), so the list only contains the few contributions for which the Linden who integrated my patch did bother updating that file themselves). It was back in a time, when the Open Source concept was better understood and respected by LL... > This fix is meant as a fix for the LL viewer, and not for your own > Third-Party-Viewer. It's meant to be part of any viewer, unless you keep it in a private list that only CA contributors can read from and post in *and* that you close the sources of the patched viewer ! The viewer code is LGPL, meaning that any viewer with a compatible license (such as GPL viewers like mine) *can* include any part of its code. That's the exact purpose of OPEN SOURCE code, mind you ! > By publishing changes to my fix on the LL mailinglist, this will also > mean that I cannot use those changes for the LL viewer, and that > seems very counterproductive for me. Again, there is nothing that I published there but a trivial bugfix that is NOT copyrightable. I would also add that whole chunks of LL's viewer have been taken/adapted from other Open Source authors (especially in llmath: you'll even see the mention for such code borrowing in the comments), authors who NEVER signed a CA with LL and are probably not even aware that their code is used in LL's viewer: again that CA stuff is pure hypocrisy invented by a sick lawyer at LL. Henri Beauchamp. Open Source contributor, for 6 years (and still counting) in SL and its viewer. From martin.fuerholz at fuerholz.org Sun Feb 17 01:59:47 2013 From: martin.fuerholz at fuerholz.org (=?ISO-8859-15?Q?Martin_F=FCrholz?=) Date: Sun, 17 Feb 2013 10:59:47 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217102223.09f5ade5.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal><20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal><20130217005834.b2f6b55f.sldev@free.fr> <20130217102223.09f5ade5.sldev@free.fr> Message-ID: <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC> Hello, me and others cannot reproduce your 'nipple bug', neither with your 'cool nipples' from the marketplace, nor with the test setup you've given in your earlier mail. Neither with nor without my latest version of the fix for BUG-840, on LL Release and not either on the LL Beta viewer. If you found a repro please create a Jira issue so that this can be addresses as a different issue, as - like you said - it has always been this way, and therefore not affected from my fix. Thank you. -----Urspr?ngliche Nachricht----- From: Henri Beauchamp Sent: Sunday, February 17, 2013 10:22 AM To: MartinF?rholz Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL On Sun, 17 Feb 2013 01:25:36 +0100, Martin F?rholz wrote: > Hello Henri, > > first: no I cannot reproduce the issue with small prims. They are resized > in > a viewer with my fix from <0.01, 0.01, 0.01> (whis is the minimum prim > size > in the LL viewer) to <0.014, 0.014, 0.014> perfectly, just exactly like in > the current SL release viewer. I DO CONFIRM THAT THE BUG ***###DOES###*** HAPPEN WITH LL'S LATEST VIEWER V3.4.5.270263 (like it did happen with all former v3.4 and v3.3 viewers: I didn't test older ones). Perhaps you have different settings than mine and not seeing it, but this bug DOES exist ! From sldev at free.fr Sun Feb 17 04:27:22 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 17 Feb 2013 13:27:22 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> <20130217102223.09f5ade5.sldev@free.fr> <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC> Message-ID: <20130217132722.fe5383ce.sldev@free.fr> On Sun, 17 Feb 2013 10:59:47 +0100, Martin F?rholz wrote: > Hello, > me and others cannot reproduce your 'nipple bug', neither with your 'cool > nipples' from the marketplace, nor with the test setup you've given in your > earlier mail. You can deny all you want, but I do know what I am seeing on my screen... Henri. From kirstiemc555 at hotmail.co.uk Sun Feb 17 05:55:20 2013 From: kirstiemc555 at hotmail.co.uk (Kirstie McKenzie) Date: Sun, 17 Feb 2013 13:55:20 +0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217132722.fe5383ce.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal>, <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal>, <20130217005834.b2f6b55f.sldev@free.fr>, , <20130217102223.09f5ade5.sldev@free.fr>, <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC>, <20130217132722.fe5383ce.sldev@free.fr> Message-ID: > > On Sun, 17 Feb 2013 10:59:47 +0100, Martin F?rholz wrote: > > > Hello, > > me and others cannot reproduce your 'nipple bug', neither with your 'cool > > nipples' from the marketplace, nor with the test setup you've given in your > > earlier mail. > > You can deny all you want, but I do know what I am seeing on my screen... > > Henri. > I am also unable to reproduce the "nipple bug" on Second Life 3.4.5 (270034) Feb 5 2013 10:46:31 (Second Life Beta Viewer) or on Firestorm merged up to the 3.4.5 codebase. I tested with Henri's Cool Nipples (thanks Martin for the gift ;)) and also with Henri's repro from an earlier comment. The nipples/prims correctly resized both when cammed out and cammed in closely. Testing system: Second Life 3.4.5 (270034) Feb 5 2013 10:46:31 (Second Life Beta Viewer) Release Notes CPU: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz (2493.75 MHz) Memory: 3326 MB OS Version: Microsoft Windows Vista 32-bit Service Pack 2 (Build 6002) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GT 230/PCIe/SSE2 Windows Graphics Driver Version: 9.18.0013.1054 OpenGL Version: 3.3.0 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v7.0 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Built with MSVC version 1600 Whirly Fizzle _____________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/2f0ed607/attachment.htm From sldev at free.fr Sun Feb 17 06:01:05 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 17 Feb 2013 15:01:05 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217132722.fe5383ce.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> <20130217102223.09f5ade5.sldev@free.fr> <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC> <20130217132722.fe5383ce.sldev@free.fr> Message-ID: <20130217150105.f3e7a281.sldev@free.fr> On Sun, 17 Feb 2013 13:27:22 +0100, Henri Beauchamp wrote: > On Sun, 17 Feb 2013 10:59:47 +0100, Martin F?rholz wrote: > > > Hello, > > me and others cannot reproduce your 'nipple bug', neither with your 'cool > > nipples' from the marketplace, nor with the test setup you've given in your > > earlier mail. > > You can deny all you want, but I do know what I am seeing on my screen... > > Henri. And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv (note: it's an OGV video: VLC can read it, if your standard player can't). Henri. From fuerholz at gmx.net Sun Feb 17 07:08:37 2013 From: fuerholz at gmx.net (=?ISO-8859-15?Q?Martin_F=FCrholz?=) Date: Sun, 17 Feb 2013 16:08:37 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217150105.f3e7a281.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal><20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal><20130217005834.b2f6b55f.sldev@free.fr><20130217102223.09f5ade5.sldev@free.fr><0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC><20130217132722.fe5383ce.sldev@free.fr> <20130217150105.f3e7a281.sldev@free.fr> Message-ID: <63A999470BE84E25BEA1C9D9609154D8@MartinPC> Hello Henri, thank you for your video. I was able to 'kind-of' reproduce it partially in LL Viewer 3.4.5 (270263). The prim doesn't visually resize to it's full size, it's 10% smaller than it should be until I zoom out and back it. I will try to fix that and update the repository. Tyvm. I cannot find a Jira issue for that bug, could you please file one? Thank you. -----Urspr?ngliche Nachricht----- From: Henri Beauchamp Sent: Sunday, February 17, 2013 3:01 PM To: MartinF?rholz Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL On Sun, 17 Feb 2013 13:27:22 +0100, Henri Beauchamp wrote: > On Sun, 17 Feb 2013 10:59:47 +0100, Martin F?rholz wrote: > > > Hello, > > me and others cannot reproduce your 'nipple bug', neither with your > > 'cool > > nipples' from the marketplace, nor with the test setup you've given in > > your > > earlier mail. > > You can deny all you want, but I do know what I am seeing on my screen... > > Henri. And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv (note: it's an OGV video: VLC can read it, if your standard player can't). Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges From kirstiemc555 at hotmail.co.uk Sun Feb 17 07:10:40 2013 From: kirstiemc555 at hotmail.co.uk (Kirstie McKenzie) Date: Sun, 17 Feb 2013 15:10:40 +0000 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130217150105.f3e7a281.sldev@free.fr> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal>, <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal>, <20130217005834.b2f6b55f.sldev@free.fr>, , <20130217102223.09f5ade5.sldev@free.fr>, <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC>, <20130217132722.fe5383ce.sldev@free.fr>, <20130217150105.f3e7a281.sldev@free.fr> Message-ID: > And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv > (note: it's an OGV video: VLC can read it, if your standard player can't). > > Henri. > __ Aha! Okay, I can repro :) Video was helpful, thanks. Are you JIRAing that? Whirly Fizzle _____________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130217/16b531f5/attachment.htm From sldev at free.fr Sun Feb 17 09:25:38 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 17 Feb 2013 18:25:38 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <63A999470BE84E25BEA1C9D9609154D8@MartinPC> References: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> <20130216194451.29799.5608@domU-12-31-38-00-90-68.compute-1.internal> <20130217005834.b2f6b55f.sldev@free.fr> <20130217102223.09f5ade5.sldev@free.fr> <0E8BD5A254AA43F09E2D550ACFC3CD87@MartinPC> <20130217132722.fe5383ce.sldev@free.fr> <20130217150105.f3e7a281.sldev@free.fr> <63A999470BE84E25BEA1C9D9609154D8@MartinPC> Message-ID: <20130217182538.17875ac1.sldev@free.fr> On Sun, 17 Feb 2013 16:08:37 +0100, Martin F?rholz wrote: > Hello Henri, > thank you for your video. > > I was able to 'kind-of' reproduce it partially in LL Viewer 3.4.5 (270263). > The prim doesn't visually resize to it's full size, it's 10% smaller than it > should be until I zoom out and back it. In fact, something could well influence this bug: the frame rate... The higher the frame rate, and the most likely the buggy test will fail in updateXform() (since the prim is smoothly resized server-side and viewer-side, at high frame rate, the scale difference between the current and the past frame will be (worngly) considered neglectable because of that buggy test)... Since I've got frame rates in the 100+ (up to 200 FPS with the Cool VL Viewer in that skybox where I made the video), I'm probably more impacted than someone with 20 FPS... > I will try to fix that and update the repository. Tyvm. Thanks. > I cannot find a Jira issue for that bug, could you please file one? Sorry, I stopped using the JIRA for reporting viewer bugs (I keep using it for server bugs, since there's no other channel to do it for them) after LL closed it, making it impossible for anyone else than the JIRA issue creator and Lindens to read the reports... I don't have time to loose, and I lost enough time and energy on this issue already (especially for something so trivial !). Henri. From carlo at alinoe.com Sun Feb 17 12:38:35 2013 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 17 Feb 2013 21:38:35 +0100 Subject: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL In-Reply-To: <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> References: <20130215095416.29799.70877@domU-12-31-38-00-90-68.compute-1.internal> <20130216185302.32414.7139@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130217213835.3eadd6ea@hikaru.localdomain> Not only sliding doors, my normal door stopped working too more than half the time; and a LOT of others scripted objects... Even watching it doesn't always help. On Sat, 16 Feb 2013 18:53:02 -0000 "MartinRJ Fayray" wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > ----------------------------------------------------------- > > (Updated Feb. 16, 2013, 10:53 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Fixes missing childprim- position/rotation-updates when the avatar > was 20+m away and didn't have the object in view when it was changed. > > > Repository: https://bitbucket.org/MartinRJ/bug-840 > > > This addresses bug BUG-840. > https://jira.secondlife.com/browse/BUG-840 > > > Diffs > ----- > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/616/diff/ > > > Testing (updated) > ------- > > Create an object with two prims, add a script with a listener on > PUBLIC_CHANNEL and make it change the relative position of the child > prim in the listen-event. > > Move the avatar 20+ m away from the test object, and look in the > opposite direction, so that the object is not in view. > > Shout something in public chat so that the child prim changes its > relative position. > > Turn around so that the test object is in view again. > > Expected result: the prims visibly changed. > > Without this fix, the child prim would not update its position (or > rotation). > > This fix has to be tested against the following related bugs: > BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost > every sliding door script in SL MAINT-2275 [vehiclebug], Child prims > are "left behind" by animated, moving physical objects MAINT-1742 > [selection], Child object does not update position while selected. > MAINT-2247 [selection] Child object does not update rotation while > selected. > > > Thanks, > > MartinRJ Fayray > -- Carlo Wood From fuerholz at gmx.net Sun Feb 17 19:01:33 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Mon, 18 Feb 2013 03:01:33 -0000 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates Message-ID: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ ----------------------------------------------------------- Review request for Viewer. Description ------- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing ------- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130218/ceba1d96/attachment.htm From fuerholz at gmx.net Sun Feb 17 19:02:40 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Mon, 18 Feb 2013 03:02:40 -0000 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ ----------------------------------------------------------- (Updated Feb. 17, 2013, 7:02 p.m.) Review request for Viewer. Description ------- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs ----- indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing (updated) ------- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130218/fb37e6ff/attachment.htm From martin.fuerholz at fuerholz.org Mon Feb 18 00:16:59 2013 From: martin.fuerholz at fuerholz.org (=?UTF-8?Q?Martin_F=C3=BCrholz?=) Date: Mon, 18 Feb 2013 09:16:59 +0100 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <7D0FF8A7111D430F82CAE15B35C59E6C@MartinPC> I posted a copy of the test plan for both codereviews (BUG-1709 and BUG-840) at the Firestorm ? Jira: http://jira.phoenixviewer.com/browse/FIRE-8279?focusedCommentId=105648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-105648 MartinRJ From: MartinRJ Fayray Sent: Monday, February 18, 2013 4:01 AM To: MartinRJ Fayray ; Viewer Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ Review request for Viewer. By MartinRJ Fayray. Description At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. Testing See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Bugs: BUG-1709 Diffs a.. indra/newview/lldrawable.cpp (fbbee98b7512) View Diff -------------------------------------------------------------------------------- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130218/62b3fa5e/attachment.htm From sldev at free.fr Mon Feb 18 01:44:21 2013 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 18 Feb 2013 10:44:21 +0100 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130218104421.84347da6.sldev@free.fr> On Mon, 18 Feb 2013 03:02:40 -0000, MartinRJ Fayray wrote: > I fixed that by comparing the original scale versus the new target > scale (instead of comparing the original scale versus the new > interpolated target scale), in lldrawable.cpp "updateXform" to decide > whether a scale change requires an immediate rebuild or not. Yes, the child primitive is properly resized in this case, BUT, it snaps to its new size instead of resizing smoothly (which basically means that the server side smooth resizing is done for nothing at all !...). It's not very pretty and I'm pretty sure some makers and vendors of scripted items (especially the ones with apparent "mechanics" in their products) will not like it... Granted: LLVector3 vec = mCurrentScale - dest_scale; if (vec * vec > MIN_INTERPOLATE_DISTANCE_SQUARED) causes less stress than: if (old_scale != target_scale) But it's pretty rethorical and theorical since I'm still to see a sim where thousands of child prims would resize simultaneously to have high enough an impact on the frame rate in the second case... Henri. From sldev at free.fr Mon Feb 18 01:48:12 2013 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 18 Feb 2013 10:48:12 +0100 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218104421.84347da6.sldev@free.fr> References: <20130218030133.7951.18601@domU-12-31-38-00-90-68.compute-1.internal> <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> <20130218104421.84347da6.sldev@free.fr> Message-ID: <20130218104812.24b9b4f1.sldev@free.fr> On Mon, 18 Feb 2013 10:44:21 +0100, Henri Beauchamp wrote: > On Mon, 18 Feb 2013 03:02:40 -0000, MartinRJ Fayray wrote: > > > I fixed that by comparing the original scale versus the new target > > scale (instead of comparing the original scale versus the new > > interpolated target scale), in lldrawable.cpp "updateXform" to decide > > whether a scale change requires an immediate rebuild or not. > > Yes, the child primitive is properly resized in this case, BUT, it > snaps to its new size instead of resizing smoothly (which basically > means that the server side smooth resizing is done for nothing at > all !...). It's not very pretty and I'm pretty sure some makers and > vendors of scripted items (especially the ones with apparent > "mechanics" in their products) will not like it... > > Granted: > LLVector3 vec = mCurrentScale - dest_scale; > if (vec * vec > MIN_INTERPOLATE_DISTANCE_SQUARED) > > causes less stress than: > if (old_scale != target_scale) > > But it's pretty rethorical and theorical since I'm still to see > a sim where thousands of child prims would resize simultaneously > to have high enough an impact on the frame rate in the second > case... Addendum: I guess you could do the stepped resizing for non-visible prims (you could even increase the steps size) and do smooth resizing for visible (in FOV) prims... Henri. From Aleric.Inglewood at gmail.com Mon Feb 18 07:25:21 2013 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 18 Feb 2013 15:25:21 -0000 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130218152521.7852.68203@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/#review1301 ----------------------------------------------------------- I don't understand this "fix" at ALL. It doesn't seem to make any sense :/... What you need is to set the final scale once the distance between destination and current become LESS than the minimum interpolation distance, because then interpolation will never update it anymore. This fix just makes condition true all the time for your test case at your frame rate, but will still fail to reach the final scale when you increase the frame rate (or when the destination scale is simply so close to the start scale that this condition is never true). - Aleric Inglewood On Feb. 17, 2013, 7:02 p.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/617/ > ----------------------------------------------------------- > > (Updated Feb. 17, 2013, 7:02 p.m.) > > > Review request for Viewer. > > > Description > ------- > > At high framerates tiny prims get stuck upon interpolation when they are resized via script. > I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), > in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. > > > This addresses bug BUG-1709. > https://jira.secondlife.com/browse/BUG-1709 > > > Diffs > ----- > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/617/diff/ > > > Testing > ------- > > See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 > > Repository: https://bitbucket.org/MartinRJ/bug-1709 > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130218/d1725238/attachment.htm From martin.fuerholz at fuerholz.org Mon Feb 18 07:39:17 2013 From: martin.fuerholz at fuerholz.org (=?utf-8?Q?Martin_F=C3=BCrholz?=) Date: Mon, 18 Feb 2013 16:39:17 +0100 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218152521.7852.68203@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218030240.7849.58383@domU-12-31-38-00-90-68.compute-1.internal> <20130218152521.7852.68203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Hello Aleric, I?m sorry you don?t understand this fix at all. In short: other cases like the one you mentioned >still fail to reach the final scale will be treated in other parts of the code and are parts of other if/else conditions. MartinRJ From: Aleric Inglewood Sent: Monday, February 18, 2013 4:25 PM To: MartinRJ Fayray ; Aleric Inglewood ; Viewer Subject: Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ I don't understand this "fix" at ALL. It doesn't seem to make any sense :/... What you need is to set the final scale once the distance between destination and current become LESS than the minimum interpolation distance, because then interpolation will never update it anymore. This fix just makes condition true all the time for your test case at your frame rate, but will still fail to reach the final scale when you increase the frame rate (or when the destination scale is simply so close to the start scale that this condition is never true). - Aleric On February 17th, 2013, 7:02 p.m., MartinRJ Fayray wrote: Review request for Viewer. By MartinRJ Fayray. Updated Feb. 17, 2013, 7:02 p.m. Description At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. Testing See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Bugs: BUG-1709 Diffs a.. indra/newview/lldrawable.cpp (fbbee98b7512) View Diff -------------------------------------------------------------------------------- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130218/71bbd1db/attachment.htm From nyx at lindenlab.com Wed Feb 20 12:54:42 2013 From: nyx at lindenlab.com (Nyx Linden) Date: Wed, 20 Feb 2013 15:54:42 -0500 Subject: [opensource-dev] Server Side Avatar Appearance pile-on test Message-ID: Greetings all, In preparation for rolling out server side avatar appearance, we'll be running a short test tomorrow afternoon. If you are available, or know someone who is, please come to the server usergroup ( http://wiki.secondlife.com/wiki/Server_Beta_User_Group) with the latest sunshine viewer ( http://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance version number 270409). We will run the test after the server meeting, for those able to stick around. You will need several outfits that your avatar can switch between and will do so both on the old system and the new system. Also please clear your cache before attending. Please use our latest viewer as it has additional statistics gathering code that will allow us to calculate load patterns and measure the improvements expected for later releases. Let me know if there are any questions! -Nyx Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130220/5742ccd3/attachment.htm From sldev at free.fr Fri Feb 22 01:29:50 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 22 Feb 2013 10:29:50 +0100 Subject: [opensource-dev] Server Side Avatar Appearance pile-on test In-Reply-To: References: Message-ID: <20130222102950.1f0bd376.sldev@free.fr> On Wed, 20 Feb 2013 15:54:42 -0500, Nyx Linden wrote: > Please use our latest viewer as it has additional statistics gathering > code that will allow us to calculate load patterns and measure the > improvements expected for later releases. > > Let me know if there are any questions! Greetings, Today, I'm having troubles on Aditi SunshineTest resgions: the server-side baking seems broken. Whether I use LL's latest Sunshine viewer(*) v3.4.5.270409 or the Cool VL Viewer v1.26.7, which both used to work just fine before, I get "bad requests (400)" errors, like so: WARNING: RequestAgentUpdateAppearanceResponder::errorWithContent: appearance update request failed, status: 400 reason: Bad Request DEBUG: RequestAgentUpdateAppearanceResponder::errorWithContent: content: INFO: RequestAgentUpdateAppearanceResponder::onFailure: retrying (SecondLife v3.4.5.270409 for Windows) or: WARNING: RequestAgentUpdateAppearanceResponder::error: Appearance update request failed, status: 400 reason: Bad Request INFO: RequestAgentUpdateAppearanceResponder::error: Retrying... (Cool VL Viewer v1.26.7.11, either Linux or Windows builds) Was something changed that is not yet propagated to the sunshine-external sources repository (the last commit in it dates back from 8 days ago) ?... If the answer is "yes", then please commit the necessary changes today... Regards, Henri. (*) The Linux build is still impossible to run for me because it requires GLIBCXX_3.4.15: "bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by bin/do-not-directly-run-secondlife-bin)" when my system got libstdc++.so.5.0.7 (g++ v3.3.6) and libstdc++.so.6.0.13 (g++ v4.4.3). Why don't you build the Sunshine viewer on the same build system as for the other viewer branches (which all run fine on my system) ?... From nyx at lindenlab.com Fri Feb 22 08:00:19 2013 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 22 Feb 2013 11:00:19 -0500 Subject: [opensource-dev] Server Side Avatar Appearance pile-on test In-Reply-To: <20130222102950.1f0bd376.sldev@free.fr> References: <20130222102950.1f0bd376.sldev@free.fr> Message-ID: We saw similar errors for some users at the pile-on yesterday, it appears to be account-specific (some people can reproduce others cannot). There are a few commits that have not been pushed to sunshine-external yet, but nothing that should affect the behavior so fundamentally. We're going to be looking into this issue today, I'll send another email if we think we have a fix. Thanks for the report! -Nyx On Fri, Feb 22, 2013 at 4:29 AM, Henri Beauchamp wrote: > On Wed, 20 Feb 2013 15:54:42 -0500, Nyx Linden wrote: > > > Please use our latest viewer as it has additional statistics gathering > > code that will allow us to calculate load patterns and measure the > > improvements expected for later releases. > > > > Let me know if there are any questions! > > Greetings, > > Today, I'm having troubles on Aditi SunshineTest resgions: the > server-side baking seems broken. Whether I use LL's latest Sunshine > viewer(*) v3.4.5.270409 or the Cool VL Viewer v1.26.7, which both > used to work just fine before, I get "bad requests (400)" errors, > like so: > > WARNING: RequestAgentUpdateAppearanceResponder::errorWithContent: > appearance update request failed, status: 400 reason: Bad > Request > DEBUG: RequestAgentUpdateAppearanceResponder::errorWithContent: > content: > > > INFO: RequestAgentUpdateAppearanceResponder::onFailure: retrying > (SecondLife v3.4.5.270409 for Windows) > > or: > WARNING: RequestAgentUpdateAppearanceResponder::error: Appearance > update request failed, status: 400 reason: Bad Request > INFO: RequestAgentUpdateAppearanceResponder::error: Retrying... > (Cool VL Viewer v1.26.7.11, either Linux or Windows builds) > > Was something changed that is not yet propagated to the > sunshine-external sources repository (the last commit in it dates > back from 8 days ago) ?... If the answer is "yes", then please commit > the necessary changes today... > > Regards, > > Henri. > > (*) The Linux build is still impossible to run for me because it > requires GLIBCXX_3.4.15: "bin/do-not-directly-run-secondlife-bin: > /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found > (required by bin/do-not-directly-run-secondlife-bin)" > when my system got libstdc++.so.5.0.7 (g++ v3.3.6) and > libstdc++.so.6.0.13 (g++ v4.4.3). Why don't you build the Sunshine > viewer on the same build system as for the other viewer branches > (which all run fine on my system) ?... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130222/4b4b40a2/attachment.htm From sldev at free.fr Fri Feb 22 10:22:37 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 22 Feb 2013 19:22:37 +0100 Subject: [opensource-dev] Server Side Avatar Appearance pile-on test In-Reply-To: References: <20130222102950.1f0bd376.sldev@free.fr> Message-ID: <20130222192237.2dc840ba.sldev@free.fr> On Fri, 22 Feb 2013 11:00:19 -0500, Nyx Linden wrote: > We saw similar errors for some users at the pile-on yesterday, it > appears to be account-specific (some people can reproduce others cannot). FYI and for what it is worth, while I managed to make SSB work with one of my alts, after half a dozen of outfit changes with that avatar, I again got "bad requests (400)" errors... > There are a few commits that have not been pushed to sunshine-external > yet,but nothing that should affect the behavior so fundamentally. We're > going to be looking into this issue today, I'll send another email if > we think we have a fix. Thanks. Regards, Henri. From Lance.Corrimal at eregion.de Fri Feb 22 11:33:38 2013 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 22 Feb 2013 20:33:38 +0100 Subject: [opensource-dev] ok who the *beep* is sarvajeet and why is he spamming the jira? Message-ID: <64840391.8NHT36geTt@sai> in the last two hours I've gotten about two dozen jira notifications where one user by the name of "sarvajeet" commented on the jira i question by adding this comment: JEET Add comment to all issues can we please find that person, hunt him down, pour honey on him, and tie him naked to an anthill? From sldev at free.fr Sun Feb 24 04:14:00 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 24 Feb 2013 13:14:00 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions Message-ID: <20130224131400.31856185.sldev@free.fr> Greetings, I described a *serious*, *major* regression issue that I discovered yesterday while reviewing (again) the SSB code and confirmed today with tests on Aditi SunshineTest regions. Please see: https://jira.secondlife.com/browse/SUN-38 For me (and I would guess, for most advanced SL users since we use the avatar offset dozens of times over *each* SL session), this is even a show stopper issue as far as SSB is concerned. Regards, Henri. From darien.caldwell at gmail.com Sun Feb 24 10:36:12 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sun, 24 Feb 2013 10:36:12 -0800 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130224131400.31856185.sldev@free.fr> References: <20130224131400.31856185.sldev@free.fr> Message-ID: Yes, this was brought up to Nyx and Oz at Oz's last User Group meeting, by inusaito.kanya They were supposed to file a bug under Sunshine, but probably good to have someone else do it as well, in case they didn't. I'm unable to comment on SUN issues (or even make them) but I gave it my vote regardless. - Dari On Sun, Feb 24, 2013 at 4:14 AM, Henri Beauchamp wrote: > Greetings, > > I described a *serious*, *major* regression issue that I discovered > yesterday while reviewing (again) the SSB code and confirmed today > with tests on Aditi SunshineTest regions. > > Please see: https://jira.secondlife.com/browse/SUN-38 > > For me (and I would guess, for most advanced SL users since we use the > avatar offset dozens of times over *each* SL session), this is even a > show stopper issue as far as SSB is concerned. > > Regards, > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130224/b1c1a788/attachment.htm From sldev at free.fr Sun Feb 24 11:09:19 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 24 Feb 2013 20:09:19 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> Message-ID: <20130224200919.826f88ba.sldev@free.fr> On Sun, 24 Feb 2013 10:36:12 -0800, Darien Caldwell wrote: > Yes, this was brought up to Nyx and Oz at Oz's last User Group meeting, > by inusaito.kanya I alas can't participate in meetings held on voice... I regret the time when Soft Linden was in charge of OpenSource and did care about non-English speaking developers, holding his meetings in chat for everyone to be able to communicate on an equal ground... > They were supposed to file a bug under Sunshine, but probably good to > have someone else do it as well, in case they didn't. I searched for an equivalent issue before creating SUN-38, but found none. > I'm unable to comment on SUN issues (or even make them) Gotta love the new closed JIRA !... Way to go, LL... Henri. From desmoulins.uchi at googlemail.com Sun Feb 24 11:11:43 2013 From: desmoulins.uchi at googlemail.com (Niran) Date: Sun, 24 Feb 2013 20:11:43 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130224200919.826f88ba.sldev@free.fr> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> Message-ID: You meant the "closed and banning-for-trying-to-fix Jira" 2013/2/24 Henri Beauchamp > On Sun, 24 Feb 2013 10:36:12 -0800, Darien Caldwell wrote: > > > Yes, this was brought up to Nyx and Oz at Oz's last User Group meeting, > > by inusaito.kanya > > I alas can't participate in meetings held on voice... I regret the time > when Soft Linden was in charge of OpenSource and did care about > non-English speaking developers, holding his meetings in chat for > everyone to be able to communicate on an equal ground... > > > They were supposed to file a bug under Sunshine, but probably good to > > have someone else do it as well, in case they didn't. > > I searched for an equivalent issue before creating SUN-38, but found > none. > > > I'm unable to comment on SUN issues (or even make them) > > Gotta love the new closed JIRA !... Way to go, LL... > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130224/2fbdf79c/attachment.htm From secret.argent at gmail.com Sun Feb 24 15:44:53 2013 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 24 Feb 2013 17:44:53 -0600 Subject: [opensource-dev] Cocoa Project Viewer In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> Message-ID: <4C060B1B-E3DC-4510-A08D-2D77C7F1F791@gmail.com> Where should I report bugs in the Cocoa Project Viewer? On a MBP running Snow Leopard with an 800 pixel high display, the window is taller than the screen and can't be shrunk, even by editing the NS window size settings in the .plist file. This makes it unusable on that laptop. Other than that, I hope some of the TPVs bring in that code base for their Mac versions, because it's wicked fast. From carlo at alinoe.com Sun Feb 24 19:18:26 2013 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 25 Feb 2013 04:18:26 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> Message-ID: <20130225041826.27f5ef48@hikaru.localdomain> On Sun, 24 Feb 2013 10:36:12 -0800 Darien Caldwell wrote: > Yes, this was brought up to Nyx and Oz at Oz's last User Group > meeting, by inusaito.kanya They were supposed to file a bug under > Sunshine, but probably good to have someone else do it as well, in > case they didn't. I'm unable to comment on SUN issues (or even make > them) but I gave it my vote regardless. I'm unable to add a comment either to this issue. What utter crap is this??? From carlo at alinoe.com Sun Feb 24 19:27:20 2013 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 25 Feb 2013 04:27:20 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130224200919.826f88ba.sldev@free.fr> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> Message-ID: <20130225042720.04ccef21@hikaru.localdomain> On Sun, 24 Feb 2013 20:09:19 +0100 Henri Beauchamp wrote: > > I'm unable to comment on SUN issues (or even make them) > > Gotta love the new closed JIRA !... Way to go, LL... I was about to type "fuck you Linden Lab" in my previous post, but assumed they might be assholes enough to then kick me of this list... The phrase "way to go" is inventive. It would never have occurred to me to use that in this context. This whole "open source" HAHAHA project is a pathetic, lame, grrrrrrr - I want to SPIT on it. LL should be sued for fucking CALLING this "open" in ANY way. I hate you. A REAL Open Source coder, Carlo Wood PS I'd add a comment HERE regarding SUN-38, but I learned years ago already that LL doesn't listen to anyone. They are just going to give you the finger Henri (and everyone else in SL) but not going to fix this. I'm not even going to TRY add a (technical) comment. Seriously, why is ANYONE still HELPING them? Why doesn't everyone just leave this list, stop going to their meetings, and stop giving them patches? Are you all stupid or what? From geenz at geenzo.com Sun Feb 24 20:45:05 2013 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 24 Feb 2013 23:45:05 -0500 Subject: [opensource-dev] Cocoa Project Viewer In-Reply-To: <4C060B1B-E3DC-4510-A08D-2D77C7F1F791@gmail.com> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <4C060B1B-E3DC-4510-A08D-2D77C7F1F791@gmail.com> Message-ID: The minimum size for the window (as defined in SecondLife.xib) is 1024x768. This is largely to prevent any odd cases where UI elements end up getting clipped by the window inadvertently (though this is largely only a problem with the width of the window, not the height). I'll see about making the minimum size for the height of the window smaller. On Sun, Feb 24, 2013 at 6:44 PM, Argent Stonecutter wrote: > Where should I report bugs in the Cocoa Project Viewer? > > On a MBP running Snow Leopard with an 800 pixel high display, the window > is taller than the screen and can't be shrunk, even by editing the NS > window size settings in the .plist file. This makes it unusable on that > laptop. > > Other than that, I hope some of the TPVs bring in that code base for their > Mac versions, because it's wicked fast. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130224/5f531105/attachment.htm From kf6kjg at gmail.com Sun Feb 24 20:46:17 2013 From: kf6kjg at gmail.com (Ricky) Date: Sun, 24 Feb 2013 20:46:17 -0800 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130225042720.04ccef21@hikaru.localdomain> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: I know this thread has gotten completely OT, but I feel I should respond to the feeling of dissatisfaction. I contribute to help me. I know that not everything I contribute will be accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I created that I suspect that LL will never swallow, but that is already in Firestorm's LGPL codebase. What I've come to understand, and I accept as I can see the logic behind it, is that open source is not the same as open decision making, nor is it the same as allowing others to make the decisions. It simply means the code is available under a permissive license for others - including us - to review, comment on, modify, and compile for ourselves. Let me re-iterate: open source is NOT community maintenance. LL has never implied or pretended that they've set up a community maintenance program - and I think they'd have major problems if they tried. My L$2, and I will not continue in this topic on this thread. If you wish to respond to me, please take it off-list. Ricky Cron Stardust On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: > On Sun, 24 Feb 2013 20:09:19 +0100 > Henri Beauchamp wrote: > > > > I'm unable to comment on SUN issues (or even make them) > > > > Gotta love the new closed JIRA !... Way to go, LL... > > I was about to type "fuck you Linden Lab" in my previous post, > but assumed they might be assholes enough to then kick me > of this list... The phrase "way to go" is inventive. It would > never have occurred to me to use that in this context. > > This whole "open source" HAHAHA project is a pathetic, lame, > grrrrrrr - I want to SPIT on it. LL should be sued for fucking > CALLING this "open" in ANY way. I hate you. > > A REAL Open Source coder, > Carlo Wood > > PS I'd add a comment HERE regarding SUN-38, but I learned years > ago already that LL doesn't listen to anyone. They are just > going to give you the finger Henri (and everyone else in SL) > but not going to fix this. I'm not even going to TRY add > a (technical) comment. Seriously, why is ANYONE still HELPING > them? Why doesn't everyone just leave this list, stop > going to their meetings, and stop giving them patches? Are > you all stupid or what? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130224/c0c6b480/attachment.htm From jhwelch at gmail.com Mon Feb 25 01:58:04 2013 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 25 Feb 2013 04:58:04 -0500 Subject: [opensource-dev] Cocoa Project Viewer In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <4C060B1B-E3DC-4510-A08D-2D77C7F1F791@gmail.com> Message-ID: Some time ago LL went through a phase of restricting how small the viewer window could be made, which turned out to be something of a mistake. For example, I sometimes need to run my viewer at less than full screen on my 1024x768 scrreen -- I want to expose part of the desktop while monitoring for chat/IMs/etc. I'd suggest not (re)imposing any limit and let the end user determine what works best for them. -jonathan On 2/24/13, Geenz Spad wrote: > The minimum size for the window (as defined in SecondLife.xib) is 1024x768. > This is largely to prevent any odd cases where UI elements end up getting > clipped by the window inadvertently (though this is largely only a problem > with the width of the window, not the height). > > I'll see about making the minimum size for the height of the window > smaller. > > > On Sun, Feb 24, 2013 at 6:44 PM, Argent Stonecutter > > wrote: > >> Where should I report bugs in the Cocoa Project Viewer? >> >> On a MBP running Snow Leopard with an 800 pixel high display, the window >> is taller than the screen and can't be shrunk, even by editing the NS >> window size settings in the .plist file. This makes it unusable on that >> laptop. >> >> Other than that, I hope some of the TPVs bring in that code base for >> their >> Mac versions, because it's wicked fast. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From fuerholz at gmx.net Mon Feb 25 07:10:37 2013 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Mon, 25 Feb 2013 15:10:37 -0000 Subject: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates In-Reply-To: <20130218152521.7852.68203@domU-12-31-38-00-90-68.compute-1.internal> References: <20130218152521.7852.68203@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20130225151037.24380.71174@domU-12-31-38-00-90-68.compute-1.internal> > On Feb. 18, 2013, 7:25 a.m., Aleric Inglewood wrote: > > I don't understand this "fix" at ALL. It doesn't seem to make any sense :/... What you need is to set the final scale once the distance between destination and current become LESS than the minimum interpolation distance, because then interpolation will never update it anymore. This fix just makes condition true all the time for your test case at your frame rate, but will still fail to reach the final scale when you increase the frame rate (or when the destination scale is simply so close to the start scale that this condition is never true). Hello Aleric, I?m sorry you don?t understand this fix at all. In short: other cases like the one you mentioned >still fail to reach the final scale will be treated in other parts of the code and are parts of other if/else conditions. I am aware that the LL version of drawable.cpp differs in several places from the one that Henri (or other TPVs) uses for example, and the change of this fix will not make sense in other viewers. - MartinRJ ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/#review1301 ----------------------------------------------------------- On Feb. 17, 2013, 7:02 p.m., MartinRJ Fayray wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/617/ > ----------------------------------------------------------- > > (Updated Feb. 17, 2013, 7:02 p.m.) > > > Review request for Viewer. > > > Description > ------- > > At high framerates tiny prims get stuck upon interpolation when they are resized via script. > I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), > in lldrawable.cpp "updateXform" to decide whether a scale change requires an immediate rebuild or not. > > > This addresses bug BUG-1709. > https://jira.secondlife.com/browse/BUG-1709 > > > Diffs > ----- > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/617/diff/ > > > Testing > ------- > > See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 > > Repository: https://bitbucket.org/MartinRJ/bug-1709 > > > Thanks, > > MartinRJ Fayray > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130225/76c6d055/attachment-0001.htm From geenz at geenzo.com Mon Feb 25 12:51:43 2013 From: geenz at geenzo.com (Jonathan Goodman) Date: Mon, 25 Feb 2013 15:51:43 -0500 Subject: [opensource-dev] Cocoa Project Viewer In-Reply-To: <9FC5F912-6BC7-40B1-AD83-88B87CA72FAF@gmail.com> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <4C060B1B-E3DC-4510-A08D-2D77C7F1F791@gmail.com> <9FC5F912-6BC7-40B1-AD83-88B87CA72FAF@gmail.com> Message-ID: <2F0BD76A-596D-45E8-A788-ABE4300BFFC7@geenzo.com> Regarding where to post bugs. Post them under BUG on JIRA. Please include either "Project Cocoa" or "Cocoa Project Viewer" somewhere in the report to make it easier for me to track down any but reports specifically with this viewer. > You need to allow for fixed screen decorations: Window title bar, screen menu bar, and dock (even if you hide the dock, you still can't reliably hit controls near the bottom of the screen because the dock pops up, so lots of people don't hide the dock). I've went ahead and removed the minimum window size constraint to allow you to make the viewer window as small as you want to rectify this. However, the default window size will still be 1024x768 on the viewer's first startup. > Other problems I've noticed (from the discussion thread on SLU): > > I was having problems getting my avatar to load. Going into appearance and selecting current outfit clears that up. This shouldn't be related to my changes. My changes only focus on getting the viewer up to speed with Apple's Cocoa APIs, and replacing deprecated Carbon APIs in the process (with a few very specific exceptions, such as Gestalt). > I also have a problem that the mouse vanishes after using it for a couple of minutes, makes it hard to control anything. The vanishing mouse bug is known, however I haven't had a consistently reproducible case for it. Any other details other than "I used it for a few minutes" would be greatly appreciated to help narrow it down. > It reliably hangs on exit, like, every time, on both Mountain Lion (core i7) and Snow Leopard (32-bit core duo). The hang on exit is interesting. I'll look into the viewer's shut down process (I attempted to replicate how the Carbon based viewer handled this, but there's always the chance I missed a step in the process). > And it doesn't ask me if I want to quit when I close the window. Will investigate it. Chances are there's a callback missing somewhere within the window implementation specifically. We already intercept quit signals within the application delegate, but it's possible that NSWindow close needs to be overridden as well. > The antialiasing option doesn't seem to work unless you enable lighting and shadows, particularly noticeable on a laptop. I've just fixed this along with a bug where vsync would always be enabled. From sldev at free.fr Wed Feb 27 11:09:19 2013 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 27 Feb 2013 20:09:19 +0100 Subject: [opensource-dev] DirectX SDK update: should we use it ? Message-ID: <20130227200919.0f266ba1.sldev@free.fr> Greetings, Today, Windows Update proposed me this update: http://support.microsoft.com/kb/2670838 I was well inspired to follow the "Find out more about this update" link, because in the explanation page, they state: "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX Software Development Kit (SDK), you will have to update your development environments after you install this platform update." And the June 2010 DirectX SDK is precisely used by the viewer... Not being a Windows guru, I don't know whether applying the proposed update and updating to the Windows 8 SDK (which is listed among the possible solutions) is a good idea or not: will it break the viewer builds ?... If not, will the viewer builds still work under Windows XP, Vista and 7 ?... Couldn't we simply get entirely rid of the DirectX calls in the Windows viewer builds ? Any thought about this ? Henri.