View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003424||The Dark Mod||AI||public||20.05.2013 10:29||04.10.2017 13:35|
|Product Version||TDM 1.08|
|Target Version||TDM 2.00||Fixed in Version||TDM 2.00|
|Summary||0003424: A group of guards can search for too long|
|Description||(Reported by Oldjim)|
In an area where there are a number of guards either in there or moving in and out such as an open courtyard with rooms off I found that when a guard was alerted the other guards were also alerted either immediately or when they entered the area.
This is how I understood it to work under 2.0.
However the guards drop back out of alert status after a predetermined time which is fine except that this time appears to start from when the guard was alerted not from the first alert. The effect of this is that a guard drops out of alert status but is then alerted by a guard still in alert status and hence the guards as a group stay continuously alerted.
|Tags||No tags attached.|
1 – Create a list of suspicious events covering “enemy alert”, “dead body”, and “missing item”. These are the three categories we have bark sets for.
2 – For each AI, keep track of which events he knows about.
3 – For each AI, keep track of who he has warned, and who has warned him, about specific events.
4 – For each AI, keep track of which events he’s searched.
5 – Old way: When an AI is invited into an existing search, he inherits 70% of the inviter’s alert level. If the new AI subsequently sees the evidence himself (body, etc.), the code was ratcheting up the alert level to the full amount appropriate for that evidence. So an AI could join a dead body search at 15 or so, spend some time searching, then see the evidence and get bumped up to a full 22 or so, lengthening his search time. New way: for anything but a dead body, continue to give 70%, but don’t let the AI ratchet up when they spot the evidence themselves. For a dead body, give the full alert amount at the moment of invitation. This change reduces search times when in a group.
# 1 - 5 let us keep track of who’s warned who about what, to increase the realism of passing warnings and joining searches. With these in place, search times for everyone except the original “finder” will shorten a bit, and it’s easier to prevent AI from re-joining a search they’ve already participated in.
6 – Randomize hiding spot selection. This lets AI move around the search area a bit more, instead of standing in one spot for a long time, searching a subset of sequential spots that are near each other.
7 – Randomize the silence between an initial search bark and the following repeated search barks. In a group of searching AI, this helps a bit to keep clusters of barks from being heard, especially when the AI were all alerted in the same frame.
8 – Since an AI can switch searches if he encounters a new event, let him switch repeated bark sets if he goes from a “no evidence seen” event to an “evidence seen” event. Otherwise, a “no evidence seen” bark set can end up being used when conducting an “evidence seen” search.
9 – When switching from idle to alert idle, don’t stop a patrolling AI so they can draw their weapon (and acquire the idle alert walk anim) if they don’t have a weapon.
10 – Pain anims are queued so they don’t bother idle anims. When an AI is hit by multiple damage events at roughly the same time, don’t let more than one pain anim sit in the queue. For example, if there are 3 mines nearby and they explode simultaneously, and the AI lives through it, don’t play 3 consecutive pain anims. Just play one.
11 – Allow mines hit by splash damage from an exploding mine to paint a damage decal when they explode. Unarmed mines in the process of arming can also explode, since they’re packed with explosives.
12 – Don’t allow an audio alert to change the current alert class if it’s something other than “None”. This lets the AI play the correct rampdown bark. For example, if he hears a suspicious sound while searching around a dead body, he shouldn’t bark something like “It must’ve been rats” at rampdown.
13 – When “A” and “B” are searching for different reasons, and A requests B’s help, let B decide whose search is more important. For example, let an AI be drawn off a missing item search to join in a dead body search, and prevents being drawn off a dead body search to join a missing item search.
14 – Prevent “double-dipping” of the “evidence of intruders” counter. For example, if an AI is invited to join a dead body search, and then sees the body for himself, it was possible to accrue +3 during the invite and +3 at the sighting. Keeping track of what suspicious events an AI knows about (# 1 - 5 above) prevents this from happening. (“I already know about this body, so I won’t count it twice.”)
15 – Reinstate the “I’m responding to your request” bark, which had been commented out with the reason “happens too often”. With various new checks in place, that shouldn’t be the case any more.
16 – If an AI hears a propagated sound that he made, he’ll now ignore it.
17 – Corrected an anim problem when an alerted AI with a drawn weapon ran away from relighting a light with his arms at his side. The wrong idle torso anim was being played.
18 – Added a few extra checks for DEAD or KNOCKED OUT, to prevent such AI from running code they have no business running.
19 – Apply # 1 - 5 when an AI warns a friendly player. This keeps AI from repeatedly warning the player about the same event. Applied delays to failed and successful warning attempts to spread out any warnings.
|Wow, that sounds like a lot of great stuff!|
|20.05.2013 10:29||grayman||New Issue|
|20.05.2013 10:29||grayman||Status||new => assigned|
|20.05.2013 10:29||grayman||Assigned To||=> grayman|
|02.06.2013 00:53||grayman||Note Added: 0005504|
|02.06.2013 00:53||grayman||Status||assigned => resolved|
|02.06.2013 00:53||grayman||Resolution||open => fixed|
|02.06.2013 00:53||grayman||Fixed in Version||=> TDM 2.00|
|02.06.2013 00:53||grayman||Target Version||=> TDM 2.00|
|02.06.2013 03:22||Springheel||Note Added: 0005506|
|02.06.2013 03:46||grayman||Note Edited: 0005504||View Revisions|
|02.06.2013 20:21||grayman||Note Added: 0005513|
|04.10.2017 13:35||nbohr1more||Relationship added||related to 0002917|