How do I automate my monorail?

Hi! I have just completed building and testing the components for a monorail system that includes curves.

At the moment the cars are equipped with car scripts, so they need me sit inside and drive them. They follow the track well because the cars have guide brackets to keep them on track. I drive using the forward or back arrows.

What I want to do next is equip the cars so they can shuttle back and forth on their own, carrying passengers and stopping at an intermediate station if possible.

I've seen various trains that do this and I'm wondering what scripts or other systems they use as I can't find any info in 'search'.

Basically you will need to modify the script such that the processing that used to be in the control event happens automatically (probably on a reasonably short timer).

Most are going to be using a variation of MoveTo scripts which essentially cause a physical object to move to a specific location within a certain amount of time.

It can be a little tricky to setup because with MoveTo you have to worry about the object's energy (meaning it might just stop in the middle of a run until it loops back around), the distance between A and B (it will just stop if the other point is too far away), and also you have to compensate for the fact that the object accelerates and deccelerates for each call of MoveTo.

I can't remember the max distance offhand, but I think it's like 50m. So if you wanted to go from <0,0,0> to <0,100,0>, you would have to at least go to <0,50,0> first.

I don't have an example handy, so I can't go into detail atm as it won't make much sense without code to show you.

I'm not quite as good as Newgate at just tossing an example together for something like that

LOL, Newgy is the first to admit he knows absolutely sod all about vehicles.
I do know that there are generally 2 forms of vehicles, some use llMoveTo while others use the llSetVehicleVectorParam functions.

In general however they all process the user input and generate a velocity vector for the vehicle. As Tiarnalalon said one consideration will be the vehicle coasting to a stop pior to the next update, giving a very jerky motion.

The following is from a freebie vehicle script that I have used/modified on occassion.

Snippet

vector pos;
float brake = 0.5;
float timePeriod = 0.5;
integer running = FALSE;

float LINEAR_TAU = 0.75;             
float TARGET_INCREMENT = 0.5; // vehicle speed
float ANGULAR_TAU = 1.5;


default
{
    state_entry()
    {
        llSetStatus(STATUS_PHYSICS, TRUE);
        running = FALSE;
    }

    touch_start(integer total_number)
    {
        running = ! running;
        if(running)
        {
            llMoveToTarget(llGetPos(), LINEAR_TAU);
            llRotLookAt(llGetRot(), ANGULAR_TAU, 1.0);
            llSetTimerEvent(timePeriod);
        }
        else
        {
            // vehicle will coast to a stop
            llSetTimerEvent(0.);
        }
    }

    timer()
    {
        // I'm not 100% sure thsi code is required.
        // I guess its a left over from a more advanced script as pos is never initialised.
        pos *= brake;
        if (pos.x < 0) 
        { 
            pos.x=0;
        }
        else 
        { 
            pos.x += TARGET_INCREMENT; 
        }
        vector world_target = pos * llGetRot(); 
        llMoveToTarget(llGetPos() + world_target, LINEAR_TAU);
    }
    
}

Well, the solution to the coasting and speeding up problem is really to overload the MoveTo so it starts moving to the next point before it reaches the first.

Looking at the example, it looks like this is compensated for on the LINEAR_TAU and the timer event, but to explain what it's doing:

You get a time increment for how long it will take to reach each point
...this is shown in LINEAR_TAU - 0.75.

That's how long it's supposed to take to go from point A to point B.

It then has a timer event set to 0.5, which means it's going to tell it to head for point C before it reaches B and so forth. This makes it where it doesn't reach the point where it's going to slow down before it's heading to the next as subsequent MoveTo's will override any previously called ones.

Now the code Newgate gave is just a snippet of what would be needed to accomplish this fully, as the "llGetPos()+world_target" is undefined.

What I did is took the code from warpPos to generate a list of straight-line points, (obviously I removed the PRIM_POSITION from the lists) and then have it set to do a MoveTo on each of those points.

I would write it into Newgate's, but I will get interrupted a dozen times since I'm at work and it would end up being really buggy. Another reason why I don't post examples much heh.

I actually need to redo mine as I used a flight recorder and the results are not as steady as I would like since lag/etc affecting my flight path. So perhaps I'll work on it tonight and drop an example here.

I have been working on a system I call the "autoBahn"
it uses a linked list and llKey2Name to get the target positions.

I have a secion in the wilki.
http://wiki.secondlife.com/wiki/LSL_Protocol/AutoBahn

--
I have a freebox ($0L) at Charissa(230,240). This is not a final version since there is more work to be done, but you can look at the scripts and see how it works.

Buy a box and rez the bus on the test track and sit on it. It will drive around the track using a timer that applys impules on the floating physical bus.

The road scripts place a key of the next road prim in there name before the script is removed via a chat command.

A replication system upates all the road prims if needed.

Thanks for help - seems complicated, as I'm new to scripting - but I'll plod away until I get it up and running.