AI stats Wiki page

[Destined]

Is there another Wiki article about AI perception apart from the Visual Scan? I would like to include as much of the mechanics (or at least link to the respective articles) of AI percieving their surroundings as possible, as I assume that people who look at the AI stats will also want to know how they can use them. However, the Visual Scan was the only explanation on the mechanics that I could find on the Wiki.

[Obsttorte]

Some additions:

• anim_rate_X where X is the name of the anim can be used to increase (values higher 1) or decrease (values lower 1) of the animation X, mappers can use this to alter the speed of an ai for example or to make them attack faster (in terms of how long the blow takes)
• equip_action_script/dequip_action_scripts point to script functions that gets called if the player picks up or drops a body, I'm not sure anymore whether this goes on the ai or the ragdoll, in the latter case, mappers would have to alter the ragdoll definition if needed
• there is also a spawnarg calling a scriptfuntion if the ai is below critical health (low_health_script) as well as one in case the ai gets knocked out (ko_script) or killed (death_script)
• spawnargs starting with alert handle at which point ai gets to an higher alert state and how long it takes for them to calm down, playing with this values can be useful to adapt the ai's behaviour to the circumstances of a mission (and the fact mappers usually don't alter this is imho one of the reasons why some people are complaining that TDM's ai is good in some missions, whereas they seem overpowered in others)

Regarding sound: If the player makes a 'noise' (a propagated sound), the distance between him and nearby ai is calculated. According to the distance the initial noise volume is reduced and than further reduced by the value stored in the alert_aud_tresh spawnarg (a value below which ai wont hear a thing). The remaining value specifies how much the alert level of the ai is raised.

 

I think there is a max system used in regards to alarms. So if an ai is both hearing and seeing the player (or another ai), only the higher influence will be taken in account. But this is only a vague remembrance, so I may be wrong.

 

Another funny thing is gravityDir. Changing this allows you to have ai walking on the ceiling (spiders for example). Note that this cannot be changed during runtime, and is therefore only really applicable for ambient ai or very strange values. The world gravity can also be changed btw., but alos not during runtime.

 

There are spawnargs head and def_vocal_set used to alter the head and the vocal set of an ai.

[Destined]

Thank you for your input. I will add the explanation of the animation rate to the movement speed. The others might additionally need an explanation as to what the respective scripts include, but I will also add them.The alert rates might also be quite interesting for people to know and are needed to understand the sound propagation. But is it really distance that calculates the sound reduction? I thought it was only reduced by visportals. There was a discussion about that quite recently (the thread was about ambient sound, IIRC). I think I will search for that again. The problem is, I think a lot of spawnargs are a "good to know", if not for players at least for map authors, and fear I might already have too many. Well, we will see, how it turns out. I could also just make one table for the basic values and state the changes for specific classes. This would need a whole lot less space...

 

Another curiosity I found was: I used the script SteveL provided and got a list with inherited as well as uninherited spawnargs. The strange thing was that for "gas_immunity" the value was "1" for all builder characters. When I searched the inherited def-files, I could not find gas_immunity in any of them (in the ai_base.def there was the description of the spawnarg, but it was not defined there). Also, they are clearly not immune to gas, so it has to be defined somewhere. Does anyone have an idea, what I am missing?

[nbohr1more]

Given all the other technical stats, I'm surprised Interleaved Thinking isn't in your list:

 

http://wiki.thedarkmod.com/index.php?title=Interleaved_Thinking_optimization

[Destined]

In my opinion Interleaved thinking is rather a performance and not really a gameplay relevant spawnarg. That is why I left it out.

 

With this article I tried to cover the most gameplay relevant spawargs of the AI to give players an insight into what the AI can do regarding interaction with surroundigs, combat, and perception. In addition, I wanted to add some stats about weaknesses (e.g. where they are hit on the head for a KO).

[Obsttorte]

Visportals normally don't affect sound propagation, unless they touch a closed door. The thread you are referring to was about the fact, that the doom 3 engine quits sound propagation after the sound has passed through a certain amount of visportals. And yes, I am sure that the distance is taken into account for sound reduction, for one it simple makes sense, and two I've read the specific part of the source code handling this behaviour.

[Destined]

Ok, thanks for the clarification. I will take your desrcription, when I describe the auditory acuity.

[demagogue]

To understand sound propagation it's helpful to turn on the console command that shows the path and volume of sounds to the player. Then walk around and you see how it runs through portal centers and attenuates (or not).

[grayman]

Sound doesn't travel through portal centers. It travels through portal edges.

[Obsttorte]

It chooses the shortest path through the portals, which is normally at an edge or a vertex, but can also be inside the portals plane if the point the sound travels to is straight in front of the portal.

 

Note that this only applies for visportals with not more then 4 vertices. If you place visportals with more vertices, the code will choose the center for performance reasons, hence mappers never should place such portals.

[Destined]

To understand sound propagation it's helpful to turn on the console command that shows the path and volume of sounds to the player. Then walk around and you see how it runs through portal centers and attenuates (or not).

I will have a look at that, thanks!

Edit: What is the console command for that? On the Wiki I could neither find it in the "Useful Console Commands" nor in the "Cvars" article.

 

Another thing I noticed, that is related to the "gas_immune 1" thing: I also found that according to the inheritance AI have "can_drown 0", although I am pretty sure that they do drown and "ko_immune 1", which they definitely are not. Another is "ignore_alerts 1". Maybe the states are just random as the search script cannot find any inherited value.

Edited February 3, 2017 by Destined

[Obsttorte]

Which definition are you looking at?

 

The command is tdm_showsprop 1

[demagogue]

Sound doesn't travel through portal centers. It travels through portal edges.

 

Ah. I said that completely based on my memory of what I thought I saw. Although Obstortte's comment would explain it. I was following behind a clomping AI.

[Destined]

The command is tdm_showsprop 1

Thanks!

 

Which definition are you looking at?

The first definitions I worked on were the builders (due to alphabetical order). In these def-files, none of the mentioned spawnargs are defined. As an example, when searching for can_drown in tdm_ai_builder_guard.def results in no match. Via "inherit atdm:ai_proguard" I got to tdm_ai_proguard.def. this has also no can_drown, but "inherit atdm:ai_humanoid_newskel". The tdm_ai_newskel.def leads to tdm_ai_humanoid and that finally to tdm_ai_base.def, which contains the editor_bool of can_drown, but also no defined value. I have no idea, where the script SteveL gave me gets the values (they are marked as inherited, but it is not stated from where).

[grayman]

It chooses the shortest path through the portals, which is normally at an edge or a vertex, but can also be inside the portals plane if the point the sound travels to is straight in front of the portal.

 

Note that this only applies for visportals with not more then 4 vertices. If you place visportals with more vertices, the code will choose the center for performance reasons, hence mappers never should place such portals.

 

Think of unspooling string from the sound source to the player's ear. You walk through the portals, trailing the string behind you, and when you get to the player's ear, you pull on the string. For some portals it snugs up against the portal edges, for others it passes through the portal plane not at the edge but also not at the center, and that's the path the sound travels.

 

I'm not sure about using the center of non-rectangular portals, since I don't recall calculating where "non-rectangular portal" centers are. I suspect the sound path still attempts to follow the string path, but I don't remember exactly.

[Obsttorte]

There is a specific part in the code where this is handled and even commented, as the math gets a bit more complicated if the amount of vertices increase. I would have to search for that specific piece of code as it's been a while that I've stumbled over it.

 

Btw.: Nice metaphora with the string, reminds me of Hänsel and Gretel (and a bit of the myth with the minotaur labyrinth).

[Destined]

I have finally found mistake I made regarding the "ko_immune" spawnarg. This spawnarg exists for a couple of AIs (namely undead, horses and spiders), while the ko-immunity for human AIs is handled via "ko_angle_horiz/vert" that are set to 0 for the respective heads. I simply forgot that I have to include the heads as an additional part for human AIs as these add a couple of variations (apart from ko-immunity the visual angles are reduced for AIs with helmets and/or eye patches). Another table I will have to add...

The gas_immune, appears to be amistake in the script. This is set to "0" in ai_base.def and set to "1" for the melee trainer, undead, and steambots.

can_drown is only defined for undead as "0" and I assume that the code handles that it is set to "1" if it is not defined (which appears to be the case for all other AI)

[Destined]

Regarding fov cones, I noticed that for guards with eye patches, it usually gets an fov_rotation of "-30 -20 0", which I assume turns the fov slightly to the right and thus only reduces the fov on the left side (where the eye patch is). However, for the two city guards with eye patches, this correction is missing. So far, they have "0 -30 0", the latter is a compensation of the reduced vision upwards. Just wanted to know if this is on purpose or was just missed...

[Destined]

I have another question for people who know the game well: How does the tactile acuity of AI work? Is it just an AI collision model touching the player's collision model or is there also a more complex machanic involved?

[Obsttorte]

I guess that the collision model is used. But I never checked in the code.

[grayman]

collision

[Destined]

Thanks, will include that.

[Springheel]

Regarding fov cones, I noticed that for guards with eye patches, it usually gets an fov_rotation of "-30 -20 0", which I assume turns the fov slightly to the right and thus only reduces the fov on the left side (where the eye patch is). However, for the two city guards with eye patches, this correction is missing. So far, they have "0 -30 0", the latter is a compensation of the reduced vision upwards. Just wanted to know if this is on purpose or was just missed...

 

Are you sure they're not inheriting the proper values from elsewhere? I can't remember exactly how I set it up now, but I think I made some 'master values' that were inherited by the heads that needed them.

[Destined]

Yes, you have made the "atdm:ai_head_base_eyepatch" base for guards with eyepatches, that have reduced field of vision (110) and a fov_rotation (-30 -20 0) to reduce the fov to only one side, and the "atdm:ai_head_base_cityhelm" base, that has a reduced vertical fov (100) and a further turned down fov_rotation (0 -30 0) due to the helmet.The entities atdm:ai_head_citywatch_eyepatch01 and atdm:ai_head_citywatch_poor_eyepatch01 combine the two visual constrictions. They use the "atdm:ai_head_base_eyepatch" base and "manually" correct for the reduced vertical fov. However, the "fov_rotation" was most likely simply copied from the "cityhelm" base and thus only has the "0 -30 0" correction of the vertical field, but is missing the horizontal correction from the eyepatch. The correctly combined "fov_rotation" should be "-30 -30 0". If you like, I can change it and post the corrected file here.

[Springheel]

If you like, I can change it and post the corrected file here.

 

 

I checked and you're right. If you wanted to paste the correct line below I can copy/paste it.