Weapon target check intervals

Jip

I'll use this post to keep track of discussions.

To answer @BlackYps , the latest log of changes (before / after) can be found here:

https://pastebin.com/4i86J4qj

List of units that have SPECIALHIGHPRI and SPECIALLOWPRI as their categories:

https://pastebin.com/fZ7Mcrep

I'd also like to note that the discussion is not about whether we're going to do this. It is about how we're going to do this. We're going to have to think in solutions. The performance we'd leave on the table by not doing this is unacceptable.

Issues

(1) Weapons have a lower reaction time, this is particularly noticeable with the delayed vision updates. As an example: a t1 scout can pass a t1 interceptor if they fly towards each other to some degree. The interceptor does not have the reaction time to take it down because there is a delay on the vision being updated and there's an (additional) delay on the weapon checking for targets (0.3 -> 0.7). This is not an issue when there is radar coverage.

(2) Some weapons have an extensive list of target priorities. It is not unusual to find more than ten different target priorities for a single weapon. These should be reduced to 4 - 8 elements each, depending on the expected instance count of a unit and its attack radius. As an example: an experimental can have 8 because you can count the number of active instances on one hand. A Mantis should have at most 4, as we can have hundreds of those walking around.

Solutions

(1) After a suggestion of BlackYps the approach to compute the target check interval has changed slightly. All interceptors happen to have the same target check interval as before.

(2) We could remove the SPECIALLOWPRI, SPECIALHIGHPRI and ALLUNITS categories from all weapon target priorities lists. These are either operation related, improperly used or out of place. As an example, take the target priorities of an Aeon T4 Rapid Fire Artillery:

TargetPriorities = {
    'EXPERIMENTAL MASSFABRICATION',
    '(EXPERIMENTAL * ARTILLERY - FACTORY)', -- don't include fatboy
    'TECH3 ANTIMISSILE',
    'NUKE STRUCTURE',
    'TECH3 STRUCTURE ARTILLERY',
    'TECH3 ENERGYPRODUCTION',
    'ORBITALSYSTEM',
    'EXPERIMENTAL MOBILE',
    'TECH3 STRUCTURE',
    'TECH3 MOBILE',
    'STRUCTURE',
    '(ALLUNITS - SPECIALLOWPRI)',
},

Even though storages are set to SPECIALLOWPRI, they are also a STRUCTURE and therefore they still have a higher priority than all the other units.

Impossibilities

(a) We can not change the logic that is used to determine viable targets. That is part of the engine. We can only change the parameters.

BlackYps

Did many (or all?) units constantly recheck targets before?

Sprouto

It is a valid option, but it's not super widespread - and it is a valid option in certain cases. Combined with the targeting interval - it can be a performance issue - especially if the priority list is long ( each and every category is checked every interval so it multiplies very quickly ).

Jip

@blackyps said in Weapon target check intervals:

Did many (or all?) units constantly recheck targets before?

I'd need to check, but I think the majority did yes.

maudlin27

Just to check re the point about never rechecking for targets if one has already been found, does that mean if I fly an air scout over a bunch of T1 MAA, followed by bombers, the T1 MAA will all target the air scout (it's the only unit they see), and if they fail to kill it (often the air scout travels too fast, unless its cybran MAA or is going almost directly at the MAA) theyll keep trying to target it while the bombers are free to cause carnage as long as the air scout stays within range of the MAA?
Similarly a land scout could be used to distract Aeon T2 PD (although it'd require more micro) allowing a guncom to close in without taking damage if the opponent isn't paying attention?

Jip

All ground to air units (and structures) are allowed to retarget, exactly because of that reason. See the paste bin dumb .

As an example:

Processing: ueb2204 (<LOC ueb2204_name>Air Cleaner)
 - Weapon label: Fragmentation Flak
 - - WeaponCheckinterval (prev): 0.30000001192093
 - - WeaponCheckinterval (post): 0.5625
 - - AlwaysRecheckTarget (post): true
 - - TrackingRadius (post): 1.1499999761581

thecore

"100 units with each 50 targets and 5 priorities: 100 x 50 x 5= 25.000 checks*"
I wonder if targets can be sorted by distance from each unit and also targets separated into priority groups.
So instead of each unit checking all near by targets, they just check the nearest enemy unit per group.
arrayPriorityGroupEXPERIMENTAL[0]
arrayPriorityGroupSNIPER[0]
etc

So if you had 100 units, checking 5 groups each having 50 units in them then you only need to check the nearest unit per group and then decide which one has priority.

In the example the unit would target the nearest unit ranked by Priority. So if there was a unit with q higher Priority it would target that unit instead.

Not sure if this would be a improvement or not as sorting can be quite taxing on performance.

Jip

I'm afraid that all of this is part of the engine. And we can not rewrite the logic.

Ctrl-K

@thecore not the best idea sorting according distance: nearest unit stays behind and you have to turn weapon to it.

MazorNoob

Will setting target priority affect AlwaysRecheckTarget? If I'm sending a few tanks to kill engies and an enemy tank gets into range first I'd rather they switched to an engie when possible. Same issue with e.g. killing power in a raid, switching immediately vs. in 10 seconds after killing some tanks makes a difference.

ZooDoo4U

I'm wondering what changes have been made since vanilla SupCom? I've played a long time, never saw where enemy units would get in range and not fire at them. Remember seeing a couple people asking about this scenario "Anyone see enemy units move in range but never fire..."? I'm starting to notice more and more in most every game. Not only this seems the game in general keeps getting more and more laggy with each successive patch.

Also no way to make the checks key or hash lookups rather than an n*m list match?

thecore

@bluescreenof4z0t maybe check nearest unit within line of sight first before checking any distance.

Jip

Remember seeing a couple people asking about this scenario "Anyone see enemy units move in range but never fire..."?

That is this scenario:

https://forum.faforever.com/topic/3805/cybran-t2pd-having-problems-targeting-and-not-firing-at-targets-in-range

We're fixing that too, as structures will no longer have a scanning radius (for targets) that is larger than their own range.

Not only this seems the game in general keeps getting more and more laggy with each successive patch.

This is the case for single player games. It is fixed with:

https://github.com/FAForever/fa/pull/3837

It is available on FAF Develop. I can highly recommend you to give it a try, especially if you play alone. The benchmarks show a 30% to 40% performance increase when you play alone on FAF Develop .

I'm wondering what changes have been made since vanilla SupCom?

A lot - in particular with the complicated target priorities. This can cause the issue that you describe where a unit 'waits' for a more valuable target to get into firing range.

arma473

@jip said in Weapon target check intervals:

structures will no longer have a scanning radius (for targets) that is larger than their own range

This allows turrets with no target to turn towards an incoming target? That's not a bad thing.

Jip

@arma473 said in Weapon target check intervals:

@jip said in Weapon target check intervals:

structures will no longer have a scanning radius (for targets) that is larger than their own range

This allows turrets with no target to turn towards an incoming target? That's not a bad thing.

It is when we have overly complicated target priorities. Take this forum thread and my answer in the second post:

https://forum.faforever.com/topic/3805/cybran-t2pd-having-problems-targeting-and-not-firing-at-targets-in-range

Brutus5000

I'm not really into the details, but checking the same thing over and over again seems a bit weird, when there are good data structure such as a priority queue.

Assuming the engine gives us access to events (a) a target entered turret range (b) a target left turret range (c) a target is no longer accessible (destroyed/submerge/lifted off).
For a) Determine the targets priority and add it to the priority queue.
For b) Delete it from the priority queue
For c) Delete it from the priority queue
For d) A user changes the priority: recalculate priority queue (but with same targets)

For determining the current target: Take the first item from the priority queue.

No need to iterate over all targets in range every recheck interval.

Jip

The targets are computed in the engine. We only have the parameters and the output that we can work with in Lua. Anything else requires assembly patches.

KaletheQuick

Would it be possible to enforce some limit on target priorities? Like t1 can have 2 priorities, then some "ALLUNITS" catchall, t2 4, t3 6, exp 8? And enforce it so ATP mods don't interfere?

Or would batching or target sharing be possible? Like one unit of a type can just 'give' its target to a nearby unit of the same type? Or I guess a unit searching for a target asks nearby allies of the same type for their target, checks if it's in range/valid, and then if not proceeds with a whole target check?

Jip

Would it be possible to enforce some limit on target priorities? Like t1 can have 2 priorities, then some "ALLUNITS" catchall, t2 4, t3 6, exp 8? And enforce it so ATP mods don't interfere?

That is what I'd like to have - yes. Perhaps not that extreme, anywhere between 4 to 6 is fine. But 10+ is a bit much. The balance team isn't quite in favor yet.

Or would batching or target sharing be possible? Like one unit of a type can just 'give' its target to a nearby unit of the same type? Or I guess a unit searching for a target asks nearby allies of the same type for their target, checks if it's in range/valid, and then if not proceeds with a whole target check?

I'm afraid that finding nearby units is a similar query to finding nearby targets .

Jip

I've given this some thought and I think we can have a good compromise.

We can make a distinction between the 'primary' purpose of the unit and all the 'secondary' things that a unit can do too.

As an example, take the T2 UEF Transport. The primary purpose of the transport is to transport units. It is accompanied by two air to ground guns and two air to air guns with the following statistics:

-- air to ground

-- damage related
Damage = 3,
RateOfFire = 3,

-- performance related
TargetCheckInterval = 0.3,
AlwaysRecheckTarget = true
TargetPriorities = {
    '(ALLUNITS - SPECIALLOWPRI)',
},

-- air to air

-- damage related
Damage = 12,
RateOfFire = 1,

-- performance related
TargetCheckInterval = 0.5,
TargetPriorities = {
    '(ALLUNITS - SPECIALLOWPRI)',
},

We can all agree that the weapons are not impressive. We can also all agree that nobody would ever use a t2 transport for anything beyond transporting units. These weapons primarily exist for aesthetics.

Similarly, we can identify that:

The weapons of scouts (with the Selen as exception) are secondary to the purpose of the scout
The anti air weapons of frigates are secondary to the purpose of a frigate
The anti air weapons of destroyers are secondary to the purpose of a destroyer
The direct fire weapons of cruisers are secondary to the purpose of a cruiser
The anti air weapons of any tech 3 naval vessel (with the air carriers as exception) are secondary to their purpose
The anti air weapons on the average gunship / bomber (with the restorer as an exception) are secondary to their purpose
The anti air weapons of the average ground experimental is secondary to their purpose

And we can find some more candidates by looking individual units.

Performance

With that we define the 'primary' weapons to be the weapons that the unit is supposed to be using, and all other weapons are 'secondary' to give the game a more aesthetical feeling.

We can immediately see the impact on a reasonable scenario. Take 100 frigates in formation with 300 hostile ASF patrolling in the center of the formation.

Current situation, game is running at about 10 - 12 ms / tick, with a sudden jump to 25 - 28 ms / tick about every second

With the suggested changes of the next chapter, game is steadily running somewhere between 8 to 10 ms / tick and there's no sudden jump

Changes

With all of that said, I'm suggesting the following changes for primary / secondary weapons:

Primary weapons

TargetCheckInterval = math.max((0.5 * (1.0 / RateOfFire)), 0.5)
AlwaysRecheckTarget = true
TargetPriorities = { something between 4 to 6 elements }

This means that primary weapons can respond to change, they can have decent target priorities and their check interval is reasonably fast in comparison to their attack speed.

One exception: the primary weapons of an experimental unit are allowed to have a lower target check interval and have additional target priorities.

Secondary weapons

TargetCheckInterval = math.max((1.0 * (1.0 / RateOfFire)), 1.0)
AlwaysRecheckTarget = false
TargetPriorities = { ALLUNITS }

This means that the secondary weapons are unable to respond to change, have a lower target check interval and they make no distinction between valid targets.

What is next

Unless I've been persuaded of anything else I will push this through into the game in about two weeks. Therefore use this topic to discuss this - what are the pros and cons? Is it worth the performance? Should we do this or not?

I also highly recommend everyone to replicate the scenario used in the performance section. You can view the sim time (ms / tick) by opening the console (using ~ hotkey) and then typing ren_ShowNetworkStats. If it suddenly closes, type an e first and then remove it again.