Harker

The issue is that the LITENING we have only has two levels of optical zoom, WIDE and NAR. The 1-9 zoom levels are digital zoom and as such, the more you zoom in with them, the worse the picture quality should get. This isn't simulated and thus led to the pod vastly overperforming in terms of image quality when zoomed in. The correct approach would be to keep the digital zoom as is and make the picture worse and worse as you zoom in. ED, however, instead decided to limit how much you can zoom, but still keep the picture perfectly clear. It sort of achieves the intended effect of not letting you see details from further away than you're supposed to. I'm guessing it's a temporary measure until sensor effects are reworked.

Indeed, the relevant manual makes no mention to having to select LAT and LON separately, the only relevant UFC option shown is POSN.

So instead of blurring digital zoom, they limit the zoom level and only on the Hornet. Again, the same pod works differently on different jets. These changes, for one way or another, need to be global, not module-specific.

I agree. Especially for the A variant.

Although I cannot find the time for very long missions sometimes, I still appreciate a mission that's realistically long. So, 2+ hours is OK with me, personally. But it should be designed in a way that the time taken makes sense. Like, flying ingress and egress routes, tanking, staying on station for some time and actually using your sensors, such as IDing aircraft or ships visually or with the FLIR, guiding a couple of SLAM-ERs, escorting aircraft out of a zone, intercepting, working with the JTAC etc. It's OK to have long ingress and egress, as long as you also have a good amount of things to do besides that. Making a mission without that consists of a 2 hour CAP, where absolutely nothing happens, although realistic, would not be fun for me. I think the user made campaign Operation Exigent Riviera found a good balance and of course, Raven One is a great example.

When the ATFLIR is zoomed in to the 2.0 level in MFOV and NAR, the WP flag(s) move as you slew, in the direction of slewing. The flags should not move. 2.7.2.8165.2 Open Beta. Track attached. FA-18C_ATFLIR_waypoint flag moves at 2nd zoom level.trk I believe this successfully pins down the problem encountered here:

For me, it's the much more sophisticated avionics in general and MSI in particular (especially after missing features are implemented). The amount of situational awareness, sensor integration and target management that the Hornet can offer cannot be matched by the Viper. That's the biggest one. Third display, allowing you to have two sensor pages and still have the HSI/SA pulled up. Both aircraft have good HOTAS schemes, but I like the extra automation of the Hornet (ranked target stepping, quickly pulling up the RDR ATTK, AZ/EL, HSI/SA etc) and the ability to select options with the TDC. Easier to navigate menus. In the Viper, you only have 6 pages available and you need to replace an existing one, if you want to view another one. In the Hornet, you can view all pages easily and quickly switch to the important ones. Two MIDS radios for a total of 4 radios. Higher flexibility in loadouts. Carrier ops. There's something very satisfying about doing an OK landing after a long mission and proper carrier ops add an extra element on top of everything else.

The radar doesn't work in a vacuum though. The target ranking and undesignate-to-designate logic are controlled by the MC, based on trackfile properties and the radar does not build the trackfiles itself, the MC does, through the MSI system. If you don't make use of ranks and do everything manually with the TDC, you can somewhat bypass the system, but if you want to use ranks and target stepping, you work with tracks and other things enter the equation. This does not negate what was said though, the radar system and the MC will employ range and Doppler gates to isolate the intended track. That becomes even more important for STT and also true for ACM modes, where MSI processing stops.

GGTharos is right, without Doppler and range gates, it's impossible for a radar to distinguish between a cold missile that's 5 NM away from you or a hot bandit that's 20 NM from you. If the gates were implemented, if the radar was tracking a target with Vc=900 NM/s at 20 NM away, in STT, it wouldn't switch to an outgoing target with Vc=-900 NM/s at 5 NM away, because the Doppler shift is completely different and the range is completely different. So that's a non-issue IRL. As for stepping through targets with Undesignate, some of the criteria the MC uses to rank threats are ROE, closing velocity and hot aspect, so it'd rank incoming verified bandits higher than your own missile. If that's not the case, then something is wrong with the ranking in DCS. There's also the possibility that the radar could correlate the outgoing missile trackfile with its separate tracking of the missile for the radar-missile datalink and exclude it from being selected or even presented in the first place, but I have no info about that.

Not implemented yet, I checked recently. That knob is indeed what you're looking for, but although the emitter type letter is changing on the display, the filter logic is not implemented.

Yes, you can have various zones defined on the HSI/SA/HSD etc, for various reasons. Some could be refueling zones (Harrier already does that), no-fly zones, borders etc. The logic is similar to how the SAM zones are marked on the same displays.

Very good idea. +1

You're right, it should be faster. The ALR-67(V)2 is coupled with the INS, so it can log the threat azimuth and update it on the display at the speed of the other INS elements, when changing ownship azimuth. In DCS, it's much slower than the INS update speed. I'm not sure if the RWR is only updating the azimuth upon a new detection or it's working with the INS, but slower than it should. Both the Tomcat (earlier version of the same RWR) and the Harrier (same version) update the azimuth faster, when turning. There have been a few discussions about this in the past.

The correct approach would be to make the FM correct enough for each airframe, so that each aircraft would react differently to the same turbulence, not bake in a turbulence effect out of nowhere.

The easiest way is to be on SIL and get info on the trackfile from the datalink. You can see the altitude and Mach of an off board trackfile if you hover the TDC over it. Then, you can set up your radar so that you can detect it quickly, go out of SIL and engage. If you enter STT from an non-ACM mode, you can switch TDC priority between displays. I was actually surprised that my FLIR autotrack target dropped after I silenced my radar and the trackfile disappeared, but I'm pretty sure that's a bug (probably) and also WIP, since the FLIR in autotrack mode can contribute to the MSI trackfile by itself. The AZ/EL does have a FLIR level, you can switch between the radar and FLIR one with OSB 5 or by bumping the SCS towards the AZ/EL. The main problem with the AZ/EL, however, is that it's not showing off board MSI trackfiles, as it should. That'd make it very easy to stay on SIL and point the FLIR to an off board track, so hopefully it gets implemented sooner rather than later. You should also be able to designate an off board MSI trackfile as the L&S, but that's not implemented yet either. In short, I go with SIL and turn on my radar only to engage, but the entire EMCON approach will change after the missing MSI functionalities are implemented.

The texture file only has one side and the file is mirrored on the 3D model. ED themselves would need to change this.

This is how it should be done. An area behind the island should cause turbulence, your plane shouldn't wobble on its own. I'm guessing HB will remove their effect when/if ED adds the burble properly.

Second test, I made sure I was in look-up mode. Own altitude, 10k ft, targets at 32k ft and 37k ft. Tu-95MS detected at 78 NM. No difference from before. Track attached. 2.7.1.7139 Open Beta FA-18C_radar detection_78 NM for large RCS.trk

Using the radar equation for Rmax and starting from the detection range of the Su-27 (~47-48 NM), with an RCS of 5.5 m2 in DCS, the terms other than the RCS are bundled together as a constant of ~31. So, for the DCS Hornet, we can roughly use Rmax = 31 (RCS)^0.25. Using that, a Tu-95MS (RCS 100 m2) should be detected at ~99 NM and the IL-78M (RCS 80m2) should be detected at ~92 NM. In my test, I was flying at 18000 ft, while the targets were at 20000 ft. I was in RWS with HPRF, 20 degree azimuth, 1 bar scan. The targets were hot and closure speed was around 950-1000 knots. I detected both the Tu-95MS and the IL-78M at ~79 NM, meaning 20 NM and 13 NM below what I should have. Even a detection range of 85 NM is still well below the expected one. Now, the RCS values for the two large planes might be a little old, but a max detection range of 79 NM corresponds to an RCS of 42, which is way too low for these planes. So, either the RCS values are wrong or the radar detection matrix of the Hornet does not utilize the radar range equation.

My thoughts exactly. I'd like to have VS for completeness, but getting RWS, TWS and more importantly MSI to work correctly, is far more important and, IMO, a requirement for Early Access.

Well, the 742-100 only talks about RWS, TWS and VS, as A/A master modes. Other than those, you have ACM, STT, RAID and auto-acquisition modes. This document is for the post-MSI APG-65 though, so maybe the APG-73 RUG II is different. Yeah, I also looked and found info on the APG-66 that says ~30 NM. Then there's the question of the mode, look-up or look-down etc... But at least in DCS, we should be discussing the Viper's RWS and TWS modes, nothing else. If ED wants to add other modes that offer increased detection range, such as LRS, then they should model them properly. I got no comment on the KJL-7V1, really. It was introduced more recently than the APG-68(V)5, I'd say that it could be more comparable to the V8 or V9. But that's all speculation, as I haven't really spent much time looking into it. It really would depend on how much it improved over the older Phazotron designs it was based on.

Try increasing the ageout setting in the DATA sublevel and save it with SET, in the RWS page. For the AMRRAM, it defaults to 4, increase it and it might help with maintaining targets. The ageout setting is only supposed to control how long the bricks stay on the RDR ATTK page, but in DCS, it also controls how long the trackfile is maintained after the last detection. Which is shouldn't, as the logic is different for that IRL and is based on whether or not the target was detected on the same sweep of the next cycle.

AFAIK this shouldn't be possible. The jet will steer you to one thing at a time. Boxing TCN should remove the AG designation and steer to the TACAN station and designating should unbox TCN and switch steering to the designation.

Increase your ageout setting, in the DATA sublevel and press SET in the RWS mode page. The setting is implemented wrongly in DCS and ties the radar memory to the bricks ageout setting. For the AMRAAM, it defaults to 4, so until the bug is fixed, increase it.

Our Hornet should certainly have it, it's a clearly described in official manuals. But from what I can see from comments from ED, we're probably not getting it.