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).