View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002909 | The Dark Mod | Coding | public | 08.11.2011 01:50 | 18.04.2014 16:49 |
Reporter | Springheel | Assigned To | grayman | ||
Priority | normal | Severity | normal | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 1.07 | ||||
Summary | 0002909: AI Warnings -- don't alert friends already searching | ||||
Description | I had two AI searching around a body together and one of them gave a warning bark to the other, "I saw something strange a while back". I don't think AI should give warnings to AI who are already investigating the same stimulus, though I'm not entirely sure how you would track that. Maybe check to see if the other AI is already searching and don't warn if so? Something to discuss when we go over warning behaviours for 1.08. | ||||
Tags | No tags attached. | ||||
Were they both already searching when the bark occurred? If an AI that's not searching ( A ) finds another that is ( B ), A will join in the search and cause B to bark, to make it look as if B asked for help. This won't happen if the search is because of a door that's not supposed to be open. I did this because adding to a search around a door can cause nasty congestion as they walk back and forth through the door. Otherwise, it is possible for two AI to warn each other about things they already haven't been warned about. The simple fix is to make searching AI not warn other searching AI. |
|
This could be a bit tricky. If non-searching A rounds a corner and finds B searching, A will join B in the search. The code handles this by copying B's search info to A, setting A's alert level to 70% of B's search level, and having B bark an appropriate warning based on the type of search (enemy, body, etc.). A and B search for a while, their alert levels ramping down. A's search level is less than B's, so he drops out of searching into Observant, at which point we're back to the original situation: non-searching A sees B searching. And then we have the same thing all over again: A gets 70% of B's alert level, A gets a copy of B's search info, and B barks something. If B barked about an enemy the first time, this time he could bark about a corpse, a missing item, or evidence of intruders, in that order. But as far as the player is concerned, A and B were both searching, and in the middle of that search, B barked at A again, which seems odd. But the code knows that A has stopped searching, and is now fair game to be barked at and asked to rejoin the search. Atm I'm not sure how to get around this. |
|
Unless you are going to add a memory state to keep track of this (eg: New-Search > Current-Search > Past-Search) ... Maybe force A to search until B is done? |
|
I've made a couple changes that should reduce how often AI are getting dragged back into searches, but they don't seem to matter much. When several AI are searching, if one with a high alert level barks something, the others are alerted and their levels increase. It isn't until the highest alert level in the group drops out of searching mode that they begin to resume patrols. This is definitely a 1.08 investigation. |
|
I've made changes since this was reported that should eliminate or reduce the problem. Let's keep an eye out and if it appears to be fixed, we can close this. |
|
Marking this 'revolved' since it's been quiet for months. | |
Date Modified | Username | Field | Change |
---|---|---|---|
08.11.2011 01:50 | Springheel | New Issue | |
08.11.2011 01:50 | Springheel | Status | new => assigned |
08.11.2011 01:50 | Springheel | Assigned To | => grayman |
08.11.2011 02:31 | grayman | Note Added: 0004134 | |
10.11.2011 00:35 | grayman | Note Added: 0004137 | |
10.11.2011 01:35 | nbohr1more | Note Added: 0004138 | |
10.11.2011 23:25 | grayman | Note Added: 0004139 | |
07.07.2013 22:24 | grayman | Note Added: 0005657 | |
07.07.2013 22:24 | grayman | Status | assigned => feedback |
18.04.2014 16:49 | grayman | Note Added: 0006534 | |
18.04.2014 16:49 | grayman | Status | feedback => resolved |
18.04.2014 16:49 | grayman | Resolution | open => fixed |