I... hate... rotations...

[Lash Carver]

Can somebody please help? I'm basically making a rezzer but I want to be able to rotate it and have it rez stuff "forward" according to the rotation of the rezzer itself. I have the position part worked out, but the rotation is always wrong!

 

I don't know how to do this mathmatically! I'm rezzing the objects using the rezzer's current rotation but I'm guessing I then need to add / subtract / multiply the prim's origional rotation?

 

so if I record positions and rotations like this...

v =

 

then rotate and rez, it should look like this...

<

||

 

or this...

 

= ^

 

or this...

||

>

 

 

does that make since?

 

[Rolig Loon]

You should be able to do that without any magic.

llRezAtRoot("My Object", llGetPos() + <0.0,1.0,0.0>*llGetRot(), ZERO_VECTOR,llGetRot(), 1);

That should put the new object to one side of the rezzer and give it the same rotation as the rezzer itself, regardless of which way you turn the rezzer.

[Lash Carver]

In my build, the rezzed objects can go beyond the 10m by memorizing their own locations and rotations and when rezzed they jump into position. So how do I do this without using a rezzed pre-determined location?

 

Right now I'm trying something like this... (but failing)

llSetRegionPos(llGetPos()+MyOffset*ParentRot);

 

Obviously all pieces are rezzed exactly ontop of the rezzer then moved into position.

[Rolig Loon]

If your object is being rezzed at the same position and rotation as the rezzer, then the llSetRegionPos statement you wrote should do the job.  I assume that ParentRot is the rezzer's rotation and that you are either sending it to the rezzed object with a handshake message or that your new object is getting it from a quick sensor scan.

[Lash Carver]

yep quick & tiny sensor scan to get parent/rezzer. But as I said the rezzed objects are rezzed at the wrong rotations right now. I need them to be rotated according to how they once were mixed with their new rotation. What am I doing wrong?

[Rolig Loon]

So match their rotation on rez to the rezzer's rotation.  That's what I wrote in my first response.

[Lash Carver]

But there has to be a calculation using the old rotation for it to come out right.

 

If I match rotations... the child starts at 90 degrees. I rez it matching the rotation of the parent and now the child rezzes at 0 or whatever the parent is, without even rotating anything. see what I mean?

 

Thank you for the continued help though!

[Rolig Loon]

I think we're not communicating.  I thought you wanted the rezzed object to face the same way, relative to the rezzer, regardless of which way the rezzer is rotated.  It sounds like that's what it's doing, matching the rotation of the rezzer.  What did you expect it to do?

[Lash Carver]

ugh sorry hard to explain, thats why I tried to use the symbols for you.

 

It's like this... the rezzed prim stays in the same position based on whatever the rezzer's rotation is.

 

[Profaitchikenz Haiku]

I think part of the problem here is that you may be recording the rotation of an object relative to the rezzer, but as a region rotation, that is to say, the actual rot obtained by llGetRot. The rotation of the object around it's axis is one thing, but the rotation of it in respect to another item is more a question of positions. The position of the object as LLGetPos is similarly not the same as the position of the object relative to the rezzer.

When you rotate the rezzer and re-rezz,  the vectors are going to change. Your prim which was previously 10 metres greater X and 5 metres greater Y then has to be 10 metres Lesser Y and 5 metres greater X after the rezzer has rotated 90 degrees in a clockwise direction. So, what is required here is not the rotation of the object itself, but the rotation around a point.

Have a look at  http://wiki.secondlife.com/wiki/Rotation this page , in particular the section headed

Position of Object Rotated Around A Relative Point

 

After that, there may still be a rotation to apply to the object if it is to be inverted, or twisted, and that is in effect the object's rotation you will see on the built floater extressed in degrees, but it will be relative to the object's centre, not a regional rotation.

And yes, I hate rotation too.

[Rolig Loon]

I just sent you a demo that uses the code that I posted above.  It produces exactly the result that you are drawing.  I'm not sure what else you want it to do.

[Lash Carver]

Yes your example works perfectly and that's exactly what I am needing (although your rezzer was no mod so I couldn't see that part).

 

For some reason mine does not work like that... Here's what I have...

 

//when position & rotation are recorded
list x=llGetPrimitiveParams([PRIM_POSITION,PRIM_ROTATION]);Pos=llList2Vector(x,0);MyRot=llList2Rot(x,1);MyOffset=<Pos.x-ParentPos.x,Pos.y-ParentPos.y,Pos.z-ParentPos.z>;//when rezzedlist x=llGetObjectDetails(ParentKey,[OBJECT_ROT]);ParentRot=llList2Rot(x,0);llSetRegionPos(llGetPos()+MyOffset*ParentRot);llSetRot(ParentRot);

 As-is, it rezzes the child prim sideways everytime instead of the rotation I had it when I recorded.

[Rolig Loon]

Oh, my.  I apologize.  I was working too fast and didn't check the perms before I sent you that demo.  OK, here are the scripts.   First, the rezzer .......

default{    touch_start(integer total_number)    {        llRezAtRoot("Child",llGetPos(),ZERO_VECTOR,llGetRot(),-88927);    }        object_rez(key id)    {        llSleep(0.2);  //Be sure to give the Child enough time to open a comm channel        llRegionSayTo(id,-88927,(string)llGetRot());    }}

And then the Child (the rezzed object) ....

default{    on_rez(integer startup)    {        llListen(startup,"","","");    }        listen(integer channel, string name, key id, string msg)    {        rotation ParentRot = (rotation)msg;        llSetRegionPos(llGetPos() + <0.5,-2.0,0.0>*ParentRot);        llSetRot(ParentRot);    }}

So, as I said, you rez the object with the same rotation as the rezzer and then you pass that rotation to the Child so that it knows how to reposition itself properly when it applies llSetRegionPos.  The final step, applying llSetRot, is truly redundant since the Child already has that rotation, but I included it as a placeholder, just in case you wanted to apply some other rotation at that point.

[Innula Zenovka]

A variation on Rolig's method, which I mention in case you want to use the rezzer's message to send information other than the rezzer's rotation, would be to do something like this:

listen(integer channel, string name, key id, string message){	rotation rot = llList2Rot(llGetObjectDetails(id,[OBJECT_ROT]),0);//get the rezzer's rotation	vector v = (vector)message;	llSetRegionPos(llGetPos()+v*rot);	}

[Miranda Umino]

When you want to move an object the first question is "in which coordinate system , i am ?"

 

You write

MyOffset = Pos - ParentPos;

 

So, MyOffset is the position of the object B relatively to the object A  but in which coordinate system  :

in the coordinate system  where the origine is A ( and described by ParentPos ) and the axis of the frame of refrence are again the regional axis

But as you will move later your rezzer ( object A ) and rotates it  , and your rezzer had too a rotation mayb e not null , you want , in fact , the position of the object B relatively to the object A in this following coordinate system :

object a ( the rezzer ) is the point of origine of the coordinate system  : the axis of the object A are the axis of the coordinate system

 

So you need to fix your formula when you record your coordinates :

MyOffset = Pos - ParentPos;

by

MyOffset = ( Pos - ParentPos ) / ParentRot ;

where ParentRot is the rotation of the rezzer

 

 

Your script should be something like :

/when position & rotation are recordedlist x=llGetPrimitiveParams([PRIM_POSITION,PRIM_ROTATION]);rotation ParentRot = llList2Rot( llGetObjectDetails(ParentKey,[OBJECT_ROT]), 0);Pos=llList2Vector(x,0);MyRot=llList2Rot(x,1);MyOffset=(Pos -ParentPos)/ParentRot;//when rezzedlist x=llGetObjectDetails(ParentKey,[OBJECT_ROT]);ParentRot=llList2Rot(x,0);llSetRegionPos(llGetPos()+MyOffset*ParentRot);llSetRot(ParentRot);

 

 

Is it celar and do you understant better , or should i give more details or an instance ?

[Lash Carver]

Thank you all so much for the information! I will work with it all a bit more and see if I can get it working. You've really helped me alot!

[Lash Carver]

ok after looking into all of this, I suddonly realized Rolig's example is perfect except for one thing. If you rotate the child prim, it does not keep the rotation given after being rezzed. How can I incorperate the child's rotation into the mix so it can be rotated in any direction relitive to the parent prim?

[Rolig Loon]

If I understand your question properly, multiply ChildRot * ParentRot, either before you send the information to the newly rezzed object or afterwards.