View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004936 | The Dark Mod | AI | public | 31.12.2018 22:13 | 03.01.2019 19:48 |
Reporter | grayman | Assigned To | grayman | ||
Priority | normal | Severity | normal | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 2.07 | ||||
Target Version | TDM 2.07 | Fixed in Version | TDM 2.07 | ||
Summary | 0004936: Sykes not sitting properly when using 2.07 | ||||
Description | Sykes doesn't sit properly on his stool. | ||||
Tags | No tags attached. | ||||
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 |
|
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. |
|
Did you retain the same exact coordinates for a test map? | |
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. | |
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. |
|
Excuse me... what the hell is "dormant" state? | |
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 =) |
|
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. |
|
The bcd women may or may not be the same problem. I'll investigate those once this one's settled. |
|
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. |
|
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. | |
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? |
|
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. |
|
That clears it up, thanks. | |
Okay, I believe I have a solution that covers all cases. Testing now. |
|
New 3989 solution looks good, sykes behaving himself now. Will commit in a few hours. |
|
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 |
|
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 |