Default774

Everything seems correct here. Your steerpoint is directly in front of you at 16000ft. Try setting the steerpoint at ground level

Default Mirage f1ee

As a quick example, here is the briefing image for the hard landing mission compared to the actual visibility

Callsign: Default Aircraft: F-16 SEAD

Some more details on the hawk in its own dedicated post here. SM-2 is also affected as is shown in the patriot post you linked. I imagine this is mostly an issue with the legacy SAM scheme that will get fixed over time as the SAMs get redone.

If you have any specific examples of this happening I'll try to reproduce it and report it seperately

here is a short track showing the mortars missing with altitude differences mortar_alt.trk mortar_alt.acmi

CATM-120C in modelviewer null

As another funny sidenote, you should see what 120s do when they target an already destroyed target or miss. You could say there's some very slight oscillations. 120_twitch.acmi 120_twitch.trk

About mach1.3/820kts TS. This is generally how the 120 behaves when at speeds lower than about mach 2.

The AIM-120 has a chance of experiencing a tracking failure in the later stages of terminal guidance when fired at multiple radar detectable targets. In the case of the track, a pair of mi-24s being engaged by a NASAMS battery. 120_wh.acmi 120_wh.trk

Small excerpt from the manual

The JSOW(-A) has a chance of entering massive oscillations when fired. This seems to be completely random, and when it occurs it causes the weapon to miss. The attached track shows 2 out of 4 JSOWs entering extreme oscillations, causing them to fall short and miss the target area completely. JSOW_WIGGLE.acmi JSOW_WIGGLE.trk

Fixed in latest OB

As far as I could see this bug is vram related, It used to happen 100% of the time on my 8GB RTX 2080 if I opened F10 or F2, After upgrading to a 12GB 4070ti it hasnt happened even once. Youre not going to see this happen on a 2080ti with 11Gb of vram. Valve Index @ 100% SteamVR SS, 32Gb RAM, 5800x3d

Old track was done on an X56. Here is a new track using an Orion 2, exact same problem occurs. f16_gmt_ergo2.trk

"Each BLU-97/B CEB consists of a shaped charge, a scored steel casing, and a zirconium ring, for anti-armor and anti-personnel fragmentation and incendiary effects. Each CEB is designed to fragment into 300 fragments. Given the top attack angle of the weapon, the CEB can be effective against the generally light armor covering the top of an armored vehicle such as a tank." I wouldn't really class 10% damage on a direct hit to a tanks roof as effective, this is not correct as is.

I'm not really sure why this was moved to wish list, I don't see how making the GMT radar mode not borderline unusable would be a wish list item and not just a bug. Just as a hypothetical, lets apply the same logic to the the air-to-air radar. If the A-A radar also needed obtusely precise cursor placement and would drop lock if you weren't flying perfectly straight, would that also be a wish list item and not a bug? Does ED not consider this a bug? I'd love to have a bit more clarity on this.

The GMT radar mode requires the placement of the radar cursor to be absolutely pixel perfect to be able to get a GMTT Track on a moving vehicle. From my testing whether or not you can get a GMTT track on a vehicle seems to be solely determined by how perfectly you can align the cursor with the target. Here is a small image with examples from the track that show the difference between a cursor placement that is good, and one that is ever so slightly misaligned, causing you to enter a FTT instead of a GMTT on the moving target. Seeing as the GMT function of the radar is not covered in the manual, here is a small excerpt from the Wags video on GMT as a reference for what you would expect to happen. As you can see the cursor does not need to be anywhere near as precisely places in the original wags video, and snaps to target instead of entering an FTT somewhere near the moving target. Furthermore, anything other than perfectly straight and level autopilot flight causes the GMTT track to drop virtually instantly. In the track, the asymmetric drag from my loadout is enough to drop the GMTT track as soon as the autopilot is turned off. f16_gmt_ergo.trk

It is not entirely fixed. https://streamable.com/k7taqg f16acmsttlock.trk

The mirage 2000 jammer has the same forcefield effect. Removing blink from in game jammers is a bandaid fix, it is the wrong place to look. Removing blink jamming from mirage and F-14 will not stop my autohotkey script

Are you referring to the real missile or the in game one?

The amraam does not stop receiving datalink updates if the missiles radar turns on.

Something to note is that the PL-12 has a 30° radar beam width in lua which I don't think is quite right. For reference the aim-120 has a beam width of 15°. I'd like to know why this was done as it causes the seeker behaviour of the pl12 to differ slightly from the 120. Aside from slightly higher (imperceptible) CCMk on the pl12, 0.11 Vs 0.10 for the 120, and the aforementioned beam width the seekers are identical. Furthermore, isn't the pl12 supposed to have an R-77 based/derived seeker (ccmk 0.2)?

@Маэстро