Ahmed

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.

I can reproduce it below 10ft MSL at least on this laptop (default settings). Track attached with keyboard shenanigans. mirrors.trk

I see this is tagged as "need evidence". NFM "High AOA Flying Qualities" section has some information on it.

^^^^ what they said. First of all we are aiming for 40%-ish of the real due to what is available publicly. And from what the DCS Hornet could ever be, there are still plenty of partially implemented features and dozens of open bug reports. Hoping to see some more dev time allocated to all that in future updates. I don't know how long until the module is commercially tagged as "complete", but it is still far from a 100% completion state.

The wings are NOT going to snap off at 9G.... Plus also, the g-limiter should work MUCH better than it does in DCS. While over-ging is possible, it shouldn't be as easy as it is in DCS... So many things to fine tune still...

There is nothing of that modeled in DCS, just any player within a huge beamwidth (defined in the db files as 90º for most if not all emitters...) receiving a lock warning. However, fixing only that and making only the locked player receive a lock warning won't send you anywhere closer to real life. It will just give you a perfect and ideal, almost magic, sensor. What DCS should model is more accurate beamwidths and how a receiving RWR would interpret what it receives, that would lead to stuff such as getting spurious lock/launch warnings when you are not the target but are close enough to it, and other effects. Of course real stuff suffers of many more limitations, such as mippling/ambiguities, longer times required to detect certain emissions, bad intel.... that are probably out of the scope of DCS. So, TLDR, this seems to currently be half-bug/half-feature in DCS. Fixing the bug without completing the feature brings nothing but less realistic behavior.

You guys are way too spoiled with perfect sensor modeling in DCS and other sims, and other stuff such as only getting missile launch warnings when you are specifically the target without any consideration to basic rf propagation. "Spurious" warnings are not necessarily bugs. While in DCS some of these my be near-ridiculous, we are also missing many other factors that make real RWRs much less perfect sensors than what many think they are based on what they see in DCS and other pc sims. Just look at Victory205's comment...

Against an S-300+.... probably integrate that SEAD/DEAD flight into a larger package including many more HARM shooters, SOJ, TALD/MALD launchers, maybe TLAMs... all with a coordinated TOT plan and probably multiple attack axes. Maybe one day.... for now in DCS a single hornet player can abuse the game's mechanics and score a hit relatively easy.

The AGM-88 has a proximity fuse, so that part is not necessarily wrong.

Launch warning is triggered by a discernable mode switch (change of PRF, detection of CW/PD illuminator, detection of command uplink...). Thus, an AIM-7 launch for example can "easily" be detected. An AIM-120 launch, regardless of being launched in STT or TWS, should likely not produce any launch warning on the target prior to the missile going active, for the same reasons above (STT would however still produce a lock warning). I think that most of this is actually correctly modeled in DCS.

That seems to overperform sustained turn rate by 50% indeed with reference to rl docs.

It may be the same issue that I reported here: The problem there was that it was even tracking when the tracked object maneuvered while masked.

Hi, Noticed that the SA shows lock lines for other players when they don't have an L&S track. After further looking, it seems that the ACQ point track is being broadcast and shown to other players as a lock line when the player is searching in RWS and has no L&S track. MP tracks attached. server-20211117-140717.trk test-20211117-210839.trk

The problem here is essentially that DCS HARM targets a unit, and thus the unit model center. That's why armor incorrectly comes into play. As seen in plenty of footage, the HARM should guide to the emitter itself, and emitters themselves are exposed enough to be damaged beyond usability by any HARM impact. The vehicle may survive, but the radar wont. The real fix would be improving DM of ground units and having ARMs target the emitters rather than the unit centroid. See example with inert AARGM

Hi, Using getSensors() on a ground unit in a group with mixed types seems to return the wrong sensors. See the attached example with P-19 returning SNR-75 sensors instead of its own. getsensors.trk

There is definitely some odd behavior either on the FM or FCS. I hope this is being investigated for the FM update.

Hi, A/A waypoint information (including both L&S and ownship bearing/distance) disappear in DCS when STT is entered from ACM. They should be available in all instances of STT, TWS and RWS, according to the real documentation. Track attached. aa_wpt.trk

Hi, Compared to publicly available HUD footage, the HUD EW lines in DCS seem to be misplaced. In the screencaps below, notice that the real threat code does not occlude the heading tape when directly at the 12 o'clock position (is above it), and likewise stays out of the airspeed box at most angles. In DCS, the center reference position they use also seems to below the real. The stem lengths in DCS seem also too long (especially the dashed/long) in comparison. Last 2 photos are a rhino but they show cleared footage and seem to match the hornet's. Reference videos for the attached screencaps: https://www.youtube.com/watch?v=up7V79QzCog (hornet screencaps) https://www.youtube.com/watch?v=wPY_BzTTqqQ (rhino screencap) This is aside from the previously reported issues with the non-lethal/lethal/critical logic and the missing flashing long stem. Track also attached. hud_ew_pos.trk

Hi, Noticed that "RTS RWS" from HACQ or WACQ goes back to RWS but leaves the boxed "ACM" indication instead of fully exiting the ACM condition. This doesn't happen from BST or VACQ, where the correct SIL pushbutton is shown on return to RWS. Tracks attached. rts_hacq.trk rts_wacq.trk