View Issue Details

IDProjectCategoryView StatusLast Update
0002282The Dark ModAIpublic27.10.2011 05:16
Reportersotha_sil Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status closedResolutionfixed 
PlatformWin32OSWindowsOS VersionXP
Product VersionTDM 1.02 
Target VersionTDM 1.04Fixed in VersionTDM 1.04 
Summary0002282: Initially sitting AI's sit on air after relaxing from a disturbance
DescriptionSituation:
*A chair with path_corner, path_turn and a path_sit (wait 30, wait_max 60)
*A path_corner away from the chair.
*An AI which patrols the route to (away from chair)->(path_corner next to chair)->(path_turn)->(path_sit)-> (away from chair)

This works nicely. The AI walks to the chair, sits down, raises up after a while, walks to (away from the chair) and repeats this.

Now, if there is a disturbance while the AI is seated, the AI looks for trouble. Once the AI relaxes from the disturbance, he simply sits in midair at the position he is currently located. After a while he continues with his patrol route.

This occurs every time the AI is harrassed while seated.
A test map is provided, in which you can alert the AI with a noisemaker arrow as soon as he sits down.
TagsNo tags attached.
Attached Files
sit.map (6,588 bytes)

Activities

tels

tels

04.08.2010 06:03

reporter   ~0003164

This seems to be a general bug. If you have an AI doing something on a path_node (like turning) and disturb him, he will repeat his path_node turning actions without going first back to his original position. Instead he will simply repeat the action where he comes out of the alert.

Happened to me in No Honor Amongst Thieves with the guard turning in the tunnel. After disturbing him he stood under a bright light, turning there from now and then, making it almost impossible later to get by him - had to distract him again with sound to lure him away.
grayman

grayman

31.01.2011 14:31

viewer   ~0003519

Last edited: 31.01.2011 14:32

From some notes on the AI Movement Changes Beta thread:

If he's interrupted while sitting (or turning, or waiting, or whatever), and he comes down off alert later, he should look at his current path entity, and if it's not a path_corner, he should skip it and look at the next one, etc. etc. until he finds a path_corner. Then he should go there.

That should work better than making him go back to his previous path entity. I haven't looked to see if the previous path entity that's saved is actually a corner, or whether it could be any of the multiple path entities. If it's not a corner, then going back to it won't give us what we want.

grayman

grayman

01.02.2011 02:22

viewer   ~0003521

The stored previous path entity is not used anywhere other than to help determine if the AI is patrolling. So it doesn't matter what it is.

So, I've commandeered it to only be the most recent path_corner. This lets me implement Fidcal's request that an AI who leaves a door queue because he's been there too long retreat back to where he came from.

Since it's now a path_corner, an AI coming off an alert can be sent there and be guaranteed that path entities that aren't corners will be executed in the correct order.
grayman

grayman

01.02.2011 03:13

viewer   ~0003522

I reproduced the problem in 1.02.

In 1.03 (and in today's SVN) I couldn't reproduce the problem. The guard would either return to the pew to sit properly, facing the correct direction, or walk to the other path_corner, turn, and return to the pew. It didn't matter whether I fired the noisemaker when he was sitting, or walking toward the pew, or walking away from it.

Looks like this was inadvertently fixed in 1.03.

Issue History

Date Modified Username Field Change
24.06.2010 05:44 sotha_sil New Issue
24.06.2010 05:44 sotha_sil File Added: sit.map
04.08.2010 06:03 tels Note Added: 0003164
04.08.2010 06:03 tels Assigned To => tels
04.08.2010 06:03 tels Status new => confirmed
31.01.2011 14:31 grayman Note Added: 0003519
31.01.2011 14:32 grayman Note Edited: 0003519
31.01.2011 20:20 tels Assigned To tels =>
01.02.2011 02:22 grayman Note Added: 0003521
01.02.2011 02:23 grayman Assigned To => grayman
01.02.2011 02:23 grayman Status confirmed => assigned
01.02.2011 03:13 grayman Note Added: 0003522
01.02.2011 03:15 grayman Status assigned => resolved
01.02.2011 03:15 grayman Resolution open => fixed
01.02.2011 03:15 grayman Fixed in Version => TDM 1.04
01.02.2011 03:15 grayman Target Version => TDM 1.04
27.10.2011 05:16 greebo Status resolved => closed