 |
When an AI ramps down to alert idle, if he's been at Searching or higher, he says snd_alertdown0SeenEvidence. If he's gotten no higher than Suspicious, then he says snd_alertdown0 I'll have to try to reproduce this, since the code appears to be correct. Did these AI put their weapons away before they walked off? |
|
|
Tested with an archer. Let him shoot a couple arrows at me, then got in close so he switched to his dagger. After a couple swipes, I flashbombed him. While he couldn't see me, I switched into notarget. When his sight cleared, he searched around for a while, dagger out, barking the usual "Come out and fight" stuff. When he dropped into idle mode, he immediately switched over to alert idle because he had originally spotted me and that counts toward 'evidence'. He then barked a correct rampdown bark, "I can't search forever". Does "Must've been rats" belong to the hearing or sight bark sets? Maybe your guy heard you while you were hiding, and so the last thing he registered was an audio alert, which would probably cause him to bark one of the generic hearing rampdown barks. Just a guess. I was in notarget in my test, so he wouldn't have heard anything from me, allowing him to bark the correct 'seenEvidence' bark. If that's what happening, and it's just a guess, then I need to put priorities on the visual/audio alerts so that less important ones don't overwrite more important ones. |
 |
"Maybe your guy heard you while you were hiding, and so the last thing he registered was an audio alert, which would probably cause him to bark one of the generic hearing rampdown barks" That's possible, but that shouldn't affect the bark that he gives. The specific hearing/seeing rampdown barks should only be applicable if the AI does not go to agitated searching state. Once he's doing an agitated search, it shouldn't matter how much he sees/hears, he should only give snd_alertdown0SeenEvidence (or no_evidence) when ramping down from that search. I'm off to see if I can reproduce it. |
|
|
Ok, I think you might be on to the problem. I alerted two guards and just sat out their search, and they both gave the right bark. I then alerted another guard, and while he was searching, I jumped close enough for him to hear. When he was done, he said, "Seems like it was nothing at all" which is an alertdown0 bark. |
|
|
Try the latest SVN. I rearranged the order of alert type checking in the areas where the rampdown barks occur, so that having been at a higher alert level overrides having heard a sound. I also made a change that if an AI is in combat mode, he won't register having heard a sound. Not sure if this has an effect on what you're seeing, though, since the searching guards are not in combat mode when they hear you. Please try and see if it makes a difference. If this doesn't help, I'll probably have to redesign how all this is done, since we have multiple factors involved and they at times seem to step all over each other. |
|
|
So far so good. |
|
|
Well, I'm not seeing the original problem, but there's a new problem now...AI are no longer making "snd_alert1" barks at all. I was playtesting in Living Expenses, and started hearing AI make "snd_alertdown0" barks even though they hadn't said anything about being alerted. So I did some tests, and even though I jumped near a guard and he heard me enough to go to alert 2, he didn't say anything, nor did he look in my direction. A few seconds later he gave his "snd_alertdown0h" bark. "snd_alert3" seem to be playing normally. |
|
|
I don't see a problem with the code. Did you have 'tdm_ai_debug_transition_barks' turned on? If not, please turn that on, do a condump when something odd happens, and post the dump or PM it to me. |
|
|
The condump says this: atdm_ai_builder_guard_9 enters Suspicious state and barks 'snd_alert1h' atdm_ai_builder_guard_9 enters Searching state, and barks 'snd_alert3h' However, there was no audible 'snd_alert1h' bark. I didn't hear the guard say anything until his 'snd_alert3h' bark. This originally happened in Living Expenses, with a few different AI, but I'm now using the Sound and Blackjack Trainer map for testing. I have tdm_showsprop on, so I can see when the guard is going alert due to noise, but he doesn't say anything until he gets to searching state. edit: I did add a new vocal def today ("snd_alert4NoEvidence") and uploaded it to SVN this afternoon--I can't imagine how that could cause any problem, but just to be sure, are you working with an up to date SVN? edit: Just tested with citywatch...I noticed this time every step I took after reaching his audio threshold (where he should have heard and commented), his head turned as if to look back in my direction, but then on the next footstep it jerked back into position and turned to look, then jerked back to forward and turned to look, etc. It was as if each new footstep was interrupting him somehow. |
|
|
Ok, I just took a video; I can upload it if you like. In it, you can see that the AI hears a sound that sends him to Alert 1 (right at the start of the video--the youtube resolution makes the debug text hard to read), but he doesn't make an observant bark. In fact, he's still making an idle bark at that point. I continue making footsteps and you can see his head jerks once or twice as I mentioned above. Then he makes a rampdown bark (the "huh" is part of that rampdown bark, I know it sounds like a snd_alert1 bark, but it's not). Then he hits Alert 3 and interrupts his rampdown bark with the normal "snd_alert3h" bark. edit: here is the video link: http://www.youtube.com/watch?v=zrKiWmXqVGs&feature=youtu.be |
|
|
Is the AI supposed to bark something when he rises into Observant and goes no higher? I thought he didn't start barking until he rose into Suspicious. |
|
|
He's supposed to play his "snd_alert1" bark when he goes from idle to Alert 1 ("Hmm?"), but not play a rampdown bark if he goes no higher than 1. He looks towards the stimulus but doesn't stop his patrol, if moving. If he goes from idle to Alert 2, then he plays his "snd_alert1" and does stop and looks at the spot. He also plays a rampdown bark when returning to idle. I can't remember if he is supposed to play a "snd_alert1" if he is already at Alert 1 and then goes to Alert 2, though I would think probably not. |
|
|
I looked at the 1.03 and 1.06 code and there were alert1 barks when rising into Observant. But your note here: (http://forums.thedarkmod.com/topic/14857-searching-barks/page__view__findpost__p__312584) says there shouldn't be any. So I removed them. There's no code for checking what alert level the AI came from, only what alert level he stopped at. So a rule that says "don't play alert1 if he is already at Alert 1 and then goes to Alert 2" isn't being handled, nor is there anything similar in any of the other level arrivals. I tried to make the code match the picture (http://wiki.thedarkmod.com/index.php?title=AI_barks), but that picture doesn't show anything happening in Observant, unless the comment under the upper picture ("same for observant alert") means Observant is supposed to play snd_alert1 when arriving and snd_alertdown0 when going back down, same as Suspicious. But you're saying they're different: play snd_alert1 when arriving, and nothing when going back down. Should I put back the "rising into Observant" code? |
|
|
Was there anything in the original design docs about alert barks? Perhaps something the code and the picture were based on? Just looking at the 1.03 and 1.06 code for Observant shows obvious coding errors, and even then, it didn't agree with the picture. I'm assuming that I fixed these errors throughout the different levels over the past couple years. Perhaps I've inadvertently strayed from the original design, and it would be nice to see what that design was. |
|
|
If you're referring to this quote: "Observant, Suspicious, and Searching states should not have any barks while the AI is in that state. This seems like something that has recently changed. The AI should only say something when entering and leaving these states; neither idle nor alert idle barks are appropriate while they are in them." That only referred to idle or alert_idle barks while the AI is in Alert state 1 or higher. It wasn't meant to refer to "snd_alert1" barks that AI make when entering that state. "So a rule that says "don't play alert1 if he is already at Alert 1 and then goes to Alert 2" isn't being handled, nor is there anything similar in any of the other level arrivals." Fair enough. I couldn't remember how that was set up, although it would be a bit strange for an AI to say, "Hmm? What's the sound?" when entering Alert 1 and then "A noise?" two seconds later when entering Alert 2. But I've never heard AI do that, and come to think of it, that's probably covered by the grace period after alerts where AI don't register new alerts. I'll make an updated image that covers the way it was originally supposed to work, as that one does have a few errors. |
|
|
No, I was referring to "Observant->first bark->nothing". I'll review the updated picture when it's ready, and make the code follow that. |
|
|
I think I actually intended that to fall under "when alert level is descending", but I can see where the confusion came from; it's quite misleading either way. Ok, I've made a diagram that shows how it should work. I've included two new vocaldefs that weren't part of the original: "snd_alert4NoEvidence" is a new bark for AI entering agitated search without seeing any evidence of an intruder. "snd_state3" is a bark to be played while AI are in "searching" state, if they did not reach "agitated search" state. It's just some generic "Hmmms..." so that the AI isn't completely silent during that state. I have yet to upload that one to SVN but will shortly. http://www.mindplaces.com/save/darkmod_alertstates.jpg |
|
|
One problem jumps out at me in the picture. At the bottom of the leftmost 'To Alert4' column, it shows snd_alertdown0SeenNoEvidence being played when falling back to alert idle. AI don't return to alert idle when they've seen no evidence. They return to idle. |
|
|
The 'To Alert2' and 'To Alert3' columns need rampdown barks in the Alert Idle row. "Seen Evidence" is written in the code as "Has ever seen evidence". So an AI could have seen evidence in the past, but at the moment, he goes from Alert Idle up to Suspicious, then comes back down to Alert Idle. Since he's seen evidence in the past, and he's walking around in Alert Idle with his weapon out, he's going to say 'snd_alertdown0'. The new picture doesn't show that. |
|
|
"AI don't return to alert idle when they've seen no evidence. They return to idle." Ah, okay. I wasn't sure about that. "The 'To Alert2' and 'To Alert3' columns need rampdown barks in the Alert Idle row." Those columns are the same regardless of which kind of idle the AI is in. I looked into it, but we don't have any special barks for that case (AI going to minor alert after already in alert_idle), and none of the existing ones work. Does everything else seem reasonable? edit: I've updated the graphic |
|
|
Yes, the rest seems reasonable. When rising into Agitated Search, an AI won't bark anything if he: 1 - was hit by a moveable or projectile 2 - saw an enemy, and there's enough increased alert amount to rise into Agitated Search, but not enough to rise into Combat 3 - heard something suspicious 4 - was asked to join an existing search 5 - experienced a failed KO 6 - bumped an enemy Does all this still apply? |
|
|
The new picture indicates that when dropping from Agitated Searching to Searching, the repeated barks snd_state4SeenNoEvidence/snd_state4SeenEvidence should stop. (At least, that's how I read it.) Is that correct? snd_state3 is only played when the AI rises into Searching, not when he descends to it? |
|
|
"Is that correct? snd_state3 is only played when the AI rises into Searching, not when he descends to it? " Right. If he went into agitated search, it's still appropriate for him to make snd_state4 barks as long as he's searching, even when his search ramps down to state3. When it drops below state3, he stops making those barks. The barks don't stop until he LEAVES state3 though, just in case that's not clear. If he ascends to state3 and no higher, then he plays snd_state3 for the duration of that state. At least, that's what I was thinking at the time I made the graphic. I guess now that we're adding a snd_state3, it might also make sense to use that when descending....what do you think? "When rising into Agitated Search, an AI won't bark anything if he:" I assume by 'anything' you just mean the barks on the graphic, not that AI don't say anything at all when hit by movable objects or hit by failed KOs? I don't quite understand 2 or 3. What happens in 6? Do they not say anything at all? Shouldn't the go straight to combat if they bump into the player? |
|
|
"At least, that's what I was thinking at the time I made the graphic. I guess now that we're adding a snd_state3, it might also make sense to use that when descending....what do you think?" How different are the state3 barks from the state4 barks? Do they make sense after conducting an armed search? If the AI hasn't seen evidence when he drops into Searching, he'll sheathe his weapon. Will state4NoSeenEvidence still be appropriate in that case? Answering these should help decide whether to play state3 or state4 when dropping from AS to S. "I assume by 'anything' you just mean the barks on the graphic, not that AI don't say anything at all when hit by movable objects or hit by failed KOs?" Yes, just the ramp up and ramp down barks. "I don't quite understand 2 or 3." 2 happens each time the AI gets a hit on an enemy. It takes a few hits before he rises to Combat State. I don't know the original design behind not having him bark anything as he passes through Agitated Search. 3 happens on all audio alerts. "What happens in 6? Do they not say anything at all? Shouldn't the go straight to combat if they bump into the player?" I don't think they go straight to combat. They turn toward you, and that probably allows them to see they bumped an enemy. I'm not going to try to follow that quite complicated thread atm to see where it goes; probably best to test it and see if the barks make sense. |
|
|
The state4 barks are all talking to the player: "Hey, come out where I can see you." The state3 barks are simple "Hmm..."s as if trying to figure out what they saw/heard. They're quite different. Both options have plusses and minuses. It might sound a bit odd for AI to put away their sword but say something like, "When I find you, I'm going to hurt you." On the other hand, there is not much variety in the snd_state3 barks...often only two or three different "Hmms", so they could get repetitive if they get heard a lot. Unless you have a preference, I'd just go with whichever option is easiest for you to set up. I'll modify the graphic appropriately. "2 happens each time the AI gets a hit on an enemy. It takes a few hits before he rises to Combat State. I don't know the original design behind not having him bark anything as he passes through Agitated Search." I still don't quite understand...what is the difference between what you describe and just regular old spotting the player enough to go into agitated searching? "3 happens on all audio alerts." Are you saying audio alerts can't send an AI to alert 4?? |
|
|
Currently, Searching will play Agitated Searching barks when dropping from AS to S. So I'll leave it that way unless testing says only alert3 barks should be played in Searching. Crap. I reread the code and I had it backward. You can ignore that list of 6 conditions above. Sorry. |
|
|
A question about Suspicious state. Regardless of whether the AI is rising into it or dropping into it, there's a 50% chance he will stop moving, then turn toward the alert spot if it's not in his FOV. Was this the original intent? I checked 1.03 and it was the same way back then. Whether he stops or not, he'll look at the alert spot if it's in his FOV. |
|
|
I didn't realize it was a 50% chance. I thought they stopped automatically in Alert 2, which is the only thing that differentiates that state from Alert 1. I'm not sure of the reason for that. |
|
|
I checked in the changes we've been discussing. Try it for a while and see if it makes more sense now. The only two things left open are: 1 - Should the AI bark snd_alert1 when he rises to Observant, then bark snd_alert1 again when he rises to Suspicious, which might happen soon after? 2 - Should we retain the 50% chance of stopping in Suspicious, mentioned above? My opinion is we should drop it, to make Suspicious and Observant more different. ------------------ Made ramp up and ramp down barks match Springheel’s new picture of what should happen as an AI moves around in the alert levels. Rev. 5821: ObservantState.cpp SearchingState.cpp IdleState.cpp AlertIdleState.cpp Combat.cpp AgitatedSearchingState.cpp SuspiciousState.cpp LostTrackOfEnemyState.cpp |
|
|
I'm with you on 2. Will test and keep any eye on 1. |
|
|
I've been testing a little bit...when tdm_showsprop is on, there are numbers above the AI like: Volume: 19.11 Alert: 1.22 do you know what the "Alert" number means? Is it supposed to correspond to the Alert state? |
|
|
No, those are things I added so we would be more like Thief4. :) "Alert" is the amount that sound is adding to the AI's alert level. |
|
|
Lol! Do you know of a console command that will show me the AI's current alert state? |
|
|
seta tdm_ai_showalert "1" |
|
|
Thanks. I've been testing with that on for a few minutes; helps tremendously see what's going on. One thing I noticed is that the AI made a snd_alert3 bark when _descending_ into alert3 from alert4. That shouldn't happen. The new snd_state3 barks sound pretty good. |
|
|
snd_alert3 when descending eliminated. Update your SVN. |
|
|
The latest update has introduced something odd. The AI does not stop his patrol when entering alert state 3. He continues on his patrol route, but his body 'jerks' every so often as if he's attempting to walk somewhere else, but then a frame later gets told to continue his patrol. This didn't happen when I was testing before the update. Is there still only a 50% chance of him stopping when at alert 2? |
|
|
Yes, I forgot about that. I'll remove that now, and we'll see if that stops the jerks. |
|
|
Done. Update your SVN. |
|
|
Rats. The jerking is probably caused by my 'snd_alert3' change above. Update to rev 13541 and that should be fixed. |
|
|
There's a slight improvement...when he descends to alert 2, he stops and stands. But while he's in alert 3 he continues to patrol, though he stops for half a second along the way once or twice. edit: oh, ninja'd |
|
|
I'm moving too quickly for my own good. :) |
|
|
Ok, with the latest revision, I just did a single test, but everything went the way it was supposed to*. AI came running over and searched when he hit alert3. And when he descended into alert 3 there was no bark. Looked good. * unrelated issue, but he made a "snd_alert3hc" bark even though he was alone...I'll have to see if there's a wrong vocal file somewhere. |
|
|
He'll bark the 'company' sounds if he last saw a friend less than 10 seconds ago. |
|
|
Did another ten minutes of testing, and everything seems bang on now. Not sure what caused the "hc" bark above, but it hasn't happened again. I'll more testing in real game conditions tomorrow. edit: Any reason it's that high? Seems like an AI could get quite far away in that time--most of the barks assume the friend is right there; it would be odd for an AI to say "shh, do you hear that?" after passing a friend ten seconds ago. |
|
|
This seems to be working properly now; can be further tested by 2.0 testers. |
|
|
"Any reason it's that high? Seems like an AI could get quite far away in that time--most of the barks assume the friend is right there; it would be odd for an AI to say "shh, do you hear that?" after passing a friend ten seconds ago." Let me know what you want to drop it to. I don't know why it's set for 10s. It's probably done by 'last time I saw a friend' rather than looking around for a friend because the latter consumes CPU. |
|
|
I added this line to tdm_ai_vocal_set_base.def: "prio_state3" "25" I was getting "priority not found for snd_state3". Please change it if it's not at the correct level. I've had to do this from time to time, so you might want to add a step in your "how to submit sounds" notes to provide a priority setting when checking in new sounds. When no priority is set, a default of -1 is used, which puts it below anything else the AI is barking. You'll hear it, but only after other higher priority barks are finished. |
|
|
"you might want to add a step in your "how to submit sounds" notes" Yes, sorry, I keep forgetting about that step. "Let me know what you want to drop it to. " Maybe try 5...? I realize that could mean AI don't use company barks because they've been facing a different way for 5 seconds, but it's better to have them not use a company bark when other AI are around then have them use one when there isn't, I think. |
|
|
New Windows DLL checked in to change the time from 10s to 5s. |
|
|
I'm fixing a couple bugs. 1 - When I added back the ramp up alert barks to Observant, I forgot to check for whether the AI is asleep. I had a sleeper barking alerts w/o waking up. 2 - When an AI hears a sound, he will at least look toward that sound if he doesn't search the source. I wasn't checking for sleepers again, and the same sleeper was jerking his head around each time I made a sound. 3 - When I was near an AI, but in the dark, I made a sound and he heard me, and barked snd_alert1h. But when he ramped down, he said something about the shadows and needing more light, which didn't sound right. I checked the console log and, sure enough, his rampdown bark was snd_alertdown0s. What happened was that before he heard my sound, his "check for an enemy" code spotted me standing near him, which is a visual alert. The alert rise wasn't enough for him to react to me or consider me an enemy, so I was ignorant of the fact that he received a visual alert. When he later heard me, it didn't override the visual alert type with a hearing alert type (which is the correct behavior), which caused him to bark the visual ramp down. So I'm looking into allowing the alert rise for those times an AI spots the player (but not yet enough to go to combat), but NOT registering it as a visual alert until the AI enters combat and says, "Aha! You're an enemy!" This might get a little tricky, because I have to look at the ramp up barks he makes as he's spotting the player, leading up to combat mode. I want those to still be relevant sight barks. |
|
|
I'm curious about something. Why are alert barks only emitted when an AI rises to a new state? Shouldn't alerting events be barked about on their own merit, rather than depending on alert levels? What happens if an alert pushes an AI up into Searching state and he barks something, then another alert arrives that isn't strong enough to push him up into Agitated Search? Currently the AI barks nothing about that new alert, because he didn't rise into a new state. |
|
|
Dammit. Had a nice long reply and got eaten because the page sat open too long. Quick answer: Don't know, but the existing barks might not suit being played at every alert..."Alright, who's that there?" followed ten seconds later by "Was that a noise?" might sound wrong. |
|
|
What's preferable in these instances ... 1 - Guard hears something and goes up to Searching, barking snd_alert3h when he gets there. He drops back to Suspicious, then sees something that pushes him back up to Searching, barking snd_alert3s when he gets there. When he drops back to Idle, does he bark snd_alertdown0h or snd_alertdown0s? 2 - Guard sees something and goes up to Searching, barking snd_alert3s when he gets there. He drops back to Suspicious, then hears something that pushes him back up to Searching, barking snd_alert3h when he gets there. When he drops back to Idle, does he bark snd_alertdown0h or snd_alertdown0s? |
|
|
1. snd_alertdown0s 2. snd_alertdown0h My opinion would be that his rampdown bark should match whatever bark he gave last. edit: I logged this yesterday...is it already fixed by your changes? http://bugs.thedarkmod.com/view.php?id=3487 |
|
|
Yes, 0003487 is already fixed. When I put the rampup barks back into Observant, I forgot to include the check for sleepers. If you've noticed sleepers jerking their heads in response to noises, that's fixed too. |
|
|
More changes checked in: 1 - Allow audio alerts to override visual alerts for dead and unconscious bodies. The correct rampdown bark will still be heard, though, because what's important is that the AI rose to Agitated Searching, not that he heard or saw something. 2 - Turn off Observant alert bark when AI is asleep. 3 - Turn off "looking at alert origin" when AI is asleep. 4 - Turn off repeated barks when rising to Combat from Agitated Search or Searching. 5 - The math for "last time I saw a friendly AI" wasn't correct during the first 5s of the mission, making AI think they saw a friend even if they were alone. Fixed. |
|
|
Had one report that might be related: I threw a candle to the floor, the proguard turned and said "what was that sound?" Then later he relaxed and said "Maybe it was just a shadow." Noise making shadow? (Okay, very mild cosmetic problem. Still, wanted to report it.) |
|
|
What's happening is that a sound alerts the AI, he barks about sound, and if something visual alerts him before he ramps down, he's going to emit a visual rampdown bark because the visual was the most recent thing that happened to him. We as the observer can share hearing a sound with him, but we might not be able to share seeing something visual. So, while he thinks he saw something, and barks about it when he ramps down, we don't share that. We think he should say something about sound, because that's what we shared with him. The only way to correct that is to try to match rampup and rampdown barks. If his most recent rampup bark is about sound, then he should give a rampdown bark about sound, even if he had a visual alert in between. If he should bark about seeing the visual alert after barking about the sound alert, then we'd have him emit a visual rampdown bark when he comes down. 2.01 work. |
|
|
Gotcha. |
|
|
Another thing I've noticed three times now. I alert AI to Suspicious in an area where I have put out some lights. AI gives alert bark, stands looking around. AI drops to idle, gives alertdown_to_idle bark within 1-2 seconds, AI gives a notice_lights_out a second later, he gives another alertdown_to_idle bark I don't know why he's giving a second alertdown_to_idle bark. He's not searching around the light. I haven't been able to catch this with showbark on yet to see exactly which bark the last one is. |
|
|
If he spotted a doused shouldBeOn/{1,2} light, it probably drove his alert level to Suspicious, so he's going to issue a rampdown bark when he comes down again. Edit: No, that's not right. Even though the evidence count goes up right away, the alert level doesn't go up until after he's relit the light. Which sounds like a bug. I would think an alert level could go up regardless of whether he relights it or not. This is how I originally wrote it, but my fix to 0003438 moved the alert level change to after the relight. Can't remember what I was thinking at the time I made the change. Didn't leave enough comments behind. |
|
|
Ok, I was just able to reproduce it with showbark on. (in Special Delivery, I walked down the street until reaching the dead end with the candle) The AI spotted me putting out a candle. He went to level 4 alert, searched around, then eventually gave his rampdown bark. He immediately gave a "snd_foundTorchOut" bark as he walked away, then immediately after that gave a "snd_alertdown0SeenNoEvidence" bark. edit: Just did it again, in the same spot. This time the ai went to Level 4 and gave his "snd_state4SeenEvidence" bark while searching. When he was done, he played his "snd_alertdown0SeenEvidence" bark, immediately gave a "snd_foundTorchOut" bark, then immediately another "snd_alertdown0SeenEvidence" . This only seems to happen after they notice a light out during a search. edit: Opened the map; the candle has no special setting on it. |
|
|
This question might sound irrelevant, but it's important to straightening out some confusion wrt how high an AI's alert level has gone: We made a change a while back so that, when coming down from an alert level of Searching or higher, an AI won't greet anyone for a short while. The reasoning was that greetings tend to be upbeat, and don't sound right coming from someone who just completed a search. Was the intent that this delay happen if the AI EVER was in Searching or higher, or just that he was RECENTLY in Searching or higher? RECENTLY means he was in Idle, went up to Searching or higher, and dropped back to idle. |
|
|
I'm having a difficult time reproducing this. Either the guard never gets interested in me, or he's killing me. Me getting him to stop in Level 4 doesn't seem to be in the cards. I can make a change so that he doesn't say the second "snd_alertdown0SeenEvidence", but the question for me is why he rose up out of IdleAlert just because of the light. He shouldn't add to his alert level until after he's relit the light, and he didn't do that. The only thing I can think of is that he's still seeing you in low light; not enough to rise back to Level 4, but enough to bump him out of IdleAlert. |
|
|
I changed the code so that emitting "snd_alertdown0Seen{No}Evidence" is done on an episode-by-episode basis. An episode is a rise from Level 0 to Level 4, and back down again. The code was saying that if the AI was EVER at Level 4, he should use those rampdown barks. I think it should be that he emits them per episode. Otherwise, he could come down from Level 4, hear a sound and go back up to Level 2, and again emit "snd_alertdown0Seen{No}Evidence" when he ramps down. He should be barking about having heard a sound. I think that's what's happening in your situation. The guard must be spotting you enough to push him up into Level 3 or 4, and he says something about the light being out (which doesn't change his alert level), then gives the wrong rampdown bark. |
|
|
"Was the intent that this delay happen if the AI EVER was in Searching or higher, or just that he was RECENTLY in Searching or higher? RECENTLY means he was in Idle, went up to Searching or higher, and dropped back to idle." Recently. It's okay for him to greet people later on. "I'm having a difficult time reproducing this. Either the guard never gets interested in me, or he's killing me. Me getting him to stop in Level 4 doesn't seem to be in the cards." I don't think he has to be at Level 4...the first time I noticed it the AI had only been at Level 2. "The only thing I can think of is that he's still seeing you in low light; not enough to rise back to Level 4, but enough to bump him out of IdleAlert." He's not seeing me in the example I posted above. Nor did I see any evidence that his alert level was going up...it appeared to drop normally until he gave his first rampdown bark. I'll see if I can reproduce it and watch for any adjustment to his alertlevel between the two rampdown barks. |
|
|
Just tried 10 times to recreate the scenario above, using the same saved game I was using last night, and couldn't get it to happen again. Go figure. |
|
|
Further changes: Clear the “most recent high alert level” when ramping down to Idle or Alert Idle. Rev. 5861: AI.cpp AI.h AlertIdleState.cpp IdleState.cpp State.cpp |
|
|
"I think it should be that he emits them per episode. Otherwise, he could come down from Level 4, hear a sound and go back up to Level 2, and again emit "snd_alertdown0Seen{No}Evidence" when he ramps down. He should be barking about having heard a sound." I missed this the first time, but I totally agree. |
|
|
"AI gives alert bark, stands looking around. AI drops to idle, gives alertdown_to_idle bark within 1-2 seconds, AI gives a notice_lights_out a second later, he gives another alertdown_to_idle bark" I had this happen again while playing in Old Habits II. I had a guard spot me enough to go to Alert 2. He stood looking in my direction after I darted back in the shadows, then said his rampdown bark, then commented about a light being out, then gave another rampdown bark. There was only a second or so between each bark. Don't think this is serious enough to fix for 2.0, but wanted to record it. |
|
|
I'd need a savegame just before the event to work on this. There's no sequence of events I can think of that would cause this to happen. For an AI's alert level to go up due to a doused light, he would have to relight the light. AI that don't relight lights don't drive up their alert level. They do bump the evidence count regardless, but they would have to have seen a few other doused lights prior to this for it to matter. I'd have to see when he saw the doused light, when he saw you, when he emitted each rampdown bark, what his alert level did during the event, what his evidence count was, which light caused the problem, and which barks were emitted. And also what other AI were around, and whether any of them used the same voice set. |
|
|
The lights issue above, and the bit below, are 2.01 work, so I'm going to move this to that project. "The only way to correct that is to try to match rampup and rampdown barks. If his most recent rampup bark is about sound, then he should give a rampdown bark about sound, even if he had a visual alert in between. If he should bark about seeing the visual alert after barking about the sound alert, then we'd have him emit a visual rampdown bark when he comes down." |
|
|
I'm moving this to 2.02. The amount of work that might be needed is too much for a shortened 2.01 release schedule. |
|
|
I'm taking this off the 2.02 Roadmap. I'm at the point with this rampup/rampdown bark business that I'll need a repeatable test case that fails before going back in again. Redesigning the alert system and accompanying barks--even something as seemingly simple as pairing "going up" with "coming down"--is not something that's going to get done in 2.02's timeframe. |
 |
Unable to reproduce. No recent reports. |
- Anonymous
