New combat animations

[Noisycricket]

I made some new combat animations that look more realistic. However, i sort of jumped into it one afternoon while browsing through some files and i forgot to account for the ...god damned... torch, which i just realised as I was copying them into the Noisycricket folder in models_src. Theres a few avenues I can travel. I can go back and simply apply some touch up to the existing animations to simply make more than the torso move. Or, If there is a willing programmer who can make the current animations play when the A.I. are carrying a torch, we can use the more realistic animations, in which case, i'd still touch up the current animations (so the torso does more than simply pan right/left in the parry's for example). Or i can do nothing. I've uploaded the new animations in .md5anim format to my folder in model_src and i've tested them out a little bit as well. However if we use them, I'll put them up for public download, so someone can really test them.

[Springheel]

Do the new combat animations follow the old ones pretty closely? I'd be happy to see better-looking animations, but Ishtvan spent a great deal of time getting things lined up and timed properly for the combat code.

 

Don't worry about the torch, it's trivial to keep playing the same animations for torch-carriers.

[Noisycricket]

Do the new combat animations follow the old ones pretty closely?

 

Yup they do. Ishtvan explained the combat system to me at least somewhat.

 

FTR: If we're ever motivated to re-arrange the combat animations so a guard's parry animation doesn't hold to the left, but rather is timed so it plays when the player's sword and the guard's sword cross at the same time. I can come up with some much more elaborate animations, which i already did somewhat since i forgot about the fact that A.I. "pause" their parry/attack animations. For example, i originally made a parry_thrust where the A.I. sword continued in a 360 degree movement after deflecting the sword, which looked pretty cool. Also, if the whole body can come into play (i.e., its checked as to whether the A.I. are running or not) I can do full body animations. But its only combat, something i personally rarely do.

[Ishtvan]

I'm having some SVN problems but maybe I can update just the animations folder and take a look. We talked about it over PMs and it sounds like the sword is staying in the same positions over the period of time that counts. I did have some concerns about animating the head/waist. When Domarius tried this, it overrode the code that made them look at you, so they stared off into space, and it also overrode the code that made them tilt their body up/down at you, so they could no longer hit you when crouching because their spine was stuck straight upright.

 

I don't really have time now to do a full re-tweaking. So if an animation doesn't work gameplay-wise, we may have to revert it back for now.

 

@Noisycricket: The problem with pre-calculating when the sword would hit the AI's sword is that it assumes everything is pre-determined, but it's not. It's physics based, so the AI could be running at the player who is running backwards while jumping on to a moving train. Then there's the chance that another AI could jump in front of the swing and get hit by it instead. The system doesn't use pre-canned animations that play based on a calculation the moment the swing starts. Whether or not the block succeeds is determined at the instant when the player's sword hits the AI's block, but not before.

 

I realize this looks kind of bad for the thrust parry (the others all actually make sense that they would close out a line of attack as long as they're held there). But we can't realistically model all the different ways a thrust could be blocked (is the thrust coming in to the left of their sword, to the right, up, down?). So we're kind of stuck with this fake-looking thrust parry that just puts the sword out front and leaves it there.

 

EDIT: I think what you're describing is called a "circular parry," which works in some cases, but not in others. For example, the player can hold their thrust back for as long as they want, the AI circular parry would have already finished. That's why we went with a "parry #4" which looks okay when held in place for a while, then returns to the starting position.

[Noisycricket]

I animated the head, forgetting what you said about that. However testing it in the game, it seems like the new animation has the same behavior. I'll have to do more testing some other time though, im not sure when i'll be able to get to it. The thrust_parry is the wrong one, i'll be uploading the right one is a sec.

 

I'll also put in the offer to do separate animations for the hammer wielders so they can swing with two hands, and separate ones for the torch carriers, unless they can be programmed to drop their torch (and maybe pick it up again? ).

 

I noticed a couple bugs i can report if not already known as well.

 

1# When in the test/combat map, the A.I. stopped moving when they were JUST out of range of attack and just close enough for them to pull out their sword. i was up on the elevated area where the two ai are when it happened. I reproduced it several times to test the parry animations.

 

2#The ai would sometimes do the equip_sword animation, but not pull out the sword. This happened a few times. Then one time, the a.i. ran at me, pushing into me. I couldn't run away until we bumped into something. Nor would they attach.

[Springheel]

I'll also put in the offer to do separate animations for the hammer wielders so they can swing with two hands

 

That would be nice to see.

 

Maybe it would be a good idea to deal with the combat animations for the next update, as we're a week away from a lockdown and it sounds like they would need to be tested pretty extensively.

[Noisycricket]

I'd definitely agree with that.

[Arcturus]

What about this walk animation? http://forums.thedarkmod.com/topic/11822-alternate-walk-animation/

[Springheel]

The new walk should be active. Right now both are used and AI choose between them randomly. At some point if the old one starts to look bad by comparison, we can remove it.

[Arcturus]

Both walk1 and walk2 in tdm_ai_guard_proguard_devel.def were pointing to the old walk animation. I corrected it:

 

    anim walk1                   models/md5/chars/guards/proguard/walk.md5anim
   {
       frame 7     footstep
       frame 25    footstep
   }

   anim walk2                   models/md5/chars/guards/proguard/walk1.md5anim
   {
       frame 3     footstep
       frame 20    footstep
   }

[Springheel]

That would help, wouldn't it. Thanks.