Weapon target check intervals
-
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 -
"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]
etcSo 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.
Never Fear, A Geek is Here!
-
I'm afraid that all of this is part of the engine. And we can not rewrite the logic.
-
@thecore not the best idea sorting according distance: nearest unit stays behind and you have to turn weapon to it.
-
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. -
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?
-
@bluescreenof4z0t maybe check nearest unit within line of sight first before checking any distance.
-
Remember seeing a couple people asking about this scenario "Anyone see enemy units move in range but never fire..."?
That is this scenario:
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:
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.
-
@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.
-
@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:
-
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.
-
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.
-
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?
-
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
. -
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 jumpChanges
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 typingren_ShowNetworkStats. If it suddenly closes, type anefirst and then remove it again. -
@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.
-
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).
This is an example where I would not consider their direct fire a 'secondary' weapon. They actually do decent damage, they can actually take out a unit. I was thinking of the UEF / Aeon cruisers when writing this
Seraphim sub hunters would be another example where you might build them both for the AA and for the anti-sub capabilities.
Another example where it is not a 'secondary' weapon in the sense that it can actually take out a torpedo bomber.
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.
I agree - you phrased it better than I did.
-
Everything here sounds pretty good to me. I personally hate when units decide to change targets themselves and leave a unit nearly dead. Unfortunate we hit another limit of not having engine access though. That said, good job working with what you have access to Jip.
-
@snagglefox said in Weapon target check intervals:
Everything here sounds pretty good to me. I personally hate when units decide to change targets themselves and leave a unit nearly dead. Unfortunate we hit another limit of not having engine access though. That said, good job working with what you have access to Jip.
Me too - I'd prefer them to just fire away. But that is something to discuss with the balance team.
-
This post is deleted!
