MARLAN_

PLEASE fix this issue. Its been happening for years. It ruins any MP mission that has briefed timings (luckily this mission was a small check ride, which is why I finally have a small track file where it happens fairly quickly) The issue happens shortly after 0956, both Cat 3 and Cat 4 will not accept any aircraft (View the aircraft carrier) server-20240417-160837.trk

Various different public radar handbooks clearly say that HPRF has worse (not zero) detection against cold targets due to competing with side & main lobe clutter. In addition, and most importantly, Range Gated HPRF (RGHPRF) does not have this problem. RGHPRF has all-aspect capability (comparable to MPRF) but not used at low altitude (<5K) due to high false alarms and shorter detection range than HPRF. The F-18 uses both HPRF and RGHPRF.

It works as expected for me.

Read page 1

I'm sick of going in circles. Go ask US Navy pilots what is considered the normal landing weight at the boat. You can interpret it however you want, but your opinion is just an opinion. I'll try to explain one last time: the listed restrictions are normal cases (i.e. it would be a special case to be limited to 33K). You can only land at 34K when: using full flaps (or half if >40 knots) (normal), and if your lateral weight is not excessive (normal), and if you are using IFLOLS (normal), and if you are using a 3.5 deg glideslope (normal). I really don't understand why this is so confusing, but I'm done going in circles on this, it is irrelevant. All that matters is that 34K is a case that can happen, and if the DCS F-18 is collapsing gears <34K (adhering to the applicable conditions, e.g. lateral weight and glideslope) then it is a bug, thats it, end of story. I still don't even know if it actually is breaking <34K because it seems the bug is something else entirely anyway. I am only here because I don't want ED to think that the DCS F-18 should be collapsing its gears >33<34K because that is completely wrong. P.S. that image you posted is not public release, and breaks forum rules, you should edit it out and remove it before you receive warning points or worse.

Yes, that is correct, but the "restricted" is the normal. The "restrictions" are normal situations. Think of it this way: Jogging: Unrestricted: 10km/h Restricted: 15km/h Restriction: Must wear shoes.

Its likely a race condition, this should be reviewed by a developer, not a community manager. Race conditions are tricky to track down often times. It is not possible to "get a track" of a race condition.

It seems like this is a race condition causing the datalink tracks not to render. I tried various different startup procedures (e.g. turning on DL while engines are spinning up, trying starting right before left and vice versa, etc.) trying to force the bug to reproduce but nothing I did caused it to reliably reproduce, it only showed up in maybe 1/5 attempts or so. Key notes: 1) Nothing I did would cause the datalink contacts to appear on the AZ/EL page (including cycling the generators, and resetting the mission computers, choosing different pages, etc.) EXCEPT FOR: when I put the RDR ATTK page on the L-DDI and then selected AZ/EL afterwards, everything appeared normally. This leads me to believe it is some kind of race condition where selecting RDR ATTK causes it to re-render and fix it, but without seeing the code this is all speculation. 2) When re-playing the saved track file where I produced the bug, the bug did not reproduce. Which further makes me believe this is a race condition. Track file where I "reproduced" the bug is attached, but as mentioned, it does not reproduce in the track file, at least not in the one replay I did, since there's a good chance its a race condition you could probably just keep replaying the track file until it happens again. azelbroke.trk @Callsign JoNay - Since it might be a little buried in the above: To "fix" the issue in flight - select the RDR ATTK page on the L-DDI, then reselect AZ/EL.

They should improve their "nothing"/"livery not found" case. On a slightly different but related note, if a `description.lua` is missing (or the flags) the default should be no numbers (or one style, e.g. USN) rather than ALL numbers displayed. Its quite weird that they inverted it when they made this change, its no surprise that there have been countless issues since then.

That's wrong, the normal is 34K. The "restrictions" are things like you can't use MOVLAS, there's a list in the NATOPS, and the listed restrictions are all special situations. Multiple F18 pilots have told me this as well, feel free to ask some yourself. It doesn't matter what anyone here believes anyway, it clearly states 34K is an acceptable limit, whatever you believe it to mean, I guarantee its not wheels breaking (and 39K is listed as well for field landings). I am happy that wheels are damaged if you make a very hard/bad landing, but if they're breaking at 34K that's just straight wrong.

34K is max trap at the boat, 33K is for special conditions. If wheels are breaking at 34,001 lbs something is tuned incorrectly on the FM. Additionally, you should be able to land up to 39K at the field (flared, or easy landing).

Finally have flown enough to form an initial opinion: Overall - I think the FM changes are very good, excellent work from ED. BFM feels much closer to real life as far as I've heard/been told/researched. Nose low game plans finally work which is wonderful. It also seems to regain energy slower which is also more realistic as far as I've been told. Flying in DCS feels more like flying an actual jet and less like being on rails. It took a bit to get used to it, whether its BFM/CASE 1 or AAR, but after getting used to it, I'm quite happy with it.

DCS seems to base the capabilities of HPRF (and I would guess the entire radar implementation) on target aspect, not closure. To reproduce: Select HPRF, try to detect a contact that is flying away from you, it will be impossible (0% Pd) to detect at any range, any Vc, or any dragging heading. The direction an object is facing is irrelevant to radar, it doesn't care what side is the "front". HPRFAspect.trk

The overall functionality is realistic, but it is a little too accurate, how much is "too accurate" I don't know, this is just based off of asking a F-18 pilot about it, obviously not going to push for details. If I was ED I'd just add in some amount of random inaccuracy and call it a day.

In the second video, Wags received a CUT pass grade after landing, is this intended behaviour for ACLS or from the LSO?

Have you tested in multiplayer with multiple aircraft spaced 1 (or 2) minute(s) apart? Is this working now? Last time I checked (a long time ago since I gave up on DCS CASE 3) only the first aircraft to call in would be able to use ACLS, would love to get back into CASE 3 if its working for multiplayer!

The radar slew speed is "correct" -- albeit its of course not fun for anyone without simulation hardware, and still likely requires some curve tuning either way. The fact that the SA page slew speed is different than the radar slew speed, but still controlled by the same curves is hilarious to me, especially because tuning curves is basically necessary for the radar slew speed. ED really needs to separate these curves/speeds and let you choose your own (or make the SA page speed the same as the radar). I love that the radar is faster, but its obviously not fun for people with different kind of controls, and the SA page still moves at a snails pace.

Broke my mission tonight... sigh.

I'm sure you're already aware (i.e. just commenting on that people complained), so I'm just adding for the sake of the thread: One should not expect to be successful defeating an AMRAAM with a notch in almost any situation except the absolute most perfect situations (the real defense uses BVR timelines and kinetic defeats - this by the way is public release information). People who are complaining really need to be ignored by ED, this is meant to be (as far as I'm aware) a digital combat simulator not a "hardcore airquake" video game.

It is the best at quite a lot actually.

That's my point, its all one-in-the-same. Here's a question for you, where is there evidence that it will inhibit launch? If everything is a MSI Trackfile which clearly states it includes sources in addition to the radar (most notably, FLIR and datalink), where does it say that a MSI trackfile is actually radar only? It is of course important, the radar is your best data source! But where is evidence that it will inhibit your launch? Where does is evidence that only ownship radar source is used for support and not any of the clearly stated listed MSI sources as part of MSI trackfiles? I wasn't talking about terminal, yes we know the AMRAAM will stop accepting input from the ownship (at HPRF or MPRF active, depending on the aspect/closure of the target) because at this stage the likelihood you notch an active AMRAAM should be vanishingly rare (except for DCS) -- but prior to this point, notching is still possible, but if you had support from other your sources it becomes exceedingly unlikely to work. I'm not disagreeing with anything Hulkbust said. I did not say your radar needs to be actively transmitting, just that it needs to be in the azimuth like Hulkbust said. If you read the radar schematics you can learn how quick look works. Every time I even vaguely mention the name of a publicly available document my comments get removed and I get warned, so I won't even mention document names here, but they aren't hard to find by searching on Google.

Publicly available documentation will define MSI as combining trackfile information from multiple sources combining them all into one trackfile, e.g. radar, FLIR, data link, and HAS. That same document will then explicitly reference everything as a MSI trackfile. This to me strongly implies its all part of the same system (i.e. radar contribution isn't required to launch/support as that would be different type of trackfile than a MSI trackfile). The lack of radar contribution just means you will have a lower track quality as it is your best source. L16 update rate is not that slow, L16 examples show F/F would have ~112 timeslots, equally spaced that is about ~100ms per update between fighters. Relying on the AIC only though would be slow as it won't update for ~10 seconds. The F-18 being able to incorporate all sources into trackfiles is one of the defining features of the F-18, and inhibiting a launch because it doesn't have radar contribution would defeat a large part of MSI. Imagine for a moment how valuable MSI would be in the case of a notching aircraft (putting aside how easy it is to do in DCS to begin with) -- if you had a FLIR track, or a wingman abeam who isn't being notched, suddenly that contact can't just turn into the beam and become invisible. Preventing you from supporting (or launching) a missile in this situation seems very silly to me as we would simply be limiting available information to the missile. It is quite known that notching is no longer a reliable technique in more modern engagements, this is likely one significant part of that (in addition to radar & processing improvements) As Hulkbust said (and I concur as far as my understanding goes) you should be able to support a missile as long as it is roughly inside your radar azimuth (including side lobes) even without your ownship radar contribution. You could even in theory shoot outside of this as well, it would just be an unsupported missile off the rail (and burn a lot of energy turning that hard) flying to the only known active/intercept point.

The mission editor should just be able to add whatever callsign he wants, especially because there is a difference between ATC & Tac callsigns.

Locking an aircraft that you are RV'ing on, whether thats a tanker or a flight member is standard procedure in real life.

For AAR you don't really need tacan, not that you can't use it or anything, but is more of a backup. You should know roughly where the tanker track is prior to takeoff (as part of briefing), then use your SA page / datalink and radar (go STT once you find it) for navigation. For formation flying, set your tacan +63 above whatever the lead pilot has set and use A/A mode. For example 48X / 111X for a 2-ship, 48X / 111X / 111X for a 3-ship, or 48X / 111X / 111Y / 48Y for a 4-ship (this is so your -3 can easily get range to either the -1 or -4) but this isn't the only way you can set it up. There are some limitations to what channels you can use as well.