MARLAN_

I appreciate that! As far as I understand/have read, missions shouldn't be automatically changed during release requiring the user to correct it after every release (or setting it before). I'm particularly referencing PP Missions here, although TOO missions should work the same way and shouldn't be automatically changed without user consent... if you select TOO1 it should remain in TOO1 and only step between priority stations (8->2->7->3 as available/ready), not automatically change to a totally different mission, even more of an issue when using pre-planned missions. Edit: Looking into the workaround more, the current implementation seems very strange. It is essentially setting stations as the root, and not missions.

@BIGNEWYI checked schematics & other sources for all applicable systems and in no case does is it ever indicate that the STEP button, nor release should the MC switch PP missions on its own, it indicates many many times however, that STEP and RELEASE should only switch between stations. You can have multiple different missions with vastly different target areas, the DCS F18 is currently automatically switching between missions when using STEP, but even more critically, during release, especially when QTY is used, which will result in unintended side-effects. You're right, current DCS implementation is correct.

It's hard to read what you write in your replies, but to be clear, it should step to an entirely different mission during that release? What evidence do you have that entirely different missions should be automatically stepped into during a release? I understand it now, I was wrong, DCS is correct here.

Is it working differently internally than my provided track? JDAM should not step to a entirely different mission during release. Real World could have (potentially) all 6 PP missions filled out with targets for different target areas, mission factors, etc. Is it intended in DCS that when pickling the MC will step to an entirely different mission? Particularly strange when QTY is selected, it will release your first bomb on to PP1 STA 3's target Coordinate and then the second bomb can release on PP2 STA 7's target coordinate. This makes selecting QTY unusable when more than one PP mission is filled out (and when we eventually get the data cartridge, you could easily have multiple missions filled, but only one being used based on planning factors) as bombs will step to the incorrect mission during a release when selecting multiple stations in QTY. Hopefully the issue here is being described clearly. Nothing in the sources I have reviewed indicate the MC should step to a different mission during release, only that it will step STA 8 -> STA 2 -> STA 7 -> STA 3. I was wrong, current DCS implementation is correct.

How do you use QTY when the MC is selecting the wrong bomb to drop then? Have you watched the track?

When depressing STEP in the JDAM MSN sub-page when you have more than one Pre-Planned Mission with a coordinate (PP) it steps between the pre-planned missions. This causes major issues when during release it will cause your bombs to hit the same target more than once. For example: PP1 STA 3 -> Target Coordinate A PP1 STA 7 -> Target Coordinate B PP2 STA 3 -> Target Coordinate C PP2 STA 7 -> Target Coordinate D Set QTY -> STA 3 & STA 7 Select PP1 When IN ZONE -> Press & Hold Pickle Switch STA 3 released with PP1 (Target Coordinate A) STA 7 released with PP1 (Target Coordinate B) <- THIS IS OKAY SO FAR Select PP2 Press & Hold Pickle Switch STA 3 released with PP2 (Target Coordinate C) <- STILL OK STA 7 released with PP1 (Target Coordinate A) <- NOT OK - This makes it very easy to double up bombs, in the above example, Target D was not employed on, and Target A was employed on twice. This can be avoided of course by manually verifying every single release, but that invalidates the usage of QTY. In this particular bug report, I don't have evidence that I can share, but I think it's quite obvious that there is an issue when it mission computer is stepping between pre-planned missions, especially during release with QTY selected since the resulting effect is targets are missed/doubled up. JDAM-PP-STEP.trk

DLZ do not correctly indicate ranges which is extremely important for knowing whether a shot is valid or not. I would guess a calculation somewhere is incorrect, and may also be relevant to why the LOST cue is still indicating at the wrong time consistently. Tacview-20220826-180901-DCS-DLZInaccurate_40NM_35K_0ATA_AND_35NM_35K_45ATA_HOT.trk.zip.acmi Tacview-20220826-180751-DCS-DLZInaccurate_25nm_25K_45ATA_HOT.trk.zip.acmi Tacview-20220826-180700-DCS-DLZInaccurate_5NM_15K_0ATA_COLD.trk.zip.acmi DLZInaccurate_5NM_15K_0ATA_COLD.trk DLZInaccurate_25nm_25K_45ATA_HOT.trk DLZInaccurate_40NM_35K_0ATA_AND_35NM_35K_45ATA_HOT.trk

FYI Proxy fuze should be set on the Stores Page with the Size Selector (and RCS would control at what range the AMRAAM will go active) and wouldn't be a constant

Gameism Personally I'd love for the sake of realism if it was changed so it is set on the ground, same as how the F16 module does it.

Field Altitude (MSL) won't match when setting what DCS incorrectly indicates is QNH. e.g. at Nellis, you could have an altitude that is hundreds of feet inaccurate.

I'd love to see the AI incorporate timelines into their tactics so they aren't just always reacting and can literally just act on a defined timeline. Lower skill can "miss" their timeline when they shouldn't, and higher skill can sometimes elect to press the timeline when they are able to. e.g. Shoot at NLT SR, Skate at MOR, etc.

I love the enthusiasm! Sorry, I've been busy this week, and got an interview for a new job on the 16th, but I absolutely want to finish this project soon, I just have some more things to fix up.

Make sure your stick is centered. You may need to recalibrate your stick, or add some dead zones.

It's absolutely a bug. Also mentioned here https://forum.dcs.world/topic/305485-valid-trackfiles-cannot-be-designated-immediately

Who said the radar is "completely broken"?

I'm not aware of any way to set a DT2 while in STT. Undesignate in STT, STT RAID or Spotlight should return to search.

Undesignate in RWS, VS, or TWS (not spotlight) will invoke L&S stepping (create L&S if it doesn't exist, swap DT2 & L&S if DT2 exists). In STT, STT RAID, Spotlight, or ACM conditions (BST, AACQ, VACQ, or WACQ) undesignate will return to search or exit the ACM condition. As far as I'm aware, this is already correctly implemented in DCS, although I almost never use Spotlight or STT RAID (and we don't have VS) One tip: Instead of pressing RSET to drop a designation, select BST, GACQ, then AIM-120 (or AIM-7). This will not only drop all designations, but also reset your radar to your radar presets that are set to your weapon, while it does require a couple more actions, it ends up being a lot faster and reliable since it's HOTAS'able. It's practiced real world, especially after a skate and preparing to reattack.

We all are allowed to have our own interpretation/opinion of what is considered broken or not, to me it's very broken (I never said "completely broken" by the way) and to you it's mostly accurate, but what I said though is not a "false statement" that you have proof is incorrect, the proof of my claims is in the module, the many sources, the SMEs, the bug reports, the provided evidence, etc. There is a long list of bugs or incorrect implementations in the forum, many of which are supported with evidence and many are considered accepted/reported by ED, whether it's specifically F-18 radar, general radar, or otherwise, and the Google Doc you've seen that lists a lot of missing (and very important) features that are needed for proper F18 radar operation that all have sources. Making claims that it is "mostly accurate" is hurtful to the community because any informed members (and there are many, they are often just quiet observers in these public spaces) start to lose hope that the module will be fully (as far as usable evidence can support of course) completed one day. I've seen many diamonds of the community start to fade away because they've lost hope. My words are probably too harsh, but your words are too "fantastic". ED has created something absolutely wonderful in this sim and everyone in the community I'm sure are extremely happy that DCS exists and they (I assume, can't speak for everyone of course) just want to see it come full circle. The DCS: F-18 is so close, but needs that extra love to finish it off, but pushing it under the rug saying it's basically done isn't the right move, but I also shouldn't be so harsh, maybe I am just jaded for waiting so long and seeing so many steps forward combined with many steps backwards.

I think it's probably a fair bet to say most aren't using the radar correctly, but the radar is also definitely very broken, so it's both. Understandably though, it is hard for people to learn how to use it correctly when the way it works in DCS is pretty "strange" to put it nicely, in addition to some misconceptions in the community that also muddy learning (e.g. "soft" lock) that make it harder. It becomes a circular game of learning how to do it correctly, then learning what is bugged, or incorrectly implemented in DCS, then learning how to get around the bugs or wrong implementations, and then the people who teach others the above have to go through the whole cycle constantly. e.g. The LOST cue in DCS still indicates LOST incorrectly which makes people believe their missile should no longer be supported (this is the right idea for them to have!).

Set QNH when less than 18K (e.g. on deck) using something like MOOSE ATIS will give you QNH, the preset value from DCS is incorrect and is actually setting QFF, you can also just look up the field elevation and set your altimeter to match that when on deck, of course this only works when you're on deck. QNH will indicate field elevation on your altimeter when you're on deck, e.g. it will indicate ~1,870' when at Nellis AFB, then you could fly e.g. 3,500' for your overhead. Switch from QNH to QNE (29.92) passing transition altitude (18K in most places) QFE is rarely used in aviation as far as I'm aware, maybe in Europe or Russia it's used?

Glad it works for you! Honestly a bit surprised you figured it out, it's a bit of a mess right now. I'm working on cleaning things up right now to try to get a public release out.

@BIGNEWYAny update on this bug? Looks like it was reported almost 4 months ago and is a bug that causes aircraft to fall off of the deck edge (even with chocks on) when spawning in from parked and is quite literally sickening when in VR. I noticed it again today (haven't use turning carriers in awhile)

I'd love to see a much less accurate/reliable RWR, as far as I know our RWR is waaay too perfect in DCS but I don't know the exact specifics, just that it's too reliable. That said though, as far as I know we also shouldn't have top/bottom blind spots (except for a tiny cone directly in front and low) and we are missing INS stabilization.

You're right, I should have double checked first.