Harker

Good to hear

That's different, the AIM-7 guides by having the seeker pick up the radar's PDI signal reflected from the target. If it sees a reflection, it'll go towards it. That also means that you can illuminate another target with your radar and the AIM-7 won't know any better and go for that one (not sure if that's possible in DCS). The AMRAAM instead guides towards a trackfile (a software-created target, that has position, velocity, acceleration data etc) by using commands received directly from the radar, it doesn't rely on anything being reflected by the target. It then turns on its own seeker and starts combining both the received commands and its own active seeker data. The AMRAAM doesn't know if the actual target even exists, prior to detecting it itself. I guess one way to switch targets post-launch would be for your radar to mistakenly associate a different aircraft with the existing trackfile, I'm pretty sure that's not possible in DCS though. Then again, once the ARMAAM goes active, if it fails to spot the desired target, it'll increase the acceptable limits for velocity, acceleration and distance from the intercept point, in an attempt to re-acquire. During that step, it's possible that it picks up another aircraft in its search volume. Both of these scenarios are not pilot-controllable though. Of course, the above are based on my understanding. I don't have any official documents that describe the AMRAAM's behavior in detail and I have no idea what newer versions are capable of.

Happy it worked, enjoy! Hi. The best way to go about it is to drop my textures (the two files in the "FA-18C Hornet LCD MDIs by Harker" folder) into the folder of the other cockpit livery mod and replace when prompted. Then, in the DCS Special options, select the customized cockpit from the drop down list and also, select "MFD Reflections -> Static" from the drop down list below (my textures don't have fake reflections, but it's just a naming convention in DCS). You should both get the rest of the customized cockpit, as well as my display textures, then.

If the track is dropped completely (memory times out etc), it shouldn't be possible to "re-acquire the same target". The FCR doesn't know that it's the same target, it's just a new contact now. For all the FCR (and possibly the pilot) knows, it's a different aircraft. Thus, the FCR shouldn't send guidance commands to the already launched AMRAAM, and the latter should simply continue towards the last intercept point. If that's not the case, then it's either an engine limitation or its WIP. The Hornet is a different case, since it employs MSI. The radar is not a necessary contributor for a trackfile to exist. MSI can use Datalink (and other) data to build and maintain trackfiles, although that part is not fully fleshed out yet in DCS. Thus, even if the radar drops the target, as long as other sensors contribute to MSI, it is maintained. However, if the radar is the only thing that contributes to the trackfile, the above conversation also applies here.

Hi, are you sure you placed the folder named "FA-18C Hornet LCD MDIs by Harker" in C:\Users\(username)\Saved Games\DCS(or DCS.openbeta)\Liveries\Cockpit_F-18C\ ? If so, you should be seeing this option in the drop down list of customized cockpits, in the Special tab of Options, in-game. Out of curiosity, are you actually getting the LCD-looking screens (kind of dark blue/purple color) or only seeing the green DDIs still?

That one is a bug. It's fixed internally.

I can confirm the issue is present on the current Open Beta. However, I tested internally on the Caucasus map, today, and cannot reproduce. So it's possible that it is fixed internally. I'll keep an eye out, but if you can, please test again after the next Open Beta update drops.

I'd actually prefer very few default liveries and for them to make the texture template available as soon as possible. That way, people can make and download what they want, while at the same time saving drive space.

2) Yes, you need to drop a WP on Echo. If you acquire it visually (or via the FLIR or Radar), you can also designate it and instantly drop a MK (Markpoint) on it, which is much faster. You can then either create an Offset with bearing and Range or just set up a courseline and anchor using that. Keep in mind that the Offset symbol drifts on the SA page (reported bug), so use the HSI for position keeping. 3) Keyhole CAS is complicated, no other way around it. It also takes us a while until bombs are delivered, in my group. A couple of points, the situation is unlikely to change between successive runs, so it's fast to adjust to the next target. And you can already start taking the 9-line on the way there, if time is of the essence. I don't know how it would go in a real world situation, but I'm guessing the JTAC/AFAC would handle available assets according to the situation.

1) Not possible to rename WPs from inside the cockpit, unfortunately. 2) For keyhole CAS, I tend to make a WP on Echo and set up an Offset for holding. Is that not what you're asking? Or you can just drop down a WP on Echo, plot a courseline from the A/B/C/D direction to use as a visual reference on the HSI and and make sure you're at the correct distance. 3) Before asking for a 9-line, I put myself in a stable orbit and prepare an empty WP. I use a notepad to write down the info, read it back and then input it in the jet. Don't try to get everything done in 1 minute, do it at your own pace. I found out that it helps if you have a consistent way of noting down info, so you can easily abbreviate some things for yourself and also easily reference the info you've taken.

It's Link 16 data, via MIDS. You'll only get that info on the JHMCS and that part/window of the AZ/EL page, if there is MIDS data available. In the AZ/EL, there are also other windows, for on-board sensor data, but they're not populated in DCS yet.

To be fair, I've found precious little about the range estimation feature. But it's nothing more than the RWR receiving a signal strength. AFAIK, most RWRs display the signal strength in some way, also taking into account the things you mentioned (frequency range, scan frequency, radar mode). I would expect that a threat that's far away, but has STT on you, would be considered more lethal than one that's just searching, at the same range. And there's a host of other things the RWR suite considers. Some signal strength estimation, alongside the emitter type etc, to determine the lethality of a threat, is necessary. How can the RWR (which can only process a limited number of signals at the same time) or the pilot looking at the screen, determine which emitter out there belongs to a priority threat vs one that's far away? In heavily populated airspaces, this becomes very important in order to maintain SA. Otherwise you either have 16 Lethal emitters and you don't know which ones are actually a threat, or you have zero Lethal emitters, until one of them starts tracking you in STT, which may never happen until it's too late, if at all.

I'm far from well informed in the matter, but from what I understand, in very simple terms, it can use the received signal strength vs the expected max signal strength for the emitter type. IIRC there's a thesis on the ALR-67 that discusses this to some extent. Also consider that other RWRs are also capable of this, such as the ALR-56, which places the icon closer to the middle, as the emitter signal strength increases, or the SPO-15, which indicates the signal strength of the primary emitter. The ALR-67 takes it a step further and can combine that estimated range/signal strength with a lethality factor (e.g. a MiG-29 is not lethal at 60 nmi, but a MiG-31 can be), in order to classify the emitter as Safe or Lethal. I'm also unsure about this, but I suspect that the system is conservative in its range estimation and is biased towards a shorter estimated range, for safety.

It's not supposed to show range, it's supposed to consider the range estimate to the emitter in its classification of the threat.

Just how the real thing works, based on public info. BST and WACQ place the range scale to 10 nmi, VACQ to 5 nmi. If I had to guess, I'd say the decision to limit VACQ to 5 nmi is that you're mainly using it to lock a defending target that's above or below your HUD limits during ACM and you want to avoid locking anything else that might be further out.

The "TDC depress on brick -> STT mini-raster" logic works. Try it on targets closer than their max detection range. SCS with the TDC on a brick also works. You might be noticing that, at max detection range, the mini-raster doesn't transition to STT immediately, but that's not necessarily wrong, STT acquisition can fail. The question of whether STT should have higher range than the detection range is another matter though.

ACM modes are range gated. Targets can be detected, but they are rejected beyond a certain range, since the point of ACM is to focus on nearby targets.

Would be nice if it was implemented. A lot of this info is available already in DCS and can be found on the SA page, so it's a matter of populating this page with the data, instead of the static values.

IAMs will only accept coordinates given in DDMMSS.ss format, currently. If you want to display all of the other coordinates in the aircraft in that format, you need to go to HSI->DATA->A/C and toggle the LATLN format option, located next to OSB 15.

I don't see anything wrong. It's supposed to be, the Maverick's seeker is much lower quality (makes sense, since it's supposed to be destroyed). See these for reference. I would say that DCS's quality is still much better than IRL.

Are you running any mods, by any chance? Shader, terrain or custom scripts? Any unit mods (that add custom units/objects) in the Saved Games folder? If so, try without them. I had a similar problem some time ago, with the Hornet's radar, and it was caused by such a mod.

Not a bug. If you have set up a course, CPL will attempt to intercept the courseline and get you to the destination, on that course. If you want to use CPL to fly straight to the destination, don't input a course (or input one that will fly you directly there and change it later).

That sounds normal, PP and TOO coordinates are station-specific. PP1/STA8 and PP1/STA2 are separate, for example. So, if I understand correctly, you programmed the four stations separately, selected the PP# you wanted for each station and then pickled one bomb from each station, which guided to the coordinates listed in its PP target upon release. If the above is what happened, then it behaves correctly.

Just tested the OB branch, works correctly here. 2B does HI-MED MED-HI HI-MED MED-HI 4B does HI-MED-HI-MED MED-HI-MED-HI HI-MED-HI-MED MED-HI-MED-HI

Agreed, if a reply is available, it should be displayed at the correct spot, regardless if a trackfile is present or not. If a trackfile is present, the IFF reply should be added to the trackfile information. And yeah, IFF replies should also be able to generate CIT-only MSI trackfiles, but that's part of the larger MSI implementation.