AI Entering Combat State

[Springheel]

The animation code ignores numbers in the name of animations. As far as the code is concerned, search1, search2, and search3 are all "search". If there is more than one the code chooses randomly from them every time the animation is called.

[grayman]

The animation code ignores numbers in the name of animations. As far as the code is concerned, search1, search2, and search3 are all "search". If there is more than one the code chooses randomly from them every time the animation is called.

 

I can't find where either of those things is done. The number must be stripped when the anim is parsed from the *.def file, because at lookup time, the code only looks for "search" and any replacement anims that might have overlaid that.

 

You've seen one of many search anims randomly selected in the game?

[Springheel]

Yes. You should be able to see it yourself if there is a lot of AI. Some will play the search that has the weapon held straight up in front of them, and some will play the search where it is more horizontal. The mage has a third version where he plays his "summon light" animation, so it's quite easy to see when that one gets called. We have multiple versions of walk_alert too, some AI will have their swords out straight and others up (hammers will occasionally be held down near the floor).

 

This worked in D3 as well, you can see many of their monsterdefs had multiple versions of the same animations.

 

Can't help with tracking down why it works; I just know it works.

[grayman]

I just found both ends.

 

Any anim name that ends with a number is a random anim. The number gets stripped, and the anim is added to the set of animations.

 

The key is that multiple animations can have the same name.

 

So when the script says to run the "search" animation, the code that inspects the animation list finds all the anims named "search" and if there are more than one, it picks one randomly.

 

Okay, mystery solved.

[SeriousToni]

Congratulations!

[grayman]

The initial test of an archer also having a dagger was successful.

 

In close combat, he uses the dagger.

 

In ranged combat, he uses the bow.

 

In order to test his ability to switch back and forth, I first have to solve the "I'm a truck and I'm going to run you over" problem. That's next.

[Springheel]

Cool!

[grayman]

Archer is now switching back and forth between melee and ranged attacks, depending on his distance from me.

 

The amount of time it takes to switch from his bow to his dagger is around 3s, so this might offer the player an unfair window to strike. I can't speed up the anims, and there's no delay between finishing the bow sheathing and beginning the dagger draw.

 

I'm open to suggestions on how to reduce the player's advantage.

 

It's not a problem going the other way: sheathing the dagger and drawing the bow. The player is too far away to strike, unless he's going to switch to his own bow, which will eat up the window time, so there's no advantage.

 

Edit: If I increase the melee range for the archer, then he'd switch to his dagger earlier, the player would be farther away, and that might close the window. That's one possibility.

[demagogue]

You could try to get the best of both ways... He doesn't draw until the player is relatively close (as it is now; or whatever feels best), but then the archer has a reaction to run from the player as he comes in & stays at a set distance in the time it takes to draw the dagger, then he runs back in or finally lets the player run in. So then he doesn't get dagger committed until the player is clearly going for melee range, but he backs up & gives himself space right on the edge in that time (... in most cases anyway. Sometimes there will be a wall in the way or something).

[Springheel]

One option is to define a new animation that is a duplicate of the bow sheath, and then use anim_rate to speed it up. The archer could use that one when switching to a melee weapon and the normal one when putting the bow away casually?

 

Although three seconds may not be big enough to worry about.

[grayman]

Good suggestions.

 

Another is to just drop the bow, but that would be the least desirable because the archer wouldn't be able to get it back.

 

Probably what I'll do, to avoid unnecessarily complicating things, is leave it as is and let y'all test it to see what you think.

[grayman]

Mages, werebeasts, zombies, and sword-swingers are comfortable with the combat changes. All do what they're supposed to when in melee or ranged.

 

The archer said to say "Thank you" for his new dagger.

[Springheel]

The archer said to say "Thank you" for his new dagger

[RPGista]

Awesome work! This should give me something interesting to experiment on the new version!

[Springheel]

How did you handle the animation issue, btw?

[grayman]

The animation couldn't be handled using the current design. That only allows for one attached weapon, and relies on the replacement anims on the weapon to provide their own "draw" and "sheath" anims.

 

I changed the design so we now have "draw"/"sheath" and "draw_ranged"/"sheathe_ranged" (I left the incorrect spelling of "sheath" the way it was). The first pair is for use with melee weapons and the second pair for use with ranged weapons.

 

Hammers still use the "draw"/"sheath" replacement method, since they're melee weapons.

 

Bows use the new "draw_ranged"/"sheathe_ranged", and have no need for replacement anims, since they're not overlaying the "draw"/"sheath" anims. The remainder of the replacement anims for walking alerted, etc., where we use the joint names, remain the same.

 

Depending on which weapon needs to be drawn, the code will play the correct animation. Ditto for sheathing.

 

I haven't tested any of this when torches are involved. They should work as is with the new design, but you never can tell until it's tested.

[grayman]

@Spring,

 

I found out why my elite guard is freezing when fighting a zombie.

 

There's no animation called "melee_parry" and the DLL code wasn't written to handle missing anims, and it gets the guard into a certain state from which he can't leave. The guard chooses this anim because none of the other available parry anims are well-suited for the zombie's attack.

 

For now, I've changed the script to play "melee_parry_Over" instead. This lets the guard not only stop freezing, but to kill the zombie.

 

I can leave it that way,

 

OR

 

if you want to make a "melee_parry" anim, then I'll switch back when that's available.

 

We would need an animation called "melee_parry" for both:

 

tdm_ai_female_animations.def

 

and

 

tdm_ai_guard_proguard_devel.def

 

It also looks like there are these in tdm_ai_melee_sets.def:

 

"anim_rate_melee_parry_rl" "1.1"

"anim_rate_melee_parry_lr" "1.1"

"anim_rate_melee_parry_over" "1.1"

"anim_rate_melee_parry_thrust" "1.1"

 

and there's no entry for anim_rate_melee_parry.

 

Thanks.

[Springheel]

I don't think there was ever anything but those four parries, because parrying was only meant to work against AI with weapons. Are we going to allow parrying of unarmed attacks? Unarmed swings, bites, or other non-weapon attacks don't seem like good candidates for parrying, IMO, at least not with a sword.

[Sotha]

I don't think there was ever anything but those four parries, because parrying was only meant to work against AI with weapons. Are we going to allow parrying of unarmed attacks? Unarmed swings, bites, or other non-weapon attacks don't seem like good candidates for parrying, IMO, at least not with a sword.

 

Yeah. Would be weird to parry unarmed attacks. Parrying is sensible and works only if both combatants are careful and keeping their distance: people dueling.

 

If it is about a beast or a zombie madly rushing -without worrying about their own safety- to kissing range in order to bite/claw you, surely the attack cannot be parried. If you can't keep the distance to the creature, you get one free hit when they swarm you and then you are wrestling with them.

[grayman]

The melee combat system assumes an attack/parry design, and each combatant queries the other combatant's melee state and recent behavior to help him decide what to do next.

 

It's very complex, so I can't gauge what it would take to ignore parries. The simplest approach is to allow them. If I had a sword and was fighting a zombie, I'd probably want to use it both for offense and defense.

 

I haven't yet studied how the zombie or mage makes his way through the system. They don't have parry anims, so the lack of them probably keeps them out of the parry state. But swordsmen and Builders have weapons and can parry, and they'd need so learn how not to do that.

[Springheel]

AI can try and parry, but they shouldn't be successful against unarmed attacks, just like the player isn't. Not only would it not make a lot of sense to parry a spider bite with a sword, but the animations wouldn't look right at all (not to mention the sounds).

 

edit: This spawnarg exists and is used for daggers: "can_parry" "0"

 

Don't know if you could switch that dynamically based on the opponent, though. Unarmed monsters just use an animation called "melee" for attacking, unlike AI with weapons, if that's helpful.

 

Another shot in the dark...make a new animation def called melee_parry, but point it to an attack animation? So when the AI goes to choose that parry in response to an unarmed opponent, he'll play an attack animation instead?

[grayman]

Thanks, that helps.

 

By default, AI are set up as "can't parry". When a weapon is attached, the weapon tells the AI if he can now parry. So, the sword says "yes" and the dagger says "no".

 

So that's one way an armed AI can tell if he should skip his parry anims or not.

 

What I've added to that is a check of whether the enemy uses an unarmed melee weapon. This should cover the mage, werebeast, zombie, and spider. If so, then the AI will skip his parry anims and only use his attack anims.

 

I've tested this with my guard and zombie, and it looked fine. The guard wins.

 

I'll test the guard against the other unarmed melee AI to see if more tweaking is needed.

 

So there's no need to create a "melee_parry" anim. In the melee scripts, I'll leave in my change to "melee_parry_Over", though, in case an AI ever asks for the general melee parry anim.

 

Thanks for the help.

[grayman]

I found this in tdm_ai_humanoid_undead.def:

 

   //undead have no eyes and can't be blinded
"sr_state_2" "0"
"sr_state_3" "0"

 

This means the undead can't receive any visual stims, and are invisible, because they don't give off visual stims. They can only see the player, but only because spotting the player doesn't rely entirely on visual stims from the player.

 

I understand the comment, but the ramifications are extensive and, I believe, not good. I marched my guard back and forth on a tile floor in front of a standing zombie, and he didn't react to the footstep sounds either, so I guess his hearing isn't that good. Except that he heard the guard when the guard spotted me and barked about it. So there are a few inconsistencies.

 

I'd like to turn these back on so that the undead can see other AI, and other AI can see them. Having undead be invisible until an AI bumps into one, at which point they become visible so they can be fought, seems a bit silly.

 

As for the "can't be blinded" comment, I can handle that as a special flashbomb case a different way.

 

Comments?

[grayman]

I committed the combat changes I've made to date.

 

There are a few more things I need to work on.

 

Details here.

 

I included a DLL for windows. Make sure you delete any gamex86.dll file in your darkmod folder after downloading and before testing.

 

I included one of my test maps: maps/test/roomofenemies.map.

 

Before you hit the Attack button, enter "notarget" mode, then hit Attack, then fire a noisemaker at the wall behind the zombies. Since the zombies and guards can't see each other yet, you have to get them moving.

 

Note that the archers will draw daggers for melee combat.

 

Note that anyone's fighting at all.

[Mr M]

Grayman,

 

Although coding is alien to me, at the least I can do is to thank you greatly, for the work you are doing!!!!. Frankly I don't think you guys get enough appreciation. Many of us sit back because of lack of knowledge in these areas, .... but it is very much appreciated!!

 

Thanks for ALL of your hard work!

 

Goes the same to the others! Without all of you, this great gaming would go nowhere very fast.