 |
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? |
|
|
Um, 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. |
|
|
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. |
 |
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. |
- Anonymous
