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 <fuerh...@gmx.net <mailto:fuerh...@gmx.net>> > > 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@lists.secondlife.com > <mailto:opensource-dev@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
_______________________________________________ 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
