Harker

The TDC display logic is now the same as in the RDR ATTK and AZ\EL pages. The speed and altitude information are not tied to the TDC, they are tied to the trackfile, and they match its color, like in the other pages. This is correct and how it should be.

I tested myself, and what you're seeing here is the reported bug in the OP. MK saves the elevation in FT, but with with the value of M. In this case, the elevation was probably 33FT, and was saved as 33FT -> 10M -> 10FT, as per the bug. The pod is looking at the same LAT LONG coordinates, but it looks offset because it's looking "below" the ground elevation. So, nothing to do with DTED or drift etc, this is just the bug at work.

I also noticed this while doing missions in colder weather. The indicated fuel in lbs actually goes down when the temperature is lower, which contradicts what the NATOPS says. Also, regardless of the NATOPS, JP-8 has a positive thermal expansion coefficient, so its density should go down with increasing temperature.

SCAN RAID is not available when the target is below 5 nmi, so make sure that's not the case. (A crossed out SCAN RAID cue should also appear for 5 seconds if SCAN RAID is commanded but not available, but we don't have that in DCS yet)

We do have a shred of MSI implemented, otherwise we wouldn't be able to correlate ownship and MIDS tracks at all, and MIDS wouldn't be able to contribute to the ROE matrix. Although of course we're missing most of the MSI logic, it is important that all bug reports should consider that MSI should exist, and point out the buggy behavior with that context in mind, so as to avoid creating confusion over how should things work. As @Tholozor said, all on-board tracks should be considered as MSI trackfiles by default, so radar track = MSI trackfile. Lastly, MIDS tracks are never processed as MSI trackfiles right now anyway, the information is just correlated with the ownship trackfile. So those MIDS tracks would be available in any mode. In any event, the only thing we should be getting in A/G mode from the AIR radar is uncorrelated bricks and nothing more, and MIDS tracks that aren't processed into MSI trackfiles. The fact that we're getting MSI trackfiles from the MAP mode is a problem. Thankfully, it does seem that this is not the case in the dev build. I also tested myself and can confirm what @NineLine says, I don't see any trackfiles on the SA, and when I select the AMRAAM to quickly switch to A/A mode and AIR radar, I don't see any pre-existing bricks or trackfiles.

That should not be happening. MSI trackfiles are only built with A/A radar modes (not VS though) and only in NAV and A/A master modes. Here, the radar is in MAP mode, meaning it's only getting raw returns, not building anything, and the master mode is A/G. MSI trackfiles should not be built in A/G mode at all, even if the radar is in AIR, in RWS mode. An example is in A1-F18AC-742-100, 011 03, pg.3, par.18 This bug becomes even more "visible" if you switch to A/A mode quickly, after noticing the trackfile on the SA. You will observe that the RDR ATTK B-scope display already has several bricks, indicating the missiles were indeed being detected and the radar was generating bricks while the radar was in A/G MAP mode.

I'm not saying that, as I'm not sure what the radar exactly does when the switch is on STBY. It's possible that it can still receive incoming signals, and if that's the case, the MC can process them. The only info I have at hand now says that moving the switch to STBY activates/maintains all components of the radar set fully operational, but does not apply high voltage. It's very possible then, that since all components are operational, the radar can receive incoming signals.

I'm sure for STBY (I guess not), but the radar should indeed be capable of tracking interference sources in SIL. SIL will just stop the radar from radiating, but it will still process all incoming signals. About the range of the jammer being calculated in SIL past the "DCS burn-through" range, it's possible that passive ranging is available, given that the radar can determine an azimuth change rate based on the jammer and the ownship. The Hornet's radar also has special Quick-Look functions available in SIL, for quick updates on trackfiles of interest, although I don't think that's what's at play here. If it's intended, it's probably passive ranging.

Indeed, but due to the trackfile quality from MIDS being generally low, the MC will notify you in a few ways. If the L&S does not have radar contribution, then you will get a " NO RDR" cue on the RDR ATTK page and below the TD box on the HUD.

Not having this problem here. Are you running any mods? There were some updates to the TGP masking logic and masking indicators on the DDI and HUD (still WIP).

Definitely not correct behavior. The second HARM is within the same shot parameters, and thus the shot is valid. Furthermore, I realized that even if the second HARM is crossed out, it will still launch when you press the weapons release button. Which means the HUD, STORES and HARM pages are bugged when it comes to the cross out symbol being present.

Thanks, I also reported it now, alongside other issues with Offsets. What I can see is that after the FLIR (and only the FLIR) becomes the designating sensor, it will actually slew the Offset coordinates, alongside the weird FEET -> METERS switch that you mention here. Generally, I would only used Offsets as fixed points and avoid slewing the designation with any sensor, for now.

You need to depress the TDC to update the designation with the LITENING. The ATFLIR updates the designation continuously, as long as it's the sensor that drives the designation.

Thanks for bringing this up. Further testing showed that this bug manifests itself when you don't have any trackfiles with radar contribution or AOTs. I linked this report to my own.

Actual sensor fusion, as in the ability to designate trackfiles without radar contribution, or slave sensors to them. Another thing would be the ability to use sensors other than the radar to contribute to and/or create MSI trackfiles. Lastly, there's a system to "rank" sensor importance/priority, to determine which one is the most reliable, and thus use it as the primary source of data. Like how the radar is higher priority than MIDS right now (even though you get information from C2 and/or F/F, your MSI trackfile's position, altitude and velocity is primarily determined by your radar).

I reported this recently as well. All indications, including BRA, should either be in True or Magnetic, depending on the selection in the A/C subpage of the HSI.

I could recreate this, I reported it as well.

The correct behavior is that Offset elevation is the absolute value of the Offset itself, not the difference between the Offset and the Waypoint (so it's now correct in-game). If the game manual says otherwise, it's a mistake.

According to documentation, STT should indeed be not available when in the A/G master mode. You can switch to the A/A radar by selecting AIR, but the only modes available are RWS and VS (no TWS, since trackfiles are not build in A/G master mode). Automatic acquisition modes, as well as STT, are unavailable.

The feature works as in the real jet. When you are in A/A, are carrying a HARM, and being locked by a surface to air system, the weapons release button is always hot with a HARM in Pullback. I suggest binding the trigger and the weapons release button on different buttons, so this isn't a problem anymore. The same situation can arise when you are in A/G mode, with a weapon selected and the gun hot as well.

How one DDI label at the bottom right of the STORES and EW pages is not cluttering. The intent is to always keep the pilot informed of the status of the HARM Pullback setting, regardless of the mode.

EECM is not modeled at all, throughout DCS. Only some ECM effects are modeled. The Hornet can currently resolve the angle and elevation of jamming targets, and display them as Angle Only Tracks (AOT). At around 21 NM, it can also resolve the range.

They can be donated from C2 assets as MIDS surface points, much like you can see the ground designation of your wingman on the SA page. The C2 asset can create a surface point, and assign attributes to it (e.g. SA-10, hostile), and so the point will show a red 10, with a red, dashed circle. If the RWR picks it up and correlates it, the circle becomes solid. And because it's a MIDS point, you can TUC it and get relevant info, as well as hide it from the SA display subpage (which we don't have).

The current behavior is incorrect, the warning altitude is supposed to reset to zero, once, after weight on wheels is achieved after the gear is cycled, but in DCS, it resets to zero as long as there is weight in wheels.

This is reported.