[Customize & New Feature]Targeting Optimizations

[TaranDahl]

1. Technos won't SelectAutoTarget if they are not IsArmed. Didn't check thoroughly, more tests or disassembling are needed.
2. New flags to customize the scanning delay per techno, and differently for player and AI. Default to the vanilla flags NormalTargetingDelay and GuardAreaTargetingDelay. As enemy scanning is a costly part of the total overhead, this should be able to improve the performance, especially on the maps with numbers of enemies.

[General] or [SomeTechno]
AINormalTargetingDelay=
PlayerNormalTargetingDelay=
AIGuardAreaTargetingDelay=
PlayerGuardAreaTargetingDelay=

P.S.: The docs are coming, s∞n.

[MortonPL]

Documentation please

[github-actions[bot]]

Nightly build for this pull request:

• compiled-dll-e812b1143aac647c74a6cc996b25336105a5c265.zip These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[TaranDahl]

Documentation please

It's here now.

[TaranDahl]

This can be merged after tests.

Some friends in Chinese community tested this. No fatal error, desync, or misbehavior was found. Didn't check for edge cases carefully, though.

[mevitar]

Deployed infantry appear to be ignoring these tags. In fact, they also appear to be ignoring the two original tags. They shoot immediately at anything that gets nearby, no matter how high delay values i set. Some hardcoded behavior for deployed infantry, i suppose.

Didn't notice any other issues.

[TaranDahl]

From my personal perspective, the implementation of DistributeTargetingFrame may not be as efficient as modifying the random range of TargetingTimer which is default to (0,2).

Yeah. It does incur some additional overhead. However, its purpose is not to replace that randomness. It is designed to address the frame rate drops caused by the periodic auto-targeting of a large number of units pre-placed on the map.

[CrimRecya]

Yeah. It does incur some additional overhead. However, its purpose is not to replace that randomness. It is designed to address the frame rate drops caused by the periodic auto-targeting of a large number of units pre-placed on the map.

If that's the case, then I think we can try to make TargetingTimer start a random value during TechnoClass::Init?

[CrimRecya]

The Tanya’s problem mentioned in the doc should have been resolved, remember to remove it.