Keeping a physical object from rotating?

I'm building an elevator, and I need to keep it from rotating. Putting it in a fairly tight shaft keeps it from rotating... much... but it still visibly rotates.

I call llSetStatus(STATUS_ROTATE_X|STATUS_ROTATE_Y|STATUS _ROTATE_Z, FALSE) right after llSetStatus(STATUS_PHYSICS, TRUE);

I get into the elevator in the shaft.

It gets stuck on the walls.

I try it with the elevator outside the shaft.

It starts rotating anyway.

What am I missing?

Why is it rotating in the first place? You mean, it wobbles when people get onto it?

ummmm, Havok2?

I don't know exactly what you're doing of course, but normally things like elevators don't need physics at all. In fact if it's in a shaft the physical item would be continually colliding with the walls of the shaft which can potentially cause problems for the sim. For an elevator you're normally better off using a non-physyical approach with llSetPos().

If you want to move an object more than 10m simply repeatedly call llSetPos() until the target position is reached.

eg...

vector g_target_pos = < simx, simy, anyZlessthan768 >

while ( llGetPos() != g_target_pos )
{
llSetPos( g_target_pos );
}

This example is full speed, I'm sure you can work out ways to slow it down yourself

If the z-axis of your elevator is straight up or down then maybe you could use llLookAt.

Arcane suggestion time: make the elevator a vehicle and use VEHICLE_VERTICAL_ATTRACTION_* and VEHICLE_ANGULAR_FRICTION_TIMESCALE. Plus you could use VEHICLE_HOVER_HEIGHT to move between floors.

1. Yes, with people in it, it's unstable.

2. Non-physical elevators would be great if I wanted them to leave the passengers behind.

3. The problem is that the Z axis DOESN'T remain vertical.

4. I thought of making it a vehicle, but I've had SO much trouble with the vehicle code while trying to make realistic innertubes that I'm really leary of taking that on.

I was hoping there was an llRotateToTarget like llMoveToTarget that would do a damped rotation towards any angle.

Take some time to think out of the box...

Use an animation or a pose to hold the AVs in the position you want and have the agents "sit" in the elevator. Poses can make them appear to be standing, the sit target will keep them in the box. Really you don't need physics for an elevator.

There is llLookAt and llRotLookAt which allow damped rotations.

And one way to carry passengers in a non-physical elevator would be to put down benches and whisper "Please take a seat, this elevator will be leaving soon".

OK, let's pretend for a moment that I'm capable of thinking out of the box by myself. I have a reputation for thinking so far out of the box that the box needs therapy. I know a dozen ways to get around without using a physical elevator. I'm already using sit teleporters, non-physical vehicle teleporters (which is what you're talking about) and a 500 meter gravity lift. I happen to want to use a physical elevator this time, so I'm building a physical elevator.

I'm going to need to solve this problem anyway for some physics-scripted-only vehicles I'm working on, and I need something that behaves like a physical elevator, so the time is right...

End of the "why don't you use a non-physical/teleport/gravity elevator" thread, OK?

pathetic, from all your comments it's pretty obvious to me you don't know what your doing.
if you don't need help that's fine with me, you're now ignored.

Ah-hah. I saw llRotLookAt and that doesn't solve the problem I'm running into, but I didn't notice that llLookAt appears to be exactly what I need... the name is a little confusing since most people don't look along their Z axis.

Thanks.

Is it just me, or are the axes in SL picked just completely randomly from the point of view of cartesian geometry?

Well, hell, of course not. I mean, if I knew the answer already, I wouldn't need to ask any questions.

I don't know. I gave up on trying to do rotation math in my head a long time ago. These days I take a trial and error approach - write the code that seems right to me, try it out, and then fix the rotations, because I invariably get it wrong.

No need to get snarky, Lauko. Anyway, Lex Neva tried this approach for a sort of "Jetsons-style tube" lift system (being that the elevator itself was an invisible platform).

That said, the only real option sort of constantly monitoring rotation and correcting, I'd say, is to just use a round shaft and round elevator. then it doesn't matter.

Now I think about it more, a vehicle elevator wouldn't be that hard. Really. All you'd need would be controls that changed the hover height, and a really low angular friction timescale to make sure it didn't spin much. If I wasn't working on something else right now I'd give it a shot.

I don't have a problem with the elevator rotating around the Z axis... an off-center avatar doesn't really cause any significant torsional force around that axis, and a final llSetRot() after I turn physics off at the destination solves any that does occur. The problem is that the elevator tries to tip over on its side because of the off-center mass of the avatar: it's rotating around the X and Y axes, not Z.

I'd go that route, but I'm trying to figure out how to solve another problem that doesn't seem to work well with vehicles either. I want to build a vehicle where the direction of motion and the facing are completely uncoupled. I can turn down the angular friction by increasing the timescale, but that just gives me a vehicle that moves in swoopy curves... not one that spins while moving in a straight line.

Unless you have an idea that can help there, I'll keep on experimenting with physics-only vehicles like the elevator.

Direction of motion needn't be connected with facing, as long as VEHICLE_LINEAR_DEFLECTION_* and VEHICLE_ANGULAR_DEFLECTION_* are set to values which disable them. I have a balloon that moves in all sorts of directions without changing facing. It certainly spins while moving in a straight line.

Oh, cool, I'll have a look at what I can do with that.

if you're using non vehicle motors you can either lock rotation on every axis, or if that is undesirable you can use whatever loop is moving your elevator to also monitor and adjust rotation of the elevator using llSetRot (which should work fine if used often enough on a physics object). Also when moving up and down you'll want to keep track of your x and y location and constantly readjust to your base x and y so that your elevator stays on course. Otherwise, tube or no, you will drift. For lighter elevators llMoveToTarget works fine. For more fancy, heavier ones, you will want to use the vehicle api simply because it can move prims that have no energy left.