Help with coordinates for linked objects

I'm running into some annoyances with positioning linked objects. I'm making a crude rezzer script. I place the object where I want it, the rezzer calculates the distance between itself and the object, and then stores the value for later rezzing. Upon rezzing, however, the object ends up in the wrong place. Apparently an object reads its own position one way, and another object rezzes it a different way. Best I can tell, this has something to do with the actual center of a linked object and the center of the root prim of a linked object being different.

I need some way to get around this, but I can't figure out any mathematical way to fix this apparent bug. Surely this problem has been encountered before, but I can't seem to find any solutions after quite a bit of searching. Any help is appreciated.

The solution is to store, the offset rather than a distance or absolute coordinates. Then add the offset to llGetPos() within your llRezObject() function.

Yep I have been through that with a linkset. DO not use llRezObject.

Use llRezAtRoot instead.

Eeeeep. You will need to find out the root position also. One thing I did a long time ago was create a script that would set the object name with the root position, turn the linkset "temporary" and then remove itself. Then I would take the linkset into inventory and put it in the rezzer. The rezzer would llRezAtRoot using LLGetInventoryName as to what to rez and the postion to rez at.

Editted. Ugh oh I am sleepy and didn't catch that. I set mine temporary because I was creating a temp on rezzer.

One other thought:

At the time I had tried using Geometric center and all kinds of stuff. You might possible try getting the center of the bounding box and try rezzing there.

EUREKA! That was a months old problem for me. Try this:

Place this script in a linkset to get the center of the bounding box:

default{
    touch_start(integer total_number){
        vector pos = llGetPos();
        key thiskey = llGetKey();
        list box = llGetBoundingBox(thiskey);
        vector min = llList2Vector(box, 0); 
        vector max = llList2Vector(box, 1); 
        vector offset = (min + max) / 2;
        vector bb = offset + pos;
        llSetText((string)bb, <0,0,0>,1);
        llSetObjectName((string)bb);
        state next;
    }
}
state next{
    touch_start(integer total_number){
        llSetText("", <0,0,0>,0);
        state default;
    }
}

Then place this in another prim to act as the rezzer:

default {
    touch_start(integer num_detected) {
        llRezObject(llGetInventoryName(INVENTORY_OBJECT, 0), (vector)llGetInventoryName(INVENTORY_OBJECT, 0), ZERO_VECTOR, ZERO_ROTATION, 42);
    }
}

Touch the linkset to set the name and take a copy into inventory and place into the rezzer. WHen you touch the rezzer it will rezz it exactly where the existing linkset is. You won't see it though because they both occupy the same spot. Just delete a set and the other is still there.

I'll give the bounding box method a try tonight. My previous method was to simply subtract the object's llGetPos from the rezzer's llGetPos and store that offset. Then the rezzer just used llRezObject with the offset, and that's when the problem came about.

Thanks for the help. Any other ideas are still welcome, I like to try different things.

EDIT: I got the bounding box method to work out, and it's a fairly nice solution. However, I guess because of the inconsistency of the physics system, the calculated offsets are always a slight bit different every time I read them. Though objects seem to rez alright, the differences between the coordinates read and the final output can sometimes be as much as .05, which ends up being very noticeable with aligned objects. If there is any other method that is more exact than this, I'd really love to find out.

I've messed around with a few things and haven't come up with a better solution yet, though I have found a new problem...

I'm basically using a notecard to store an object's offset and its rotation, these values assuming the rezzer has zero rotation. When rezzing the objects, I can make the rezzer change the offsets based on its own rotation, and I can get it to correct the object's rotation by multiplying the stored rotation by the rezzer's rotation.

The objects themselves contain scripts to read off the calculated offset and rotation to paste into the notecard. While they fetch the offsets correctly at any rotation (divides offset by rezzer's rotation), I can't figure out how to make them calculate what their rotations would be if the rezzer had zero rotation (assuming the rezzer currently -isn't- at zero rotation, but the object itself has the proper offset and relative rotation). If you could figure out that mouthful, it would seem like a rather simple expression, but I can't work out any manner of mathematics to calculate what I'm looking for.

Here's a rough example using only the Z rotation (in degrees): When the rezzer has zero rotation, object A should be 290. However, if the rezzer is at 270, object A becomes 200. If all I knew was the rezzer and object's current rotations (270 and 200), how do I calculate what the object's rotation should be if the rezzer had zero rotation (290)? Note that I have the appropriate euler and quaternion conversions in place, and the notecard only stores euler rotations currently for ease of comparison. After I get this equation figured out, I will just have the quaternion rotation put in the notecard.

My long-windedness should indicate how long I've been trial-and-erring this seemingly simple little problem without success. I'm sure the answer IS simple, so someone please enlighten me before I start losing sleep over geometry! >_<

You could check out the record and position sections of newfie's builders buddy. AFAIK, linked objects are positioned iaw the root prims.
/54/2b/96792/1.html

ahhh you aren't really a scripter until you have missed a few nights sleep!!!

Rotations aren't my strong point. I am hoping that since I am replying and bumping the thread to the top then it will get a response from some one that knows a better way to do this.

What comes to mind for me is:

float bz = 290;

default{
	touch_start(integer num_detected) {
		az = 270;
		bz = az + bz;
		if(bz > 360){
			bz = bz - 360;
		}
		//insert bz.z into the rotation
		llSay(0, (string)bz);
	}
}

[6:25] Object: 200.000000

Well I got the general idea from your example, reversed it, and it works! Here I was trying to multiply and divide rotations when all I had to do was simple addition and subtraction. Figures the answer was easy.

I suppose those are all the answers I need. Special thanks to Jesse Barnett, who will be getting some credit in my script.