Making an automated monorail?

This is a question as to which function to use, llApplyImpulse or llSetForce.

I know that llApplyImpulse is not a constant force, and that llSetForce is. I've never used either, however, so am unsure which would be easier to stop in a smooth motion. If I set a llApplyImpulse, would it slow and stop of it's own accord?

If I used llSetForce of say 3, and made it move forward at that speed, and then later added llSetForce of -1, and then -2, and then -3, would this make it move at one speed and then slow to a stop, or would it make it move at one speed, and then suddenly backwards, and then backwards faster, etc.

Which one is more easily controlled, and which one would be easier to make slow and stop, instead of a sudden stop?

ETA:: Also, using either of those, would a physical object be able to folow a non-physical rail without breaking off? (Lets say a torus following around a second, larger torus)

I'll leave the rail issues to someone who's played with it more than I have.

If you give an object an impulse, it will not slow down unless it is in contact with the ground, where there is pseudo-friction. This MIGHT happen when in contact with large objects (floor, road, etc.) as well, but you'll have to experiment; this might've changed with Havok 4 anyway. Trying to stop something with impulses is going to be jerky unless you are careful to do it in very small, frequent bursts.

llSetForce() will apply (add) a constant acceleration or deceleration (acceleration opposed to current velocity), which is probably more what you want for slowing down, but you'll have to be careful there to adjust the force (including turning it off) as the velocity decreases or changes direction for any reason.

You might also experiment with llMoveToTarget(), which applies a force that is calculated based on the object's displacement from a target point (and hopefully for your application also based on the object's velocity relative to the point, which I suspect to be the case). Picking a point out in front of the object where you want it to stop, and playing with the damping coefficient might give you what you want. See http://www.lslwiki.net/lslwiki/wakka.php?wakka=llMoveToTarget

Thanks for the lovely explanations!

I don't think llMoveToTarget will work for this particular endeavor, which is why I'm trying for the impulse/force ones. What I'm attempting is a monorail that works anywhere, essentially. It will have a non-physical rail, and attempt to use some sort of force to push it from behind, then slow and stop at a certain point. I'm going to be testing this in a few minutes, if only very slightly, to see if the idea even works. (That is, if using local force would allow an object to be pushed along a rail, without being told where to go other than that.)

I'll post the results in a few, gonna try it with a box at first, essentially. I'll test both llApplyImpulse and llSetForce, to see the difference. First test will be just following the rails (Whether it's possible or not)

Good luck. I'm hopeful that Havok 4 will make this a lot more feasible that Havok 1 did, though I believe I've seen accounts of some success even there. I'll cross my fingers for you.

Basic tests completed..hrm... looking a little iffy.

The setup:

Rail:
====
.4 x10x10 torus

'Car'
====
Small torus attached to tapered, thin box. Made for low mass, quickly made.

Script
====

default
{
        state_entry()
        {
               llApplyImpulse(llGetMass()*<10,0,0>, TRUE);
        }
}

Replace llApplyImpulse with llSetForce to change to the other test.


Results:

llApplyImpulse showed no signs of movement whatsoever along the rail. Just hung limp, as if no force was applied at all (Maybe I did something wrong? I did attempt it with different values, on all axes)

llSetForce worked as hoped, but not as smooth. The 'car' moved along the rail torus, full circle, but stopped at the changes in angle along the torus. I'll be retesting with a thinner rail in a moment. Also tried at 100 units of force, the car ran off the track after spazzing out, and tried 20 units of force, it spazzed out but stayed on track longer than the 100 units/

Haven't tested llMoveToTarget at all, as this was not a setup I think it would work for.


EDITED TO ADD MORE INFO.

Test 2 : Oval Rail, llSetForce()

The track was changed to two half torii and towo straight cylinder sections. Same 'car' as before, same script.

Again, it followed the track, but was very jittery. I anticipate a second rail would ease some of the jitter, sing it's mostly swinging side to side from the curves. No idea if it would still work with a second rail however. Another test will follow.

Attempted an incline, and found that with only one directional force, of 10 units, it would not go up the 16* . Attempted to add a second force to Z, again 10 units, the 'car' just laid up against the rail. Removed the dangling segment to see if the ring would work on its own, and it leapt from the rail. Apparently not enough mass for that amount of force.

Solution so far:

llSetForce() works as the driving energy of the monorail, but needs specific accommodations in all likelihood. Curves it would seem should be very gradual, not at all sharp, or risk de-railing.

Next test :

Dual Rails:

Attempted a two rail variation on the same thing. The track was not a complete loop due to my laziness (Didn't wanna work out a whole circuit that was all equidistant for one single test.).

Car was two rings, side by side, attached to a bar holding two triangle shaped boxes.

Results:

The car failed miserably. While it was obvious that the force was working, I made one important oversight:

The local attribute tot he force wouldn't allow for any stopping, or it would aim the car directly up.

The extra width and friction (Or whatever) caused the car to tilt up immediately, and the force just kept it shoved against the rail.

Next tests:
Two rails, four guiderings (To prevent tilting

One rail, two in-line guiderings.

Next Test:

One rail, two in-line guiderings.

Used a second version of the one rail one ring as a base (Different sizes, and a different force of 15 units for that set because of it).

Lengthened and hollowed the box, moved guidering to the front end, and copied it to the back end for two rings. Still short to avoid a possibility of making curves impossible.

Force was required to be bumped up, I used a force of 20 units and got a comparable speed to the 15 unit one-ring version.

Results:

Surprisingly to me, this version was slightly more stable than the one ring version. The one-ring often angled above the rail while this one stayed well below level with it. Speed slowed more severely on the change in geometries however, caused by the dual rings.

Next test:
Two rails, four guiderings.

Test:
Two rails, Four guiderings

Setup:

Same car as the in-line guiderings, but with the rings set to the side, and copied to the other. Added another, small, central front prim 'engine' to ensure force was distributed fairly to the front.

Railing had to be set up special, as the rails needed to remain equidistant. Straight section, followed by a total of approx 45* curve, then a second straight section. Blocks on each end of the rails to stop the car.

Results:
Wonderful!

Initially I tested it without any curve to be sure it would work at all, and it didn't aim up or down any significant amount, but up slightly. (Promising!)

After I added the curve and ending section, and let it go, there was no major tilt in any direction, (Still slightly up, but not enough to hurt) though the car slowed down almost completely at the start of the impromptu curve (Sections of cylinders).

Best car version, however, this design requires a very specific track, which is not something I look forward to. The force did not need to be increased from the in-line test, and speed was lovely and consistent.

Next test will be later on today, maybe tomorrow, and will be stopping and starting the car. If I achieve a full circuit, with stopping and starting, I will expand to a prototype passenger car and full-size rails for testing.

If you wish to see any of my tests, let me know, this most recent, the one-ring, and the two-ring one rail are still in existance.

Have a picture of how these are set up? Or a SLURL to see it in...ummm...RL?

I can send you the three I have, each is a coalesced object. I took them off of the sim because it's a sim in development, and have been writing these on my laptop, so can't exactly just put pics up from my PC.

But if anyone wants the three I still have, just let me know in-world and I'll send em.

I've sent you a copy of each, Max. Max prims is the 4 ring version with.. lesse. I think 20 prims total.


(Wow..wasn't letting me reply for the last 15 minutes or so..said invalid thread XD)

Don't use either. There are considerations to do with energy which will stop the scripts moving at unpredictable times, particularly for loaded objects. This is practically impossible to debug as energy functions are not even understood by Lindens as far as I can see, let alone documented for resident use.

For physical movement the vehicle functions are the ones to use, which do not use energy - otherwise, use nonphysical movement with llSetPos on a timer.

Naysayer!

Thanks for that info ^_^

I'm still going to continue with my tests though, see if I can get something working at least generally consistently for about 2 days, just to see if I can. If that works out I may market a similar system, with warnings about what you've brought up ^_^

This project is me starting to learn physical scripting a little bit, and then at some point soon I'll start my first vehicle.

Well, just to save you some time: if you come across an issue where suddenly, an object stops moving, won't move unless reset or fiddled with, and there is no scripting problem, it is an energy issue. And there is no way around it apart from using a different mechanism.

I do say this as someone whose first serious scripts were for automated vehicles and still makes them professionally. Still, things may have changed a bit with Havok 4 I suppose.

I do thank you ^_^

I have heard of energy problems before, and am honestly hoping H4 fixes it at least a little.

One question I do have that you may be able to answer, if an object is made non-phys and then phys again, does it 'reset' the energy?

You know, I'm not sure. It's been so long since I used energy-related functions to move vehicles that I don't think I even tried it. I'd be interested to hear the results.

kk ^_^

Then when I do set up my big test situation for two days or so, I'll set one to stop using energy functions, and one to stop by turning the car non-physical, and restarting by making it physical again. That seems like it may be the best method anyhow, and if it makes it work better, then awesome!

http://www.youtube.com/watch?v=sdUIqvkzfdQ

This in on Havok 1, mind you.

On Havok 4 this does NOT work. Movement is jerky at most as any point where two parts of the "rail" connect, the "vehicle" will collide as if hitting a solid wall and slow down considerably.

And yes, this is a physical object driven by Force.

It occurs to me that llSetouyancy might help reduce the friction.

So far my attempt at a full size example hasn't made it around the first curve..what you described happens partway through. I'm gonna keep trying thou.

The material you choose is important as well. According to the wiki, glass has the least friction of all materials...

Hadn't thought about the friction of it! I used plastic for lower mass, maybe I should try glass and see if it helps at all.

Having played with this sort of thing myself I agree with Ordinal on the energy issue. Yes friction can be reduced with glass and yes buoyancy can help to smooth the ride out a little, there are still issues.

When buoyancy is set to low the monorail will use up even more energy and if it collides with anything such as an avatar you may find that it starts to spin around the guide track or exhibit other strange behavior.

In terms of what your trying to achieve anything with a mass of about 90 (ish) will probably begin to have performance issues. Try making as many of the objects as you can hollow to keep the weight down.

llOwnerSay((string)llGetMass());

will give you the mass.


You can get you object to shout out it's energy on a timer to find out how it's doing if you do insist on using forces and impulses instead of a vehicle. At least that way during testing you can see how it performs.

Thankfully energy is replenished every couple of seconds (1 second?) so as long as you don't drain it too much things should continue to work.

place this code segment in a timer to get the energy of your object

llOwnerSay((string)llGetEnergy());

See also, the Vomit Comet: http://www.youtube.com/watch?v=bMERVZ-7lyg

Lol...It's a migraine waiting to happen


I had completely forgotten about that vid...Nice post!