Jump to content
.kju

Arma 3 targeting review - revision 2

Recommended Posts

As follow-up to the first such analysis for A3, here is the second revision.

I am looking for input on mistakes, forgotten aspects or topics, or simple and specific suggestions to improve the current state.

 


 

Let me first give a brief high level overview/demonstration of some of the core fundamental issues in practical terms:
 
1)
Once a capable player gets into a plane or chopper with AT missiles, it virtually stops all ground vehicle use as the radar picks up targets even beyond viewable and "viewdistance" (engine term) range easily and reliably.
So he flies high enough, spams "next target (in veh)", gets all hostile targets assigned instantly, shown with target type info and crew member name in MP, and missiles hit very reliably.
 
Ground base AA is only a limited threat for a couple of reasons (simple CM mechanic, static unit vs extremely mobile and flexible unit, teamwork, AI abuses, etc).
Overall the usual engagement is also too extreme - either air unit is dead or AA unit is dead in a matter of moments. Who spots ("next target (in veh)") who first.
 
 
2)
A capable player operates tanks by himself as:
  • easier to operate alone and instant switching of positions inside a vehicle
  • mobile tank is far weaker compared to stationary tank due
  • vehicles with engine off turn to white radar target and thus cannot be "next target (in veh)"ed/ - "lock target" is required to use instead (where you need to know yourself about the target/where to click/have some game mechanic challenge to achieve it)
  • thus mobile is very prone to die against air units
  • a player spams "next target (in veh)" as gunner/commander for mobile targets and "lock target" on the horizon or the area stationary targets are assumed to be
  • this way he will lock the hostile vehicle very fast and as stationary tank cannot be "next target (in veh)"ed 
  • while the mobile in addition has the downside of motion and movement which makes awareness way harder
  • its easier to move alone - one moves from building to building (white radar signature), or woods/trees to some degree (reduce radar effectiveness somewhat) trying to find protecting from locking that way
 
3)
If available, players use AI to operate vehicles, even though the pathfinding is a big problem, as AI is even more efficient in radar use, target identification and fast engaging; mostly as stationary or semi mobile "gun turrets" (with the downside of AI not being as flexible and dynamic as good humans reacting to various situations)
 
 
Brief overview of the underlying engine functionality issues:
  1. Radar works way too well/powerful - basically a sphere around the unit; if unit is within, it gets identified.
  2. The exact working of the radar system is unknown and non obvious to players. Experts know some parts and abuse these elements (ie engine off=>white radar signature=>"next target (in veh)" no longer works; or importance of "next target (in veh)"; or spam use of "lock target" on horizon to lock targets beyond object draw distance, or use of AI to reveal targets as the info share within the group is basically perfect).
  3. Identification of hostile works way way too well. Its just side based of the vehicle, plus if engine is running (plus some distance aspect to it, yet thats very minor) - and info sharing within the group. Important - its not such much about hostile vs friendly (or neutral) - its about hostile => red radar signature => enables "next target (in veh)"ing.
  4. Locking is based on viewdistance (terrain drawing distance setting) and not on object drawing distance. So even irScanToEyeFactor=1 allows locking beyond drawing distance - aka you can lock targets in the distant fog.
  5. AI mechanics (knowsAbout system, precision, etc) vs Player vs AI ("player need the simple system or otherwise AI is way too strong") vs Player vs Player each have their own constraints and requirements - hard to balance them all with realism as target and limited resources to adjust the existing system
  • Like 26

Share this post


Link to post
Share on other sites

Suggestions:

 

1. EHs

  • "detected" (entity on the radar) - returns: _sourceVehicle, _targetVehicle, _awareness (based on cfgVehicles accuracy - like vehicle/tank/M1A1), _relation (unknown/neutral/friendly/hostile)
  • "targeted" - returns: _sourceVehicle, _targetVehicle, _weapon, _magazine, _muzzle, _lockType (ir, nv, laser, air) - triggered when vehicle locks a target with any weapon type - action "vehLockTargets", "lockTarget"
  • "untargeted" - returns: _sourceVehicle, _targetVehicle, _weapon, _magazine, _muzzle, _lockType
  • "lockAcquired" - returns: _sourceVehicle, _targetVehicle, _weapon, _magazine, _muzzle
2. SQF cmds
  • "_vehicle setVehicleTarget _targetVehicle" (objNull to unset) (could be also type specific (IR/NV/Laser/Air) or the parameter an array [_targetVehicle,_lockType])
  • "_targetVehicle = getVehicleTarget _vehicle" (objNull if nothing targeted) (could be also type specific (IR/NV/Laser/Air) or return an array [_targetVehicle,_lockType])
  • "_vehicle setLockAcquired _targetVehicle" (objNull to unset)
  • "_lockAcquiredVehicle = getVehicleLockAcquired _vehicle" (objNull if nothing lockAcquired)
  • "_vehicle setWeaponTargetAbility [_weapon,_type,_boolean]" - change ammo/weapon attribute (a la setUnitTrait) from https://community.bistudio.com/wiki/A3_Targeting_config_reference - most importantly irLock, airLock, nvLock, laserLock (canLock may work too and could be easier to realize (weapon instead of ammo)
  • "_vehicle setVehicleTargetSignature [_type,_boolean]" - irTarget, nvTarget, laserTarget
  • "_vehicle setMaxLockRange [_weapon,_distance]"
  • "_vehicle setMinRadarDistance _distance"
  • "_vehicle setMaxRadarDistance _distance"
3. Config parameters4. Difficulty options5. Engine6. AI info share within groups
  • AI far away still reports targets close to player position
  • one can (ab)use radio "2 - targets" to "target" the vehicle accurately or assign as target for other AI (way too reliable and simplistic)
  • one can (ab)use AI, ie drones, to spot targets far away and use radio "2 - targets" to "target" the vehicle accurately or assign as target for other AI
See also:Related:
  • Like 15

Share this post


Link to post
Share on other sites

Misc:

Targeting:

laser/wire/radio guidances = manual aiming until impact

radar/auto tracking/IR guidances = autolock (current "next target"/"lock target") fire and forget style

Difficulty settings:AI:Dedicated server:
  • No longer possible to set/change difficulty during mission selection as admin on dedicated server
  • Like 10

Share this post


Link to post
Share on other sites

Wow, nice! This will take some time to process :) Thanks a lot for all the notes and re-reviewing your previous ones!

  • Like 15

Share this post


Link to post
Share on other sites

One of the most informative and well thought out/researched posts I think I've seen on these forum. Kudos! 

  • Like 4

Share this post


Link to post
Share on other sites

Very comprehensive .kju !  Will be interesting to get some action on these points, as they are quite important.

  • Like 3

Share this post


Link to post
Share on other sites

I'd say we need Advanced Radar Model (aka RadarLib). :P

 

 

... maybe one day :wub:

  • Like 3

Share this post


Link to post
Share on other sites

Two short comments:

1. The tickets of these two points contain very good analysis and specific suggestions. As such I haven't added them in detail again here. These two core topics that should get attention.

  • Improve countermeasures and warning system
  • Improve radar and friend-foe-identification (IFF) simulation
PS: Similar is true for the AI ticket "Improve AI info share system and AI weapon use on non visible targets system".

2. The AI analysis is rather shallow for two reasons:

  • It's unlikely to see fundamental changes any time soon here as this a very complex part of the engine and AI routines in relation to the targeting/revealing system.
  • As I haven't done a deep analysis of the state of things with AI in A3, I cannot speak with authority here. Maybe some folks from the CTI community or people using AI command systems can pitch in instead.

Share this post


Link to post
Share on other sites

I'd say we need Advanced Radar Model (aka RadarLib). :P

 

 

... maybe one day :wub:

 

That, and a more "organic" target/info sharing system between the AI - that part really needs some love.

I'm no specialist here, but it feels like not having a radio doesn't even impact the way AIs of a same group communicate.

  • Like 6

Share this post


Link to post
Share on other sites

Even shouting over 50m is quite difficult to hear clearly IRL, nevermind a battlefield going on around you!  Not having a radio should adversely affect the AI... just sayin'

  • Like 3

Share this post


Link to post
Share on other sites

It's amusing how uber thorough posts like this have a propensity to squash discussion.  I'm thinking it's because a would-be-poster thinks twice about spamming some half thought out comment or complaint cuz they know for a certainty that OP's got the goods. 

 

Amazing post

  • Like 5

Share this post


Link to post
Share on other sites

it feels like not having a radio doesn't even impact the way AIs of a same group communicate

Correct, it doesn't. Radio only affects players, sounds and subs. AI will always have "a radio". Redesigning radio and commanding is out of Arma 3's scope.

Share this post


Link to post
Share on other sites

Redesigning radio and commanding is out of Arma 3's scope.

 

emo.png

  • Like 2

Share this post


Link to post
Share on other sites

 

For the most part, I think those are mainly feature mechanics rather then technical limitation. The guns on helicopter do have dispersion, just at longer ranges. I'm sure they could mount a laser designator on every helicopter, but that would start eliminating other assets for usefulness. It's pretty saturated enough with the Darter being king of marking targets. 

Simulation of lock on/radar system could be improved in more simple ways, without going super complex IMO. For example, you can add option to make it so they only lock on laser designations, or give very limited information on what your locking onto at long distances. I think simply having options to tweak how the lock on system works in general would be awesome.

 

Share this post


Link to post
Share on other sites

Thanks for this research.

 

I will contribute a bit here as the radar systems are of interest to me and my SAM pack.

 

I agree with the "more radar is better" statements.  There ARE new values being added so fortunately I think BIS is progressing in this area.

 

I am approaching the issue with a slightly different approach.  I'm looking at this through the lens of how to make all the SAM's behave like their Real Life counterparts, to the extent of the public information we have about them.  To that end, I have made several scripts that adjust targeting based on certain loops with a throttle that is based on a random chance of success, leading to the next loop.  This is intended to indicate the "human reaction" factor that humans will take time to process and react to the threat.  While not perfect, it is a starting point. 

 

From that starting point, the skill set of the radar-controlled SAM launchers is altered whenever one of the supporting on-site vehicles is destroyed... for example the destruction of a secondary or tertiary radar vehicle will lower skill set by 10-30% based on the system.  Again, not optimal but it does achieve the effect of a behaving as a less-capable system.

 

Finally, I have added new values to my custom missiles:

- Home On Jam:   Does the missile possess “Home On Jam†capability?
- Frequency Hopping:  Does the missile possess frequency hopping capability?
- Radar Band:  Identifies the radar frequency band used by the missile and/or radar vehicle

The use of these new values is realized in the electronic counter-measures scripts or use of the incomingMissile EH.  The scripts could use something like this to read these values:

_target = _this select 0;
_ammoType = _this select 1;
_HOJ = [(configFile >> "cfgAmmo" >> _ammoType),"pook_HOJ",2] call BIS_fnc_returnConfigEntry;
_Band = [(configFile >> "cfgAmmo" >> _ammoType),"pook_Band",2] call BIS_fnc_returnConfigEntry;
_HOP = [(configFile >> "cfgAmmo" >> _ammoType),"pook_HOP",2] call BIS_fnc_returnConfigEntry;

The ECM scripts will attempt to spoof/jam/break the incoming missile based on the capabilities of the aircraft on-board jamming system.  The script use is pretty basic - read the script, use those return values in an if-then statement or similar for determining how much to spoof/redirect the missile.  Adjust this amount based on the distance, etc.  The script will return a "default" value if these values are not present, so any missile threat can be spoofed.  The variations of the on-board jamming systems can now be modeled to a higher degree of realism instead of "load it with more flares" which is the only things possible at present.

 

 

 

It is my belief that these values will increase the end-user experience because it goes from "spam the flare button" to proper engagement and use of the jamming system.   It will allow a more realistic capability to be simulated, and the "useless" slots used by jamming pods can now be made to do something instead of purely being eye candy.

 

Hopefully this information will help the discussion...

  • Like 1

Share this post


Link to post
Share on other sites

Perhaps a module or global command enabling the AI to target and fire upon empty enemy vehicles would help?

 

It's always been a bit of a hack/cheat when under fire from enemy AI when in a vehicle - just jump out and they stop shooting (at the vehicle at least).

 

From the early OFP days it has struck me as a little silly that the AI can distinguish between a manned vehicle and an unmanned one. If you're in an M1 Abrams and you see a T-72, you shoot it, end of story. AI behaviour should reflect that.

  • Like 1

Share this post


Link to post
Share on other sites

I have been told to post here. So here I go.

 

A friend and I had great fun in KOTH using the laser designator and Titan AT to hunt vehicles. Its been a while since we played and it seems like the feature has changed.

I can lock the laser with "T" but instead of a solid lock I get this http://i.imgur.com/rQhntnm.jpg no beeping either and the rocket is just flying by wire ignoring the laser (Tested with AT and AP Titan).

Are we doing something wrong or has it been removed/changed? Heres how a solid lock should look from back when it worked http://i.imgur.com/VhpnzXl.png

  • Like 1

Share this post


Link to post
Share on other sites

I really don't know whether the 'red' vehicle is modelling some miraculous ability of radar to see vibrations from a running engine(!) or whether it's supposed to reflect a heat signature (IR). Obviously moving vehicles should show up with priority tasking on a combat radar, in that instance the 'red' state is justified, otherwise, with radar all stationary vehicles should be white.

 

If the targeting vehicle also has IR detectors in addition to or as an alternative to radar, then the vehicles heat signature (already modelled) should be used to determine 'red' state. Therefore simply turning off the engine of a tank wouldn't result in it instantly turning 'white', it would remain 'red' until it had cooled down to match the air temperature.

 

Would those changes not help with the balance, or failing that at least it would be more realistic.

 

I also liked the suggestion that all vehicles, enemy or friendly should appear on radar forcing the pilot to correctly identify targets not fitted with a transponder or reverse-IFF systems before they engage.

Share this post


Link to post
Share on other sites

Originally a discussion in the Arma Discord (#arma_gameplay channel), here are my thoughts about radar stuff and missiles. Mostly oriented towards organised (non-milsim) community gameplay:

 

(contains ideas that may be influenced by kju's OP, -FM-, Vauun, X3KJ, Boberro, Zitron, Aqarius)

 

Radar

 

Currently the radar makes no sense. It appears to pick up both IR and radio waves, suffers no distortion, can distinguish between a "live" and disabled vehicle, etc.

 

When thinking of what purpose a radar serves in Arma, it's important to look at the "authentic military" angle, and the pure game-play angle. What and how is it functioning, and does it lead to good gameplay? Of course this must be looked at from the angles of both single player, multi-player and coop. I will really only be focusing on the later two, and frankly coop oriented systems will ultimately influence single player systems too, as this affects AI.

 

First things first - who/what should get a radar? Well, only things that can use a radar in real life. You're limited to AAA/SAM systems, helicopters, planes, naval vessels. Anything else that gets a radar of any sort needs to sacrifice armour/weaponry (e.g. recon vehicles)

 

Now, what should this radar be able to detect? IRL you have separate air/ground/sea radars. In Arma, while this would be nice, I can understand the possible reluctance to add even more keybinds, however, this should add more depth. Of course, only aircraft should get something like this - ships should get sea radar (but air radar optional), and ground vehicles should only really get air radar. This should still be the case, even if the radar is combined - i.e. only aircraft should be able to detect all three.

 

In terms of signals received: only radio signals should be detected by radar. So while planes should appear to both ground based radars and ship/plane based radars, ground vehicles without an active radar should not appear on another vehicle/plane/ship's radar. In other words, IR signals should not be picked up by radar, because that's silly and wrong. Radar stands for Radio Detection and Ranging, not infra-red detection and ranging.

 

So, what should be the range of a radar? I think that should depend on the object to which the radar belongs. The Cheetah and Tigris, for example, could have a config set max radar range (say of 5000m). Anything within this range shows up on the radar, and can be targeted and tracked, irrespective of viewdistance settings. Optionally, it could also be possible to change

 

Last of all for this section, should the radar be influenced by terrain/clutter interference? Absolutely, if possible (and it is, ACRE2 does this for its radio simulation).

 

Consequent Changes to Mechanics Influenced by Changes to Radar

 

  1. SEAD should now be viable mechanic. Since only active ground radar should show up, land or ship based AA should be detectable by SEAD planes (but only target-able when the appropriate weapon is selected.
  2. Following from (1), turning off AA radar should now be an option to avoid detection (via action menu, maybe, like the engine is). However, this means that target detection information is unavailable, of course.
  3. Any weapons that rely on radar lock should now only be effective when the radar lock is present.
  4. From (2), (3), it is clear that AA systems with their radars off shouldn't be able to use their weapons properly, i.e. guns don't get lead indicators or target range info, and missiles just fly straight and unguided.
  5. Weapon systems on the same vehicle/plane/ship that do not rely on radar lock should still function as always.
  6. It should be possible to hide from radar detection using terrain/cover (but this should work both ways - the hidden object also suffers interference)
  7. Detection by SEAD/other passive radar should be influenced by power of active radar - may be irrelevant at Arma's scale, but modders might like it.
  8. Chaff/ECM and IR flares could become distinct countermeasure types. This needs to be done with caution, as switching countermeasure types can be time consuming in Arma, unlike in DCS where there are separate buttons and both are always available to be deployed.
  9. Auto IFF is fine, auto recognition of vehicle and status of vehicle is BS. Please remove this.

Suggestions for IR SAMs and Air to Air Missiles

  1. Distinguish between IR guidance and radar guidance.
  2. Decide weather the Cheetah and Tigris have IR or radar guided missiles.
  3. IR launchers and missiles must lock on to the hottest part of aircraft, within a certain target reticle. Alternatively it could be a mix of IR and UV, like Stingers.
  4. A consequence of (3) is that it should be difficult to lock on to the front of the plane, or when the aircraft is coming out of the sun. You could rely either on a thermal map for locking or simply lock on to the engine hit point (yes, planes will need one) if it's within LOS.
  5. Missiles should have a cone of vision, i.e. sharp turns + flares should be able to throw them off
  6. IR missiles and launchers, since dependent on heat signatures, should have a shorter range than radar guided things (maybe 2km for MANPADs, 3km for vehicle based SAMs).
  7. Missiles could face a chance of being distracted by other heat sources (that are not flares). This is admittedly difficult and I consider this optional.
  8. Targets of IR missiles should not be informed about an incoming missile. This is realistic but treat it with caution, as it may make game play very difficult/tedious for some players/communities. Ideally, if implemented, must be optional (opt-in or opt-out) and controllable by the server admin or mission maker.

Regarding (8) from both sections above, to quote myself:

 

 

I'm okay with aircraft being able to detect incoming IR missiles...for the sake of balancing and mission making I find it convenient. Air distances are small in Arma and the time to see and react to missiles is quite less (especially because at the moment you're likely to be fired upon from within a 2km radius). Additionally, in vanilla Arma most missiless are IR, so countermeasures would become mostly useless (because few would actually deploy them)

 

If this needs to be made optional then a server side or mission side parameter to toggle it would be nice.

 

the problem is, if you can't detect MANPADs via sesnors, you will most likely get hit, given the way the AI engages (at <2km, often <1200m)

 

BI would need to look at missile/flare/damage balancing again

 

...I have to look at what works for a community in general, and if there's going to be a change like this (i.e. a warning about something is removed), then it can't catch people off guard. The way the community I play with works means that this is a possibility (open community, lots of working/busy people, etc). Hence, while I agree it's realistic and all, I would like control over it in a mission, so that it can be tailored to the people I play with. As I mentioned, even if it's opt-out it's fine (so i could use something like vehicle IRMissileWarningEnabled true)

 

The thing with the launch flares no matter what [when making a gun run, etc] is, in Arma, and with AI, the missile launches happen very fast and lock is from any angle, and the accuracy is pretty much perfect. IRL you'd need to lock on to the hottest part (e.g. engine of the aircraft), and the chance of a missile/targetting module getting confused is high.

 

So in Arma you could get hit by 4 missiles from the front when you're approaching for the attack, 1km out. Missile will likely be too close for you to react, and given how flares work (a bunch of them are launched together, as opposed to say in DCS where it's one by one), there's a fair chance you won't be able to flare again for the trailing missiles (and the trailing missiles won't get distracted by the first set of flares)(edited)

 

TL;DR:
1. I'm not opposed to not having IR missile warnings per se
2. I would however like some control over this feature, even a simple opt-out would do
3. How IR missiles work in terms of locking from the launcher, rate of fire, speed, sensitivity to background heat signatures, etc. would need review and possible revision.

 

Anti-Tank Guided Missiles

​

The changes to radar and IR missiles will consequently influence other missile systems.

  1. As mentioned before, vehicles without active radar should not be lock-able via radar.
  2. Such vehicles should only be target-able by IR lock. For this, IR view mode must be enabled by the aircraft/helicopter's gun pod or gunner. The target heat signature needs to be brought into the center of the reticle, and only then will lock be achieved. Any heat signature must be lockable. Think AGM65 Maverick.
  3. Implementing (1),(2) will make smoke screens very effective, since they'll block the heat signature.
  4. If IR optics are not present, these missiles could be SACLOS guided (similar to current behaviour when not using magic target locking).
  5. Titan launcher is Arma's Javelin. This is fine, since the Javelin relies on both optical image processing and thermal information, and is fire & forget. However, the user must align the crosshairs of the target sights to get a lock, and not just spam "target next vehicle".
  6. Titan could continue to have a SACLOS backup.
  7. PCML needs to be at best SACLOS. It can't also be a Javelin, just weaker. Thus it has to behave more like the M47 Dragon. If you absolutely must keep the F&F nature and magic locking of the missile, at least make sure that the target has to remain centered until the lock is obtained.
  8. Vehicle based Titans (such as on the Gorgon) could perhaps continue to be F&F (for consistency), but must stick to the same rules - target must be centered under crosshair.
  9. Prevent locking from a third person view.
  10. Provide a way for the server administrator or mission maker to turn off F&F for ATGMs, thereby forcing SACLOS mode.

The behind placing so much emphasis on SACLOS and harder locking methods is to inherently balance gameplay - this way the operator of the missile needs to remain exposed to score a hit. Suppressing or taking the operator out will likely mean that they won't be able to lock on, or will miss. This is way more fun than spamming T or TAB ("target next vehicle").

 

Requested script commands

 

If IR missile warnings are removed by default:

vehicle IRMissileWarningEnabled true

To disable F&F:

vehicle disableWeaponTargetLock "WeaponName";

Alternatively:

vehicle disableWeaponTargetLock [gunner vehicle, "weaponName"];

To disable locking only for the gunner (so it remains active with pilot's manual fire). Only relevant if magic locking stays.

 

Reference material

 

 

I hope I've not missed anything lol.

  • Like 6

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×