View Issue Details

IDProjectCategoryView StatusLast Update
0003331The Dark ModAIpublic10.10.2017 21:37
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityrandom
Status resolvedResolutionfixed 
Product VersionTDM 1.08 
Target VersionTDM 2.00Fixed in VersionTDM 2.00 
Summary0003331: AI have several problems when entering Combat
DescriptionThere 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.
TagsNo tags attached.

Relationships

related to 0002533 resolvedgrayman Archers run into player at melee range 
related to 0002527 resolvedgrayman Give weapons to archers 
related to 0002964 resolvedgrayman Combat: Enemy AI get stuck after hitting each other once 
related to 0003009 resolvedgrayman Blocking AI in chair traps them in place 
related to 0001824 resolvedgrayman Unarmed combat broken 
related to 0001697 closedgrayman AI errors when alerted by melee damage 
related to 0002245 acknowledged AI striking player transfers pain to player's teammate 

Activities

grayman

grayman

12.03.2013 14:57

administrator   ~0005158

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
grayman

grayman

01.04.2013 19:52

administrator   ~0005280

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.

Issue History

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