Make radar position error configurable per emitter

[WatchTheFort]

Currently, radar wobble is by default a global setting, controlled by the isTargetingUpgrade unit def tag, and the SetRadarErrorParams callout. It can also be configured per-unit with the SetUnitPosErrorParams callout.

The desire is to base radar wobble on the radar coverage of the specific unit, where position error parameters can be set per emitter. When multiple emitters cover the same unit, a method would be required to specify whether the wobble should be based on the maximum individual emitter strength, or the combined individual emitter strengths.

Proposal

• Add new unit def tags, radarError and sonarError, integer of how much radar wobble to apply
• If unspecified, use the default value as exists in current functionality
• Add new modrule, BaseRadarError, integer for default amount of radar wobble
• Add new modrule, CombinedRadarErrorReduction, string with values maximum, additive
• Calculate radar wobble for each radar blip based on the strength of the emitters detecting that blip, before applying any effects from isTargetingUpgrade

[sprunk]

Add new modrule, BaseRadarError, integer for default amount of radar wobble

Make a 1-liner gadget.

function gadget:Initialize()
  local baseRadiusInElmos = 96 -- default
  local baseReductionMultiplierPerUpgrade = 2
  Spring.SetRadarErrorParams(0, baseRadiusInElmos, baseRadiusInElmos, baseReductionMultiplierPerUpgrade )
end

Add new modrule, CombinedRadarErrorReduction, string with values maximum, additive

bool?

Add new unit def tags, radarError and sonarError, integer of how much radar wobble to apply

Names would ideally be something like radarErrorReductionLevel.

[marcushutchings]

I definately vouch for the combined strength approach over using a max function. It avoids the need to walk lists when a RADAR zone is abandoned by the current strongest unit. The difference in performance would be significant - especially we are targtting larger scale games than most RTSes.

[WatchTheFort]

Sounds good, for our desire of making T1 radars have wobble and T2 radars not, we would just make the the T2 value >> T1 value

[ChrisFloofyKitsune]

To combat spamming a bunch of T2 radars in a box of walls, we could have a gadget such that wobble reduction is adjusted to be weaker for a T2 radar based on how many other T2 radars are nearby

in other words, make T2 radars interfere with each other's ability to reduce radar wobble if there's not enough separation between them

[WatchTheFort]

@ChrisFloofyKitsune That's not the gameplay design we're aiming for, so we'll just make T2 radars strong enough that a single one is sufficient, and adding more will have no discernable effect.

[marcushutchings]

While a nice idea. I think we need to try and keep RADARs as simple a reasonably possible. RADAR is a minor feature of these games. I feel the only reason we're having this discussion is because the RADAR wobble feature was added a long time ago as a random idea and we have got used to it being there rather than wanting it specifically. If it wasn't there in the first place, I don't believe any games currently on the engine would be requesting the feature.

[GoogleFrog]

If it wasn't there in the first place, I don't believe any games currently on the engine would be requesting the feature.

I disagree. There would be some design problems to solve if radar wobble didn't exist. Radar wobble isn't the only solution so we wouldn't necessarily settle on it, but I think it is a particularly good solution.