llSetPrimitiveParams

I was using this code for doors.

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_SIZE, <9.812,7.268,0.080>]);
    }

    link_message(integer sender_num, integer number, string message, key id)
    {
        if (message == "open")
        {
            llSetPrimitiveParams([PRIM_SIZE, <9.812,0.010,0.080>]);
        }
        if (message == "close")
        {
            llSetPrimitiveParams([PRIM_SIZE, <9.812,7.268,0.080>]);
        }
    }
}

But whenever I use it the whole linkesets drifts around 0.1m after 2 or 3 clicks of the door button.
This is really annoying D:
Any ideas?

Are either of the doors the root of the linkset? Best if they aren't.

Nope

I've run into this bug before. Changing a child prim nudgeing the root prim's position by a teeny amount.

Try putting this in your root prim, making sure that link message is "heard" there too:

vector root_me_at = ZERO_VECTOR;
 
 default
 {
 	link_message(integer sender_num, integer number, string message, key id)
 	{
 		if (message == "open")
 		{
 			root_me_at = llGetPos();
 		}
 		if (message == "close")
 		{
 			llSetPos(root_me_at);
 		}
 	}
 }

Bug report it.

Everyone should. I've bug reported this one twice. Now that I know it's still around, here comes #3.

Ok thanks that stopped the drifting but now I get a stranger problem. The root prim (A floor piece) has somehow become one way phantom. I fall through it but I can get bakc up through it.

It must take a very specific set of conditions to trigger this bug as I have played with the llSetPrimativeParams commands extensively and have never seen this phenomena, but I hear others talking about it fairly often.

I did get it with a small chest that was scripted to have the lid open and close every minute, but it only happened once and after I put it back where it should be it's never moved again.

Well I seem to be unlucky then since every object I have with that line is doing it and I've tried picking it up and copying it.

The only difference I can see between what I am doing and what you are doing is that I am only going to one decimal place with the variables, and I see you are going to three. I really can't see how that would make a diff, but you never know. You might want to play with that and see if it helps. Can't hurt anyway.

Hrm... What I suspect is happening here is that for a brief moment the object kind of vanishes, (during the full object update that occurs when dimensions of a child prim are altered).

During that brief moment that the object is gone, (or being re-defined), you fall through the space that was the floor... when the object regains it's shape and place, you're already falling with enough inertia that it doesn't automatically float you back up, either that or a collision check is failing.

Once you're through and attempt to pass upward through it, a new collision check is attempted and comes back positive, not allowing you to pass.

That's my guess at least.