View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003200 | The Dark Mod | AI | public | 14.08.2012 01:02 | 17.08.2012 17:17 |
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 1.08 | ||||
Summary | 0003200: AI not hearing very well? | ||||
Description | Anyone else getting the sense that AI don't hear very much? I feel like as long as I'm crouched I can pretty much run around as much as I like and they don't even notice. Even jumping doesn't do much. I jumped on some crates in Rightful Property trying to mantle, and the AI sitting down at the bottom didn't even notice. | ||||
Additional Information | Yes absolutely, I mentioned it in another thread that I blackjacked an AI, and another came to investigate and I was able to crouch walk all around him and he didn't hear me, so I ended up being able to KO three AI without being heard or discovered. I was in total darkness but I was assuming he would at least sort of hear me and walk towards my direction like they used to do, but didn't get that at all. This is on Expert. | ||||
Tags | No tags attached. | ||||
"I have to say, AI seem to be much easier to sneak up on with this version. Before I couldn't even walk up behind them as they got alerted, now I can walk all the way around them while they are actively searching for me, and I have no issue getting behind them for a knockout. I took out three servant AIs this way, one after the other and they never saw me." |
|
I have discovered a problem. Don't know if it's new to 1.08 or not, but it seems like once a guard is actively searching for you, you can literally run around in circles and jump up and down a few feet away from him (all on a stone floor), and he will not react to the sound at all. If he can see you, he will charge, but if he only hears you, he does nothing. This results in ridiculous scenarios. | |
Grayman: "I suspect what's happening is the guard's behaving correctly, but there's a problem in that he doesn't always turn toward every sound he hears. The code tells him to search the spot where the sound came from, but if he's close enough to it, he doesn't move, but just looks around based on where the hiding spot search code tells him to look. If you move away from him a bit and jump, he should start moving toward you again. I made a change a long long time ago (pre 1.07) that kept AI from walking all the way to where they heard the sound. This kept multiple AI from bunching up at the sound location, which looked terrible because you ended up with a group of AI jostling each other and walking through each other." |
|
Grayman: "Ah, what might be happening is that if a new sound alert comes in when searching, if the location is < 50 from the current search center, the new sound is ignored. So I think this is what's happening when he appears to ignore you: 1 - jump up and down 2 - AI is alerted and walks toward you 3 - you slide sideways to get out of his way 4 - he stops 5 - you jump up and down again, and he turns toward you 6 - since he's now close to you, he doesn't move toward the sound 7 - hiding spot search gives him another spot and he either turns toward it if it's behind him, or just looks at it if it's in front of him 8 - you jump up and down as much as you want and each jump is ignored because you're close to the center of his current search 9 - he continues to receive spots to investigate from the hiding spot search, so he'll stand there turning in place or just looking around If you move away from him a ways and start jumping again, he should turn toward you and start walking toward you, because now the new alert sound is > 50 from the previous search center. Rinse and repeat, ad nauseum. To at least make this a bit more interesting, perhaps he should at least turn toward the alert spot he's about to ignore. That should be easy to do. " |
|
What might work better is having the closest searching AI move to the sound, but any other AI in the area just turn towards it. That would still avoid the jostling problem but would keep the player from being able to jump around without any consequence. But if this issue is already present in 1.07, there's no pressing need to address it now. |
|
The code that checked how close a new audio alert spot was to the previous audio alert spot allowed two outcomes: 1 – When > 50 from the previous spot, search the new spot, w/o stopping the current search. This allowed the current search to override the request to search the new spot, giving the appearance that the AI was ignoring the new spot. Fixed this so the current search is canceled and a new search started at the new spot. 2 – Otherwise ignore the new spot. Fixed this so the AI will at least turn toward the new spot. The current search is allowed to continue. The code that doles out hiding spots for searching wasn’t paying attention soon enough to a request to cancel the search and start another. Fixed that. rev. 5527: SearchingState.cpp |
|
Date Modified | Username | Field | Change |
---|---|---|---|
14.08.2012 01:02 | Springheel | New Issue | |
14.08.2012 01:02 | Springheel | Assigned To | => Springheel |
14.08.2012 01:02 | Springheel | Status | new => feedback |
14.08.2012 01:08 | Springheel | Note Added: 0004756 | |
14.08.2012 01:08 | Springheel | Status | feedback => assigned |
14.08.2012 01:08 | Springheel | Note Edited: 0004756 | |
14.08.2012 15:32 | Springheel | Assigned To | Springheel => |
14.08.2012 15:32 | Springheel | Assigned To | => Springheel |
14.08.2012 15:32 | Springheel | Status | assigned => feedback |
15.08.2012 20:32 | Springheel | Note Added: 0004761 | |
15.08.2012 20:32 | Springheel | Status | feedback => assigned |
16.08.2012 02:26 | Springheel | Note Added: 0004762 | |
16.08.2012 02:26 | Springheel | Note Added: 0004763 | |
16.08.2012 02:26 | Springheel | Note Added: 0004764 | |
17.08.2012 17:17 | grayman | Note Added: 0004765 | |
17.08.2012 17:17 | grayman | Assigned To | Springheel => grayman |
17.08.2012 17:17 | grayman | Status | assigned => resolved |
17.08.2012 17:17 | grayman | Resolution | open => fixed |