View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003515 | The Dark Mod | AI | public | 09.08.2013 14:30 | 10.09.2013 21:43 |
Reporter | Springheel | Assigned To | grayman | ||
Priority | normal | Severity | normal | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 2.00 | ||||
Target Version | TDM 2.00 | ||||
Summary | 0003515: AI giving warning barks after Observant alerts. | ||||
Description | Use "tdm_ai_showbark" "1" tp see what barks are being given. A number of times after going to Observant state, and barking "snd_alert1s", AI then barks "snd_warnSawEvidence" to a friend. I don't think they should be giving warning barks after only a minor alert. This will result in chains like, "Was that something?" "Must be my imagination" and then to a friend "Be on the alert, we got trouble". The rampdown barks suggest that the AI is dismissing whatever he saw/heard as inconsequential, so it doesn't fit for him to then warn friends about it. At the very least, Observant and Suspicious alert states should not cause warnings, as the AI isn't even alerted enough to move towards the disturbance. | ||||
Tags | No tags attached. | ||||
Another problem, which I'll throw in here, is that the "evidence of intruders" count goes up too fast with the new AI Vision scheme. Whereas the old scheme probably added 3 or 4 to the eoi count, the new scheme gets bumped each frame the player is visible. I need to rethink this. It also might explain why warnings are coming earlier than expected. The AI needs an eoi of 3 before he starts issuing eoi warnings. |
|
Ah, that probably explains it. | |
What we should probably do is not add anything to eoi until an event causes the AI to rise to at least Searching. Any events that cause him to go to Observant or Suspicious, and to not bark warnings later, aren't worth keeping track of. So events like 'missing item' or 'door open' or 'dangling rope' are worthy of warnings, so they're worthy of eoi. Events like a footstep or a splash, not worthy of warnings, are also not worthy of eoi. |
|
Yes, sounds good. | |
Thinking out loud here... Since player sightings can occur every frame until the AI builds up enough alert level to declare the player an enemy, the eoi shouldn't be bumped until the AI arrives at Searching. Once he's at Searching (or above), we wouldn't bump eoi again for this sighting event. If the AI loses sight of the player and some time goes by, a future sighting of the player can be considered a new event, so when he rises to Searching, his eoi can get bumped again. So the flag that keeps his eoi from getting bumped at higher alert levels should be cleared when the AI drops back into Idle Alert. |
|
Warnings fall into 4 categories: "An enemy is here": Failed KO, bumped into an enemy, entering combat with an enemy, hit by an arrow "A dead person is found": spotted a dead body "Something is missing": saw that an item is missing "Something's up": eoi > 2 Since spotting the player but not yet recognizing him as an enemy doesn't generate the "An enemy is here" warning, it will be contributing to the "Something's up" warning. So the bump that happens when an AI enters Searching mode because of a player sighting should be +3 instead of +1. This guarantees that when the AI encounters a friend later, he will at least bark "Something's up". I think I'm done thinking about this. Does it make sense? |
|
I'm not sure if a single search state should bump the AI over eoi threshold. I think it should be coupled with other evidence; just one single search could be a servant where they're not supposed to be. A servant plus a couple lights out would be enough though. |
|
So instead of bumping +3, I should just bump it +1. I'm only going to bump it if the alert pushes him into Searching, or if he's already in Searching or higher and it hasn't already been bumped. If he gets high enough to enter combat, then it'll be bumped +3 at that point. |
|
Instead of bumping an AI’s count of evidence by +1 each frame that he’s spotted the player, only bump it +1 when he’s in Searching state or higher. To keep it from being bumped each frame while in those states, only allow one bump per “sighting”. If the AI drops back to Alert Idle, allow the bump on the next “sighting”. Rev. 5848: IdleState.cpp AlertIdleState.cpp State.cpp Memory.cpp Memory.h |
|
This is checked in to the trunk and merged to the 2.00 branch. It'll be in tonight's package build. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
09.08.2013 14:30 | Springheel | New Issue | |
09.08.2013 16:22 | Springheel | Description Updated | |
09.08.2013 16:34 | grayman | Note Added: 0005980 | |
09.08.2013 16:36 | Springheel | Note Added: 0005981 | |
09.08.2013 16:38 | grayman | Note Added: 0005983 | |
09.08.2013 16:39 | Springheel | Note Added: 0005984 | |
09.08.2013 16:43 | grayman | Note Added: 0005985 | |
09.08.2013 16:54 | grayman | Note Added: 0005986 | |
09.08.2013 17:16 | Springheel | Note Added: 0005988 | |
09.08.2013 17:21 | Springheel | Note Edited: 0005988 | |
09.08.2013 17:39 | grayman | Note Added: 0005989 | |
09.08.2013 18:26 | grayman | Note Added: 0005990 | |
09.08.2013 18:27 | grayman | Note Added: 0005991 | |
13.08.2013 01:40 | grayman | Assigned To | => grayman |
13.08.2013 01:40 | grayman | Status | new => assigned |
13.08.2013 01:41 | grayman | Status | assigned => feedback |
10.09.2013 21:43 | Springheel | Status | feedback => resolved |
10.09.2013 21:43 | Springheel | Resolution | open => fixed |