Moving linked prims unlinks set?

I've been working on an idea for a house; The idea was that I'd set up a basic house, get the thing finished, link it together, then give it a "brain" prim. I'd set up the brain with a script that would tell each prim to go to specific positions, - llSetLinkParams stuff. The idea was to make a house that would rearrange itself without using one of those rezzer things.
However, after working fine for a day and a half on the test prim (One wall of the house), it now does something strange:

Script 1 fires off, resetting the prim to point 0,0,0 (From the parent prim) and turning the prim into a .01, .01, .01 cube.
Script 2 fires off, setting the prim back up where it should go - The llSetPos sets the prim at the location it's supposed to go.
However, when it does this, it unlinks the entire house.

At the time, I'm using llSetPrimitiveParams (and llSetPos, and llSetLocalRot, since they're fidgety at times) to set all the information, because the link numbers keep changing every time it unlinks itself and I have to re-link it. Since llSetLinkParams doesn't really work when prims aren't linked, you can see why this is a problem...
The only hint I have when it comes to why it would do this is that when I try to link it again, I often get a "Prims too far apart" message. The "brain" prim is rather small, since I wanted something non-intrusive for each style of house, and I know that prim mass effects how far away links can be; However, I've been able to relink the house with no effort at all on other occasions. Can anyone think of wat's causing the mass unlinking?

default
{
    link_message(integer sender_num, integer value, string text, key id)
    {
        if (llGetSubString(text,0,3) == "Mode")
        {
            llSleep(11);
            if (text == "Mode 1")
            {
                llSetPos( <-4.37171, -0.09952, 7.63420>);
                llSetLocalRot(<-0.29642, -0.09342, -0.95044, 0.00862>);
                llSetPrimitiveParams([PRIM_COLOR, ALL_SIDES, <1, 1, 1>, 1, PRIM_TEXTURE, ALL_SIDES, "e914f323-0eda-4277-5fdc-01cf88015cab", <2,2,0>, <.5,.5,0>, 0, PRIM_TEXTURE, 4, "cf3090f0-7df9-fcf7-550f-5d48ffd8b9fb", <1,4,0>, <0,0,0>, PI / 2, PRIM_TEXTURE, 2, "e914f323-0eda-4277-5fdc-01cf88015cab", <4,2,0>, <.5,.5,0>, 0, PRIM_SIZE, <5, 10, 5>, PRIM_TYPE,0,0,<0.000000, 0.750000, 0.000000>,0.949850,<0.000000, 0.000000, 0.000000>,<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>]);
            }
        }
    }
}

The sleep amount is to give people time to exit the building before it reconstructs itself.

After some futzing, I think it has to do with the fact that the prim is in its reset state (size .01,.01,.01) when it moves; I changed it so it changes size first, then moves, and it no longer unlinked. However, I can't seem to figure out a method to correctly get the position to set it for llSetPrimitiveParams. llSetPos would work perfectly; I have the parent offset, and I just pop it in and go. However, when it's in the llSetPrimitiveParams, the location is global. Now, I figure there's a simple method to solve this; Add llGetRootPosition in and offset the original local position by the root's global position, thus getting the position I want.
Now, it moves it to the root position for the reset, as it should, then decides that <0,0,0> local is <0,0,0> + <offset> local. It doesn't do this when I tell it to give me the value; llOwnerSay returns the correct location for llGetRootPosition + <offset>, but the list is ignoring the extra information. Putting it in a separate vector and adding it before the list returns the same results.
The parent prim is currently huge; I know it's not an issue with the limit on linking distance.

default
{
    link_message(integer sender_num, integer value, string text, key id)
    {
        if (llGetSubString(text,0,3) == "Mode")
        {
            llSleep(11);
            if (text == "Mode 1")
            {
                vector position = (llGetRootPosition() + <-4.37340, -0.09950, 7.63390>);
                llSetPrimitiveParams([PRIM_COLOR, ALL_SIDES, <1, 1, 1>, 1, PRIM_TEXTURE, ALL_SIDES, "e914f323-0eda-4277-5fdc-01cf88015cab", <2,2,0>, <.5,.5,0>, 0, PRIM_TEXTURE, 4, "cf3090f0-7df9-fcf7-550f-5d48ffd8b9fb", <1,4,0>, <0,0,0>, PI / 2, PRIM_TEXTURE, 2, "e914f323-0eda-4277-5fdc-01cf88015cab", <4,2,0>, <.5,.5,0>, 0, PRIM_SIZE, <5, 10, 5>, PRIM_TYPE,0,0,<0.000000, 0.750000, 0.000000>,0.949850,<0.000000, 0.000000, 0.000000>,<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>, PRIM_POSITION, position, PRIM_ROTATION,llGetRootRotation() +   <-0.29644, -0.09341, -0.95046, 0.99138>]);
            }
        }
    }
}

Have you tried to pull all the SIZE, ROTATION, and POSITION out of the llSetPrimitiveParams and instead use llSetScale, llSetRotation, and llSetPosition? That way you can still use the local coordinate system and mess around with the ordering of the operations.

Yes, I stated that in both posts. The problem is the fact that I don't want 70 running scripts on my 512 parcel, and since all of the functions I want to do can bet set in an llSetLinkParams, I could control the entire building with only one script.

You rock! Now if every body thought this way the world would be a better place.

Hooray! Wait, that still leaves the problem.

I think it has to do with the non-uniform scaling. When you resize a 10x5x1 wall to .01x.01.x01 cube, it scales it by a different amount in each dimension. So there's no easy way to reposition it after you inflate it again. If you there was a simple uniform scale, you could inflate and reposition it using that scale as a multiplier. The inflation code would look something like this (psuedo-code)

// assume you know the deflated scale and how much you deflated it
float DeflateScale = 0.1 // you deflated by 0.1, so you will inflate by 10.0
vector OriginalChildSize // you know this somehow

llSetLinkPrimitiveParams(child_link_num, 
            [PRIM_SIZE, OriginalChildSize * (1.0/DeflateScale), 
             PRIM_POSITION, position * (1.0/DeflateScale)])

I'm not sure I understand... The center of the cube is the center of the cube, regardless of the size...*

*Unless you did prim torture on the cube.

Is there any chance I could get a clarification on the previous suggestion? I still don't understand how the center point of a single prim would be different.

I haven't tried this in-world yet - just a gut feeling.

When you change the order of operations (scale, position, rotate) you will get different results. At first, when you moved the cube before scaling it, it just worked.

But after you changed the order, you're scaling the cube by a factor of S before moving it. I was thinking you might have to multiply the amount you move it by S as well, in order to get it to the right place. When you use non-uniform scaling, it's not clear what the value of S should be.

The lsl wiki has some code on the llSetScale page that shows example of downscaling and upscaling. The wiki seems to be down right now, here's the google cache: http://64.233.167.104/search?q=cache:DW4ynuuBl1kJ:lslwiki.net/lslwiki/wakka.php%3Fwakka%3DllSetScale

I had a llSetPos() that I moved from the beginning to after the llSetPrimParams, and it worked fine; It seems to be an issue with llSetPrimParams. I'm wondering if it's possible to fix it.

Edit: Wait, do you think I'm trying to move the prim to compensate for a size change on the parent prim? I'm just trying to move it in the linked set; The llSetSize() info only refers to position moving in relation to linked set scaling.

Dumbest mistake ever, and it took me this long to figure it out.
PRIM_POSITION acts exactly like llSetPos, which means that when in a link object, it's already local. I was trying to offset for local, so it was silently failing.

llSetPrimitiveParams() and llSetLinkPrimitiveParams()