Weapon target check intervals

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.

maudlin27

@jip While I agree in principle with the idea of having simple checks for a secondary weapon where that weapon's effect is negligible, I'd disagree with making it as broad as 'if it's not the primary purpose then downgrade it'.

As an example, you mention cruisers with direct fire weapons. Sometimes I will build a Cybran cruiser for the primary purpose of using its direct fire weapon, since on some maps it's the optimal unit for taking out a firebase (although having said that I dont actually know what its default priorities are so maybe it wouldnt make much difference).

Seraphim sub hunters would be another example where you might build them both for the AA and for the anti-sub capabilities.

Other examples where you might build a unit for a combination of its weapons/non-primary purpose would be restorers, and in theory continentals (although in practice they're a bit too weak to use efficiently as a combat unit that can also sometimes transport units)

I'd therefore suggest a stricter threshold, where the weapon must both be a secondary purpose, and also be very bad at that secondary purpose. So for example a fatboy's anti-air or a transport's air to ground would fall into that category, but a Seraphim sub hunter's AA or a Cybran cruiser's direct fire attack wouldnt.