http://fteqw.svn.sourceforge.net/viewvc ... 4player.qcthe predraw function of your player or whatever entity should run prediction then call Q4PM_Draw, and you'll get a q4 player model running around.
note that this code is incomplete and doesn't deal with weapon animations or anything. I got bored. Sue me.
Been about 11 months since I even looked at that code, but it served its purpose which was to make sure that this stuff was actually possible.
Point is that the engine is capable (DP supposedly has the same skel_* builtins as FTE). It just needs (CS)QC to drive it.
Note that the engine does not provide ragdoll support. While it is possible for that to be written in QC (with ode physics or whatever), it would take a ton of work.
The 5th and 6th args of skel_build are the 'first' and 'last' bones to build/copy into the skeletal object. You can use those to provide upper/lower distinctions so that shooting is separate from running (last==-1 means 'all following bones').
Of course, this is generally not relevent for weapon models as you can more easily get away with not needing to blend anything other than between the poses within a framegroup, which is all automagicly done by the engine anyway, but could be useful with something like a spinning barrel that you want to spin down smoothly or whatever, like the q3 machinegun.
The thing to remember is that the engine renders a mesh. And cares only about that mesh. It gets the positions of the bones from somewhere. It internally builds those bones on demand to match the interpolation + frames of each model. Skeletal objects gives you direct control over the exact bone poses, overriding the engine's normal building stuff.
You could use sagdoll, ode, or twig, and implement ragdoll without depending upon any canned animation files. If you do actually read the code I linked to, you'll notice that the animation data used isn't even in the same model file as the mesh.
I don't really make models. I'm not convinced they'd be anything but terrible if I did.
That said, if you want a running animation to really work, you should bear in mind that the csqc will want to blend the animations together, so all directions should have the same total duration (even if different framerates), and cover the same distance.
Missing the strafe animations and depending upon torso twisting will probably look bad.
Note that csqc has a frame1time field which says the absolute time into the current framegroup. You can increase that field not relative to actual time, but instead relative to actual distance traveled (moveddistance/distanceanimationisepectedtotravelpersecond. You can see an example of this in my code. Note the dotproduct between movement and v_right to figure out how much left/right they moved). This will keep the feet synced with the ground.
For shooting, you can either just directly use the frame(group) numbers from ssqc and simply interpolate based on those, or try to animate inteligently based on whenever a shot goes off and whether they're still holding the fire button. I dunno, animate it how you want, I'm not gonna write your mod for you.
Sat May 12, 2012 1:44 pm 
I just (as everyone I suppose) like to use tools that I understand! 