Movement animators vs. main loop "evolve"

[fargoth]

I've walked through the irrlicht movement tutorial.

It seems there are two ways to move a scene node - one is through an animator, and the other is setting position and rotation in the game loop.
I think using animators is the more elegant way, but I can't find an example of how to use it the way I want to...

I want to set an animation to make the player's avatar turn (90, -90 or 180 degrees) - and than after he finished turning to the right orientation - start the 'fly straight' animator, while keeping collisions in check - and having the 'fly straight' animation stop when the user asks for a new direction (switch back to the rotation animation)..
The obvious solution is to check the rotation and position in the game loop and in a setNewDirection function in the player class - but that would be as ugly as using setPosition ans setRotation manually - so I guess there's a better way...

So, how can I tell when to stop one animator, and start the other one?

Should I create a custom animations for 90 and 180 rotations - and use an animation finished callback?

[CuteAlien]

Combining animators is tricky. Especially when they all want to set the position as they can then conflict with each other. The only functions you get are ISceneNodeAnimator::hasFinished and the callback for the collision animator. There are no events for them.
What to do with that is really up to the programmer. I only used the animators for simple stuff myself (like I need something rotating somewhere) and never tried combining them into some more complicated systems.

For player controls I tend to write my own stuff.

[fargoth]

Thanks for the reply, I thought I was missing something...
So I guess I'll just write the rotation bit myself, so that I'd know exactly when to stop and start walking straight.

Do you have any advice regarding player controls?
I've currently inherited IEventReciever, and made my event receiver acquainted with my player class (keeping a reference to it) - so that whenever a new direction is pressed I call the player's public function changeDirection which determines what it does if you call it's evolve(deltaT) function (which you do in the main game loop).

Does this scheme sound plausible? I've noticed the example uses a different approach - using an array of booleans to note which key is down and set the motion in the main loop... which I find dirty and unmaintainable if there are many actors in the scene.

[CuteAlien]

Do what you think is best. My own controls tend to be complicated as I usually separate node-control and input rather strongly and have some steps in between. To give you a rough idea you can take a quick look at controller, input and device classes here: https://bitbucket.org/mzeilfelder/trunk ... at=default
But more complicated than usually necessary (it was originally very flexible so users could fine-tune simulation of joystick axes by keyboard etc... something I gave up on as it was too complicated for players).