Default774

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)?

@Маэстро

Also having this problem, dcs startup times have roughly tripled for me, dropping in my dcs.log. dcs.log

The AIM-120 exhibits very erratic control response when guiding onto targets that make sudden maneuvers. This behavior can be shown best by using a NASAMS site and firing JSOWs at it. The JSOWs make a small maneuver a few miles from the target provided they have enough energy. In response to this maneuver, the missiles proceed to massively overcorrect and oscillate, sometimes causing the missile to miss. 120_err.trk 120_err.acmi

Unfortunately unless you manage to find a document that explicitly states the 120 will not in fact fly itself to intercept a predicted impact point that's 5000ft underground this is all a bit pointless sadly. I would love to see Maestros thoughts on this (I cant figure out a way to tag his username, dont have a cyrillic keyboard)

Keep in mind this is a sample size of one, I'd like to see if any others that have been suffering from this are also able to solve it this way before drawing any conclusions.

For anyone still having this issue, I was able to help someone else fix this by clearing shaders, then launching the game in singlethreaded and compiling shaders in ST. After doing this your MFDs should no longer be blurry in MT.

Just to be clear, you dont need a script to do this, but it will make it easier to do. The following track has me manually toggling the jammer. 120_manual.trk

I know you've probably heard this a million times before but do you have any tracks/tacviews/videos? If you have tacviews/videos I will try to reproduce it myself.

All AIM-120 related reports have been getting effectively ignored for the past few months, not sure why, probably something internal. I think there's already plenty of tracks for this issue. If I find any more interesting behaviour I'll be sure to add it here later.