View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003317 | The Dark Mod | AI | public | 12.02.2013 22:43 | 25.02.2013 23:47 |
Reporter | Springheel | Assigned To | grayman | ||
Priority | normal | Severity | normal | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 1.08 | ||||
Target Version | TDM 2.00 | Fixed in Version | TDM 2.00 | ||
Summary | 0003317: AI need ability to react to sudden deaths of nearby AI | ||||
Description | Right now there is no difference between an AI finding a body that has been dead for hours and seeing an AI killed right in front of him. Generally AI should be much more agitated about seeing an AI killed right next to them...perhaps some kind of counter, where if the AI spots the dead AI within 5 seconds of him dying, they react differently, running for help, taking cover or immediately searching the area. | ||||
Tags | No tags attached. | ||||
Civilian AI should definitely flee if a neutral or friendly AI is killed in their POV. Armed AI should go to full alert. They should NOT go to check the body, as they currently do, but immediately start a search pattern. |
|
Should armed AI react to finding a neutral body? See 0003078, where I made them ignore neutral AI, whether dead or alive. My reasoning was that if the body belonged to a neutral team, the guard couldn't care less. |
|
Atm, if an AI dies in view of several other AI, the "person" stim from the dead AI reaches the others in the same frame, and they recognize the death at the same time. It doesn't seem realistic for two reasons: 1 - AI on the same team react the same way, in unison, and 2 - they all react instantaneously. I'm considering a random delay (0.5s -> 1.5s) between receiving the stim and reacting. Is that acceptable? |
|
Yes, a random delay makes sense. I think the most reasonable behaviour is for the armed AI to search even if the killed AI was nuetral. If a guard is standing on the street and sees a beggar killed right in front of him, it isn't going to seem believable if he ignores it. He'd probably pull out his weapon and search to see if there is a threat. As for whether this would apply to bodies that have been there for a while, that's an open question. I could see arguments for both sides. |
|
Okay, then I'll let AI react to dead neutrals if spotted w/in 5 seconds. After that, I'll just make it a 50% chance they'll react. Satisfies both camps, in a hacky sort of way. I'll add the 0.5->1.5s random delay to the body stim as well. ------------ Though it has nothing to do with this bug, what about unconscious neutrals? Should guards be reacting to a neutral being KO'ed in front of them? Same behavior as for dead neutrals? |
|
Hmm. Yes, I think it should be the same behaviour. If you see someone collapse suddenly, chances are you're going to assume something happened, rather than it being a heart attack, so you'd still pull out your weapon to assess the threat. | |
These things happen when an AI finds a body: 1 - evidence count goes up 2 - he registers that he found the body, and will tell others he sees in his travels 3 - he barks that he found a body 4 - alert level goes up and he starts searching 5 - Mission stats are told that a body is found and whether the player was responsible or not When we talk about "ignoring" a body, I suggest we're only talking about skipping # 4. For example, if the player KO'ed someone and the mission objectives say "Don't KO anyone", we'd still want the mission to abort, even if the finding AI just walked across the body and didn't start searching. Right? |
|
If you're asking which of those should still happen if the AI sees the body within X seconds of the kill/KO, I'd say 1, 2, 4 and 5 should still happen. The barks for 0000003 are not really appropriate for seeing someone killed in front of you. I think going straight to agitated search barks would be fine. If you're asking which of those AI should do to neutral bodies if they fail the 50% chance to react, I'd agree that everything but 4 would be reasonable. Where is the kneeling animation in that sequence? I think that should be left out if within X seconds, but is appropriate for neutrals who 'ignore' the body. |
|
Kneeling is part of the search. The search routine is told whether to kneel at the body and/or search the body first. If the body is seen w/in 4s of when it hit the ground, the search routine is told NOT to kneel and NOT to search the body first. The AI might take a few steps toward the body, but only if their first search point is near (but not at) the body. One of my test cases is a ring of AI standing around another AI. If I kill or KO the central AI, the others will bark and begin searching. Looks okay. I'll implement your suggestions. I've done close to that already, so it shouldn't be much more. ------------------------------ Wrt civilian or unarmed AI fleeing when they witness a murder or KO ... The flee code assumed that the fleeing AI had spotted you (it was full of "enemy this" and "enemy that"). To get it to also handle witnessing murders or KO, where you might not be visible (no enemy), I needed to make a few changes. This works now, but ... The AI will bark snd_to_flee, then run away. While running, he occasionally barks snd_flee. You might want to listen to these and see if we need two pairs of barks instead of one: one for fleeing a spotted enemy (existing snd_to_flee & snd_flee) one for fleeing a murder or KO (new snd_to_flee_event & snd_flee_event) In my most recent test, the witness AI barked "he's got a sword!" as he ran away, after I'd killed his friend with an arrow to the head. The witness didn't see me. |
|
Hmm, good point, I hadn't considered the barks in that case. I'll check and see what might be appropriate...there's "raise alarm" and "go get help" barks that might work. |
|
Had a couple funny moments this morning. A fleeing AI ran through a cloud of gas and dropped like a sack of rocks onto another gassed AI. As he landed on the other AI, he barked, "There's a man down here!". A few tests later, I had a couple of fleeing AI that went down because of gas, and they kept on barking their snd_flee barks while lying unconscious on the floor. Turns out the flee code wasn't keeping track of whether a fleeing AI got killed or knocked out, and it let him bark after he was KO'ed. Fixed now. |
|
That's another good reason for a short delay before barking. :) | |
Split dead and unconscious body reaction code into two parts. The first part runs immediately, and sets up a random delay from 0.5s to 1.5s before running the second part. The second part sets up the search. In a room full of AI witnessing a murder or KO, this keeps them all from reacting in the same frame, barking at the same time, drawing their weapons at the same time, and starting their search at the same time. If an AI enters the Combat state after the first part runs, but before the second part runs, the second part is aborted. Create a window starting with a kill or KO and ending 4s later. If an armed AI reacts to a visual stim from the body inside this window, he will not begin his search at the body, nor will he go to the body and kneel down. He simply starts searching. If he finds the body outside the window, he reacts as he always has: starts his search at the body, and possibly kneels down at the body. If an AI witnesses a death or KO of a neutral AI, he will react the same as if it was his friend that went down. If he comes upon the body outside the window, there’s a 50% chance he will react to finding the body. If an AI is a civilian or is unarmed, and he witnesses a murder or KO, he will flee. The flee task code needed to be changed to account for not having an enemy. Fleeing AI that got KO’ed or killed stayed in the flee state. In the case of being KO’ed, they continued to call for help while lying unconscious on the ground. The fix is to abort the fleeing state if KO’ed or killed. AI will no longer join searches if they come across one while fleeing. A killed or KO’ed AI will fire his visual stim the next frame, instead of waiting until the next scheduled stim time. This eliminates having to wait up to 2.6 seconds after death or knockout before someone notices. Gave a priority “5” to “snd_greeting_pagan”. This was missing. Corrected a bug that caused a pair of AI to greet each other once, and then never again. Don’t respond to a request for help when fleeing. Play different barks when fleeing, depending on whether a murder or KO was witnessed, or a body was found later or an enemy was seen. Fixed a bug in pathfinding that allowed AI to bump into open doors. Smooth out running through already-opened doors. rev. 5700: CombatState.cpp CombatState.h FleeDoneState.cpp FleeState.cpp State.cpp State.h FleeTask.cpp GreetingBarkTask.cpp HandleDoorTask.cpp HandleDoorTask.h AI.cpp AI.h AI_events.cpp AI_pathing.cpp Actor.cpp Actor.h Mind.cpp EscapePointEvaluator.cpp EscapePointManager.h Game_local.cpp Game_local.h rev. 13334: tdm_ai_vocal_set_base.def |
|
Date Modified | Username | Field | Change |
---|---|---|---|
12.02.2013 22:43 | Springheel | New Issue | |
12.02.2013 22:44 | Springheel | Relationship added | related to 0003310 |
12.02.2013 22:52 | Springheel | Note Added: 0005063 | |
19.02.2013 05:34 | grayman | Note Added: 0005079 | |
19.02.2013 05:34 | grayman | Assigned To | => grayman |
19.02.2013 05:34 | grayman | Status | new => assigned |
19.02.2013 14:13 | grayman | Note Added: 0005080 | |
19.02.2013 17:21 | Springheel | Note Added: 0005082 | |
19.02.2013 17:52 | grayman | Note Added: 0005085 | |
19.02.2013 19:39 | Springheel | Note Added: 0005087 | |
20.02.2013 20:02 | grayman | Note Added: 0005094 | |
20.02.2013 20:03 | grayman | Note Edited: 0005094 | |
21.02.2013 01:16 | Springheel | Note Added: 0005095 | |
21.02.2013 03:19 | grayman | Note Added: 0005096 | |
21.02.2013 20:49 | Springheel | Note Added: 0005097 | |
21.02.2013 20:54 | Springheel | Note Edited: 0005097 | |
21.02.2013 21:36 | grayman | Note Added: 0005098 | |
22.02.2013 01:00 | Springheel | Note Added: 0005100 | |
25.02.2013 23:47 | grayman | Note Added: 0005107 | |
25.02.2013 23:47 | grayman | Status | assigned => resolved |
25.02.2013 23:47 | grayman | Resolution | open => fixed |
25.02.2013 23:47 | grayman | Fixed in Version | => TDM 2.00 |
25.02.2013 23:47 | grayman | Target Version | => TDM 2.00 |