View Issue Details

IDProjectCategoryView StatusLast Update
0003337The Dark ModCodingpublic23.03.2013 02:51
ReporterArcturus Assigned ToSpringheel  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 2.00 
Summary0003337: bug when unalerted zombie is hit with a sword
DescriptionIt appears when you hit zombie with a sword before he notices you. Zombie then can't get close to you. In the video you can see that bug happens only when you hit it with a sword first. If you hit it with blackjack and then with sword it's ok. In the video Zombie is neutral first, but it happens also when you hit an unalerted zombie enemy too (e.g. from behind).

http://www.youtube.com/watch?v=g6c_ILxWKgQ&feature=youtu.be
TagsNo tags attached.

Activities

grayman

grayman

10.03.2013 01:26

viewer   ~0005142

I've been making combat changes while working on a half-dozen issues.

When I got to this one, I couldn't reproduce it. A neutral zombie, when hit with a sword, only played one pain animation, and had no trouble chasing me and getting near enough to whack me.

Once I've committed the changes I'm working on, folks should test zombies and see if they can reproduce the problem.
Springheel

Springheel

10.03.2013 02:36

administrator   ~0005145

I was able to confirm it locally. Hopefully something you've already done has fixed it.
Springheel

Springheel

15.03.2013 15:02

administrator   ~0005190

I haven't seen this in quite the same way as before, but the zombie still does occasionally play pain animations when it hasn't been hit. I hit a friendly zombie, back up while he spins around looking for him, and then move towards him again...he will often play another pain animation at that point before moving towards me.
grayman

grayman

16.03.2013 19:59

viewer   ~0005201

I can't reproduce this using SVN and a team 0 (friendly) atdm:ai_undead_zombie.

If I hit him from behind, he plays his pain anim, then turns toward me.

I back up, then walk toward him. He whacks me w/no pain anim.

He'll follow me around, whacking me, but I see no further pain anims.

Perhaps I need a test map so I can see all the spawnargs on the specific zombie.
Springheel

Springheel

18.03.2013 23:19

administrator   ~0005208

Last edited: 18.03.2013 23:20

I've uploaded a testmap to SVN test_zombie.map. Walk up to the zombie and do a thrust into his torso and then back up. He plays his pain animation, then goes into combat pose, then plays another pain animation. Sometimes he then attacks and sometimes he stays standing where he is.

grayman

grayman

19.03.2013 19:23

viewer   ~0005212

Last edited: 19.03.2013 19:26

I don't know what's causing this problem, yet.

But I've noticed that when the Torso pain anim and the Legs pain anim start in the same frame, the Torso anim will continue for about 154 frames (2.464 seconds) and the Legs anim will do 2 frames.

At the moment the Torso pain anim completes, the Legs pain anim is restarted, and runs for 2 frames, then about a second later it's restarted and runs for 2 frames.

None of the Legs anims completes normally, in the sense that the anim script recognizes the completion.

Can you verify that the Torso and Legs anims have the same number of frames? And what is that number.

I notice that there are different anims depending on where you hit him.

I'm interested in the one for his right arm, if that helps.

Springheel

Springheel

20.03.2013 00:06

administrator   ~0005213

Last edited: 20.03.2013 00:42

The zombie uses exactly the same pain animations as other humanoid AI. It shouldn't play different animations depending on where you hit it (the old D3 zombie did).

There are 4 different pain animations, chosen randomly. Most are 36 frames, but the first one (with the step backwards) is 66 frames.

All of them call the frame command "call overrideLegs" on frame 1, which ensures that the animation is played on the leg channel (otherwise it plays only on the torso channel).

A few other observations that might be useful:

This only seems to happen when the zombie is not alerted. Once he is in alert state, he reacts normally.

The initial pain animation appears to play normally on the leg channel, as far as I can tell from watching it. But then the leg channel stops working and the zombie just stands there playing animations on the torso only.

Also, I tried another humanoid that can do unarmed combat; the mage. It looks like his behaviour is also a bit odd. After hitting him, he plays his pain animation, but he stands still for several seconds before charging me. During one of these standing periods between pain and charging me, his legs played an idle "tap foot" animation!

I tried swapping the model of the zombie with a proguard, and the behaviour stayed the same, so it's nothing specific to the mesh, animations or joints.

If I had to make a wild guess I would say it has something to do with not having to play a weapon draw animation.

Springheel

Springheel

20.03.2013 00:41

administrator   ~0005214

Hmm, maybe not. I tried attaching a sword and setting him to unarmed combat 0, but that just made things weirder. When I hit him, he would play his pain animation, stand and rotate 180 degrees, and then "jitter" in place.
grayman

grayman

20.03.2013 00:41

viewer   ~0005215

My next question was going to be: "What is overrideLegs?"

What's happening is that the pain anim script starts the animation on both the torso and the legs, and syncs them.

After two frames of the leg anim, the overrideLegs frame command gets called, stopping the pain animation on the legs.

It appears that the leg anim gets restarted once the torso anim finishes, but it stops again when it hits the overrideLegs frame command.

It might restart two or more times after that.

So we have code that says to run the pain anim on both torso and legs, perhaps conflicting with a frame command that says not to run it on the legs, and maybe something's getting screwed up because of that.

Do all pain anims use the overrideLegs frame command? I'm going to try not running the leg anim and see what happens.
Springheel

Springheel

20.03.2013 00:43

administrator   ~0005216

Yes, all the pain animations use it.

I can't verify what you're saying about the pain animation not playing on the legs, however. It seems to be playing properly, at least the first time.
Springheel

Springheel

20.03.2013 00:47

administrator   ~0005217

Last edited: 20.03.2013 00:48

Well, that's interesting. I commented out the override frame command from the pain animations, and just did 3 tests...each time the zombie attacked properly.

So it definitely looks like that is the culprit...but I don't know why it doesn't happen on armed AI.

This opens up the option of a quick fix...I could just make new animation definitions for the zombie (and possibly mage) that don't have the leg override.

grayman

grayman

20.03.2013 00:53

viewer   ~0005218

That solved the problem. I guess when an overrideLegs frame command is in the mix, the DLL should not be asking for the legs to run separately. For some reason, stopping the Legs pain anim simply delayed playing it until the override ended, which was when the torso pain anim completed.

Perhaps this problem affects anims other than just pain? I see overrideLegs used on pain anims for other AI, as well as playing cards, tapping feet, sitting, werebeast melee combat, zombie melee arm swings, etc.
grayman

grayman

20.03.2013 00:56

viewer   ~0005219

Ninja'd.

We can either remove overrideLegs wherever it appears, or have the overrideLegs code in the DLL do nothing.

I wouldn't want to go around trying to figure out which Leg anims to have the DLL not call, because the code won't know if overrideLegs appears in the anim.
Springheel

Springheel

20.03.2013 01:02

administrator   ~0005220

Last edited: 20.03.2013 01:09

I added the override legs in the first place because at the time the pain animations did not play on the legs channel. Maybe something has changed since then, since they seem to work now without it.

I wonder why this doesn't seem to affect armed AI?

Most combat animations also have that frame command, which was needed to stop them from running into the player while swinging.

I'd rather not remove the commands from any other animations until there is an obvious problem.

grayman

grayman

20.03.2013 01:08

viewer   ~0005221

It could have changed when someone added a separate call to the Legs channel, then synced them. Before my time.

The comment associated with overrideLegs in the scripts is:

"Disables the animation currently playing on the given channel and syncs the animation with the animation of the nearest animating channel."

With Head = channel 0 and Torso = channel 1 and Legs = channel 2, I assume this means that if the Legs pain anim is disabled, it syncs itself with whatever's going on on the nearest channel, the Torso.

What the comments don't say is that for some reason the disabled anim gets restarted later.

Maybe the best thing to do is what you're doing: delete overrideLegs for those anims where we see this type of problem.

I don't know why armed AI don't exhibit this. Maybe having a weapon involved prevents it from happening.
grayman

grayman

23.03.2013 02:51

viewer   ~0005234

I encountered an instance of atdm:ai_townsfolk_wench_armed exhibiting the double-pain problem. I'm monitoring the pain anims very closely right now, and I know that I'm not issuing two anim requests.

I see that a lot of female animations use overrideLegs.

I commented them out of the female pain animations and the problem stopped.

So I'm going to commit this change.

I tried shooting arrows at other AI (builders, city watch, mages) and didn't see the problem.

Issue History

Date Modified Username Field Change
06.03.2013 18:46 Arcturus New Issue
06.03.2013 20:23 grayman Assigned To => grayman
06.03.2013 20:23 grayman Status new => assigned
10.03.2013 01:26 grayman Note Added: 0005142
10.03.2013 02:36 Springheel Note Added: 0005145
15.03.2013 15:02 Springheel Note Added: 0005190
16.03.2013 19:59 grayman Note Added: 0005201
18.03.2013 23:19 Springheel Note Added: 0005208
18.03.2013 23:20 Springheel Note Edited: 0005208
19.03.2013 19:23 grayman Note Added: 0005212
19.03.2013 19:26 grayman Note Edited: 0005212
20.03.2013 00:06 Springheel Note Added: 0005213
20.03.2013 00:15 Springheel Note Edited: 0005213
20.03.2013 00:17 Springheel Note Edited: 0005213
20.03.2013 00:17 Springheel Note Edited: 0005213
20.03.2013 00:22 Springheel Note Edited: 0005213
20.03.2013 00:23 Springheel Note Edited: 0005213
20.03.2013 00:28 Springheel Note Edited: 0005213
20.03.2013 00:28 Springheel Note Edited: 0005213
20.03.2013 00:41 Springheel Note Added: 0005214
20.03.2013 00:41 grayman Note Added: 0005215
20.03.2013 00:42 Springheel Note Edited: 0005213
20.03.2013 00:43 Springheel Note Added: 0005216
20.03.2013 00:47 Springheel Note Added: 0005217
20.03.2013 00:48 Springheel Note Edited: 0005217
20.03.2013 00:53 grayman Note Added: 0005218
20.03.2013 00:56 grayman Note Added: 0005219
20.03.2013 01:02 Springheel Note Added: 0005220
20.03.2013 01:03 Springheel Note Edited: 0005220
20.03.2013 01:06 Springheel Note Edited: 0005220
20.03.2013 01:08 grayman Note Added: 0005221
20.03.2013 01:09 Springheel Note Edited: 0005220
20.03.2013 17:21 grayman Assigned To grayman => Springheel
21.03.2013 01:32 Springheel Status assigned => resolved
21.03.2013 01:32 Springheel Resolution open => fixed
23.03.2013 02:51 grayman Note Added: 0005234