CODE
default
{
touch_start(integer total_number)
{
state one;
}
}
state one
{
state_entry()
{
llSetScale(<0.1, 0.1, 0.1>);
}
touch_start(integer num)
{
state two;
}
}
state two
{
state_entry()
{
llSetScale(<1, 1, 1>);
}
touch_start(integer num)
{
state one;
}
}
Real simple, all it does is flip back and forth between two sizes. Steps to reproduce:
* Rez 2 cubes, A and B. Link them so A is the root. Drop the script in B (child prim)
* Touch it a few times and verify that it's correctly switching between the two sizes
* Turn flexi on for prim B
* Touch it a few times now and see what happens
Here's what I see: the prim ends up with <0.1, 0.1, 1> or <1, 1, 0.1>. In other words, the Z axis of the scale is set to the n - 1'th value specified. Right-clicking and editing the prim sometimes makes it snap back to its correct size.
I can force it to go to the correct size by doing something like:
CODE
llSetScale(<1, 1, 2>);
llSetScale(<1, 1, 1>);
Doing <1,1,1> twice doesn't work, probably because the second function call doesn't send an update out, since it decides the change isn't large enough or something. Even this fails sometimes, and it'll end up at one of the two "bad" sizes.
I know people have reported issues with scale/position changes with flexi prims, and I'd experienced them too, but I could never reliably reproduce it. If someone could try this and let me know if they see the same behavior, then I'll bug report it.
Also, would you agree that this seems like a client bug?
Seagel Neville