The difference lies in how the player animates as he goes from a standing --> moving at top speed (and vice versa)
In 9-way it will look better because the blend between ACT_IDLE and any other sequence involves blending between two poses (one pose in which the player is standing still, and the 2nd pose in which the player is moving at full speed). The movement will look much better at intermdiate speeds because the foot placement gets blended. What this means, when a player goes from standing to fill tilt running, as he acelerates, it will look like he's taking smaller steps until he reaches full speed (at which point, he'll be taking larger steps)
Just open a 9-way model (CS :Source, DOD:Source, L4D) and look at how the player moves as you adjust the "move_x" "move_y" parameters.
At values of 0.5, it will look like the player is taking smaller steps.
With 8-way animation, at intermediate speeds, it just adjust the playbackrate. So when a player goes from standstill --> full tilt running, it doesnt look as natural because the foot placement is NOT being blended.
It's a very subtle difference and another reason why 9-way is better than 8-way.
On Aug 7, 2011, minh...@telus.net wrote:
From an end user standpoint, 9-way and 8-way animations will end up looking the same. The only difference is in how you ( the coder ) has to use them, and also in how the models are compiled.
If the models you are using for your mod are using "move_yaw" parameter, then you HAVE to use the 8-way animation code.
If the models are using the move_x and move_y parameters then you HAVE to use the 9-way code.
Both 8-way and 9-way use the following pieces of information.
1) MovementYAW : The direction of the players movement (relative to where he's aiming). This will range from 0 --> 360. 0 means he's going forward, 180 means he's walking backwards, 90 is strafing to the right, 270 to the left
2) MovementSpeed : The speed in which he's moving. This will vary from 0 --> maxspeed (depending on how fast u defined this in your mod)
3) IntendedSpeed of current animation: This "intended speed value" is something the animator should have embedded in the model. If you open up HLMV and select a particular animation (such as run), and then set the playbackrate to 1.0, you should see the top speed of the animation (usually it's around 250 --> 300). If you switch to another animation like walk, the top speed should be around 160. These values will vary depending on how the animator made his animations.
The difference in how these two pieces of information are used is as follows:
For 8-way animation: The code takes MovementYAW and sets the "move_yaw" parameter based on this. I believe it's basically a 1 --> 1 conversion as the "move_yaw" pose param ranges from 0 --> 360 also. It then takes MovementSpeed and sets Playbackrate() function to specify how fast to play the animation. This will vary between 0 --> 1. The playbackrate value is detemined by comparing the player's movement speed with the current animation's intended speed value. If the player's movement speed is ZERO, then the code will blend to the ACT_IDLE sequence.
For 9-way animation: The code takes MovementYAW and MovementSpeed and IntendedSpeed in conjunction to determine which values to set "move_x" and "move_y" to. It uses some tricky math (involving cosine), which you can see if you study the function ComputePoseParam_MoveYaw(). To better understand how move_x, move_y works. Let's consider a few situations:
Player running forward at top speed: move_x = 1.0, move_y = 0.0
Player running forward at half speed: move_x = 0.5, move_y = 0.0
Player running to the right at top speed: move_x = 0.0, move_y = 1.0
Player running to the left at top speed: move_x = 0.0, move_y = -1.0
Player standing still : move_X = 0.0, move_y = 0.0
So that pretty much describes the difference between how 8-way, 9-way work. I prefer using 9-way for the following reasons:
- you don't have to blend in ACT_IDLE when the player stands still
- you don't have to adjust Playbackrate().
From and end user standpoint, they both look the same though. Your decision to use either 9-way or 8-way rests ENTIRELY on how the model was compiled. If you're using the standard alien swarm models, then ur stuck with 8-way. I'm pretty sure all Source games after DOD:Source use the 9-way system. 8-way is so 2004...
So to answer your original question:
How can I integrate the hl2mp aiming into the ASW player animstates without screwing up leg anims or anything ?
You'd have to recompile the ASW models to use "move_yaw" paremeter (which would require the original .smds for the player models). You wouldn't actually have to modify any of the animations, you just need to modify the .qc file so the sequences are compiled differently.
However, switching between 9-way and 8-way will not solve your problem. From what I understand, you want to be able to specify which direction the marine's gun is pointing ? For that you'd need to make new 9-way aim animations and create a "body_yaw" pose parameter.
On Aug 7, 2011, Psy_Commando <psycomma...@gmail.com> wrote:
Ok, but aren't there advantages with the 9way anims ?
On Sun, Aug 7, 2011 at 2:14 AM, Tony "omega" Sergi <omegal...@gmail.com> wrote:
don't use the asw animstates. just replace it entirely.
unless you're planning on keeping "marines" as separate entities.
On Sun, Aug 7, 2011 at 3:06 PM, Psy_Commando <psycomma...@gmail.com> wrote:_______________________________________________Yet another question. This time about animstates. I'm trying to re-integrate parts of the hl2mp animstates into alien swarm. The reason I'm doing this is because, in alien swarm, there is no aiming anims. The marine's hands are IK-ed onto the gun model.... And also marines don't turn their heads or torso.
The pose parameters for the torso and head, aren't even initialised by default, so any other char models than the marine chars will look all twisted on itself and weird, but that's not my question.
ASW uses 9-way leg anims and it would seem the hl2mp code doesn't. As far as I understand it, 9Way anims use a x and y move parameter for leg pos, while the hl2mp has a move_yaw parameter instead. How can I integrate the hl2mp aiming into the ASW player animstates without screwing up leg anims or anything ?
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
-Tony
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
