 |
Just so we know this wasn't a fluke, it just happened to me again in Solar Escape. I jumped into the water, and resulting splash alerted the thug. He saw me when I surfaced and threw a rock at me, then got stuck bouncing between sheathing his sword and spotting me, as above. |
 |
Does the Too Late video still work for you? It gives me an error. |
|
|
Unfortunately, I can't use the save game. My version of the source no longer matches what I was using when I attached the pk4 that you're using. I'll have to try to reproduce it. |
|
|
The first time the video didn't work, but then I clicked the link again and after a few seconds it worked. |
|
|
Played the next time I tried. It looks like he's entering combat, dropping out, and re-entering. I haven't had that happen in my testing, so it probably has to do with the lightgem level in that particular scene, and him being right on the cusp of combat. I'll look at that next. |
|
|
I've been working with the torch-bearing guard in Too Late for the past couple days, and I couldn't get him to repeat this problem. It might be that code changes I made for 0003492 took care of this problem. |
|
|
Not quite as severe, but I caught another instance of this in Old Habits II. A guard spotting me and I ran and jumped on top of some barrels where he couldn't reach me. He could still see me though. He threw a rock and ran around a bit, then got stuck in a loop where he would give his combat bark and draw his sword, then give his enemy out of reach bark and sheath his sword, then throw a rock at me, then run around in a circle, then start the pattern over again. I saved the game and it appears to happen on reload, so I'll upload it, although was before tonight's build was uploaded. |
|
|
Tonight's build had no new binaries or DLLs, so it should still run yesterday's savegames. |
|
|
Happily, the savegame runs. I'll be looking at this today. |
|
|
Here's what's happening: 1 - Guard enters combat. 2 - Guard decides he can't get to you. 3 - Guard throws rock. 4 - Guard sees that you have the bow out, so he runs for cover, which is a spot right behind where he's standing, so he runs in a wide circle to get there. 5 - Once he's there, he can still see you, so he exits cover to return to Combat. 6 - However, Combat has erroneously been removed from his state queue, so he returns to Agitated Searching. 7 - But his alert level is still up in Combat, so he jumps immediately into Combat, but he starts Combat all over again, not picking up where he left off. 8 - Go back to step 1 and repeat. So there are two problems: 1 - Can't remove Combat state from the state queue when the player becomes unreachable 2 - Can't loop forever from Combat to Unreachable to Seek Cover to Leave Cover to Combat to Unreachable to Seek Cover and on and on. |
|
|
Ah, okay...could this be the cause of the first one too? I did have my bow out in that episode, though with water arrows selected, not broadheads. But perhaps he was calculating for cover and then realizing there was none, which made the looping much quicker? |
|
|
Sounds like the same problem. AI don't inspect arrow type. All they "see" is the bow. |
|
|
It might take a day or two to fix this. I have to move some code around, and I have to be careful not to cause something else to break. |
|
|
I'm not able to come up with a quick solution to this. We've encountered a "race condition" where an AI is trying to perform these three actions simultaneously: 1 - run for cover because the bow is out 2 - come forward to engage in melee 3 - stand still and throw rocks This only occurs when the player is unreachable, the AI only has a melee attack, and the player has the bow out. Since this isn't a crash, and I don't see it as a critical problem, I suggest pushing this to 2.01, when I'll have time to arrive at some solution that allows these three goals to live with each other. The risk of my screwing up some other AI behavior is high if I try to implement a quick fix. Btw, this has nothing to do with the AI Vision changes. It doesn't happen in 1.08 because "run for cover" was fixed in 2.00. |
|
|
Actually, it does happen in 1.08, because the guard can see my feet. This allows the "run to cover" code to work correctly for the architecture in that room. (The 2.00 fix included not checking from the guard to my feet, but from the guard to my eyes.) So the problem experienced here occurred in 1.08 too, and is not 2.00-specific. |
|
|
Ok, I'll move it to 2.01 then. |
|
|
There's no quick fix for this, and 2.01's shortened schedule won't provide enough time, so I'm moving it to 2.02. |
|
|
I don't like that it takes so long for the guard to leave cover and return to the spot where he was when he decided to run for cover. He should be looking around for the enemy, and possibly not returning all the way. He should be doing this: 1 - Step out of cover 2 - Scan for the enemy 3a - If the enemy is visible, and has the bow out, and is unreachable, then run for cover again w/o re-drawing the melee weapon. 3b - If the enemy is not visible, enter Lost Enemy state. 3c - If the enemy is visible, but unreachable and the bow is gone, start throwing stones. Don't run for cover, don't re-draw the melee weapon. 3d - If the enemy is visible and reachable, re-draw the melee weapon and attack him. Don't run for cover. Don't throw stones. |
|
|
Instead of switching from CombatState to UnreachableTargetState, push the new state. This allows Combat to stay on the state queue, which means that once the unreachable->take cover->spot enemy sequence occurs, you don’t drop back to AgitatedSearching, then immediately climb to Combat. This change takes AgitatedSearching out of the sequence. When returning to Combat, skip over the initial reaction delay and return to what you were doing when the enemy became unreachable. This requires saving the Combat substate when UnreachableTargetState is pushed. These two changes stopped the behavior of bouncing back and forth between drawing and sheathing a weapon. Changes made as other bad behaviors were noticed during debugging: When emerging from cover, if you were bumped by the enemy, return to Combat. When leaving StayInCoverState, don’t always go to LostTrackOfEnemyState. Depending on conditions, you might want to return to Combat, or simply exit the state with a lower alert level (which returns you to Combat, which immediately drops to Agitated, etc.). Change the place where you check if you should run for cover from before throwing a rock to after. Up to four seconds might have passed between the original check and throwing the rock, in which time conditions might have changed. Double the travel time allowed when looking for a place to take cover. This change allows AI to find a more reasonable hiding spot than before. When finding that the AI is too far away to throw a rock, correct the method used to choose a place to run to where you’re closer. The old method didn’t care about changes in floor level between the AI and the enemy. Randomize the time between rock throws. Instead of a constant 3s, change to 2-4 seconds. Rev. 5951: AgitatedSearchingState.cpp AgitatedSearchingState.h CombatState.cpp EmergeFromCoverState.cpp LostTrackOfEnemyState.cpp StayInCoverState.cpp TakeCoverState.cpp UnreachableTargetState.cpp UnreachableTargetState.h ChaseEnemyTask.cpp InvestigateSpotTask.cpp AI.cpp AI.h Memory.cpp Memory.h Mind.cpp Rev. 13792: tdm_ai_base.def tdm_ai_humanoid.def |
- Anonymous
