View Issue Details

IDProjectCategoryView StatusLast Update
0003053The Dark ModAIpublic22.12.2018 03:37
Reportersotha_sil Assigned To 
Status feedbackResolutionopen 
Product VersionTDM 1.07 
Summary0003053: AI should be able to alert sleeping AIs
DescriptionAt present, alerted AI's cannot alert sleeping AIs.

It would seem sensible behaviour that an AI who is aware of intruders in the premises would like to wake up sleeping AI.
TagsNo tags attached.


related to 0001928 closedSpringheel Sleepers can become alert while asleep 




11.03.2012 04:04

administrator   ~0004392

Last edited: 11.03.2012 04:05

View 2 revisions

The following behavior was established in the past:

If the sleeping AI is in Observant State, he won't wake up.
In Suspicious State, he'll wake up.
In Searching State, he'll wake up.
In AgitatedSearching State, he'll wake up.

A missing item will put him in Observant State, but he won't wake up. So it doesn't look right when a fellow guard walks by and says, "Hey, come help me search for a thief," and the sleeper stays asleep. After a second and third theft, the result is the same.

I'm thinking that receiving an alert message is enough reason to wake up or get up from sitting. Somebody said something directly to you, which is different than maybe hearing a sound from somewhere that isn't enough on its own to get you moving.

What do you think?



12.03.2012 03:35

administrator   ~0004396

Last edited: 12.03.2012 04:10

View 3 revisions


This is a bigger job than I first thought.

It's possible that I won't be able to get to this for 1.08. I tried to immediately awaken the sleeping AI at the point the warning AI passed the message, but that led to the awakening AI falling through the floor when he gets out of bed. I learned more about why this happens, but it's not the problem I'm trying to solve.

So I abandoned that idea and tried to get the existing wakeup mechanism to wake up the AI. But that's based entirely on alert level, and because the arrival of a warning message depends on 'sound', there's no guaranteed delivery, as there is with regular greetings. If I insert a wakeup delay (because that seems more natural than the sleeping AI jumping out of bed almost before the warning AI starts his bark), it lets the alert level to come down, which prevents the AI from waking up.

So while investigating all this, I found that unsuccessful warning messages that don't get through because they're not 'loud' enough, aren't flushed from the system. They accumulate, and are all delivered with the first message that IS loud enough, in the same frame. This makes for a messy situation with warnings piled upon warnings, and it has to be dealt with.

This is going to take some time, and perhaps it would be better for it to wait until we've replaced the balky dependence on 'sound' with a guaranteed warning delivery mechanism.

Edit: Forgot to mention that an AI's audio acuity is cut in half when he goes to sleep, making it twice as difficult for him to hear a warning.



28.03.2013 00:44

administrator   ~0005250

Update on this.

The problem of unheard messages backing up is now fixed. Unheard messages will be flushed from the queue.

I've also changed the message delivery so it occurs at the end of the bark that the player hears. It might be possible now to wake up a sleeping AI in the same frame the message arrives, so I'm going to look at this problem again.


22.12.2018 03:36

developer   ~0011012

The current behavior appears to be emergent or indirect. There is no hardcoded "locate AI to wake them" feature but the name of this bug has "should be able" which means that it is resolved in three ways:

1) Able to wake via emergent nearby alerting
2) Able to wake via placing a "team" flee point near the sleeping AI
3) Path Nodes, RIT, scripting.

Issue History

Date Modified Username Field Change
10.03.2012 14:17 sotha_sil New Issue
10.03.2012 14:46 grayman Assigned To => grayman
10.03.2012 14:46 grayman Status new => assigned
11.03.2012 04:04 grayman Note Added: 0004392
11.03.2012 04:05 grayman Note Edited: 0004392 View Revisions
12.03.2012 03:35 grayman Note Added: 0004396
12.03.2012 03:37 grayman Note Edited: 0004396 View Revisions
12.03.2012 04:10 grayman Note Edited: 0004396 View Revisions
12.03.2012 20:57 tels Relationship added related to 0001928
28.03.2013 00:44 grayman Note Added: 0005250
24.11.2017 16:38 grayman Assigned To grayman =>
24.11.2017 16:38 grayman Status assigned => new
22.12.2018 03:36 nbohr1more Note Added: 0011012
22.12.2018 03:37 nbohr1more Status new => feedback