View Issue Details

IDProjectCategoryView StatusLast Update
0003472The Dark ModAIpublic15.12.2018 05:18
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionunable to reproduce 
Product VersionTDM 2.00 
Target VersionTDM 2.07Fixed in VersionTDM 2.07 
Summary0003472: AI playing wrong rampdown bark
DescriptionI was testing in Fiasco, and had an AI bump into me, which sent me running through a crowd of AI. I turned a corner and hid in a shadow. One of the AI came around with his sword drawn, searching for me. When he was done searching, he said, "Must have been a rat."

I then stepped into the light and let an archer see me long enough for him to take a shot at me. I then dropped a flashbomb and hid. He came over and did an agitated search for a while, and then said, "I guess it was nothing."

Both AI were in agitated search state (swords out) so they should not be playing "snd_alertdown0" when ramping down.

TagsNo tags attached.

Relationships

has duplicate 0003445 resolvedgrayman AI goes into alert_idle because of rats. 

Activities

grayman

grayman

03.07.2013 22:03

administrator   ~0005629

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

grayman

03.07.2013 22:28

administrator   ~0005630

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

Springheel

04.07.2013 00:15

administrator   ~0005631

Last edited: 04.07.2013 00:15

View 2 revisions

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

Springheel

Springheel

04.07.2013 00:25

administrator   ~0005632

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

grayman

05.07.2013 18:11

administrator   ~0005636

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

Springheel

06.07.2013 21:58

administrator   ~0005650

So far so good.
Springheel

Springheel

09.07.2013 00:46

administrator   ~0005664

Last edited: 09.07.2013 00:50

View 3 revisions

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.

grayman

grayman

09.07.2013 01:54

administrator   ~0005665

Last edited: 09.07.2013 01:55

View 2 revisions

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.

Springheel

Springheel

09.07.2013 02:02

administrator   ~0005666

Last edited: 09.07.2013 02:16

View 8 revisions

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.

Springheel

Springheel

09.07.2013 02:20

administrator   ~0005667

Last edited: 09.07.2013 02:29

View 5 revisions

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

grayman

grayman

09.07.2013 03:28

administrator   ~0005668

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

Springheel

09.07.2013 11:09

administrator   ~0005669

Last edited: 09.07.2013 11:15

View 2 revisions

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.

grayman

grayman

09.07.2013 13:54

administrator   ~0005670

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

grayman

09.07.2013 13:59

administrator   ~0005671

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

Springheel

09.07.2013 14:47

administrator   ~0005672

Last edited: 09.07.2013 15:09

View 2 revisions

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.

grayman

grayman

09.07.2013 15:17

administrator   ~0005673

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

Springheel

09.07.2013 16:07

administrator   ~0005674

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
grayman

grayman

09.07.2013 16:31

administrator   ~0005675

Last edited: 09.07.2013 16:32

View 2 revisions

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.

grayman

grayman

09.07.2013 16:48

administrator   ~0005676

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

Springheel

09.07.2013 17:11

administrator   ~0005677

Last edited: 09.07.2013 17:17

View 3 revisions

"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

grayman

grayman

09.07.2013 18:40

administrator   ~0005678

Last edited: 09.07.2013 18:42

View 2 revisions

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?

grayman

grayman

09.07.2013 19:18

administrator   ~0005679

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

Springheel

09.07.2013 20:02

administrator   ~0005680

Last edited: 09.07.2013 20:13

View 4 revisions

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

grayman

grayman

09.07.2013 21:04

administrator   ~0005681

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

Springheel

09.07.2013 23:56

administrator   ~0005682

Last edited: 10.07.2013 00:00

View 4 revisions

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

grayman

grayman

10.07.2013 01:14

administrator   ~0005683

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

grayman

10.07.2013 01:36

administrator   ~0005684

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

Springheel

10.07.2013 12:08

administrator   ~0005685

Last edited: 10.07.2013 12:11

View 2 revisions

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.

grayman

grayman

10.07.2013 14:22

administrator   ~0005686

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
Springheel

Springheel

10.07.2013 14:25

administrator   ~0005687

I'm with you on 2.

Will test and keep any eye on 1.
Springheel

Springheel

10.07.2013 21:18

administrator   ~0005689

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

grayman

10.07.2013 21:33

administrator   ~0005690

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

Springheel

10.07.2013 23:07

administrator   ~0005691

Lol!

Do you know of a console command that will show me the AI's current alert state?
grayman

grayman

10.07.2013 23:09

administrator   ~0005692

seta tdm_ai_showalert "1"
Springheel

Springheel

10.07.2013 23:17

administrator   ~0005693

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

grayman

10.07.2013 23:37

administrator   ~0005694

snd_alert3 when descending eliminated. Update your SVN.
Springheel

Springheel

11.07.2013 00:17

administrator   ~0005695

Last edited: 11.07.2013 00:18

View 2 revisions

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?

grayman

grayman

11.07.2013 00:25

administrator   ~0005697

Yes, I forgot about that. I'll remove that now, and we'll see if that stops the jerks.
grayman

grayman

11.07.2013 00:30

administrator   ~0005698

Done. Update your SVN.
grayman

grayman

11.07.2013 00:36

administrator   ~0005699

Rats. The jerking is probably caused by my 'snd_alert3' change above.

Update to rev 13541 and that should be fixed.
Springheel

Springheel

11.07.2013 00:36

administrator   ~0005700

Last edited: 11.07.2013 00:37

View 2 revisions

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

grayman

grayman

11.07.2013 00:38

administrator   ~0005701

I'm moving too quickly for my own good. :)
Springheel

Springheel

11.07.2013 00:42

administrator   ~0005702

Last edited: 11.07.2013 00:54

View 3 revisions

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.

grayman

grayman

11.07.2013 01:05

administrator   ~0005703

He'll bark the 'company' sounds if he last saw a friend less than 10 seconds ago.
Springheel

Springheel

11.07.2013 01:06

administrator   ~0005704

Last edited: 11.07.2013 01:09

View 2 revisions

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.

Springheel

Springheel

13.07.2013 23:51

administrator   ~0005715

This seems to be working properly now; can be further tested by 2.0 testers.
grayman

grayman

13.07.2013 23:59

administrator   ~0005716

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

grayman

14.07.2013 15:35

administrator   ~0005725

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

Springheel

14.07.2013 16:28

administrator   ~0005726

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

grayman

15.07.2013 15:00

administrator   ~0005733

New Windows DLL checked in to change the time from 10s to 5s.
grayman

grayman

16.07.2013 04:27

administrator   ~0005737

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

grayman

16.07.2013 17:17

administrator   ~0005738

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

Springheel

16.07.2013 18:41

administrator   ~0005739

Last edited: 16.07.2013 18:41

View 2 revisions

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.

grayman

grayman

16.07.2013 19:11

administrator   ~0005740

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

Springheel

16.07.2013 23:50

administrator   ~0005741

Last edited: 17.07.2013 01:52

View 3 revisions

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

grayman

grayman

17.07.2013 17:31

administrator   ~0005746

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

grayman

17.07.2013 19:08

administrator   ~0005750

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

Springheel

11.08.2013 13:21

administrator   ~0005999

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

grayman

11.08.2013 13:54

administrator   ~0006000

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

Springheel

11.08.2013 14:00

administrator   ~0006002

Gotcha.
Springheel

Springheel

15.08.2013 23:44

administrator   ~0006028

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

grayman

16.08.2013 18:25

administrator   ~0006029

Last edited: 16.08.2013 18:30

View 2 revisions

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.

Springheel

Springheel

17.08.2013 01:29

administrator   ~0006031

Last edited: 17.08.2013 01:38

View 5 revisions

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.

grayman

grayman

17.08.2013 13:31

administrator   ~0006032

Last edited: 17.08.2013 13:32

View 2 revisions

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.

grayman

grayman

17.08.2013 13:57

administrator   ~0006033

Last edited: 17.08.2013 13:57

View 2 revisions

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.

grayman

grayman

17.08.2013 20:14

administrator   ~0006035

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

Springheel

17.08.2013 20:17

administrator   ~0006036

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

Springheel

17.08.2013 20:26

administrator   ~0006037

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

grayman

17.08.2013 23:33

administrator   ~0006040

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
Springheel

Springheel

18.08.2013 13:46

administrator   ~0006045

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

Springheel

04.09.2013 01:07

administrator   ~0006149

Last edited: 04.09.2013 01:08

View 2 revisions

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

grayman

grayman

04.09.2013 01:49

administrator   ~0006150

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

Springheel

10.09.2013 21:43

administrator   ~0006175

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

grayman

23.11.2013 16:34

administrator   ~0006265

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

grayman

06.04.2014 18:52

administrator   ~0006507

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

nbohr1more

15.12.2018 05:17

developer   ~0010925

Unable to reproduce.

No recent reports.

Issue History

Date Modified Username Field Change
03.07.2013 20:21 Springheel New Issue
03.07.2013 20:21 Springheel Status new => assigned
03.07.2013 20:21 Springheel Assigned To => grayman
03.07.2013 22:03 grayman Note Added: 0005629
03.07.2013 22:28 grayman Note Added: 0005630
04.07.2013 00:15 Springheel Note Added: 0005631
04.07.2013 00:15 Springheel Note Edited: 0005631 View Revisions
04.07.2013 00:25 Springheel Note Added: 0005632
05.07.2013 18:11 grayman Note Added: 0005636
06.07.2013 02:30 Springheel Relationship added has duplicate 0003445
06.07.2013 21:58 Springheel Note Added: 0005650
06.07.2013 21:58 Springheel Status assigned => feedback
09.07.2013 00:46 Springheel Note Added: 0005664
09.07.2013 00:46 Springheel Status feedback => assigned
09.07.2013 00:46 Springheel Note Edited: 0005664 View Revisions
09.07.2013 00:50 Springheel Note Edited: 0005664 View Revisions
09.07.2013 01:54 grayman Note Added: 0005665
09.07.2013 01:55 grayman Note Edited: 0005665 View Revisions
09.07.2013 02:02 Springheel Note Added: 0005666
09.07.2013 02:03 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:04 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:06 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:09 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:09 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:12 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:16 Springheel Note Edited: 0005666 View Revisions
09.07.2013 02:20 Springheel Note Added: 0005667
09.07.2013 02:21 Springheel Note Edited: 0005667 View Revisions
09.07.2013 02:25 Springheel Note Edited: 0005667 View Revisions
09.07.2013 02:26 Springheel Note Edited: 0005667 View Revisions
09.07.2013 02:29 Springheel Note Edited: 0005667 View Revisions
09.07.2013 03:28 grayman Note Added: 0005668
09.07.2013 11:09 Springheel Note Added: 0005669
09.07.2013 11:15 Springheel Note Edited: 0005669 View Revisions
09.07.2013 13:54 grayman Note Added: 0005670
09.07.2013 13:59 grayman Note Added: 0005671
09.07.2013 14:47 Springheel Note Added: 0005672
09.07.2013 15:09 Springheel Note Edited: 0005672 View Revisions
09.07.2013 15:17 grayman Note Added: 0005673
09.07.2013 16:07 Springheel Note Added: 0005674
09.07.2013 16:31 grayman Note Added: 0005675
09.07.2013 16:32 grayman Note Edited: 0005675 View Revisions
09.07.2013 16:48 grayman Note Added: 0005676
09.07.2013 17:11 Springheel Note Added: 0005677
09.07.2013 17:11 Springheel Note Edited: 0005677 View Revisions
09.07.2013 17:17 Springheel Note Edited: 0005677 View Revisions
09.07.2013 18:40 grayman Note Added: 0005678
09.07.2013 18:42 grayman Note Edited: 0005678 View Revisions
09.07.2013 19:18 grayman Note Added: 0005679
09.07.2013 20:02 Springheel Note Added: 0005680
09.07.2013 20:03 Springheel Note Edited: 0005680 View Revisions
09.07.2013 20:04 Springheel Note Edited: 0005680 View Revisions
09.07.2013 20:13 Springheel Note Edited: 0005680 View Revisions
09.07.2013 21:04 grayman Note Added: 0005681
09.07.2013 23:56 Springheel Note Added: 0005682
09.07.2013 23:58 Springheel Note Edited: 0005682 View Revisions
10.07.2013 00:00 Springheel Note Edited: 0005682 View Revisions
10.07.2013 00:00 Springheel Note Edited: 0005682 View Revisions
10.07.2013 01:14 grayman Note Added: 0005683
10.07.2013 01:36 grayman Note Added: 0005684
10.07.2013 12:08 Springheel Note Added: 0005685
10.07.2013 12:11 Springheel Note Edited: 0005685 View Revisions
10.07.2013 14:22 grayman Note Added: 0005686
10.07.2013 14:22 grayman Status assigned => feedback
10.07.2013 14:22 grayman Target Version => TDM 2.00
10.07.2013 14:25 Springheel Note Added: 0005687
10.07.2013 14:25 Springheel Status feedback => assigned
10.07.2013 21:18 Springheel Note Added: 0005689
10.07.2013 21:33 grayman Note Added: 0005690
10.07.2013 23:07 Springheel Note Added: 0005691
10.07.2013 23:09 grayman Note Added: 0005692
10.07.2013 23:17 Springheel Note Added: 0005693
10.07.2013 23:37 grayman Note Added: 0005694
11.07.2013 00:17 Springheel Note Added: 0005695
11.07.2013 00:18 Springheel Note Edited: 0005695 View Revisions
11.07.2013 00:25 grayman Note Added: 0005697
11.07.2013 00:30 grayman Note Added: 0005698
11.07.2013 00:36 grayman Note Added: 0005699
11.07.2013 00:36 Springheel Note Added: 0005700
11.07.2013 00:37 Springheel Note Edited: 0005700 View Revisions
11.07.2013 00:38 grayman Note Added: 0005701
11.07.2013 00:42 Springheel Note Added: 0005702
11.07.2013 00:54 Springheel Note Edited: 0005702 View Revisions
11.07.2013 00:54 Springheel Note Edited: 0005702 View Revisions
11.07.2013 01:05 grayman Note Added: 0005703
11.07.2013 01:06 Springheel Note Added: 0005704
11.07.2013 01:09 Springheel Note Edited: 0005704 View Revisions
13.07.2013 23:51 Springheel Note Added: 0005715
13.07.2013 23:51 Springheel Status assigned => feedback
13.07.2013 23:59 grayman Note Added: 0005716
14.07.2013 15:35 grayman Note Added: 0005725
14.07.2013 16:28 Springheel Note Added: 0005726
14.07.2013 16:28 Springheel Status feedback => assigned
15.07.2013 15:00 grayman Note Added: 0005733
16.07.2013 04:27 grayman Note Added: 0005737
16.07.2013 17:17 grayman Note Added: 0005738
16.07.2013 18:41 Springheel Note Added: 0005739
16.07.2013 18:41 Springheel Note Edited: 0005739 View Revisions
16.07.2013 19:11 grayman Note Added: 0005740
16.07.2013 23:50 Springheel Note Added: 0005741
17.07.2013 01:52 Springheel Note Edited: 0005741 View Revisions
17.07.2013 01:52 Springheel Note Edited: 0005741 View Revisions
17.07.2013 17:31 grayman Note Added: 0005746
17.07.2013 19:08 grayman Note Added: 0005750
21.07.2013 14:42 Springheel Status assigned => feedback
11.08.2013 13:21 Springheel Note Added: 0005999
11.08.2013 13:21 Springheel Status feedback => assigned
11.08.2013 13:54 grayman Note Added: 0006000
11.08.2013 14:00 Springheel Note Added: 0006002
13.08.2013 01:42 grayman Status assigned => feedback
15.08.2013 23:44 Springheel Note Added: 0006028
15.08.2013 23:44 Springheel Status feedback => assigned
16.08.2013 18:25 grayman Note Added: 0006029
16.08.2013 18:30 grayman Note Edited: 0006029 View Revisions
17.08.2013 01:29 Springheel Note Added: 0006031
17.08.2013 01:29 Springheel Note Edited: 0006031 View Revisions
17.08.2013 01:30 Springheel Note Edited: 0006031 View Revisions
17.08.2013 01:36 Springheel Note Edited: 0006031 View Revisions
17.08.2013 01:38 Springheel Note Edited: 0006031 View Revisions
17.08.2013 13:31 grayman Note Added: 0006032
17.08.2013 13:32 grayman Note Edited: 0006032 View Revisions
17.08.2013 13:57 grayman Note Added: 0006033
17.08.2013 13:57 grayman Note Edited: 0006033 View Revisions
17.08.2013 20:14 grayman Note Added: 0006035
17.08.2013 20:17 Springheel Note Added: 0006036
17.08.2013 20:26 Springheel Note Added: 0006037
17.08.2013 23:33 grayman Note Added: 0006040
18.08.2013 13:46 Springheel Note Added: 0006045
19.08.2013 10:30 grayman Status assigned => feedback
04.09.2013 01:07 Springheel Note Added: 0006149
04.09.2013 01:07 Springheel Status feedback => assigned
04.09.2013 01:08 Springheel Note Edited: 0006149 View Revisions
04.09.2013 01:49 grayman Note Added: 0006150
10.09.2013 21:43 Springheel Note Added: 0006175
10.09.2013 21:43 Springheel Target Version TDM 2.00 => TDM 2.01
23.11.2013 16:34 grayman Note Added: 0006265
23.11.2013 16:34 grayman Target Version TDM 2.01 => TDM 2.02
06.04.2014 18:52 grayman Note Added: 0006507
06.04.2014 18:52 grayman Target Version TDM 2.02 =>
24.11.2017 16:36 grayman Assigned To grayman =>
24.11.2017 16:36 grayman Status assigned => new
15.12.2018 05:17 nbohr1more Note Added: 0010925
15.12.2018 05:18 nbohr1more Assigned To => grayman
15.12.2018 05:18 nbohr1more Status new => resolved
15.12.2018 05:18 nbohr1more Resolution open => unable to reproduce
15.12.2018 05:18 nbohr1more Fixed in Version => TDM 2.07
15.12.2018 05:18 nbohr1more Target Version => TDM 2.07