Object Position

In my past experience I know that linked objects have some sort of average position between them. Now based on this, I would assume for llRezObject, all one needs to do is put in the appropriate regional coordinates and you'll have your object exactly where you want.

I discovered that they seem to disagree on this matter of calculated linked objects. When you put in regional coordinates, llRezObject does not calculate it the same way as the object tab or even llGetPos. For example:

llRezObject("Thingy",<88.59274, 10.33763, 116.17599> , ZERO_VECTOR, <0.00000, 0.00016, -0.00018, -1.00000>, 0);

produces coordinates of:
Thingy: <91.03052, 4.97718, 115.10012>
as confirmed by llGetPos and the object's x,y,z position sliders.

So is this a bug or merely a cruel way to make it insanely hard to position anything except relative to the rezzer?

I would hazard a guess that one of them is using the position of the parent prim of the object, while the other is using the 'center of mass' position of the object. I'd say llRezObject() is doing the former, and llGetPos() is doing the latter. That is annoying.

What happense if you rez it with ZERO_ROTATION?

with zero rotation, same thing happens. I was just correcting rotatation as this was the rotation my original object reported.

Essentially the goal was to place a rezzing object -somewhere- and then place the original another place, gather data from the original and place it into llRezObject so that it rez's the object based on this data. The conclusion was that something is fuxd.

Is the object doing the rezzing less than 10m away from the target rez point? If not, that's your problem. Object's can be rezzed farther than 10m from their rezzing object.

Siro, I'd say it was the latter.

What is happening is that when you rez a multi-prim object, the position you provide is used as the average position for the prims in the object. This isn't the position of any particular prim (unless there is only one) and it isn't the same as the centre of mass of the object (unless all the prims have the same mass).

There doesn't seem to be an LSL call to locate the average location of the prims in an object, but you can do it by hand: add up all the Xs and divide by the number of prims, etc. Then compare that with the location you get with llGetPos and add the difference into your rez call.

Definitely cruelty...

Well, except llGetCenterOfMass and llGetGeometricCenter.

These operate on *this* object though, so you would have to rez the object and then have it correct its position. Not ideal.

Thanks Wednesday, I had forgotten about llGetGeometricCenter; I don't think I've absorbed all the 1.5 changes yet.

Siro, given the existence of llGetGeometricCenter one thing you might consider would be to rez the object once, and run a script in it to give you the difference between llGetPos and llGetGeometricCenter. Then, take that "error vector" and add it into your rezzing code to pre-compensate for llRezObject's odd behaviour.

I have a system that runs into this problem and I might try an approach along these lines. For now, what I've been doing is using llRezObject to put the object roughly where I'd like it to be, then sending it a message on a private channel saying where I'd like it to move to. That works, but this might be nicer.