Advice on a fixed path physical object

The problem I'm currently looking at attempting is a runaway mine cart. So, the basics are that it will be a vehicle following a fixed route, at fairly high speed, so I'm looking for advice on several things:

Handling the route
I've first of all ruled out using scripts in each section as I think that for a fast moving vehicle the issue of communicating with them reliably could be difficult.
So this leaves to store the points in the objects itself, which ought to be easy enough, I won't be randomly changing track sections or anything.

My current thoughts are:
A big list, the number of points could be fairly large, not large enough to cause memory issues but large enough that I'm concerned that looking up entries might be annoying for any tight corners with several points fairly close together. What is the look-up time for a list like for such an application, are there any alternatives? Lookups would be mostly sequential (1, 2, 3, 4), does this actually make a difference?
Also, while I said I don't need it to update for dynamically changing tracks, I may have alternate routes that it will randomly take. My current thinking for that is that after looking up a new target, the main script would communicate with a secondary script to find out which point to go to next (ie it'll use a link message to request an integer back).
This other script may actually be state based, so if there are two possible routes, then it will go into one of two possible states, and branch in that way rather than using ifs. Again, is there a better way or is this a reasonably sound way? Each state would run through it's range of numbers then change to another state as needed. I was also considering using this method for retrieving the next co-ordinates, ie each point would have it's own state in this secondary script, and it would change state after each lookup, thus following a route. However, would passing the co-ordinates in a string via link messages be fast enough, or are list lookups faster?

Coding the actual movement
Physical objects are something I haven't touched and this one strikes me as potentially being annoying.
What it needs to do:
- Follow a series of points that may differ in height. Each pair of points will correspond to a straight piece of track, though gradients may differ.
- Ignore collisions or obstructions when moving from point to point, pushing aside avatars if necessary
- Travel at a fairly high, constant speed between points. Starting out relatively slow though picking up speed quickly (ie it'll start on a steep-ish part).

I'm thinking, is it possible with a physical object to tell it to move somewhere and have it do that without worrying about other things, or falling or whatever, in the same way a non-physical object and llSetPos moves directly to a point but smoothly? Would physical + phantom work, if so, can a target be set BEFORE making the object physical, as I don't want it to fall into the ground before it starts moving. ie; it will be non-physical to start with while avatar(s) get into the cart. Does movement support the at_target events for immediately knowing where to move next, how quick is this likely to be when heading to another point immediately after arriving at one?
Any script samples or advice on this is welcome, as I can see it requiring a lot of experimentation and I'd like to get it done sooner rather than later if possible.

Cheers to anyone who gives help

Smooth fast physical motion following a predetermined path is pretty non-trivial stuff IME. Madwand Thatch has the best examples I've seen, roller coaster type things (although not with a cart). I don't know anything about vehicles, and perhaps this is better done with those, I've just tried things with physics objects.

Collisions are likely to be annoying, physical + phantom works well. Falling to the ground isn't a problem - immediately after setting status physics, set your bouyancy, or your movetotarget and there isn't enough time to fall. There is a choice in how one actually gets the physics object to move - with llSetForce, perhaps llApplyImpulse, or more likely llMoveToTarget. llMoveToTarget is great for moving things to targets, but not so great for constant speed motion. Frequent updates of the parameters in the llMoveToTarget function might do what you want though.

The at_target and not_at_target events work great, possibly a good idea to use llMinEventDelay to save the sim if you use not_at_target for updating what you're doing.

I've done something like this with the cars in Suffugium, and I have to say, it's one of the most complicated, mathematics-intensive physical things I've scripted in SL.

I did pretty much what you're saying; I described the path in a notecard as a set of vertices, which is essentially equivalent to specifying a sequence of "legs" of a path to take. I have the cars grab the start and end coordinates for a leg, and try to stick to the line between them while moving in a nice acceleration curve between the start and end. When the car gets near the end, I flip to the next leg and do some tricky stuff to take the corner smoothly.

I decided not to use llMoveToTarget() because it starts off fast and then gradually gets slower, not at all what I wanted. I just use a hell of a lot of llApplyImpulse() calls, and some llRotLookAt() calls to keep the vehicle oriented.

Remember while you're doing something like this that you really can't count on Havok. You've got to make sure your code is resilient to being flung off-course for no reason whatsoever. Sometimes people will come by with "physics disruptors" on, and your car will go flying.

Good luck!

Well, I've managed to cobble together a working llMoveToTarget() system, which basically calculates how far it has to go and uses that for tau (ie it does llVecDist(llGetPos(), target) / speed) and using llMinEventDelay(0.25) it keeps repeating that till it reaches 1m of it's target, and then immediately changes to the next. I've yet to try and use it on a large corner or whatever, which I may do to try and get around the issue of it turning too fast, I may actually go for rotations to define the co-ordinates, ie the first three are the X,Y,Z co-ordinates, and the fourth is a measure of a corner's size (thus it interpolates the points for a fourth value of > 1.0).

I had a greatly appreciated suggestion from Madwand Thatch to use a rail and a torus holding the cart to it, but I think that due to the cart being on ground that that may not work out very well, though it's a nicely dynamic solution (just change the rail configuration to change path).