View Issue Details

IDProjectCategoryView StatusLast Update
0003515The Dark ModAIpublic10.09.2013 21:43
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionTDM 2.00 
Target VersionTDM 2.00 
Summary0003515: AI giving warning barks after Observant alerts.
DescriptionUse "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.
TagsNo tags attached.

Activities

grayman

grayman

09.08.2013 16:34

viewer   ~0005980

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.
Springheel

Springheel

09.08.2013 16:36

administrator   ~0005981

Ah, that probably explains it.
grayman

grayman

09.08.2013 16:38

viewer   ~0005983

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.
Springheel

Springheel

09.08.2013 16:39

administrator   ~0005984

Yes, sounds good.
grayman

grayman

09.08.2013 16:43

viewer   ~0005985

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.
grayman

grayman

09.08.2013 16:54

viewer   ~0005986

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?
Springheel

Springheel

09.08.2013 17:16

administrator   ~0005988

Last edited: 09.08.2013 17:21

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.

grayman

grayman

09.08.2013 17:39

viewer   ~0005989

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.
grayman

grayman

09.08.2013 18:26

viewer   ~0005990

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
grayman

grayman

09.08.2013 18:27

viewer   ~0005991

This is checked in to the trunk and merged to the 2.00 branch.

It'll be in tonight's package build.

Issue History

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