Explosives - Fix AI always knowing Sapper's location

[mrschick]

When merged this pull request will:

• Prevent AI from always knowing the exact location of the player who placed/detonated a mine or explosive.

At the moment, whenever AI is hit by the effects of a mine (both sensor- and remotely triggered), it immediately knows the exact location of the one who triggered and/or placed that explosive and will turn around to engage. This is especially annoying when conducting ambushes against AFVs.

It turns out that the code causing this is setShotParents, more specifically the second argument which defines the "vehicle which shot the projectile".
Setting that to objNull prevents AI from knowing the killer's exact position, causing it to enter a more realistic search pattern where they progressively turn to scan the terrain.

I'm not 100% sure whether unsetting killer will cause other issues. Don't think so though, since medical_status appears to have code in place to catch just those.

ACE3/addons/medical_status/functions/fnc_handleKilled.sqf

Line 37 in 1efe823

_killer = _unit getVariable [QEGVAR(medical,lastDamageSource), _killer]; // vehicle

[LinkIsGrim]

See #9190

@PabstMirror

[PabstMirror]

i dunno, for a while people complained about the opposite #2654
does [null, real] make them alert but not set knowsAbout on the player?

[mrschick]

See #9190

Ah, didn't notice that. Maybe it could be a (default on?) CBA setting instead? That would make it more noticeable.

i dunno, for a while people complained about the opposite #2654 does [null, real] make them alert but not set knowsAbout on the player?

Yes, with [player, player], immediately after being hit the affected AI will always knowsAbout -> 1.5, which is sufficient for vehicles to train their guns on the player's exact position, even through terrain, with no LOS at all. If that happens from a nearby observation position, it will take very little time for the AI to start engaging.

With [objNull, player], they know much less when the mine goes off, so they don't immediately know where to look, but they do get put into combatMode -> "COMBAT" if hit, so they will search and most of the time find you pretty easily if exposed.
I have not yet encountered a clear limitation of the AI which would make this a bad default implementation.

[mrschick]

Maybe it could be a (default on?) CBA setting instead?

Something like this maybe?

[LinkIsGrim]

There's already a variable, having two setters for this is overkill IMO.

If kill stats and vanilla AI aggression (as in, AI being alerted to an explosion) work, then 13dcc9b can be merged IMO

[mrschick]

Yes, but I would argue that the setting is more noticeable, more people are going to look through the settings than the framework documentation when it comes to setting up their server and missions.

I'm proposing only the setting, and getting rid of the variable flag.
Choosing between [null, player] and [player, player] is better than between [null, player] and nothing. Setting the instigator (2nd value) does not cause issues, people may want to set the 1st argument though for compatibility with some scripts.

[mrschick]

This would be an alternative implementation, only the variable, but the new default is [null, player] and enabling it will set [player, player].

[PabstMirror]

getPlayerScores player
and
acex_killTracker_outputText

both seem to work as expected with this pr and defaults