LSL idea: llSmoothTranslate() and llSmoothTranslateLocal()

To improve non-physical animation, I'ld like to suggest:

llSmoothTranslate(vector position, rotation rot, float tau);
and
llSmoothTranslateLocal(vector position, rotation rot, float tau);

Which would basically work like a combination of llSetPos and llSetRot/llSetLocalRot - in fact, the physics engine would do exactly as the current versions do and move the prim to the new location immediately and there would be the same script sleep as related functions, but the client would be signaled to smoothly translate the prim there over tau seconds. I figure there would probably have to be some constraint on tau, to avoid being able to use this to create completely undetectable prims for others to run into.

This would be fantastic for smoothly opening doors, landing gear, primitar animations, you name it.

OK, you smart folk - is good or no?

Sure. That could be done in the client side of things as far as I know. Long as it doesn't need to parse collisions between Point A and Point B, what's not to like?

Agreed, we already have llTargetOmega() but it's next to useless for anything but spinny things.

For collisions, I believe when using things like llSetRot() collisions aren't handled during the move anyway, aside from the fact that it's almost impossible to hit it while it's moving, it also doesn't handle the event until it's done executing whatever event is already being handled. Should just be the same here.
I know I for one wouldn't want it sending collision requests in the middle of the move anyway for any application I'd use it for. For example, if someone walked into a door to open it via a collision, if they kept colliding with it while it was opening it would just try to close again and end up at all kinds of random positions.

pop over to this thread for a similar discussion.

(except for Haravikk - he's already there )

So basically what you are saying is that you want to have control over the builtin interpolation. I agree with that, I've suggested something like that a thousand times already, but I dont think it should be implemented in the way you suggest it.
I believe the best way to implement this would be to add a new parameter to llSetPrimitiveParams, that would specify the shape of the interpolation function.
Right now the builtin dampening is logarithmic, growing really fast at first but slowing down as it arrives to its destination...
What we all want is the ability to use a LINEAR interpolation function.
Why stop there though? Why not let us have any other type of function?
Or even just a few more. We could poke the lindens to add more constants and function shapes as we come up with ways to use them.

I like it, I'm tired of doing this with texture animations it always gets messy, at least the way I do it by making the moving prim go invisible before moving it and then play an animation of the moving prim on another prim.

Sounds awesome to me, tho I'm not one of the "smart" folks... I would like to see it as a flag in llSetPrimitiveParams also (but only because I usually am both rotating and moving at once, and very seldom use the individual commands anymore)