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 ! 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
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 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. ___ 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
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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
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@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 ___ 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
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 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. ___ 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- 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 ___ 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- 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 ___ 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
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 -, 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.
diff.txt
Description: Binary data
___
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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
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@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 -, 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
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
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 -, 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
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 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
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 -, 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
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 -, 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- 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 ___ 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
[opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- 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 ___ 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
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
On Fri, 15 Feb 2013 09:54:16 -, 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())
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
--- 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 ___ 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
