Ahmed

Hi, I noticed that the HARM in TOO mode can home on the 1L13 and 55G6 VHF EW radars. Publicly available documents suggest that the lowest band the AGM-88C can home on is the C band, and thus it wouldn't be able to target VHF emitters. In the DCS Hornet it seems it is not possible to target these emitters in SP mode, only TOO, and they don't have the RADAR_BAND_1_FOR_ARM or RADAR_BAND_2_FOR_ARM attributes in the database, so this leads me to believe that this is a bug in TOO rather than a design decision. Track attached. harm.trk

The primary usage of the radar channel, AFAIK, is to prevent interference between radars in close proximity (i.e. wingmen). While it would be great to have them in the sim, they shoudn't really have any effect over any decent DECM setup, as the processor will generate appropriate signals for whatever it has identified as the threat it intends to deceive.

That particular campaign you installed seems to need you to edit some lines on the MissionScripting.lua file of your DCS install to save campaign progress. I'd suggest you take a look at the campaign's readme file or other install/usage documentation

Do you have any source for this claim? As far as I know only some 5th gen platforms have this capability.

Agreed. While the last update reportedly fixed some issues some people were experiencing with some modules, I found it way excessive if click and dragging on the Hornet (resulted in tens of .inHg for a minor click&drag)

Number 6 is indeed still present and looks like a misinterpretation of a note on the NFM normal procedures

There is a radar / jammer filter priority logic for exactly this reason. Aside from being togglable from the RDR ATTK page, it is automatically enabled while guiding an Aim-7 or Aim-120. However, it is not implemented in DCS.

So far it seems the way DCS simulates it is way oversimplified (resulting also in a really op system), and doesn't consider a lot of factors, just depicting moving units as spawned form the ME/scripting. As you can read in the bug reports section, there are some reports and requets for ED to improve this to perform in a more realistic manner.

As I posted in another thread, a quote from an article: There are also some videos from ODS on Youtube where it is actually put to some good use (also described in Vipers in the Storm), but it must definitely be way more limited than what any PC game has ever modelled.

Thanks for looking into it. Your SMEs will definitely know better, but there are several accounts online on how useful GMT really is. For example: from http://www.ausairpower.net/SuperBug.html

Submarines are also detectable at 80NM, beyond the horizon, in 18+ foot swells (200kt wind). GMT/SEA have probably been too early accessed. Hoping that it gets polished for the release.

This does make a lot of sense.

The RWR should actually go off for anyone within the coverage area of the FLOOD cone, not just the target. This is true also for other types of guidances, but especially true for a mode such as FLOOD. I hope that this gets implemented correctly to avoid magic sensors.

Hi BN, I recorded a new track showing the issue. As explained above, the search/acquisition radars show up on HARM TOO despite alarm state being green. This only happens in multiplayer with a remote server. radar_test-20201228-173718.trk

Bumping this as the issue still persist on latest OB. Acquisition radars that are not emitting show in HARM TOO, despite correctly not showing on RWR, as you can see in the track.

AI flies true altitude

Hi, Despite multiple reports on the forums and other means of bug reporting, it seems that the DCS F18 RWR threat ring logic is staying as it is (understandable, given that precise information is difficult-to-impossible to find publicly). I'd like to request, though, that the HUD EW symbology for missile launch (non-flashing long stem) gets reported as "likely incorrect". Videos around the web suggest that missile launch indications is a flashing long stem, as seen in (including ML tone), and among others, suggest that it should be a flashing long stem. This is also covered in publicly available documents ("If special lethality conditions exist, the emitter character code, and if applicable its enhancement code is flashed on the HUD display"), and fully congruent with how it is represented in both the azimuth indicator and the EW MFD page. In any case, the whole RWR threat ring logic should probably be revisited at some point, as it is very likely wrong and, hopefully one day, further stuff such as ambiguities and mippling introduced.

Indeed

Looks like you mainly need to understand the FCS logic and practice trimming the DCS Hornet. For the 1% pull on the break, if you don't want to climb or descend, you will need the appropriate bank angle, get a feel for it. When you lower gear and flaps, especially if light and already level, there is still some balloming in the DCS Hornet that you will have to deal with. Then the important thing is trimming on speed, so that's what you should practice until you understand. It'll be really simple when you get it. As for maintaining 30º of bank..... there is still some FM issue with having negative lateral static stability with flaps full (/half?), it tends to overshoot, so you need to bring the bank angle into your scan and continuously correct for that. Once you roll on final you should be already trimmed on speed, if you are trying to do that in the last seconds of the approach it will likely be messy as you say, so just practice trimming on a level flight and once you get the idea apply that to your landing pattern. Lex had a very good video on that but I can't find it anymore, maybe somebody else will post it.

F2 altitude is just the world Y coordinate, so it is normal that you see a difference between your indicated altitude and true altitude, unless you are at ISA and without any kind of instrument error (if that is simulated).

One thing to remember here is that target altitude was already shown before GPS was introduced, so that should debunk most of the GPS theories. It could have been updated to use that though, but would that be done if there is a posibility of having a GPS denied/degraded scenario, when you have self-contained air data always available? I don't know the real answer, and it is probably difficult to find in the public systems documentation, but my guess would be that it is likely referenced to ownships's baro altitude. Probably something for ED to check with SMEs

Tlepolemos, there are real manuals, publicly available, that describe this. I advise you get ahold of them and read them before insisting more on your point.

I'm not reporting that the video is different than DCS. I'm reporting that DCS is different than the NFM-000 description of how it works. The video is just an added reference aside from the DCS replay track (and happens to match the NFM description as you would expect).

Hello, I noticed that acquisition radars are shown on the HARM TOO display and can be targetted despite the unit being in alarm state green, only in MP (dedicated server). They also are shown visually turning on the exterior views. They are not detected by the RWR, suggesting it is some kind of MP desync issue and they are actually not emitting, as per alarm state. In SP, the mission works as expected and they are not displayed on the HARM TOO display. Track attached. radar_test-20201106-185346.trk

Track attached as requested. Also, below, video showing the real tone rate changing according to the above description (from timestamp 0:34). In DCS the chopped tone rate is always the same. yawrate.trk