View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003337 | The Dark Mod | Coding | public | 06.03.2013 18:46 | 23.03.2013 02:51 |
Reporter | Arcturus | Assigned To | Springheel | ||
Priority | normal | Severity | normal | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 2.00 | ||||
Summary | 0003337: bug when unalerted zombie is hit with a sword | ||||
Description | It 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 | ||||
Tags | No tags attached. | ||||
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. |
|
I was able to confirm it locally. Hopefully something you've already done has fixed it. | |
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. | |
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. |
|
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. |
|
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. |
|
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. |
|
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. | |
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 |