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 -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
