Bots hold cover angles towards incoming threats

[sunzenshen]

Description

Bots have a very short memory of recent unseen threats (3 seconds), so in order to encourage bots to hold threat angles for a longer period of time, we use the directional movement of the potential threat as a general heuristic of whether the threat is still pursuing the bot.

Toolchain

• Windows MSVC VS2022

[sunzenshen]

When neo_bot_remember_incoming_threat_debug is enabled, yellow indicates where the bot remembers was the last known location of the threat, and red indicates the difference between the last known position and the actual position.

The usual 3 second timer is delayed if the threat is still moving towards the bot, assuming the last known position is not visible.

Note that this does not affect what threat the bot prioritizes, it only extends the memory that a threat used to be at previous location, so if the bot does not have any other threats, it will use CNEOBot::UpdateLookingAroundForEnemies to infer what is a potential visible area that the threat could emerge from, given the last known position. Since this tweak only affects the lifetime of a known threat, it does not directly effect which threat is chosen from GetPrimaryKnownThreat, so bots can still engage other targets while remembering the last known position of older threats.

One known side effect is that this does cause bots to retreat for longer periods of time, hence the velocity check to see if the threat is moving closer. This directional movement check prevents two bots from indefinitely retreating away from each other.

It may also be worth waiting to see the interactions with PR #1651, as bots may throw more grenades due to the longer timers further allowing bots to find cover while still remembering a threat.

[Rainyan]

Perf nit: WorldSpaceCenter is more expensive to calculate than GetAbsOrigin. Since we only care about the relative direction vector rather than exact position, perhaps favor the latter?

[Rainyan]

Do I understand correctly that this is effectively the bots cheating? I'm not sure how I feel about it, especially since this is a behavior directly intended to combat against the player being cheated, which could feel a bit unfair.

I could also see a problem where a shrewd human player would learn to recognize his fellow bots staring at an angle fixedly to mean there is a target there, giving them a kind of wallhack-by-proxy.

One hacky way around this could be to make it probabilistic, so the bot may or may not identify an incoming threat, who may or may not be a false positive. Sort of emulating how human players can have a hunch and hold a completely irrelevant angle, or sometimes predict the push perfectly. This would also make it moot to try and use the bot holding behavior to proxy-wallhack the enemy.

[sunzenshen]

Another approach could be to estimate how long it could take for an enemy to arrive at an emergence point near the bot, and add to the timer based on this travel estimate.

That said, such an approach might take more computation, and I'd like to merge in other PRs to get an idea of how much CPU budget we have left with various player machines. If it turns out that we have more budget for calculations, it could be a good idea to consider such advanced reasoning.

[Rainyan]

Scheduling some kind of think timer to the future sounds like a good idea. I imagine it's not much more expensive than NavAreaBuildPath, plus storing the total length and dividing by class speed.