Ahmed

IRL pilots have also confirmed that the G-limiter in DCS is much worse than the real. It should be possible to over-g, it should definitely NOT be as easy as it is in DCS. In close connection with this report, the G-limiter in DCS also doesn't allow the aircraft to achieve the G-limit in the FCS page (i.e. will cap sustained G at 7.1g when the FCS page states 7.2g) under many different conditions.

If you can reliably detect a contact you can track it. The thing irl is that there is no such thing as a hardcoded maximum range to detect a specific RCS target, this will vary due to a wide variety of factors, and can be modeled as 50% probability of detection range, 99% pd range and so on, and in the lower %pd ranges consistent detections will be unreliable and thus tracking may break too. That's why a certain 3rd party has done a great job bringing that radar model to DCS, and that's also why the current ~83% hardcoded limit in ED's modules (while you can perfectly track in TWS) is really inaccurate.

Thanks for the response. Sorry for the confusion, the mention of priority was just that the video is also a good example of how those 6 most priority threats are shown, it wasn't intended as to insinuate that it has any relation with the overlapping. What is visible in the video is that no 2 symbols overlap (probably, as you say, because offset is on, even though we can't know this for sure... but in DCS even in offset mode they do overlap under certain conditions). I'll take the opportunity to say it also shows some of the missing symbology such as the flashing long stem ("critical threat with special lethality conditions" in the book), and should also help illustrate the whole lethal/non-lethal/critical misinterpretation we currently have in DCS. So many things in such a short clip!

Yep I tried to reach you on Discord with the same comment. Alternate symbols are mippling or other enhancement symbols (e.g. SH in the old times), not some anti-overlapping logic. In any case, symbols, at least in offset mode, should not overlap and they do in DCS. The short video scene linked below has a very good example of the priority logic and how symbols don't overlap. In DCS under certain combinations of lethality they still do overlap, my suspicion being that because the source text ED used for that logic comes from the "old" suite where the thread rings were reversed and that refers to the azimuth indicator logic.

I think that they mean that there is not enough documentation to model them, not that there is no documentary proof of a 2005 Hornet having TOO/PB EOM. There is limited documentation about those in some 2001 documents that don't have any mention to export control in their distribution notice. Currently we seem to have the older non-EOM HARM avionics (partially) simulated.

Most has been said by others. Just adding: 1) Fixed RWR threat rings (i.e. correct what goes into non-lethal, lethal and critical rings) and associated HUD EW. 2) Improved radar model. As mentioned recently in another thread, having the radar have 100% probability of detection of something at e.g 48NM but only be able to STT It at e.g. 36NM is very wrong. 3) Radar resolution cell modeling. An yes please.... get this easy thing fixed. LDDI changing is not correct for the year and operator of our Hornet (SMEs will confirm)

Oh, I'm afraid that you are right. I noticed that there was some MEM logic working in-game and wrongly assumed it was fully implemented. Good point!

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.