Jump to content

Recommended Posts

On 29. 1. 2017 at 4:55 PM, Jack Ost said:

Otherwise, there is a small problem on the gui with radar numbers : http://hpics.li/38b31e5

Thanks for the report. French localization was updated to also use only the SI symbol.

 

17 hours ago, SuicideKing said:

...essay...

Wonderful! That's a solid feedback and good notes. Thanks a lot!

  • Like 2

Share this post


Link to post
Share on other sites

Oukej I know this is off topicish for this..but since suicideking mentioned in his rather nice post... the Titan top down. just saying. it would be a very welcome much loved addition. the boots on the ground would salute you. brown envelope full of cash en route.

Share this post


Link to post
Share on other sites

Well, he already said that they can't to the PLOS mode for the NLAW, so I doubt that will be different with the Titan.

Share this post


Link to post
Share on other sites
18 hours ago, SuicideKing said:

Context:

  • I haven't been able to try out dev branch, because I don't have enough disk space.
  • Most of my information comes from discussions with @chortles
  • I have been following developments on this thread and in the A3 Discord server's #arma_gameplay channel.
  • Based on all of this, I have some observations, comments and suggestions to make.

I discounted most of what followed based on this, it read like I was getting 'SuicideKing-splained'.

Share this post


Link to post
Share on other sites
On 25.1.2017 at 11:10 AM, oukej said:

We don't have the tech to simulate PLOS.

 

I think you could come pretty close with the relatively new CCIP, that you added to aircraft guns some patches ago. So the NLAW could fire a missile that is not guided, but would fly in a straight line (unlike the ballistic trajectory of the RPGs) but the sight would lock on targets and have a CCIP built in which would let you easily engage moving target with high probability of hitting.

 

*edit* new implementation seems to be an improvment nevertheless:)

  • Like 1

Share this post


Link to post
Share on other sites
16 hours ago, dr. hladik said:

> visual sensor

It is just another possibility. We still plan to tweak it (or any other) according to feedback.

You can optically track something via an image contrast. Its capability should scale strongly with environmental setting (heavy rain, fog, ...). Which makes it more complex than all the others propably.

I wouldnt put this sensor in vehicles we have in A3, and only use it for weapon tracking (which is possible). Its nice to have as sensor for mods however.

 

It would help if the display would tell you what type of sensors you have in your vehicle. It just says "sensor" currently, which is useless.

  • Like 1

Share this post


Link to post
Share on other sites

I'am also scapitical about visual and IR sensors, it is simply too arcade.
instead you should have the possibility to set GPS targets. 
Then, it would be wise to add a function to delete GPS-Targets, to avoid that the radar overloaded with GPS-targets.
Recent GPS-Targets should be flicker in a high frequency and older GPS-Targets should flicker in a lower frequency and so on.
 

Share this post


Link to post
Share on other sites
8 hours ago, x3kj said:

You can optically track something via an image contrast. Its capability should scale strongly with environmental setting (heavy rain, fog, ...). Which makes it more complex than all the others propably.

I wouldnt put this sensor in vehicles we have in A3, and only use it for weapon tracking (which is possible). Its nice to have as sensor for mods however.

 

It would help if the display would tell you what type of sensors you have in your vehicle. It just says "sensor" currently, which is useless.

Please clarify: do you mean having keeping the visual sensor in the engine as a possible sensor type and maybe adding it to other weapons besides the PCML (which at last check was only able to detect/track targets with visualTarget = 1) but simply excising it from vanilla vehicle configs?

8 hours ago, x3kj said:

It would help if the display would tell you what type of sensors you have in your vehicle. It just says "sensor" currently, which is useless.

Hmm... so far the thread OP screenshot shows the three cones for IR, visual, and active radar having different colors, although I acknowledge the exception for when the horizontal angle coverage matches up exactly with another sensor's and overlaps. I imagine that what you're looking for is a way to also indicate whether or not one's vehicle has laser/NV/'passive radar' sensors as well? (There's been quite the discussion on that last one over on Discord, whereas the laser sensor seems to clearly correspond to historical such as the old Pave Penny, and so far the 'NV' sensor is for detecting thrown IR Grenades.)

 

@oukej One thing I'm inquiring about if I haven't already is whether a sensor's animDirection can be tied to the TGP, giving a single-seater a way to have a sensor be aligned with/be pointed wherever the pilot is looking or otherwise pointed the pilotCamera... in essence, a way for a single-seater pilot to have the same gameplay benefit that the attack helicopters currently get with turret-aligned sensors.

Share this post


Link to post
Share on other sites
2 hours ago, 204 Kallisto said:

I'am also scapitical about visual and IR sensors, it is simply too arcade.
instead you should have the possibility to set GPS targets. 
Then, it would be wise to add a function to delete GPS-Targets, to avoid that the radar overloaded with GPS-targets.
Recent GPS-Targets should be flicker in a high frequency and older GPS-Targets should flicker in a lower frequency and so on.
 

 

And how would you control this functionality? (We are severely limited when it comes to free keys)

  • Like 2

Share this post


Link to post
Share on other sites

Hello oukej!

 

I have been playing since the days of Operation Flashpoint, and while that isn't anything special around these forums, I've been working in the air force for almost 10 years now dealing with fighter aircraft. So, as you may see my post count is record-low, but this topic has sparked my interest. What I am seeing so far is a fantastic boost to ARMA 3 that will benefit the entire sandbox simulation greatly for all players, ranging from aircraft to infantry. The main thing that comes to mind here is that even in the early days for OPF, I can still remember the frustration of getting into a civilian car in some forgotten area of the map, just to be hit by a Maverick missile 15 seconds later from a distant loitering A-10. I blame the magic radar (curses)! Hopefully, you will eliminate that, unless, you are being lased by a FAC, in which case a maverick or GBU to the face is more than welcome! "GG, FAC.... GG!". That is the reward for mastering a complex weapon system, with newly implemented sensors!

 

I can imagine all kinds of new scenarios and addons come from this implementation, but it has to work well for everyone, both players and AI. So I would like to share a few thoughts and ideas with both you and the community!

 

Firstly:

 

Target identification:

Even in 2017, there are a very limited amount of sensors that are capably of identifying the model and type of target you are locked on to. It's actually easier the other way around, if someone is locked to YOU. The reason for this being the enemy's "radar signature" which may be known to your forces. In this case, the vehicle carrying a "Radar Warning Receiver" may update its database regularly with new intel in order to be able to recognize threats. This may be known as "Threat detection". Advanced threat detection systems may combine threat detection with the vehicle situational awareness systems (such as a Horizontal Situiational Indicator or HSI for aircraft) and overlay information there. This means that if the vehicle has a threat detection device, it can tell you what is locked onto you, where its general direction is, and if it just pinged you, is tracking you, or is guiding something at you. With advanced systems, you may even know exactly where the enemy is, and what the known maximum range of its weapons are so that you can avoid entering its lethal range.

 

Now, if YOU are the one scanning for enemies, chances are you must solely rely on your eyes, or the eyes of your allies. Even with a solid radar lock, if you can't visually identify an enemy, you never arm your weapons. So in order to make shot, you either have to close the distance so you can see the target yourself (with eyes or targeting pods - yes these can be used in air-to-air for identification), or you have to rely on allies. One way to bypass this is to know where all allied forces are, and assume the unknown contacts are hostile. This may add extra gameplay elements such as monitoring target height and speed. These will quickly tell you if it's a "fast mover" or a helicopter. High speed/Alt = usually a jet, while low speed/Alt = usually a helicopter. 

 

But, if you really want to make things green or red on the radar hud, and avoid "white" contacts, I have the following proposal:

 

Realistic mode:

 

  • VISUAL (eyes)/Aircraft HUD (Head Up Display):
  • All radar contacts appear as boxes, locked targets have added diamonds.
  • Friendly aircraft have boxes too, but with an X over, signifying it's a friendly.
  • NO symbology whatsoever outside the aircraft cockpit HUD, unless the pilot has a helmet with helmet mounted sights. (You guys actually have working HUD's in the game, but they are redundant since the "game HUD" fills that role already.
  • NO text whatsoever to tell the player what type of target it is, players must rely on visual feedback and the radar HUD symbology.

 

RADAR HUD(display) and/or Helmet mounted sight:

  • All allied contacts are green (assuming datalink (or IFF - Identify Friend or Foe) equipment is installed and will report position and type to all friendlies)
  • All other contacts are white (assuming they are beyond visual range, and no allies with datalink (or IFF) have "revealed" them).
  • All visually confirmed targets, detected by player or allied player with datalink/IFF are red, until target data has expired (aged a certain time), then it will be a white contact again.

 

Option:

  • An editor placeable tracking radar, or airborne AWACS (mod/addon) will simulate having an Early Warning/Fighter controller function that will reveal all detectable enemy air contacts as red. An added bonus of this is that if you eliminate the radar, the enemy will lose the capability to instantly reveal targets. This tracking radar may also have an option to show enemy type/model (in real life, dedicated operators can see where planes originate from and look at radar signatures to make out what type of hostile this is.)

 

Arcade mode:

 

  • Like regular vanilla arma. Magic Radar. Greens, whites, reds. They're everywhere!

 

 

Secondly I'd like to bring up locking methods and symbology. I have always felt that the "in-game HUD locking" is rather lacking and very unsatisfying to use. You can essentially use the TITAN AA to point the cursor at a plane, hit "T" and wait for a magic box to appear around the target, wait for the diamond to form, then click fire and watch the missile fly, all without looking through the optics of the Titan AA. Get my point?

 

Target locking/tracking:

 

In real life, target locking and tracking can be carried out in numerous ways. Recent years have seen advancements in both radar and electro-optical tracking areas. ArmA has used a more or less "magic" locking system that could use some improvements. So here are a few more suggestions I think you can pull off with your tactical coding skills :)

 

IR sensor tracking:

 

Most notably on IR-seeking missiles, these missiles do not require a radar lock in order to fire. They may benefit from having a radar, since a radar can determine target speed, angle and distance so that the pilot can see if he has a good firing solution, but they do not need a radar. In real life, pilots can use audio feedback to determine if they have a good lock, this is the case for the AIM-9 Sidewinder and FIM-92 Stinger missiles. A certain tone or "growl" will tell the pilot if the missile has a good lock. After that, the missile uses IR contrast, and if more advanced, IR Imaging, to determine where the target is and guide onto it. It's cheap and dirty, but works very well. Since IR missiles are essentially guided by passive cameras, they are extremely hard to detect. Only advanced aircraft are equipped with UV or IR Cameras that cover a 360 degree arc. These are able to detect the rocket engine flame from missiles and give simple callouts to pilot such as "Missile, 6 o clock" etc..

 

IR missiles may be spoofed by flares, ground clutter or other heat sources such as other aircraft or even the sun. Anything that will mess with the seekers contrast. Flares should be more potent against low-end IR seekers, and less potent against high-end IR seekers. This also allows for smarter flare management. Maybe have options such as "Burst, single and continuous"

 

My suggestions for better IR missiles in Arma 3:

 

  • Remove IR locking symbology and replace with a audible tone system (for both shoulder fired and vehicle fired), unless the firing system incorporates a radar for target detection and range. This also eliminates the locked aircraft's capability to detect the threat completely, unless it is coming from a vehicle with an active radar. It still won't tell you if the missile has been fired though, only that you have been locked.
  • Add IR seeker countermeasure resistance parameter to the mix. A cheap shoulder fired missile could easily be fooled by flares/sun/ground clutter, whilst an advanced IR-image seeker can tell the if it is flares or not. Basically each time an IR countermeasure is used, perform a probability test to see if IR-lock is lost or not. (This will balance the advantage of shoulder fired missiles not being detected by the locked target, against weaker seeker heads).
  • IR seekers will lock onto ANY valid heat source (even ground if hot enough), both during target locking and during missile tracking/flight. (In example, if you are locking onto a plane that drops a burst of flares, you won't really be sure if you are actually tracking the flares or the aircraft. This forces AA-players to wait for the "sweet spot" when there are no distractions around the target, and fire.
  • IR Jammer. I believe the Su-29/Su-25T actually have IR jammers that strobe beams of IR light in its 6 o'clock direction. This "blinds" missiles approaching from behind and causes them to veer off course. Some ARMA air and/or ground vehicle may benefit from such a system.
  • Better countermeasure system/new modes:
  1. Burst - Fires a pair, or a small burst of pairs (like in vanilla - used when you know a missile is coming to create much distraction)
  2. Continuous - Fires a single or pair every 3-4 seconds (used when flying over likely AA threats with passive seekers (IR) to make target lock difficult)
  3. Automatic - Only available for vehicles with UV/IR Camera launch detectors. When player clicks button a normal "Burst" fires, but if missile is detected, it will automatically dispense a burst of flares. (Much like vanilla AI acts today).

 

This was "all" I had time to write now :)

 

I have a few tips on Radar homing missiles too. Will post those ideas later :)

 

Also, I have some experience with computers and limited coding knowledge, so I don't think these elements are too hard to implement. 

 

As for gameplay, I think it will enhance the experience, but not make it too difficult for the playerbase to master. Besides, this kind of seeker revision will benefit all types of players, from ground to air. Magic radar is like Arma's answer to aimbot :P

 

Please comment if you like, or want more explanation :)

 

 

 

  • Like 9

Share this post


Link to post
Share on other sites
5 hours ago, dr. hladik said:

 

And how would you control this functionality? (We are severely limited when it comes to free keys)

GPS targets would actually make sense to "magic lock".

Share this post


Link to post
Share on other sites
2 hours ago, russian rullet said:

Now, if YOU are the one scanning for enemies, chances are you must solely rely on your eyes, or the eyes of your allies. Even with a solid radar lock, if you can't visually identify an enemy, you never arm your weapons. So in order to make shot, you either have to close the distance so you can see the target yourself (with eyes or targeting pods - yes these can be used in air-to-air for identification), or you have to rely on allies. One way to bypass this is to know where all allied forces are, and assume the unknown contacts are hostile. This may add extra gameplay elements such as monitoring target height and speed. These will quickly tell you if it's a "fast mover" or a helicopter. High speed/Alt = usually a jet, while low speed/Alt = usually a helicopter. 

 

But, if you really want to make things green or red on the radar hud, and avoid "white" contacts, I have the following proposal:

IDing targets gameplay was something we tried to emphasize. We've actually got rid of the automatic enemy confirmation. And it works on the display as you're suggesting:

2 hours ago, russian rullet said:
  • All allied contacts are green (assuming datalink (or IFF - Identify Friend or Foe) equipment is installed and will report position and type to all friendlies)
  • All other contacts are white (assuming they are beyond visual range, and no allies with datalink (or IFF) have "revealed" them).
  • All visually confirmed targets, detected by player or allied player with datalink/IFF are red, until target data has expired (aged a certain time), then it will be a white contact again.

With small differences. Allied (green) are only contacts from the same side. Contacts from a friendly side will still be shown white. Red contacts - and this is still just a plan - are only those that have been "confirmed as hostile" by a script command. This is to allow scenario creators come up with either pre-determined scenario setting and ROE or to come up with a dynamic system for confirmation of enemies. Hopefully allowing also this:

2 hours ago, russian rullet said:

An editor placeable tracking radar, or airborne AWACS (mod/addon) will simulate having an Early Warning/Fighter controller function that will reveal all detectable enemy air contacts as red. An added bonus of this is that if you eliminate the radar, the enemy will lose the capability to instantly reveal targets.

 

2 hours ago, russian rullet said:
  • All radar contacts appear as boxes, locked targets have added diamonds.
  • Friendly aircraft have boxes too, but with an X over, signifying it's a friendly.

This is the current state. https://community.bistudio.com/wiki/Arma_3_Targeting#Identification

Boxes/brackets are for tgt marking by vehicle systems. Diamond is to indicate missile seeker and its locking state.

2 hours ago, russian rullet said:
  • NO text whatsoever to tell the player what type of target it is, players must rely on visual feedback and the radar HUD symbology

The nametags are gone from 3D symbols. So...can I mark this as done? ;)

 

2 hours ago, russian rullet said:
  • NO symbology whatsoever outside the aircraft cockpit HUD, unless the pilot has a helmet with helmet mounted sights. (You guys actually have working HUD's in the game, but they are redundant since the "game HUD" fills that role already.

We need a fall-back system and also something that works in optics and simple weapons (where HUD/HMD drawing technology can't be used).
Having the targeting indication only in HUD/HMD would be an ideal state but we may not have the resources to achieve it.

2 hours ago, russian rullet said:

Most notably on IR-seeking missiles, these missiles do not require a radar lock in order to fire.

Ours do neither :) Ammo and vehicle systems can work independently. You may have no vehicle sensor at all but you will still be able to lock a target using the missile's own seeker. Vehicle systems may for example let you track the target outside of missile's envelope.

 

2 hours ago, russian rullet said:
  • Add IR seeker countermeasure resistance parameter to the mix. A cheap shoulder fired missile could easily be fooled by flares/sun/ground clutter, whilst an advanced IR-image seeker can tell the if it is flares or not. Basically each time an IR countermeasure is used, perform a probability test to see if IR-lock is lost or not. (This will balance the advantage of shoulder fired missiles not being detected by the locked target, against weaker seeker heads).

It's already available. We may attempt rebalancing the vanilla configuration. If you have a concrete example where the behavior is suboptimal :) please pinpoint us and we'll look at it.

 

2 hours ago, russian rullet said:

IR missiles may be spoofed by flares, ground clutter or other heat sources such as other aircraft or even the sun. Anything that will mess with the seekers contrast. Flares should be more potent against low-end IR seekers, and less potent against high-end IR seekers. This also allows for smarter flare management. Maybe have options such as "Burst, single and continuous"

...

IR seekers will lock onto ANY valid heat source (even ground if hot enough), both during target locking and during missile tracking/flight. (In example, if you are locking onto a plane that drops a burst of flares, you won't really be sure if you are actually tracking the flares or the aircraft. This forces AA-players to wait for the "sweet spot" when there are no distractions around the target, and fire.

 

You can lock on burning wrecks :) Locking actual flare seems already (and sadly) out of scope. (And afaik the modern missiles don't usually pursue bad tracks...perhaps even the wrecks aren't very accurate)

And hey, thanks a lot for your post!

  • Like 8

Share this post


Link to post
Share on other sites
10 hours ago, chortles said:

Please clarify: do you mean having keeping the visual sensor in the engine as a possible sensor type and maybe adding it to other weapons besides the PCML (which at last check was only able to detect/track targets with visualTarget = 1) but simply excising it from vanilla vehicle configs?

yes. Its a way to model other systems not represented (i.e. "remote saclos", where the aiming of the missile is done by a seperate independant system, that received the target from other sensors (laser, ir, ...)

 

 

Quote

Hmm... so far the thread OP screenshot shows the three cones for IR, visual, and active radar having different colors, although I acknowledge the exception for when the horizontal angle coverage matches up exactly with another sensor's and overlaps. I imagine that what you're looking for is a way to also indicate whether or not one's vehicle has laser/NV/'passive radar' sensors as well? (There's been quite the discussion on that last one over on Discord, whereas the laser sensor seems to clearly correspond to historical such as the old Pave Penny, and so far the 'NV' sensor is for detecting thrown IR Grenades.)

Its not clear what is what on the display, and what sensors your vehicle has and so on.

 

Another thing that i would like to see improved is direction reference points in the radar display. Currently you have to hold a ruler to your monitor to tell if a target is directly "in front of you" or if it is off to the side. 

 

It would be nice to have a "Hunter view" / Lock view/ chase view. Currently you only get a topdown view of the sensors. What about a view from pilot's perspective.? A 2D projection of the radar cone viewed from the rotation-axis of the cone. That means when a blip is at the center of the screen, you are flying directly towards it. When a target is off to the right, it shows on the right side.   Only works when the cone is <180° (ideally alot smaller, like 90° max). It could be exclusively for locked targets, so that you know where you have to rotate your turret (AA) or how to turn your plane to approach it directly.  As added benefit, other targets do not have to be searched (unless other screen shows the radar as well), temporary reduction in performance. The mode is shown in this Mig-21 radar tut for example  (locking view)

 

  • Like 1

Share this post


Link to post
Share on other sites

 

2 hours ago, oukej said:

With small differences. Allied (green) are only contacts from the same side. Contacts from a friendly side will still be shown white. Red contacts - and this is still just a plan - are only those that have been "confirmed as hostile" by a script command. This is to allow scenario creators come up with either pre-determined scenario setting and ROE or to come up with a dynamic system for confirmation of enemies. Hopefully allowing also this:

That's great to hear! Much hype!

2 hours ago, oukej said:

This is the current state. https://community.bistudio.com/wiki/Arma_3_Targeting#Identification

Boxes/brackets are for tgt marking by vehicle systems. Diamond is to indicate missile seeker and its locking state.

Aaah. Of course. I have not been messing around too much with vanilla units lately. My bad :s

2 hours ago, oukej said:

The nametags are gone from 3D symbols. So...can I mark this as done? ;)

Yeah, that's great! :D

 

2 hours ago, oukej said:

We need a fall-back system and also something that works in optics and simple weapons (where HUD/HMD drawing technology can't be used).
Having the targeting indication only in HUD/HMD would be an ideal state but we may not have the resources to achieve it.

I think I know what you're saying. I made another post in the thread about custom info for the Jets DLC. I was wondering if you could use the already implemented red-dot-sight collimator code to display the aircraft hud in a more realistic way? Currently, HUD is only aligned if you do not move the pilots head. If you use TrackIR, and look slightly to the sides, the aircraft HUD symbology does not align with the real world any more, because it does not feature a collimator. Do you know if this is possible to achieve?

2 hours ago, oukej said:

Ours do neither :) Ammo and vehicle systems can work independently. You may have no vehicle sensor at all but you will still be able to lock a target using the missile's own seeker. Vehicle systems may for example let you track the target outside of missile's envelope.

I was thinking more about passive locking. So you don't have to actively hit "T" in order to lock, but rather just keep the seeker pointing at the target long enough to acheive lock. The Igla or Strela launchers, for instance, basically just point at target until solid tone, then release. Is this possible within the vanilla code at the moment? If so, I didn't realize that :) This would mean that even without a steady lock, the missile may "latch" onto a heat source after launch.

 

2 hours ago, oukej said:

It's already available. We may attempt rebalancing the vanilla configuration. If you have a concrete example where the behavior is suboptimal :) please pinpoint us and we'll look at it.

That's funny. My experience when shooting flares at AI is as follows: You lock an AI, then fire a missile. Immediately the AI dispenses flares, and the missile will lose lock every time. It then appears as if the AI has a cooldown before it can use flares again. If you manage to reload and fire a new missile before this cooldown, or a teammate fires while the first burst is still going, you may get a hit. It does not appear random, and feels like it can easily be "tricked" by just timing when you fire the missile. Also, AI has 20/20 superman X-ray vision coupled with 6th sense so they ALWAYS know the exact moment you fire. IR seekers are the hardest to spot in real life, because they do not emit any radio frequencies towards the target. If you fired AMRAAMS in ARMA, then I would understand, because that thing lights up a radar warning receiver in no-time. But regular IR missiles?? This could be solved in a few different ways... Either:

 

  • Random chance based on AI pilot skill for IR seeker detection with flare dispensing.
  • Field of view based, where each vehicle has a visual FOV limit, so typically behind/below/above blindspots will not alert the AI.

 

The two of the above could be combined.

 

 

 

Lastly, thank you so much for taking the time to read and answer. That's just fantastic! Love the game, love your work! Keep it up :)

 

 

  • Like 6

Share this post


Link to post
Share on other sites

All of this is very cool.  I really want to see this new tech used to broaden the gameplay of various vehicles, not just jets.  Specifically, I would love to see more variety in missile guidance, both from shoulder fired weapons and from vehicles.

 

Shoulder fired missiles:

-For gameplay reasons and balance, it would be nice if the NLAW functioned more like the M47 Dragon and was SACLOS guided.  NATO doesn't have a light anti-tank weapon that is comparable to the RPG, so it would help from a balance perspective to ditch the fire and forget capabilities of the NLAW in favor of SACLOS. It would also diversify the gameplay by having an anti-tank weapon that has to be guided with SACLOS, as there is little reason to use the SACLOS functionality on the Titan AT when you can just lock on and let it loose.

-A top-attack mode would be amazing for the Titan AT.  If this weapon is analogous to the FGM148 Javelin, it would be very cool if we could lock on to and do a top attack on any point aimed at in the game world with the Titan AP missile as well.  The Javelin can lock on to much more than just vehicles, and can be used to target structures and more.  Call of Duty was the last time I saw this type of functionality, but it really would have a place in a game like ArmA where its tactical use could be realized and enjoyed.

 

On the topic of RWR and warnings:

-ARH and SARH are the easiest types of guidance to detect, as they require only a radar receiver on board the vehicle to pick up the targeting signal.  Both requires that either the missile or firing platform "illuminate" the target with a radar emitter, which makes it easy for the target to know when they are being targeted.  (SARH is much more common than ARH, so I would love to see aircraft having to maintain a lock on a target to guide a missile in to a kill while the target tries to ditch the lock by dipping lower or dumping chaff).

-Laser guidance is also fairly easy to detect, though I am not sure the tech in ArmA exists to implement any sort of warning that your vehicle is being lased or there is an enemy laser marker nearby.  This requires another dedicated sensor (LWR), however. 

-IR, non-laser guided SACLOS such as wire guidance, contrast seekers, and Passive Radar homing threats are much harder to detect.  These guidance types do not require any signal to be emitted, and incoming ordnance with these guidance types must be detected with some sort of on-board sensor.  Modern active protection systems often use some combination of auditory and radar sensors to detect the noise when the weapon is fired and radar to track the trajectory.  Of course, these weapon types have a smaller radar cross section, so they would be detected far later (at a close distance) than non-stealth aircraft (a high-flying Orca, for example.)  

 

I guess the best way to do this is to lump in detection of IR missiles with "passive radar" detection.  It isn't unrealistic to assume that any vehicle with IR missile detection will also detect radar emitters.  

 

AI and countermeasures:

-AI should drop flares and chaff not all at once and immediately when a missile is fired, but in bursts at short intervals once the missile is detected depending on the above factors.  Each flare dropped should have a chance of distracting the missile, depending on the missiles resistance to countermeasures (this chance would apply to players as well).  

 

GPS guidance:

I would really love you guys if some sort of GPS guidance was implemented in the game.  Hell, it could even be implemented through the in-game map and marker system fairly easily.  If the player has a GPS or is in a vehicle equipped with GPS, then when placing a marker on the map a new marker type option is available called "GPS Marker" with a unique icon.  Unlike other markers, these would not be shared across the current radio channel and players would have to verbally communicate coordinates to other players with a GPS.  Then, with a GPS guided weapon equipped (some bombs or artillery rockets/shells) the player could tap "R" to flip through the GPS markers and soft-lock on to them, and they would be labelled in 3D on the HUD with the text given to them on the map so you could identify which is which when flipping through them.  It would be great to see this on the self-propelled guns, the Scorcher, and maybe on some bombs included in the jets DLC.  Simply aim at the marker until you get a solid lock, release the bomb or fire the rocket, and you will get pinpoint accuracy.  

 

New jet loadouts:

-I know you guys aren't planning on having a way to adjust a vehicle loadout on the fly, but it would be cool if some new weapons were included for these vehicles and the vehicles were included in the game as new assets, just with different loadouts.  The Buzzard AA and CAS versions are examples of what I am talking about.  With the GPS system I mentioned before, these could be included on a more bomb-heavy loadout for the Wipeout and Neophron.  There could also be a more missile heavy loadout for anti-armor missions, and the existing loadouts would best be described as multirole.  Assuming the new DLC jets are fighter craft, they could have AA, CAS, and multirole loadouts as well.  

-It would also be great if addWeaponTurret worked better on aircraft and the weapon's ammo were visually represented.  For example, if you try to move the DAR missiles on the Falcon UAV from the gunner seat to the pilot seat (because the Falcon AI doesn't work) then you lose the CCIP and the rocket pods don't visually appear to have rockets in them.  With a wider variety of weapons in the Jets DLC, this could be used to great effect by players to design their own custom loadouts in missions.  

 

 

 

I know it is a lot, but I love this game!

 

Off topic, but it would be really nice to get a different version of the artillery computer as an option in the difficulty settings for the scenario, instead of a point and click map, it would open a window where we could input coordinates, select an ammo type and propellant load from those available on the vehicle, and it would give an azimuth and elevation.  The current artillery computer is frustrating if you want a scenario with artillery and want to use the built-in radio spotting, because artillery targets come up as targets that you just click on and there is no player communication.  Alternatively, you can turn off the automatic marking of enemies on the map to encourage communication, but then the communication required just to engage infantry becomes a bit much for players like me that are more casual.  An optional more hands-on artillery computer is a solid middle ground.

  • Like 5

Share this post


Link to post
Share on other sites
15 hours ago, x3kj said:

Another thing that i would like to see improved is direction reference points in the radar display. Currently you have to hold a ruler to your monitor to tell if a target is directly "in front of you" or if it is off to the side.

Such "ruler" can be added to the display - orig. from vehicle icon, straight up - is that what you mean?

 

15 hours ago, x3kj said:

It would be nice to have a "Hunter view" / Lock view/ chase view. Currently you only get a topdown view of the sensors. What about a view from pilot's perspective.?

A C-scope? Is it necessary when targets can be indicated on HUD?

Spoiler

imgv6D.gif

 

  • Like 2

Share this post


Link to post
Share on other sites
15 hours ago, Strike_NOR said:

I think I know what you're saying. I made another post in the thread about custom info for the Jets DLC. I was wondering if you could use the already implemented red-dot-sight collimator code to display the aircraft hud in a more realistic way? Currently, HUD is only aligned if you do not move the pilots head. If you use TrackIR, and look slightly to the sides, the aircraft HUD symbology does not align with the real world any more, because it does not feature a collimator. Do you know if this is possible to achieve?

It is. If the symbols get offset from their world ref. when moving, tilting, swaying head it means the MFD class is badly configured and doesn't use *toView sources. If you see something like that on vanilla aircrafts please let us know! If you see it elsewhere let the mod authors know and you can redirect them to MFD documentation (many thanks to Kitoon for composing it)


 

15 hours ago, Strike_NOR said:

I was thinking more about passive locking. So you don't have to actively hit "T" in order to lock, but rather just keep the seeker pointing at the target long enough to acheive lock. The Igla or Strela launchers, for instance, basically just point at target until solid tone, then release. Is this possible within the vanilla code at the moment? If so, I didn't realize that :) This would mean that even without a steady lock, the missile may "latch" onto a heat source after launch.

It is possible for non-vehicular weapons (there's an issue with vehicular ones).
In previous Armas the weapons usually used the auto-acquisition. But it was too OP and made it too easy to reveal anything just by looking in its general dir. Back then it wasn't rly possible to restrict that acquisition so we went with making it manual. With sensors and few new lock properties it's no longer the case and we will hopefully start using this approach again :)

 

  • Like 4

Share this post


Link to post
Share on other sites
9 hours ago, oukej said:

Such "ruler" can be added to the display - orig. from vehicle icon, straight up - is that what you mean?

Yes thats what i mean, would be helpfull. Also three shorter lines indicating 3 6 and 9 o clock position of the vehicle.

 

Quote

A C-scope? Is it necessary when targets can be indicated on HUD?

Yeah a c-scope. I admit, if it just shows the locked view it is not that usefull, when having HUD symbols at the same time. For AA gunners it is helpfull, as sensor fov may be greater than optic fov. In Planes the target can leave visual fov as well (dog fight) and if you dont have track-IR you can't see where the target is. I'm not a big fan of the HUD target indicators either. Now that we have sensor system and display, it would be nice to limit the display of HUD icons to advanced vehicles/equipment where that could actually be a thing (maybe even tied to character gear, like that enormous jet pilot helmet - they would actually have a purpose then). Having the c-scope show all targets (not just the locked one) would of course provide more usefull info, especially since the HUD does not show non-locked targets (unless thats just a config setting)

Edited by x3kj
clarification/elaboration
  • Like 1

Share this post


Link to post
Share on other sites

Thoughts after reading this and playing around a bit on dev branch:

 

Overall, looks like a huuuge improvement over the current system.

 

Target identification is a bit fast for my tastes. It seems like you can identify the exact vehicle type within 10 seconds when you get close enough, which kind of invalidates other forms of target identification (the underside camera, intel from the ground). I'd prefer if the automatic identification stayed at the generic level (ie. "Car", "APC", "Tank") for much longer, so there's an advantage to manual identification.

 

Paired with the above, it would be nice if there was a way to have your underside camera track the current target. You can already do this manually, but it's a bit cumbersome. This would be good for target identification, as well of getting an idea of how viable it would be to hit your target.

 

I'm a bit confused as to what the "Visual sensor" is supposed to represent. My understanding is that that sort of system is used for tracking, not identification. In other words, a pilot can designate a target to be tracked using something like contrast sensing, but the system itself can't tell the difference between a high-contrast vehicle and high-contrast terrain. Is it meant to represent a near-future system that is actually capable of doing the image processing to identify vehicles? Or is it supposed to represent the pilot looking around and identifying things himself? If so, why doesn't the Buzzard have it, and why is the arc so limited?

 

IR/Visual sensors being limited by object draw distance is a pretty massive downside. Is this a tech limitation? I'd guess it's because you can't calculate LOS without the objects being loaded, which would be unfortunate. If that's the case, is there any chance of that being fixed in the future, perhaps with a more dynamic "draw" system? Or is that more of an Arma 4 problem?

  • Like 3

Share this post


Link to post
Share on other sites
23 hours ago, oukej said:

If you see something like that on vanilla aircrafts please let us know! If you see it elsewhere let the mod authors know and you can redirect them to MFD documentation (many thanks to Kitoon for composing it)

Sorry oukej! For some reason I tried this in a ARMA 2 ported aircraft. I've checked all vanilla craft and the huds are all working :) Would really like to see working HUD symbology in the future though, right now it displays some common stuff such as speed, height and attitude. It also has a working flight path marker (which is very nice) and a "boresight" function. It would be nice though with a working CCIP "pipper" for guns, rockets and bombs that is limited to HUD View. The current one that works in 3rd person also, and shows "overlayed" in the game world is still a little arcade in my opinion :)

 

23 hours ago, oukej said:

With sensors and few new lock properties it's no longer the case and we will hopefully start using this approach again

This sounds very nice! In old ArmA I assume this would probably trigger a number of events leading to situations where a soldier with a stinger would act as an early warning radar system :P not really realistic.

However I would love to see air-to-air engagements that function close to this in terms of passive IR locking:

 

(2:25 to 3:13) Notice how you do not have any range info or cues telling you to shoot, because the Fire Control System does not know the distance to target or if a hit can be guaranteed.

 

 

 

I think this aspect is important to get right in ArmA. Because it is a viable tactic to switch off radar to go "stealthy", then when locking and firing an IR seeker, the enemy will have no clue. Just the eyesight to see missile smoke!

 

The rest of the video showcases how it works with radar assisted tracking too (just for launching purposes, not for actual missile guidance).

 

I also hope to see Passive, Semi-Active and Active Radar seeking missiles in ArmA too :)

  • Like 1

Share this post


Link to post
Share on other sites
13 hours ago, darkChozo said:

Target identification is a bit fast for my tastes. It seems like you can identify the exact vehicle type within 10 seconds when you get close enough, which kind of invalidates other forms of target identification (the underside camera, intel from the ground). I'd prefer if the automatic identification stayed at the generic level (ie. "Car", "APC", "Tank") for much longer, so there's an advantage to manual identification.

ID distance is configurable separately from the sensor's detection range.
 

13 hours ago, darkChozo said:

I'm a bit confused as to what the "Visual sensor" is supposed to represent. My understanding is that that sort of system is used for tracking, not identification. In other words, a pilot can designate a target to be tracked using something like contrast sensing, but the system itself can't tell the difference between a high-contrast vehicle and high-contrast terrain. Is it meant to represent a near-future system that is actually capable of doing the image processing to identify vehicles? Or is it supposed to represent the pilot looking around and identifying things himself? If so, why doesn't the Buzzard have it, and why is the arc so limited?

 

IR/Visual sensors being limited by object draw distance is a pretty massive downside. Is this a tech limitation? I'd guess it's because you can't calculate LOS without the objects being loaded, which would be unfortunate. If that's the case, is there any chance of that being fixed in the future, perhaps with a more dynamic "draw" system? Or is that more of an Arma 4 problem?

Contrast seekers, CCDs, EOTS... in vanilla configs atm it's range/angle will usually reflect the vehicle's optics (pilotCamera or the gunner's optics). Pilot camera (TGP) is only able to point lock at something provided by a sensor.
The viewDist capping is not a limitation, it's just how they are set up in configs. It's because of the spectrum properties, because of how the sensors are set up to work with optics and also because it's nice to keep BVR reserved to radars as they are the only active sensor and reveal themselves.

 

2 hours ago, Strike_NOR said:

Would really like to see working HUD symbology in the future though, right now it displays some common stuff such as speed, height and attitude. It also has a working flight path marker (which is very nice) and a "boresight" function. It would be nice though with a working CCIP "pipper" for guns, rockets and bombs that is limited to HUD View. The current one that works in 3rd person also, and shows "overlayed" in the game world is still a little arcade in my opinion :)

Check Buzzard - it has the CCIP alrady in HUD. The in-game UI CCIP has been limited to optics. Have u been using Dev-Branch?

 

2 hours ago, Strike_NOR said:

I also hope to see Passive, Semi-Active and Active Radar seeking missiles in ArmA too :)

Semi-active radar guidance has sadly been cut due to complexity. Sorry about that.

  • Like 2

Share this post


Link to post
Share on other sites
30 minutes ago, oukej said:

Semi-active radar guidance has sadly been cut due to complexity. Sorry about that.

Sucks but cheers for the honesty. 

  • Like 1

Share this post


Link to post
Share on other sites

It's not a huge loss, as far as vanilla goes, but would have been nice for mods. Generally, modern missiles like AMRAAM don't need SARH at ArmA ranges, they can switch to the onboard seeker right away. Many SAMs also use SARH, but those also tend to have ranges far in excess of what you'd normally encounter in ArmA and vanilla doesn't have any SAMs like that anyway (since Titan AA is IR-guided).

Share this post


Link to post
Share on other sites
6 hours ago, oukej said:

Contrast seekers, CCDs, EOTS... in vanilla configs atm it's range/angle will usually reflect the vehicle's optics (pilotCamera or the gunner's optics). Pilot camera (TGP) is only able to point lock at something provided by a sensor.

So does that mean that visual sensors, when used for detection on a vehicle, are supposed to represent the pilot using an optical system to pick out targets? I ask because, as I mentioned, those sorts of systems typically require a human in the loop; they may be able to track a known target, but they can't tell if a set of pixels is a target or background, unlike radar and IR (to a degree). The current system gives more of an impression of automatic recognition, either by magic or some sort of more advanced image processing.

 

(EDIT: I'd note that I don't have any problem with ammo/weapon visual sensors, just the vehicle ones)

 

Also, visual sensors appear to be significantly more limited than pilot cameras on dev. Plane pilot cameras have a ~300 degree arc compared to the ~40 degree arc for visual sensors, and the Buzzard doesn't get a visual sensor at all despite having a pilot camera.

 

On an unrelated note, can we expect the HUD enhancements on the Buzzard to make its way to other jets? The runway highlighting is super impressive.

 

6 hours ago, oukej said:

The viewDist capping is not a limitation, it's just how they are set up in configs. It's because of the spectrum properties, because of how the sensors are set up to work with optics and also because it's nice to keep BVR reserved to radars as they are the only active sensor and reveal themselves.

If that's the case, the view distance capping doesn't really make sense to me. It's a performance setting, not (presumably) a reflection of real-world visibility. A player on a lower-end computer isn't flying on a foggier day or using a worse camera, he's limiting what's rendered at any one time to save on performance.

 

There are already problems with view distance and jets in the current game (providing CAS with <1.5k view distance and no sensor assistance is an exercize in frustration), I'd hate to see the sensor update contribute to that.

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, darkChozo said:

If that's the case, the view distance capping doesn't really make sense to me. It's a performance setting, not (presumably) a reflection of real-world visibility. A player on a lower-end computer isn't flying on a foggier day or using a worse camera, he's limiting what's rendered at any one time to save on performance.

 

There are already problems with view distance and jets in the current game (providing CAS with <1.5k view distance and no sensor assistance is an exercize in frustration), I'd hate to see the sensor update contribute to that.

What he's describing is default values -- meaning that you can change this via config mod -- but here's how view distance limits work:

Quote

It's possible to cap the range by viewDistance (or its portion) for systems that work within visual range. Set the DistanceLimitCoefs to -1 to disable any impact of view distance on the sensor for beyond visual range systems.

The actual sensor's range is the smallest of [maxRange, resulting objectViewDistanceLimit, resulting viewDistanceLimit] but never lower than minRange

In the following case the sensor will be able to detect targets that are within the object view distance as terrain view distance will always be bigger. However if the obj. view distance is set above 5km the sensor won't be able to detect anything above 5km. If it's conversely set below 500m, the sensor will still be able to detect targets at 500m even if they are not visible.


class AirTarget      // ranges for targets with sky background
{                                            
        minRange = 500;         // -1 if undef; in meters 
        maxRange = 5000;       // -1 if undef; in meter                                                        
        viewDistanceLimitCoef = 1;      // -1 if undef; coefficient, multiplies current view distance as set in player's options. -1 means view distance is not used to limit sensor range.
        objectDistanceLimitCoef = 1;    // -1 if undef; coefficient, multiplies current object view distance as set in player's options. -1 means object view distance is not used to limit sensor range.
 
};

 

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

×