by Spike » Fri Apr 13, 2012 2:20 pm
I assume you mean purely in regard to animations, rather than an actual bug?
if you're making your own gamecode+models+etc, you'd use skeletal models.
You'd then have one animation (read: framegroup) for running forwards, and one for running sideways. Both animations must have the same duration.
you'd then figure out which direction the player is moving in, and then blend them according to the direction the player is facing or so (if running at 45 degrees, 50 50). The time into the animations to use is based upon the distance traveled, and both use the same animation time - this keeps the legs in sync even if the player suddenly changes from 100% forwards to 100% right (in reality, the direction traveled will follow a curve, as quake's direction changes are not instantaneous, thus the animations do need to have similar timing).
You'll need to blend towards an idle animation so the legs don't freeze completely in some weird frame if the player is standing still.
Read DP's documentation on the FTE_CSQC_SKELETONOBJECTS extension for the engine calls to make. Note that this extension allows full separation between upper and lower body parts, and you can have a separate head/mouth for 'free'... thus no more running-on-the-spot when shooting, etc.
Yes, this stuff does require csqc. DP does support server side skeletal objects too, but bandwidth, interpolation, etc will make them unusable for actual animations.
note that v_right*normalize(self.velocity) will be 1 if self is moving to the right, -1 if its moving to the left, and 0 if its not moving sideways (essentually, right*velocity rotates velocity into modelspace). do the same with v_forward and use pythagoras to work out which forward/right/left/back animations to play.
Its jumping that's the annoying part.
.