Ahmed

If this is the intended result, the team should probably consider implementing a model based on % probability of detection per sweep vs range/rcs (instead of a hard-coded formula that always returns the same max distances for detection and acquisition for a given RCS), as one of the third parties has already done, together with full MEM logic (that I think is working now) and RCS variation with external stores. Otherwise the current effect from having that reproducible hardcoded result and reduced "lock range" is really not realistic.

Why would you disable a resource available in the real aircraft? We already have a really overdone and unrealistic wing-snapping model to try to deter people from over-g-ing. I personally would rather have a better damage model for the hornet itself that seems to be unable to survive any blasts, other than 4000fpm landings, lacks (like all aircraft in DCS) fragging and loses the wings before the stores hanging from those wings. I understand why you want to forbid people from using the paddle switch in "competitive" servers, but for that darkman above gives you a very good solution.

Recorded in a laptop with keyboard, but I think it still illustrates the issue. The flight model/FCS exhibits negative static stability when in PA mode. After rolling to a 30º bank, going hands off results on the aircraft overbanking progressively. This is highly unusual for a fixed wing aircraft and would definitely be documented in the NFM if it were a known handling characteristic. latstab.trk

Hi, TERM settings have no effect on the AGM-154C, as in the track 154c.trk

Hi, As in the title, turning the RWR OFF while the jammer is transmitting and the JAMMER ON legend is visible in the RDR ATTK format leaves the JAMMER on text forever in the RDR ATTK format. jammer on.trk

This is definitely not correct for the KC-135.

Currently the hornet only has a partial simulation of the CLASS/TYPE options in HARM TOO, and is also missing the MN FILE option, that limits it quite a lot in comparison to what ED has implemented on the viper DED HARM page. While arguably there is not enough OS documentation to completely implement all of the above in-cockpit options, a good compromise would be to allow the player to edit the contents of the class tables at the mission planning stage when DTC/MUMI gets implemented (or at least through a external LUA file), rather than having the predefined ones hardcoded. This would at least allow the DCS Hornet to match the DCS Viper on capabilities that are available to both irl.

You are making a very big assumption there that I don't think that you can back up and thus would be misleading. And as Hulkbust44 says, there is enough open source knowledge on many systems to implement many things that are not implemented in DCS. Unfortunately, as I don't think anybody can prove with OS info whether TOO is correctly or wrongly implemented right now, I think this is not one of those things.

The FM/FCS also has the standing bug of the negative static lateral stability while in PA mode (i.e. the hornet constantly tends to overbank while in PA mode)

Flies off a boat, has 2 engines (that should make a difference if the DM is fixed), and (if we finally get it) has an unmatched MSI for a 4th gen.

@BIGNEWY, if I may as a question: why was this moved to the wishlist? The DCS Hornet was advertised with SP/TOO/PB HARM modes as a feature, and EOM is just a submode of TOO and PB (entered by simply selecting TOO/PB a second time). There is a lot of documentation available on them in publicly available docs.

Yes, this happens always at 20k true (world) altitude in DCS. Funnily enough I can't manage to reproduce this in SP to submit a track, but I get it always in our group's MP server.

It's a bug and it was reported AFAIK. SRS should still take you to the correct channel because the person that contributed the code for the F18 SRS exporter is very smart

And another (probably spurious) JAM cue in a random BFM YT video by pure coincidence. a

Hi, This must be reported already but I can't find it anymore on a forum search. The Barometric Low Altitude Warning seems to be currently using true world altitude instead of sensed barometric altitude. This makes it unusable on days that are not ISA because, as you can see on the attached track, it triggers are completely different barometric altitudes than set to. baro_alt.trk

There is no visible L&S on your video, that's exactly why/when the "JAM" cue is visible (the JAM cue shows when jamming is detected not associated with the MSI L&S or STT trackfile. If the jamming were associated with the MSI L&S or STT trackfile then it would say "XJAM" according to the 742 that Harker points to, or, apparently in a 2016 Hornet, in some contexts "VJAM" looking at my screenshot). The 6 in your photo, taking into account that it is a 1991 photo and thus pre ENT92A, represents only a lethal threat (don't compare it to the meaning you get on DCS of that same symbology as it is wrong in DCS).

Exactly what he says. The only catch here is that DCS models a hard altitude and not an elevation angle (not to mention that it also limited to a single radar per unit, so can't model the 1S11 and 1S31 in the Straight Flush vehicle). Currently in DCS the max 7km altitude is set in the missile definition. So, some room for improvement here to be able to simulate a full strength SA-6 battery at some point.

JAM Code/cues are also present on 2016 Rhinos Hornets. Whether its presence is related to own jammer active as OP says, or own radar detecting jamming against it (as some docs seem to suggest -- see JAM/XJAM cues), is beyond my understanding.

This was the way it is in the manual decades ago (i.e. critical threats on the inner ring) and that's why other planes like the F-14 have it that way in DCS. The DCS Hornet was released that way, but ED correctly fixed it to critical threats on the inner ring, just the manual hasn't been updated as the OP reports. The ring logic (i.e. the interpretation DCS has made of what lethal, non-lethal and critical mean) is wrong currently though.

This is probably a very good idea... There are some issues, like no deck crew wands at night, that likely most users would be putting near the top of that list.

There are some other systems that have been misunderstood from public docs and implemented wrongly (e.g. several ALR-67/HUD EW issues, including threat ring logic), that are also not due to contractual reasons. As EA doesn't have a set end (and that is to many extents a positive thing), I hope that ED take time to fix some of these major system issues in the hornet prior to releasing it.

The Weapon.getTarget() mission scripting function returns a 'nil' target when used on a HARM that has been shot in PB mode. While the missile has no target on launch, it still returns 'nil' after it homes on a target later on in flight. See track. gettarget.trk

Now that the viper got EOM implemented, the Hornet is still missing PB/EOM and TOO/EOM and associated HUD/HSI symbology. FRM versions dating back to 2003 have information on this.

According to NATOPS, the home waypoint should be X'd out when FPAS cannot provide the home fuel caution function. This is in addition to removing the up/down arrows. DCS does the later, but does not X-out the waypoint number. home_wpt.trk

Adding to this, this post added evidence that the Harpoon should cruise at 50-200ft in skim.