llRezObject()

HIyas Everyone,

I created an object on an Open Space sim with this function included:

RezCuddle()
{
llRezObject(("Cuddle Pose Balls",(llGetPos()+(<0.236,3.098,0.739>*llGetRot()),<0,0,0>,llEuler2Rot(<0, 0, 99>*DEG_TO_RAD)*llGetRot(),randme);
}

The placement of the poseballs is perfect.

Now that I had to move to a full sim, the "Y" vector in the llGetPos() is not being called correctly or with a consistent offset. I change the value and I get a different offset each time.

I go back to the Open Space sim and everything works correctly (no lag to speak of or anything really different that I can think of). Has anyone noticed anything like this or is there a bug already noted in jira?

Please clarify.

You say "llGetPos() is not being called correctly or with a constant offset".

There's no way to call it incorrectly or pass an offset.

Do you mean it seems to be returning the wrong Y coordinate?

Also, "I change the value and get a different offset" .. please tell exactly which value you change, and what value changes as a result. When we're left to guess these things, we'll waste lots of time.

I didn't scrutinize your code because rotations make my head hurt, and I usually get them wrong. Hopefully Hewee or another of the rotation wizards will chime in.

Meanwhile, I suggest you try breaking down your code into segments and chat the results, e.g.:

    vector mypos = llGetPos();
    rotation myrot = llGetRot();
    llSay(DEBUG_CHANNEL, "I'm at " + (string) mypos + ", " + (string)myrot);
    ...

Also chat the results of the calculations.

Is it possible that you simply have the object with zero rotation in one sim, and with nonzero rotation in the other? It's an easy mistake to make (I've done it), to try to test rotation code with an object that has zero rotation. Seems to work fine until the object isn't at zero rotation, imagine that!

You and me both. But I think that this snippet, from Void Singer's page http://wiki.secondlife.com/wiki/User:Void_Singer/Rotations (which I find invaluable when I'm confused with rotations -- that is, on days with a y in them) may assist:

   vector vVecOffset = <2.0, .0, 1.0>;
    //-- even after rotating your object this will give the point in relation to it's new rotation
   vector vVecCurrentOffset = llGetPos() + vVecOffset * llGetLocalRot();
   

Rezzing the object at vVecCurrentOffset will cause it to rez I metre above the rezzer and two metres to its right, no matter which way the rezzer is facing on the sim. Assuming, that is, we started off with the rezzer oriented at ZERO_ROTATION. When things start to go wrong with my rotations, that's the first thing I check.

yay I got a mention (didn't know anyone had actually read all that, glad it helped)

@OP
formula looks right at a glance, I'll assume you didn't turn the object on it's side or drop the script in a new prim that had a different orientation than the old one (reference up on both is the same local direction, like +z). is the new one in the stratosphere? (higher than 2048 I think?), is it close to a sim or parcel border that would cause the rez to be over that edge? or under ground? does it still misbehave if you copy the old object and place the copy in the same place as the new one?

HIyas Void,

Your assumptions are correct, the object is at about 24 meters on either island, no sim borders or underground, and it doesn't matter where it is moved to. I get a correct placement of the rezzed object on the OPen Space sim where it was created and an incorrect placement on a full private sim. I ended up just plugging in a value for the y vector that worked the best. It seems to be off by a percentage of the difference (which never gets to zero). When I get back online, I'm going to see if "scrubbing" the root prim will do anything. This is just the darndest thing..

let us know, another thing I just thought of, if it is a newly created object... is it the same size/shape as the old, and most importantly does it have the same reference root prim. that could throw off your calculation for offset if they are different (like accidentally tweaking the scale during prim editing)