move object based on its rotation

[Tintin Blinker]

Hi, hope someone can help me out with this one:

I am trying to script an object to move a few meters on touch, but when I use:

llSetPos(llGetPos()+<0,4,0>);

it always moves in the same direction, no matter what the objects rotation is.

However, I want it to move based on the objects rotation axis, i.e. depending on the direction its facing.

So, I need to combine llGetRot with the above somehow, but cant find examples of this so far.

Does any enlightened script guru know how I can solve this problem?

Thanks in advance! (nearly bedtime)

Tintin Blinker

[Randall Ahren]

 

---

I am trying to script an object to move a few meters on touch, but when I use:

llSetPos(llGetPos()+<0,4,0>);

it always moves in the same direction, no matter what the objects rotation is.

However, I want it to move based on the objects rotation axis, i.e. depending on the direction its facing.

---

 

What you're doing will always move the object along the y axis by 4 meters. I think you want something like this:

 

    vector dir = llRot2Left(llGetRot());    vector pos = llGetPos()+dir*4;    llSetPos(pos);

 

The foregoing should move the object along the object's y axis by 4 meters as oriented relative to the SL world.

 

[Void Singer]

you can simply a bit by using

llSetPos( llGetLocalPos() + offset * llGetLocalRot() );

 

I always recommend using local position and local rotation, as there are some situations where certain bugs in in the non-local functions are exposed causing unintended effects

[Tintin Blinker]

Eureka! hehe

First one works smooth as a fishy

Second one gives me an error, but might be  SL bugs and critters at the moment

Much obliged!

Tintin Blinker

 

[Void Singer]

you would need to replace "offset" with ... your offset

[Melkanea]

damn this post is kinda old. any advice im wanting to animate an object with rotation

i have tried every option posted but i get errors asuming is cus there was an update

 

[Rolig Loon]

Nope.  Void's advice from 2011 is still correct.  It's the standard way to set a position relative to the object's current position and rotation.  It's basic vector math. Maybe you are trying to do something completely different?

Edited March 14, 2019 by Rolig Loon

[Melkanea]

59 minutes ago, Rolig Loon said:

Nope.  Void's advice from 2011 is still correct.  It's the standard way to set a position relative to the object's current position and rotation.  It's basic vector math. Maybe you are trying to do something completely different?

Im actually learning to script. and yes it works fine if the objects are unlinked. I want to create a sphere with pyramids pointing towards each axis. I want the pyramids to move away and closer from the sphere while the entire thing rotates

[Melkanea]

[Rolig Loon]

Aha!  Then what you'll want to do is address only the links that you want to move.  That can be a rather tricky process if you are making this a dynamic process.  The simple step for each link you want to move looks like this:

list Params = llGetLinkPrimitiveParams( link_number, [ PRIM_POS_LOCAL, PRIM_ROT_LOCAL ] );
vector LPos = llList2Vector( Params, 0 );
rotation LRot = llList2Rot( Params, 1 );
llSetLinkPrimitiveParamsFast ( link_number, [ PRIM_POS_LOCAL, Lpos + offset * ( Rot_increment * LRot )]);

where you have already defined the position offset and the rotational increment earlier.  Then you repeat that snippet over and over again each time your timer event is triggered, to make the movement dynamic.  That's the simple part.  If you have many child prims to move, you'll want to do this for each one and combine the whole mess into a huge SLPPF statement so that they change at the same time instead of writing out each one (like the last code line above) individually.  It's easy to get lost and lose track of which link is which, and to keep their parameters straight as you keep updating them.

The one link that you do not want to move this way is the root prim.  If you want it to rotate as well, you simply rotate that one incrementally with llSetRot or llSetLinkPrimtiveParamsFast(LINK_ROOT,[ PRIM_ROTATION, ..... ] ).  Don't use llTargetOmega, because that only moves your object client-side.

EDIT:  You added your image while I was typing, and it looks like you are imagining a situation that is slightly different from what I just described.  The overall approach is the same, but the math will be more of a challenge to figure out, I suspect.

 

Edited March 14, 2019 by Rolig Loon
typos. as always.

[Melkanea]

Im using llTargetOmega...
And yes its slightly more complicated than i stated. i want it to be controlled. im using listen() to add some if when i touch the controls (the cubes)
The colored pyramid is what is rotating and where i want the pyramids to move closer and away from.

 

[Melkanea]

i have no idea how to implement your script im getting one error after another. i must be making them since im very new to scripting

[steph Arnott]

24 minutes ago, Melkanea said:

Im using llTargetOmega...
And yes its slightly more complicated than i stated. i want it to be controlled. im using listen() to add some if when i touch the controls (the cubes)
The colored pyramid is what is rotating and where i want the pyramids to move closer and away from.

 

What is this script for. It helps to know.

[Melkanea]

5 minutes ago, steph Arnott said:

What is this script for. It helps to know.

The colored object. i want the pyramids to move away and closer to the sphere again all while the whole thing rotates, the pyramids are also rotating on their own axis

 

 

 

Edited March 14, 2019 by Melkanea

[steph Arnott]

9 minutes ago, Melkanea said:

The colored object. i want the piramids to move away and closes to the spehere again all while the whole thing rotates

 

Think you need to use llSetKeyframedMotion instead.

[Melkanea]

Gebus! im crunching the Wiki. why is it so complicated to move 2 linked objects away from each other?
 

[steph Arnott]

9 minutes ago, Melkanea said:

Gebus! im crunching the Wiki. why is it so complicated to move 2 linked objects away from each other?
 

Well it is not, but you are rotating them as well. The server has to crunch numbers because you are not snapping the objects from start pos to end pos. You are moving them in and out on a timer . What you want is likely to stall which is why i suggest you use the keyframe function. But i am not entirely sure if that works with vectot movements.  http://wiki.secondlife.com/wiki/LlSetKeyframedMotion

Edited March 14, 2019 by steph Arnott

[Melkanea]

Thank you steph. i was talking about that page. i get it now what you are trying to explain.
its not like i can rotate and then move them in a rotating state, i need to do it all at once. 

I knew this idea would push me beyond my knowledge of LSL

Edited March 14, 2019 by Melkanea

[steph Arnott]

14 minutes ago, Melkanea said:

Thank you steph. i was talking about that page. i get it now what you are trying to explain.
its not like i can rotate and then move them in a rotating state, i need to do it all at once. 

I knew this idea would push me beyond my knowledge of LSL

Hmm well you could fudge it by creating a hollow cylinder with a cut path and scaling the cylinder size down and up.

[Rolig Loon]

We're not seeing the whole concept here, so it is hard to know what to suggest. If the entire structure is meant to stay in one place, I might be tempted to try using llSetKeyframedMotion, as Steph is suggesting.  If not, I'm afraid that will be horribly complicated. Still, it's another way to approach the challenge.

What I wrote for you is not a script but a snippet that you would need to incorporate into the timer event in your own script.  If this is one of your first scripting projects, I can understand why you are frustrated.  The logic and the math here are a bit overwhelming, especially if you are just learning the language as well. I wish I could suggest an easier way to do things.  Unfortunately, whether you use incremental movement as I have described or keyframed motion, this is not an simple script to write. 

[steph Arnott]

31 minutes ago, Melkanea said:

Thank you steph. i was talking about that page. i get it now what you are trying to explain.
its not like i can rotate and then move them in a rotating state, i need to do it all at once. 

I knew this idea would push me beyond my knowledge of LSL

Try this it will at least give you a start http://wiki.secondlife.com/wiki/User:Tapple_Gao/3D_Spinning_Pendulum_Motion

[steph Arnott]

2 hours ago, Melkanea said:

 

The more i look at your pic the more i get the impression that the blue pyramids are for moving that box. I.E direction arrows. Is this the case?

Edited March 14, 2019 by steph Arnott

[Melkanea]

10 hours ago, Rolig Loon said:

We're not seeing the whole concept here, so it is hard to know what to suggest. If the entire structure is meant to stay in one place, I might be tempted to try using llSetKeyframedMotion, as Steph is suggesting.  If not, I'm afraid that will be horribly complicated. Still, it's another way to approach the challenge.

I thought it was going to be easier, and no, im not really frustrated just realized the complexity of it. Its not my first script. 
Its my first one incorporating movements.

 The center sphere rotates and the pyramids float around it spinning on its own axis, clock and counterclockwise. The boxes are the controls, they llSay(Mychannel , "left/stop/right") accordingly. Ignore the rotating floating box and the one under it. Thats to test the "easy" way using llTargetOmega and llSetPos

I will try to explain myself better after work. with a YT vid.

 

Edited March 15, 2019 by Melkanea

[Qie Niangao]

I'm not sure I understand the objective here enough to rule out llTargetOmega. If the entire thing rotates -- meaning the center sphere spins around and the pyramids spin around with it (and maybe at the same time spin on their own axes), and if the sphere can be the root of that linkset, I'm thinking a bunch of PRIM_OMEGA properties would be by far the easiest way to make all that spinning-around stuff happen -- as long as it's not important that every viewer sees the same orientation at the same time.

If that's all acceptable, then the bit about the pyramids moving in and out is the only part of the script that needs to keep running and generating object updates, and because they're just moving back and forth relative to that root sphere, the math can be relatively simple -- completely independent of the rotations happening behind the scenes. 

[Melkanea]

My youtube video showing what im trying to create Spinning Pyramids