Trying to Figure Out How To Make a Prim Go Back And Forth

Like a swing or a piston, things like that...any ideas? I think the secret lies in tweaking the rotation script but I can't get it to do what I want...can someone be so kind as to show a stupid newbie how to do this?

I think you will likely get more/better answers if you post a specific goal you are trying to achieve with a lot more details than simply, "How do I make something move?" Is this a child prim in a link set you want to move, or the whole object? If the latter, is it a physical object or non-physical? Attachment or free-floating? If you haven't run across it yet, the LSL Wiki has great information, tutorials, and sample code:

Just a single basic prim - would like to make it go x distance in one direction and then back in the opposite direction. Like this: <------>.

Am I mistaken in that it's a variation of the rotation script? But yes, I will root through the wiki as well.

llSetPos and either a while or a for loop

Well, you are going to want linear motion such as that afforded by the 'llSetPos()' method like Osgeld mentioned. However, you then have to think about a couple of factors:

1. How fast do you want it to move from one point to the other?
   
2. How smoothly do you want it to move?
   
3. Do you want it to move uninterrupted, or do you want it to register collisions?

It is easier to make physical objects move in a smooth fashion and control the time it takes to move (using 'llMoveToTarget()'), but they will collide with other objects while moving and the same call unfortunately doesn't work for non-physical objects. For non-physical objects, you can use 'llSetPos()', but it won't move very smoothly unless you call it a lot more often than twice.

There are some limits to the distance you can move with either call. 'llMoveToTarget()' has a distance limit of about 50m. 'llSetPos()' has a limit of 10m for EACH CALL and delays the script for 0.2 seconds, but you can actually use 'llSetPrimitiveParams()' to get around this (I'm not sure if you want to in this case, though; probably you want the object to move fludly).

Here is an example of how you can do this with a physical object. The motion won't be quite pendulum-like, because although the object will slow when it reaches one end, it will suddenly move very quickly in the reverse direction until it gets close to the other end. It will probably look close enough though. (Note: this is just to help you get where you're going; it hasn't been compiled or tested yet.)

////
// Configuration values
////

vector OFFSET1 = <-1.0, 0, 0>;
vector OFFSET2 = <1.0, 0, 0>;
float HALF_OSCILLATION_PERIOD = 1.0;  // Approximate
float CLOSE_ENOUGH_DIST = 0.2;


////
// Variables
////

vector pos1;
vector pos2;

integer headingForPos1;

integer targetHandle;


////
// Functions
////

initiateMovement()
{
   vector currPos = llGetPos();
   pos1 = currPos + OFFSET1;
   pos2 = currPos + OFFSET2;

   headForPos1();
}

headForPos1()
{
   cancelMove();

   headingForPos1 = TRUE;
   targetHandle = llTarget(pos1, CLOSE_ENOUGH_DIST);
   llMoveToTarget(pos1, HALF_OSCILLATION_PERIOD);
}

headForPos2()
{
   cancelMove();

   headingForPos1 = FALSE;
   targetHandle = llTarget(pos2, CLOSE_ENOUGH_DIST);
   llMoveToTarget(pos2, HALF_OSCILLATION_PERIOD);
}

cancelMove()
{
   llTargetRemove(targetHandle);
   llStopMoveToTarget();
}


////
// States
////

state default
{
   state_entry()
   {
      llSetStatus(STATUS_PHYSICS, TRUE);
      initiateMovement();
   }

   on_rez(integer startParam)
   {
      initiateMovement();
   }

   at_target(integer targetNum, vector targetPos, vector currentPos)
   {
      if (headingForPos1)
      {
         headForPos2();
      } else
      {
         headForPos1();
      }
   }
}

(I'll post a non-physical example in the next post.)

Here's a non-physical example. Note that this will cause more lag due to constant activity (hopefully the built-in delay in 'llSetPos()' yields sufficiently for other activity on the sim. It also might appear jerky because the fastest it will move is once every 0.2 seconds. If you make the distance too great or the period too small (or possibly if there is a lot of lag), the motion will become rather erratic. You'll just have to mess with it to figure out what the practical limits are.

Note that if you wanted to intterrupt this script, you would have to change it to use a timer, or stop/reset it from outside (manually or from another script), or something. You may want to test this on a temporary object until you KNOW you have the movement well under control.

(Again this has not been compiled or tested.)
EDIT: Fixed. Compiles and even seems to work!

////
// Configuration values
////

float MAX_DIST = 2.0;
vector DIRECTION = <1, 0, 0>;
float OSCILLATION_PERIOD = 1.0;

////
// Functions
////

continuousMovement()
{
   vector center = llGetPos();

   float omega = TWO_PI / OSCILLATION_PERIOD;
   vector amplitudeVec = MAX_DIST * llVecNorm(DIRECTION);

   float initTime = llGetTime();

   while (TRUE)
   {
      float elapsedTime = llGetTime() - initTime;
      vector nextPos = center + amplitudeVec * llSin(omega * elapsedTime);

      llSetPos(nextPos);
   }
}

////
// States
////

default
{
   state_entry()
   {
      continuousMovement();
   }

   on_rez(integer startParam)
   {
      continuousMovement();
   }
}

This isn't necessarily true. There's more script activity, but this script doesn't cause any real physics engine load. The other script clearly does. Since something around 100 physical objects colliding with each other can basically wreck a sim (TD < 0.1) without any scripts in them at all, there is an appreciable load with physical objects and movement.

Hmm. Good point. Well, the physical object could also be made phantom. Then we have both no collisions and little script activity (I doubt the physical movment calculations will incur significant processing expense). Didn't really think of that before for some reason.

Thanks, everyone - I'll tinker with that and see what happens (dons goggles and protective gear)

Could the effect be "faked" by moving a texture on a prim?

Good point. This solution often doesn't occur to me because I am on LInux and cannot upload textures. So I pretty much ignore any texture-related solution. It is a textureless Second World for me. Grrr!