View Issue Details

IDProjectCategoryView StatusLast Update
0004936The Dark ModAIpublic03.01.2019 19:48
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityrandom
Status resolvedResolutionfixed 
Product VersionTDM 2.07 
Target VersionTDM 2.07Fixed in VersionTDM 2.07 
Summary0004936: Sykes not sitting properly when using 2.07
DescriptionSykes doesn't sit properly on his stool.
TagsNo tags attached.

Relationships

related to 0003989 resolvedgrayman Examine returning to sitting position after interruption 
related to 0004940 resolvedgrayman Various AI get dead/unconscious before you get to them 

Activities

Springheel

Springheel

31.12.2018 22:23

administrator   ~0011196

Ok, here's a save in the room. I noclipped to get there. When I entered the room he was in the process of spinning into place as if he had just sat down.

http://www.mindplaces.com/save/sitting_bug.save
grayman

grayman

01.01.2019 02:57

viewer   ~0011197

I can see a large origin translation at the end of the sit-down anim that pulls him off the stool, but I'm having a problem figuring out what causes this.

I copied Sykes and his stool to a test map and he sits down just fine.

Not sure what to make of this at this point.

Will continue looking when I can find the time.
stgatilov

stgatilov

01.01.2019 05:05

administrator   ~0011198

Did you retain the same exact coordinates for a test map?
Springheel

Springheel

01.01.2019 14:19

administrator   ~0011201

Could this be related to interleaved thinking? That's the only thing I can think of that would be affected by moving the player start.
grayman

grayman

01.01.2019 15:38

viewer   ~0011202

I moved the map to match Score's coordinates -- no joy.

However, I moved the player start to match Score's player start, and--sure enough--sykes shifted off his seat.

Another AI I had in the test map sat properly. Something to do with Sykes' interleaved thinking? (No.)

The issue is the neverdormant flag. Sykes has his turned off, so he starts to sit down, then becomes dormant in the middle of that, and when he returns to non-dormancy, the rest of the animation takes place, but the time between the beginning of dormancy and the end is factored into a final precision calculation I had added in 2.07 for always sitting in the same place. The calculation flings him off to one side.

Ditto for the other AI in the test map when I give him the same neverdormant setting.

I should be able to capture the time when dormancy is entered and exited, and subtract that from the overall animation time, and it should fix things.
stgatilov

stgatilov

01.01.2019 15:54

administrator   ~0011204

Excuse me... what the hell is "dormant" state?
stgatilov

stgatilov

01.01.2019 16:13

administrator   ~0011205

Added probably related issue about AI dying for nothing:
  http://bugs.thedarkmod.com/view.php?id=4940
Because all three women which I found disabled were near some sort of sitting place =)
Springheel

Springheel

01.01.2019 16:18

administrator   ~0011206

Last edited: 01.01.2019 16:18

By default, AI are set to "neverdormant" "1". If you set that flag to 0, AI will not activate unless they are in the same area as the player (I forget what designates an "area", but if the AI is in a sealed room they won't activate until the player opens the door to that room). It's generally used to boost performance, or if the mapper doesn't want an AI to be able to leave an area until the player arrives.

grayman

grayman

01.01.2019 16:33

viewer   ~0011207

The bcd women may or may not be the same problem.

I'll investigate those once this one's settled.
grayman

grayman

02.01.2019 03:57

viewer   ~0011213

I think we have a design problem that's been with us for a very long time.

When an AI sits down, he can have a spawnarg called "sit_down_slide_dist". It defaults to 8.

When an AI is very far from the player when he sits down, his animation is allowed to complete, but the looping code that moves him incrementally each frame along the slide dist doesn't run. This is the problem. I suspect that the script that handles this is suspended while the player is far away, and by the time the player gets close enough to resume the script, the animation is finished, and the loop sees this and exits.

Sykes' stool is placed so he ends up in the middle of it, without using the slide dist. If we started in the same room as Sykes, we would see him slide 8 units to the right of center of the stool. I observed this by running 2.05 and starting in Sykes' room. He was allowed to run his loop as the script intended, with no suspension, and he ended up 8 units to his right.

I might be able to mitigate this by figuring out if the loop was terminated via suspension, or seeing how close the AI is to where he's supposed to end up, and quitting the loop when he gets there, instead of quitting when the animation ends.
grayman

grayman

02.01.2019 13:28

viewer   ~0011220

It's probably more important to not try to force the completion of the slide distance once the script is un-suspended. Chairs are placed during mapping and beta testing so that the AI is as correctly placed as possible. This means the bug needs to stay in place, otherwise if I fix it we're going to have distant sitting and sleeping AI in released maps suddenly ending up in unintended locations, slightly askew of their chairs.
Springheel

Springheel

02.01.2019 15:20

administrator   ~0011224

Last edited: 02.01.2019 15:21

If that bug has been with us the whole time then that can't explain why Sykes is winding up in the wall now though, can it?

grayman

grayman

02.01.2019 15:45

viewer   ~0011225

Last edited: 02.01.2019 15:46

Him ending up in the wall has to do with my changes to 3989.

Take my changes out, and he sits squarely in his chair.

My 3989 changes are designed to get him to return squarely to his chair, should he decide to walk around a bit, then sit down again. 3989 complained that AI weren't sitting back down in the position they started in.

My 3989 change had no knowledge that the code loop that was being used for sliding him into place on the chair was being aborted (the old bug).

While you were alpha and beta testing the mission, I'm pretty sure you tinkered with his chair and/or his starting position so that when he sat, he ended up sitting correctly. (All mappers probably do.) In other words, you were working around the old bug w/o knowing the bug was there.

This leaves me with a tricky problem. If the AI sits at mission start and the player is far away, the bug affects his placement. If the AI sits at mission start and the player can see it, the bug doesn't happen, and the slide completes. Either case is fine, since the mapper will have adjusted the AI start position and/or the chair position to accommodate.

The tricky problem is that if the slide doesn't happen because of the bug, and later on, I come across the AI sitting down again after he got up for some reason, the slide _will_ happen, and he will end up in a different position in the chair.

That's part of the problem I need to solve: differentiating between a terminated slide and a completed slide.

Working on that now.

Springheel

Springheel

02.01.2019 16:05

administrator   ~0011226

That clears it up, thanks.
grayman

grayman

02.01.2019 22:21

viewer   ~0011233

Okay, I believe I have a solution that covers all cases.

Testing now.
grayman

grayman

03.01.2019 15:57

viewer   ~0011240

New 3989 solution looks good, sykes behaving himself now.

Will commit in a few hours.
grayman

grayman

03.01.2019 19:48

viewer   ~0011241

Changes needed to the 3989 fix to account for the player being so far from the sitting or sleeping AI at mission start that some AI do strange things. Like die or get KO’ed or end up in walls or off their chairs.

Rev 7893:

AI.cpp
AI_events.cpp
AI.h
PathCornerTask.cpp

Rev 15523:

tdm_ai_base.script

Issue History

Date Modified Username Field Change
31.12.2018 22:13 grayman New Issue
31.12.2018 22:13 grayman Status new => assigned
31.12.2018 22:13 grayman Assigned To => grayman
31.12.2018 22:23 Springheel Note Added: 0011196
01.01.2019 02:57 grayman Note Added: 0011197
01.01.2019 05:05 stgatilov Note Added: 0011198
01.01.2019 14:19 Springheel Note Added: 0011201
01.01.2019 15:38 grayman Note Added: 0011202
01.01.2019 15:54 stgatilov Note Added: 0011204
01.01.2019 16:12 stgatilov Relationship added related to 0004940
01.01.2019 16:13 stgatilov Note Added: 0011205
01.01.2019 16:18 Springheel Note Added: 0011206
01.01.2019 16:18 Springheel Note Edited: 0011206
01.01.2019 16:33 grayman Note Added: 0011207
02.01.2019 03:57 grayman Note Added: 0011213
02.01.2019 13:28 grayman Note Added: 0011220
02.01.2019 15:20 Springheel Note Added: 0011224
02.01.2019 15:20 Springheel Note Edited: 0011224
02.01.2019 15:21 Springheel Note Edited: 0011224
02.01.2019 15:21 Springheel Note Edited: 0011224
02.01.2019 15:45 grayman Note Added: 0011225
02.01.2019 15:46 grayman Note Edited: 0011225
02.01.2019 16:05 Springheel Note Added: 0011226
02.01.2019 22:21 grayman Note Added: 0011233
03.01.2019 15:57 grayman Note Added: 0011240
03.01.2019 15:58 grayman Relationship added related to 0003989
03.01.2019 19:48 grayman Note Added: 0011241
03.01.2019 19:48 grayman Status assigned => resolved
03.01.2019 19:48 grayman Resolution open => fixed
03.01.2019 19:48 grayman Fixed in Version => TDM 2.07