View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003331 | The Dark Mod | AI | public | 28.02.2013 15:30 | 29.12.2023 18:47 |
Reporter | grayman | Assigned To | grayman | ||
Priority | normal | Severity | normal | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 1.08 | ||||
Target Version | TDM 2.00 | Fixed in Version | TDM 2.00 | ||
Summary | 0003331: AI have several problems when entering Combat | ||||
Description | There are several problems occurring when AI enter Combat. 1 - They might not draw their weapon if the enemy is close by when discovered. They will fight as if they're holding the weapon, though. 2 - Archers have no melee weapon, and simply try to run the enemy over like a truck when in melee Combat. (issues 0002527 & 0002533) 3 - Multiple AI spotting an enemy in the same frame will draw their weapons together, bark together, and start running toward the enemy at the same time. 4 - Two AI fighting each other might stop fighting, and will stand still, glaring at each other (issue 0002964). 5 - An AI has trouble standing up from a chair when entering Combat mode (issue 0003009). This needs to be tested with failed KO's to make sure anim interruptions are handled properly. 6 - Unarmed AI can stop fighting (issue 0001824). 7 - (RPGista) AI should be able to finish the drawing weapon procedure without being interrupted by pain anims when hit while doing it. They should still take damage of course, just not have the drawing action stopped and reset when hit. 8 - (RPGista) AI sometimes have a hard time dealing with a fast moving player. Before they draw, they often want to be facing the player to be able to do it, resulting in hesitation and resetting positioning (while the player is free to hit him by going in and out of range). 9 - (RPGista) AI reaction time between alert-fully alert-aware of the player-drawing for combat is often too slow; the player is able to cover a lot of distance when running before the AI will recognize him as a threat and defend himself (this might or might not be accurate, I'm talking about a typical situation where you come from a dark shadow area and ambush some AI in a lit area). If you have his back then the situation should be hopeless for them, but if they are facing you while you're running towards them they should be able to react a bit faster. It's possible that fixes for these issues might cover existing issues, which is why I noted those existing issues. Any fixes related to standing up from a chair need to be tested with getting up from sleeping in a bed. | ||||
Tags | No tags attached. | ||||
related to | 0002533 | resolved | grayman | Archers run into player at melee range |
related to | 0002527 | resolved | grayman | Give weapons to archers |
related to | 0002964 | resolved | grayman | Combat: Enemy AI get stuck after hitting each other once |
related to | 0003009 | resolved | grayman | Blocking AI in chair traps them in place |
related to | 0001824 | resolved | grayman | Unarmed combat broken |
related to | 0001697 | closed | grayman | AI errors when alerted by melee damage |
related to | 0002245 | acknowledged | AI striking player transfers pain to player's teammate | |
related to | 0006371 | new | AIs sometimes freeze or get stuck during battle |
First set of fixes for this issue. 1 - AI might not draw their weapon if the enemy is close by when discovered. They will fight as if they're holding the weapon, though. FIXED 2 - Archers have no melee weapon, and simply try to run the enemy over like a truck when in melee Combat. (issues 2527 & 2533) FIXED 3 - Multiple AI spotting an enemy in the same frame will draw their weapons together, bark together, and start running toward the enemy at the same time. FIXED 4 - Two AI fighting each other might stop fighting, and will stand still, glaring at each other (issues 1824 & 2964). FIXED 5 - An AI has trouble standing up from a chair when entering Combat mode (issue 3009). This needs to be tested with failed KO's to make sure anim interruptions are handled properly. NOT FIXED YET. 6 - (RPGista) AI should be able to finish the drawing weapon procedure without being interrupted by pain anims when hit while doing it. They should still take damage of course, just not have the drawing action stopped and reset when hit. FIXED 7 - (RPGista) AI sometimes have a hard time dealing with a fast moving player. Before they draw, they often want to be facing the player to be able to do it, resulting in hesitation and resetting positioning (while the player is free to hit him by going in and out of range). Grayman – We might be stuck with this. The melee animations only make sense when the AI is facing his enemy, and we’re at the mercy of how long it takes turning and animations to complete. I have observed them turning and drawing a weapon at the same time, though. The code executes both actions simultaneously; it doesn’t wait for the combatants to be facing each other before weapons are drawn. NOT FIXED YET. 8 - (RPGista) AI reaction time between alert-fully alert-aware of the player-drawing for combat is often too slow; the player is able to cover a lot of distance when running before the AI will recognize him as a threat and defend himself (this might or might not be accurate, I'm talking about a typical situation where you come from a dark shadow area and ambush some AI in a lit area). If you have his back then the situation should be hopeless for them, but if they are facing you while you're running towards them they should be able to react a bit faster. NOT FIXED YET. 9 – An archer will fire arrows at the floor if his enemy is below that floor. (See ‘enemies.map’.) This was due to using an incorrect sighting method for determining if a ranged attack is capable of hitting the enemy. FIXED 10 – When an AI spots an enemy on a balcony above him, he will go to the spot under the balcony to engage him. He might slide along the floor as he tries to get closer to the (x,y) location, w/o regard for z. The problem was that the enemy chase task knew the balcony was unreachable when testing the enemy’s position, but when it tried to find reachable positions around him, one of those went off the edge of the balcony, making the movement code think it could reach the spot, which got mapped to the floor below. Also changed the search volume when trying to find which AAS area a point is in. The code was looking downward 136 units, which could pick up the floor below. Limited that to 32 units, the same as the upward limit. This might have an impact on pathfinding, so we’ll need to keep an eye on it. FIXED 11 – When an AI is hit by an arrow from an enemy archer AI, he doesn’t turn toward the direction the arrow came from. FIXED 12 – When holding a dagger, an AI in alert idle state uses an open hand on the dagger, which is the idle animation, not the alert idle animation. NOT FIXED YET. 13 – With “draw” and “draw_ranged”, look at how relighting with tinderboxes is done. Atm, it assumes only “draw” and “sheath”, and it should also know about “draw_ranged” and “sheath_ranged”. FIXED 14 – Check for “draw” everywhere in the scripts and DLL code. Covered every instance? YES 15 – Werebeast has a FOV problem because of the way he swings his head. He can walk straight at the player in full brightness and only see him sometimes. Changing his FOV from the default 150 setting to 200 fixes the problem. FIXED 16 – Randomize the first rock throw at an unreachable enemy, instead of always throwing 3 seconds after entering the rock-throwing state. FIXED 17 – Have the AI look at the enemy’s eyes when throwing rocks, instead of elsewhere. FIXED 18 – Civilians and unarmed AI should flee when hit by a projectile, assuming they live through it. FIXED 19 – Bad reaction from zombie if you hit him with a sword. (issue 3337) I couldn’t reproduce this after fixing the other problems. CAN'T REPRODUCE 20 – Add a “no_bounce_sound” spawnarg to arrow flinders to keep them from generating numerous suspicious sounds as they bounce around. Also added to the noisemaker, which also bounces around and doesn’t need the bounce sounds added to its noise sound. FIXED 21 – If an AI kills another entity, and he can’t see the body after it falls, he remains in agitated search mode and barks at the dead guy about coming forward to fight. This appears to happen even if there’s a LOS from the killer’s eyes to the body’s origin. NOT FIXED YET. It's possible that fixes for these issues might cover existing issues, which is why I noted those existing issues. Any fixes related to standing up from a chair need to be tested when getting up from sleeping in a bed. NOT TESTED YET. Test map: roomofenemies rev. 5708: Actor.cpp AFEntity.cpp AI.cpp AI.h AI_events.cpp Memory.cpp Memory.h Mind.cpp MovementSubsystem.cpp AgitatesSearchingState.cpp AlertIdleState.cpp CombatState.cpp CombatState.h ExamineRopeState.cpp FailedKnockoutState.cpp HitByMoveableState.cpp LostTrackOfEnemyState.cpp PainState.cpp SearchingState.cpp State.cpp State.h SwitchOnLightState.cpp ChaseEnemyRangedTask.cpp ChaseEnemyTask.cpp MeleeCombatTask.cpp MeleeCombatTask.h ThrowObjectTask.cpp Anim_Blend.cpp Entity.h Moveable.cpp Projectile.cpp Rev 13346: tdm_ai_animal_horse2.def tdm_ai_animal_rat.def tdm_ai_base.def tdm_ai_female_animations.def tdm_ai_ghostwoman.def tdm_ai_guard_citywatch_elite.def tdm_ai_guard_proguard_devel.def tdm_ai_humanoid.def tdm_ai_humanoid_undead.def tdm_ai_monster_base.def tdm_ai_monster_spider.def tdm_ai_monster_werebeast.def tdm_ai_steambot_base.def tdm_ai_trainer_melee.def tdm_ai_undead_revenant.def tdm_ai_undead_zombie.def tdm_moveable_junk.def tdm_moveable_weapons.def tdm_weapon_noisemaker.def tdm_ai_base.script tdm_ai_constants_usevalues.script tdm_weapon_arrow_result_base.script |
|
I filed numbers 7 & 8 as a new issue (0003362). Other unfixed problems already have their own issues assigned, so I'm marking this one resolved. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
28.02.2013 15:30 | grayman | New Issue | |
28.02.2013 15:30 | grayman | Status | new => assigned |
28.02.2013 15:30 | grayman | Assigned To | => grayman |
10.03.2013 10:37 | tels | Relationship added | related to 0002533 |
10.03.2013 10:37 | tels | Relationship added | related to 0002527 |
10.03.2013 10:37 | tels | Relationship added | related to 0002964 |
10.03.2013 10:37 | tels | Relationship added | related to 0003009 |
10.03.2013 10:37 | tels | Relationship added | related to 0001824 |
12.03.2013 14:57 | grayman | Note Added: 0005158 | |
01.04.2013 19:52 | grayman | Note Added: 0005280 | |
01.04.2013 19:52 | grayman | Status | assigned => resolved |
01.04.2013 19:52 | grayman | Resolution | open => fixed |
01.04.2013 19:52 | grayman | Fixed in Version | => TDM 2.00 |
05.10.2017 19:41 | nbohr1more | Relationship added | related to 0001697 |
10.10.2017 21:37 | nbohr1more | Relationship added | related to 0002245 |
29.12.2023 18:47 | Fiver | Relationship added | related to 0006371 |