 |
I have come to the conclusion that this is more generalized issue with path locations. There should be no step at the end where we "figure out" the original position. We know where the AI was seated "a priori" and we should be able to poll that info and use it when concluding the seating process. The same problem happens when AI return to sleep and will levitate in strange locations. We already have the sleep position where they started, we need to either use that info as a lerp factor when returning to it or (worst case) hard jump to that position at the end of the animation. |
 |
It appears that the upgrade to 'forest' removed any guards told to sit at the beginning of the mission. So I can't replicate exactly what I saw nearly 4 years ago when I filed this. I'll make a new test map. |
|
|
Use cases: 1. Use the "sitting" or "sleeping" spawnarg on an AI who doesn't patrol, and starts the mission sitting or sleeping, and stays there, unless interrupted. When interrupted, he should go do what he needs to do, then return to his initial starting spot and sit back down or go back to sleep. 2. Use a path_corner next to a chair or bed which points to a sequence of path_nodes that puts him into a sitting or sleeping state. If he is interrupted from sitting or sleeping, he should return (I'll need to check this) to finish his sit or sleep. (Maybe he aborts the sit/sleep and moves on to the next path_node; need to check.) 3. Sometimes a sitting or sleeping AI, when interrupted, will be told to start a patrol. (I.e. he was playing cards, and some alert aborted the card game and put him on a patrol route.) Make sure any changes to solve cases 1 and 2 don't disturb that behavior. |
|
|
1. The first use case is solved, but when I find a solution for the second use case, I may have to make it general enough to also cover the first use case, tossing the solution I found for that. |
|
|
2. The second use case is solved. Its solution is different than the one for the first use case, because it requires knowledge of the path_corner that kicks off the sitting/sleeping sequence. |
|
|
1 – Fixed problem of non-patrolling sitters and sleepers not returning to their initial starting points after waking up and walking around to search. 2 – Fixed problem of sitters and sleepers descending into the floor or floating above beds (as far as I can tell). 3 – Made sitters and sleepers who use path_nodes always end up at the same place on the chair or bed. Rev 7795: Memory.cpp Memory.h AI.cpp AI.h SwitchOnLightState.cpp AI_events.cpp PathCornerTask.cpp Actor.cpp IdleState.cpp Physics_Monster.cpp Rev. 15423: tdm_ai_base.script |
 |
I'm afraid the story of dying AIs is not over. See the new issue 0005156. It is similar to 0004940. I think that snap-into-position idea is good in general, but with the way how it is implemented currently it is a disaster. The "ideal sitting position" must be statically determined by the mapper, not determined in runtime. The wiki page: https://wiki.thedarkmod.com/index.php?title=Sitting_Behaviour_for_AI clearly says: "You must place the path_sit next to the chair, angled away from the direction you want him to sit." So the "ideal sitting location" should be where the used path_sit entity is. Another approach would be using the location of path entity which targets the path_sit entity. But this is very dangerous, because it may be something different from path_corner, in which case it can have pretty random location. Another problem is that the snapping happens always, without any limitations. Even if the snap-location happens to be on the other side of the map, the script would simply drag AI to there, killing him with all the obstacles in the way. There should be sane limit on the translation done this way, so that AIs don't teleport, be thrown away and killed. So my opinion is that AIs should snap into the location/orientation of path_sit entity. If this is not an option due to breaking maps, then it's better to revert all the changes, declare all sitting bugs features and hope no one dies in process. |
|
|
There's a lot of material here, and I need to find time to review it and see if there's a simple solution to the new problems that cropped up. From a quick read-through, I see there's no mention of initially sitting w/o using a path_sit entity, so that has to be factored in. Don't revert any of the "snapping to original position" code until I've had time to report back. It'll prolly be a few days, possibly a week. Thanks. |
|
|
Another possibility is to save "ideal sitting position" only when guard first starts the "sit" task (or ends it). So the behavior would be: 1. Record sitting position on first sit-down. 2. Once recorded, always used the same sit-location for the whole game, no matter what. This will ensure that the sitting-down process will always be the same. And also AIs would hopefully sit down in a way which was tested by the mapper. As a general idea, I think it would be great if sitting-down was predetermined. I.e. so that a guard always moves along same one path, as if he is "on rails". It probably lacks a bit of realism, but removes the chance of problems like this one. |
|
|
SVN: atdm_ai_thief02_3 died after 5 mins at timescale 2. 2.07 hot fix: he didn't die, but after 30 mins at timescale 2, I found him patrolling normally. A minute later, he started tread-milling, stuck in a wall. 2.07: he died after 2 mins at timescale 2. 2.06: he didn't die, but after 2.5 hours at timescale 2, I found him stuck (in a different place than he was in 2.07 hot fix), tread-milling. The tread-milling problem might not have anything to do with the dying problem, since the theory is that the dying problem is the result of changes made for this issue, back in 2.07. |
|
|
Looking at path node linkages and "move to" instructions being given to the AI just before he dies. No eureka moment yet. For the record, I'm building with MSVS2017. |
|
|
I have described what causes the problem with this guard in 0005157: https://bugs.thedarkmod.com/view.php?id=5156#c12204 The core problem is: when an AI sits down, your new code drags him to "startSitLocation". Which is assigned quite erratically and is often in some random distant places. For this particular guard, it might end up in at least three different wrong places, causing him to die/teleport outdoors in two of the cases. |
|
|
I agree with adding the missing line in the prediction area. The reason he sits at the bottom of the stairs has to do with the closeness of 316 and 300. When he comes down the stairs, he does a prediction when he gets close to 316, and when he picks the next path node as 300, 300 is close enough to 316 that he decides he has also arrived at 300. Once he "arrives" at 300, he sits down on the stairs. I've been reviewing the interleave thinking code, because the player is so far away from this guy most of the time. That might be a factor in his decisions as he gets close to 316 and 300. Btw, I disagree that startSitLocation is set "erratically". All settings made during a patrol are correct. I think the confusion is in its name. (Edit: see following note.) <del>It started life as the place where AI return to when all they do is sit or sleep in the same place. I probably overloaded its meaning when I extended it to handle interruptions anywhere during an AI's patrol. I will probably rename it to something more general, like "HeresWhereIReturnOnceImDoneWithAnInterruption".</del> Also, btw, the origins of any path nodes other than path_corners are meaningless, since they are "action" nodes, and not "location" nodes. So storing a path_sit origin at mission start does nothing. |
|
|
After further review of how startSitLocation is used, I realized it's only used by the sitting animation to slide a nearby AI into the same location prior to running the "sit down" animation, for both sitting and sleeping. With that in mind, I renamed startSitLocation to returnSitPosition. In addition to any initial "sitting" or "sleeping" AI spawnargs (not using an initial path_corner), this position is saved for all visited path_corners, even though nearly all will not lead to sitting/sleeping. This is simpler than always looking forward for path_sit or path_sleep nodes. |
|
|
But the guy in question is never interrupted. And interleaved thinking does not apply. I simply teleport to him with notarget and observe him patrolling. Should I assume that something in his patrol schedule is considered an "interruption"? Also, I did not get it: do you want to say that sitting on the stairs is the normal behavior for this guy? It is sad that path_sit location is ignored. I think a better decision would be to snap AI into the location+orientation of the path_sit entity, and return him back to where he was before that when he finishes. All those issues would never happen if mappers were forced to specify exactly where AI should sit. |
|
|
We (unfortunately) need to support the methods available to mappers over the years so we don't break released missions. He'll be interrupted during future tests. Atm I'm trying to straighten out and verify the code that becomes important when he _is_ interrupted. Since there are a variety of ways mappers can set up sitting/sleeping, we need to accommodate them all. Returning an AI to the settings he used when he sat/slept for the first time allows these various ways to continue to work. ================= As for sitting on the stairs... Interleaved thinking increases the number of frames between "thinks" for an AI when he's far away from the player. This was introduced for performance reasons, before I joined the team. In 1.04 (IIRC), I made improvements to stop unplanned AI deaths that the original code would sometimes cause. The Alchemist mission was where folks started noticing the phantom deaths, which killed off probably half the AI before the player could meet them. If you get anywhere near our guy, the delay between "thinks" decreases, so his movements look more natural. If you teleport near him or start near him, he will not behave as he does when you're far away. You can observe what he does when he's far away by setting the tdm_ai_opt_interleavethinkskipPVS cvar to "1" in your cfg file. This causes him to skip the "am I in the player's PVS" check and make use of longer "think" delays. His animations will become choppy, for instance. As mentioned above, he sits on the stairs because he's already processed the 316 node, and via the prediction code, he's also processed the 300 node. He then processes the path_sit node, but does so w/o moving over to the bench. He just sits down where he is at that frame, which happens to be at the bottom of the stairs. Once I get into the prediction code and account for these situations where the mapper has placed path_corner nodes very close to one another (this map is probably full of this stuff, if these narrow halls our guy traverses are any indication) (again--damn those mappers!), he'll make his way over to the 300 node, invoke the path_sit, and plop himself properly onto the bench. |
|
|
In a note above ... "The "ideal sitting position" must be statically determined by the mapper, not determined in runtime. The wiki page: https://wiki.thedarkmod.com/index.php?title=Sitting_Behaviour_for_AI clearly says: "You must place the path_sit next to the chair, angled away from the direction you want him to sit." So the "ideal sitting location" should be where the used path_sit entity is." This is Fake News. I corrected the wiki page. The path_sit can be anywhere (its location is not used because it isn't important. I could put it into the mission's "blue room" if I wanted). The sitting location is provided by the path_corner that precedes the path_sit, even if there are a number of action nodes (like turning your head, scratching your arm, a path_wait, etc.) that might be stuck between the path_corner and the path_sit. |
|
|
Found the root cause for the AI sitting on the stairs (and sometimes sitting in front of the nearby door). The problem is that the mappers didn't extend the monsterclip on the bench up to the ceiling, so an AAS area is created by dmap on the top of the bench, and it extends off the bench top to cover the floor in front of it, path_corner_300 sits inside that AAS area, so when the guy is standing on the floor, he can't step up onto the bench, because the bench top (AAS area) is 23 units off the floor, and AI can't step higher than 13 units. When I carry the m/c up to the ceiling and push back the front of the m/c to be > 17 from 300's origin, he sits on the bench. I also had to add an "angle/0" spawnarg to path_sit_2 so he sits at the correct angle. (When the map starts, he's facing away from the bench, but he can't get to 300 from there, so he just sits down in front of the bench.) So unless the map is corrected and re-issued, the AI will never be able to get back to 300, and will sit down at the point where the failure occurs. There's one other path_sit in the map, and it might need similar corrections. I'm afraid there's nothing we can do code-wise to correct this, since pathfinding depends on AAS areas to move the AI around, and there's no AAS area sitting on the floor where 300 sits. |
|
|
Plan at this point: 1. Test with other maps that I originally tested with back when I made the original fix to this issue. 2. Commit changes. 3. Finished. |
|
|
Fixed. See my commit note in issue 0005156. |
|
|
What about adding a safeguard against pulling guards too much? I.e. check in script that vecToIdealPosition is not greater than one meter, and do nothing otherwise. Or maybe better abort sitting/sleeping process and continue with next patrol task. |
|
|
"Pulling" guards? Do you mean don't let them sit or sleep if they're too far away from where they're supposed to be sitting/sleeping? |
|
|
Yes. Because if this happens and they are allowed to do so, that would be an awful thing to do (probably resulting in death or getting to unexpected place). |
|
|
The only thing that happens is that they sit/sleep in their present location. They don't go flying off or die; we just fixed that. |
|
|
I just posted a thread about sitting & sleeping in the wrong place. https://forums.thedarkmod.com/index.php?/topic/20270-ai-sitting-sleeping-in-the-wrong-place/ |
|
|
How about this: https://forums.thedarkmod.com/index.php?/topic/20291-beta-testing-208/page/13/&tab=comments#comment-447036 "I don't know if this beta test is an opportunity to look at this, but there seems to have been a map breaking regression, probably introduced in 2.07, which makes it impossible to complete The King of Diamonds without resorting to noclip. Specifically, there is an key character in an upstairs room who is scripted to wake up and walk out of the room at some point in play, but he is stuck against the chair he is trying to walk away from. Looking at reports of this problem in the forum (and on a posted playthrough on youtube) I'm pretty sure this started around the time 2.07 came out." Almost surely caused by these changes. I must admit that I did not play this FM, so I don't know how to reproduce the issue. |
|
|
I will look at the Ai problems cited. (I also found one in my WIP.) While the solutions to the problems might lie in the map, it's not nice to force a mapper to re-issue his work (i.e. try to have the code work around the problem). However, the computer I use for code work died yesterday with a suspected memory error. I need time to fix it before I look at any bugs. |
|
|
Builders' Forge: 1. Why does Jacob stay awake after sitting? 2. If you remove the wait node before the sleep node, why does the code warn about Jacob not being near enough to his path_corner to sleep, when he's already sitting in the chair? |
|
|
Instructions on King of Diamonds problem: https://forums.thedarkmod.com/index.php?/topic/20291-beta-testing-208/&do=findComment&comment=447230 |
|
|
Well, it's no wonder the AI has problems in that area: 1. His path_corner is right up next to monsterclip, when it should be at least 17 units away. 2. In spite of constant suggestions over the years, the monsterclip brush doesn't extend up to the ceiling, providing a nice surface for pathfinding to think the AI can climb up on the desk. AI that are allowed to do that usually get stuck. I'm going to go back before 2.07 and see if he gets stuck. There's been no report of anyone testing this with 2.06 or earlier. |
|
|
Unfortunately, I'm unable to reproduce this problem.I'm testing with beta6, and the AI is able to sit down at the desk and subsequently stand up and walk away w/no problem. I tested this 5x in a row, and he was ok each time. By whatever means, I'm going to need someone to create a savegame showing the problem, using beta6. |
|
|
Save file. |
|
|
Save from just before the issue. |
|
|
Both of these savegames abort during loading under beta6. |
|
|
Sorry. I tested with the mission dmap-ed under 2.08. I try to replicate on the original FM. I hope these failed load issues are not indicative of some sort of memory leak or pointer issue... |
|
|
Original DMAP. All advanced options off. Before the door. |
|
|
Noclip into the room |
|
|
SVN 8741 |
|
|
|
|
|
|
|
|
Parkins is stuck on the chair behind him. So this is a matter of getting him to recognize that the chair is not in the way of his forward motion. |
|
|
Test with the new test build: Saves inside the zip (before and after door). |
- Anonymous
