Advice on Physical/Vehicle/Phantom.....(please)

In brief:

I am trying to build a "suspended" pre-routed vehicle system, which I guess is a bit like a cable car in principle.

I have looked at llMoveToTarget() and realised that the acceleration and subsequent decelleration (which takes ages) is ok but not as realistic as I'd like to do, however I found loads of problems with the pyhsical object thing.. kept dropping the object to the ground as soon as the script ran..

The non physical llSetPos is ok but jerky and would need a series of small movements using a controller script etc (as seen in this forum).

I looked at vehicles (sled?) and toyed with the idea of a global hover height but came up short when i saw the dire warnings about using movetotarget type actions with a vehicle which begs the question as to how to move a vehicle on a pre determined course without the user interaction.

Could anyone loan some advice on a practical method to achive a cable car type movement - is vehicle the way to go?

I am prepared to pay for someone to assist with the bones of a script that allows me to set a determined course, set corner rotations and wait times.... I have seen a cool one also in this forum for a ground based concept but as this is a "hovering" car (in effect) I would appreciate a pointer.

Taking the script further isnt an issue, i think I just need the bones (documented) so I can experiment further.

Many thanks

Erwin

Brief update.

I tried the llMoveToPos and it seems to do the trick somewhat..

Now I need to figure out the other bits, but still cant see why the lsl wikki and tutorial suggest that using llmovetopos is a bad thing.

Still open to paying a coder to assit with this.

Erwin

One trick to using the LSL Wiki: there are many statements on the old Wiki where the author interjects his opinion rather than sticking to the facts. (e.g. saying some function is a "bad thing" or suggesting one approach is better than another.) In almost every case this occurs, the result is worse than meaningless, it's harmful, since without knowing the specifics of the problem that the reader is attempting to solve, there's no possible way the author can tell whether it's a good idea or not to do it a particular way. Pointing out alternatives is a good thing, but declaring one approach "better" than another without significant qualification (e.g. it's better under these specific circumstances when these are your goals and you don't care about these other things as much) is guaranteed to lead people astray. So just ignore anything that looks like a value judgment or opinion.

The other trick: verify. Some of the info on the Wiki is just plain wrong, probably due to no fault of the original author but rather the changing nature of SL and the poor documentation of these changes on LL's part ("oh did we forget to mention that change in the release notes? tee hee". I'd edit the errors as I come across them if I knew the LSL Wiki of the Week was going to get its changes mirrored to the next LSL Wiki of the Week.

Well the slow down and speed up of MoveTo can be mitigated by setting it to begin moving to the next target before it gets to the current. (making the loop timer shorter than the amount of time set for it to take getting there.)

The only real downside of that is you need more waypoints in your list of targets since there's a max distance.

I have a few prototype shuttles flying around in Sector001 on moveto, and they seem to do ok as phantom and physical, but they still need work since they run out of energy apparently and just stop moving for an entire loop before starting back up again. I can solve that I'm sure just by rezzing a new shuttle each loop. Little messy sure, but *shrug*.

I would suggest if you want to see what it looks like doing it this way before you have to resetup all your waypoints to try it, that you go to 001 and look at the 2 shuttles flying on autopilot and see if that is more like how you want it to look in action. As I said, it's still a little rough since I've been busy on commercial items and haven't wanted to mess with the script heh.

The only problem with phantom on this that I've noticed is that if a *real* vehicle goes through them, it lags up everything a whole lot, and somehow knocks the ship askew (even though it's set to not rotate on any axis but Z) It's probably just some odd thing about trying to calculate collisions that don't exist.

I've been wondering about this myself as it states that use llSetForce in a vehicle is a *bad* idea, but yet as far as I can tell there's a hardcap on all physical vehicles in that they cannot go faster than about 40m/s. Turning the throttle up and the friction down just makes it top off early and doesn't make it any faster at all.

I know there's a ton of vehicles that break this artificial speed limit on even throttle, and not just little repetative bursts. They function as normally as any vehicle, only they go a good bit faster.

I'm not sure if I've just missed something somewhere, but I know that I have been able to make my ships faster than 40m/s, but I'm leery of the fact that the wiki doesn't recommend using the command that I've coded into my scripts. The only down-side I've found so far is that my larger ships need higher #'s due to their mass in order for them to achieve the same velocity as my smaller shuttles.

Anyone know if this is another 'opinion', in that the average coder will not be able to control this responsively, but a good coder should be fine with it?

Hi there and thanks for the reply (and to all the others too).

I looked in search for Sector001 and nothing came up, had a gander in the profile and could only find some piloted shuttles which I am sure wasnt what you meant!

I have now come up hard against friction, <gags on chewed fingernails> and whilst I reckon that a "hovering plane" might do the trick I wanted to follow a rail route.

Waymarks seem ok - no problem with that but is there a way to "silicon coat" a rail to avoid the obvious friction issues? I am sure somebody has done a monorail, suspended car script - seen plenty of discussion about it but its all a bit black arty

It seems like when i apply a hover global tag to a vehicle it only applies to one end (or part of) the containing prim as i cant get the damn prim to stay "stuck" at a constant global level.. weird.

Cheers

Erwin

Please excuse the ramblings...

I have created a tubular rail and hung a loop from it, then attached a prim to the top with the plane vehicle script in side..

Whats odd is that the prim (with stacks of damping on) still dips at the"front" or "back" at times. I also get a side to side banging effect as the tube rubs the rail....

Is there a way to damp vertical movement completely: ie: none whatsoever?

I am also trying to damp side to side swaying - but figure that is a lesser evil than a vertically challenged cable car!

I think i have turned of banking and set the vertical stuff to full on.

This is weird, cars and planes look easy compared to this (simple I thought) concept.

Erwin

That's odd, Sector001 should've found it...but I'll add it to my picks later if that will help. Probably should do that anyway, but I'm lazy

You should be able to make a monorail as you describe...and there's a lot of ways to do it. Just decided which way will cause you to pull the least amount of hair out is the key now

The easiest solution I can make for this is to look at the warpPos code, remove the llSetPrimitiveParams part that actually causes it to warp, and use the list it makes for the MoveTo part of your script. That way you can just pick the 'straight-line' points and it will figure all that out for you.

To limit vertical movement all you should need to do is not have any variance in the Z coordinate of your target vectors. You should also turn off the ability for the object to rotate on any axis but Z.

Hi there, thanks for that.

As a prelude to NOT tearing hair out, what's the considered opinion here?

Is a vehicle (sled) the way to go , or is it better to have a physical prim using the moveto stuff?

Or a combination?

I have spent 3 days experimenting and now know a lot more than when I started, it has been suggested (by a non SL user) that 1 linear engine and 2 angular engines would make life easier for a monorail (assuming that it required that amount of complexity which i dont think it does) but in any case...

Can you have more than one motor in a linked set? or are you stuck with one.. I was thinking of a guide rail/bar that was repulsed by angular motors whilst driving along it with the linear one - turn off all angular and linear deflection and an amount of hover to make it float....!

I know its cloud cuckoo land and I should look at using llmovetopos but i really had hoped that a guide rail system would be possible.

So... vehicle or not that the question...

Erwin

Well, you could do it as a normal vehicle, but I would personally find the MoveTo easier to do.

If you think you can script the vehicle easier, I'd say go for it, but even as a vehicle maker/scripter, I found it easier to do the moveto myself. I even made a 'flight recorder' script so I could fly a path and have it record the locations at a set interval so I could just plug it right into the moveto script.

Also from what you described with the guided rail...SL can do funny things, especially when physics are involved and I can see it easily getting bumped off the track and that could cause problems, or it could just get stuck completely. You could code around that and all, but that's why I found it easier to just use moveto.

After not-inconsiderable work and much tearing of hair, I finally resolved the issue back to using llMoveToPos with a set height, making my rail phantom and lumping it.

I also found a couple threads on the forum which were of great help, so thats cool!

However I now want to tidy up the code a bit and try to make my cornering a bit more precise.

Essentially I am moving my vehicle only through 90 deg angles on a fixed 10 meter diameter circle, (radius 5m) and found the following code snippet on the forum which I simply can not get to work - I think its a case of my not understanding trigonemtry and radians in this case.

Perhaps someone could take a look and tell me if I have this completely wrong!

    llMoveToTarget(center + <radius * llSin(theStart),radius * llCos(theStart),1>,0.3); 
    theStart += PI / numIter; 
    llLookAt(center + <radius * llSin(theStart),radius * llCos(theStart),1>,0.3,0.3);

Where theStart is (I think radians) and theEnd is also radians....

I want to move an object around the circumference of a circle - is this the right way or is there a better way?

My best regards

Erwin

Just found this thread:

/54/f3/119369/1.html

Which seemed like a good idea except theres no way to control the start and end points... having said that it works a treat with a directional llLookTo added in for good measure.

float d=4.5; //radius
vector center = <33.75821, 138.80423, 27.00000>;
float x=0;
vector thrust;
integer n;


// do corner is supposed to fire the object through 90 degrees
docornerr()
{
integer steps= 10;
integer i;
for (i = 1; i <= steps; i++)
{
x-=0.5;
thrust=<llCos(x)*d,llSin(x)*d,0>;
llMoveToTarget(center+thrust,0.2);
llLookAt(center+thrust,0.3,0.2);
llSleep(0.2);
}

}

default
{
state_entry()
{
pos=llGetPos();
llSetStatus(STATUS_PHANTOM , TRUE);
llSetStatus(STATUS_PHYSICS , TRUE);

}

touch_start(integer num)
{
    docornerr();
}
}

Thed central position is set with the llGetPos call and then the object moves to the correct place - however for a train i would need to be in the right place to start with - so i guess doing a quick x,y calc in the vector of the last end point would help there....

Any ideas?

Erwin

mission implausible?

Check out the "Autobahn" project in the LSL Wiki.

It's a open protocol for automatic cars, trains, and other moving items.

It's main feature is that it uses llKey2Name to find the next target.

I've kinda gotten slowed down by other projects, but the protocol and the road script is working. The road prims set the script pin key so that they can remove themselves after being configured. This keeps it from adding more script load.

I have a crude vehicle that moves, but does not rotate properly yet.

Edit: You have to go to the old complete Wiki

It's not on this one for some reason either.
http://www.lslwiki.org/index.php/Main_Page

Edit again:
It's gone from all the Wiki's for some reason.
I'll have to re-uploadd it to the new Wiki.

hi there thanks for the reply.

its now got to the point where my head bashing has got so painful i am prepared to pay anyone real dollars to give me a working example of how to send an object around the perimeter portion of a known radius circle.

6 days spent trying to understand trig is not good.. its obviously not going in!

So - heres the chance for someone to earn some bucks to provide me with a workable corner movement function that takes a current position and applies perhaps 10 steps to roate a prim thru 90 degrees (left or right) and forward as well (as if it was turning through a corner).

Movement ahead, stopping is all sorted, i just need to show someone what the issue is and get a code snippet that works.

I think on of the issues is that the script i have tweaked off this forum relies on using the z axis as forwards which (may) be an issue?

Erwin

The key to a smooth curve is to treat the curve as a quadric bezier curve. A quadric bezier curve is parabolic in nature and thus is not exactly circular, but it does have the same acceleration for the entire curve and therefore can be made to move smoothly.

I won't go into any more detail since I am upset at the Wiki issue and can't really afford to spend the time right now. I hate to sound grumbly, but I am behind in fixing some bugs in the motion code for the laser cutting company I work for.

Edit: Here is some info.

1. Compute the center Cubic bezier point by projecting the angles from the start and the end points. In other words the center point is at where you would go if you ignored the curve and drove straight ahead from either direction.

http://en.wikipedia.org/wiki/Bezier_curve

Edit again:
I'll put the documentation in note cards and put up a free box with the scripts when I get some time.

Thank you.

I hope that you get some free time soon, its been so long since i saw any that I forgot it existed too

Erwin

I put out a free box at Charissa (211, 228, 117)

This version follows the road, but the rotation osolates and eventualy starts to spinn.

I hate to seem ungrateful, Grumble, but the box at that location in Charissa can't be copied. (Apparently 'cuz the scripts inside are NC/NM/NT)

ooops.

Edit:

I set it to sell for $0L