Walking

#1 I got a feeling this will be down to us.. I have now got all the anims
I need (walking / running with 1 handed & 2 handed weapons, in casual and
alert modes, strafing with 1 & 2 handed weapons, reloading, swimming, climbing etc)
Just got to work out how to implement them all.

Slightly OT, but..
I was wondering, is it possible to combine 2 anims, for example the legs
from one sequence and the rest from another ?.. that could be quite useful,
and save on the number of different animation sequences.

#2 Normally this is done with a "blend" animation. So yes, this is possible. However, I've had some trouble with "PlayThread", but I'm not sure if it's just me or not.

#3 PlayThread does not support a transition,so using it for the player/aiplayer is not desirable.

#4 After experimenting, and reading the docs, it appears that the method that you use depends on what you want to do.

If you want to do a whole body animation, and the character is idle, and the animation is NOT a blend animation, you would call SetActionThread. Example: Player.SetActionThread("CelWave");

If the character is moving, or has the possiblity of moving, then you need to use PlayThread, and you need to use a Blend animation. For example: Player.PlayThread(1,"dance");

Any other use causes the animation to get screwed up, or to not happen (and still screw up later on).

#5 Adding different walk and run animations was among the first source-code modifications I did to TGE when I started working with it years ago. It's not very hard to do: add a way to differentiate between walking and running (a networked flag, current speed, whatever), add the "walk" animation to the list of table action animation and modify Player::pickActionAnimation() so it uses walk instead of run based on the condition you specified.

#6 It is unlikely that the Player class will receive any new features prior to T3D release. But Manoel has described exactly how I would go about this.

#7 Every Torque based game that I've tried (and I admit, that's not a huge list) that has walking, the animations almost never line up with the rate of movement when walking, but are still usually fine when running. Is this a code issue or an art issue?

#8 @Jason: pretty much an art issue. Lots of people forget to setup ground transform for their animations, which is required for automatically adjusting the animation speed to the movement speed.

#9 @Manoel - Yeah, I've done it several times before also, it's not hard, but to be honest I get tired of doing the same modifications over and over again. If it's an "animation" issue (don't have a good animation), I would be happy to contribute a walking animation.

Or - better yet, why not have the animation selection scripted instead of hardcoded in C++, that way we don't have to deal with any of this in the engine code? Hmmm - I think I'll do that. :)

#10 I would like to have a look at it, when you are done, if it's not too much to ask.

#11 Having any kind of callback that fires on every tick for every player is something one should avoid, since script execution is pretty expensive.

However, it always depends on the project's requirements. I'm actually using way more scripting that I should be right now, for actually controlling players.

#12 You could just edit the running animation, and slow down the playback. Then you would have to go into the file eand slow down the movement speed.

But having a switch or key to set it to walk (Like holding shift or something) would be nice.

#13 @Matt - You could, but then he would be "slow running", not walking. I actually like having three states - walking, jogging, and running, all of which look completely different. Then chose which one to play based upon the speed of the player movement. (Which I adjust with keyboard modifiers when using the keyboard to move - or when using a gamepad the speed is relational dependent upon the stick position)

#14 This is the kind of stuff that is supposed to be done as source code modification. A "generic" solution trying to cover all bases would be inefficient and it would never please everyone: you just gave an example of having 3 different forward moving states, which would require changes anyway if the base engine offered support for two.

However, I think we need a new Player class that is more barebones and structured in a way that changing the way it moves, collides and animates in the source code so it suits each particular game is straightforward.

...or the component system ;)