Маэстро

Changes already committed, so it's up to Polychop now. They should change Gazelle's payload script.

Yes, it's the same behaviour as in last Rhayvn track. Will be readjusted. Missile definitely should be more agile in such cases. Thanks, but I do not see there initial issue you have described. All missiles except first one miss due to target jamming. First missile miss due to lack of energy. All your previous tracks demonstarte long range shoots against maneuvering targets which do not use ECM. In these tracks misilies approch target with low speed. Unfortunately, I can not say that exactly happens because tracks plays different on my end, but it seems to me at the moment that there is rather difference in AI behaviour(as was already supposed above) than missile issue. If you again will see the same behaviour with long range shots please attach new tracks here.

Thank you for your research, it's much appreciated! I agrred with all changes you propose, except FOV and burning time. It seems like there is a kind of mistake, because FOV is 4 degrees by default(just checked both user and dev DCS versions). With probability of 90% FOV of real missile is between 2 and 4 degrees. More narrow FOV is not quite practical. Regarding burning time it is 2.2 seconds at the moment in both DCS versions, that seems to be correct according your videos.

Yes, but problems with hitting high-g jaming tagets is intdened and caused by simple fact that missile can not measure closing velocity and range. The only thing to discuss is the level of this "issue". In falklands tracks targets do not use ECM, so that's not the reason.

BTW, just watched all 4 tracks on colleague's computer and it looks like they do not play correct. I see miss only in one track, but it happened due to low terminal speed.

There is one problem - tracks you have attached made on Falklands. Unfortunately, I have no enough disk space to download this terrain. Could you make a couple of tracks using caucasus terrain? Sorry, but I will claim this. Because there is no any raltion between guidance accuracy in very specific conditions(which was improved a bit) and poor tracking issue you've reported. The only thing which theoretically may cause some tracking issue is "HOJ mode twitching" fix, but it's may appear only if target jamming. Anyway guessing is that aim-120 issue or not is pointless without usable tracks I'll be able to run under debugger.

If your goal is to have bugs fixed it would be better to add several tracks instead of quips. (Yes, we need exactly your tracks(not acmi) to run them under debugger and see that happens in every single case)

1. This was reported eralier 2. That's not the simple aileron roll - I see g-load between 10-11g in every track, so it's the high-speed high-g barrel rolling and that's the worstest type of maneuver for missile in fact. Missile flies to the PIP(predicted intercept point) and this PIP moves with very high speed in such type of maneuver. The level of target's g-load defines how far the PIP should shift from its current position. If target performs rolling PIP moves in circle around target direction of flight. The higher g-load is the bigger radius of that circle. The higher roll rate is the faster PIP moves along the circle. The linear velocity of PIP on circle is proportional to the product of radius by roll rate(for ex. 100m radius and 5 radinas per second roll rate (~3/4 of revolution per sec) produces 500m/s linear velocity). That forces missile to perform very tight spiral with g-load at the edge of missile capabilities(at close range g-load required to intercept may be out of missile capabilities). 3. We already made several changes in our internal version and missile will behave better in such conditions, but there will be no 100% hit rate of course. In attached tracks missile hits 2 of 3 times now. One miss happens in "halfrange" track because missile has no enough velocity to reach PIP in time. These changes will be avaiable in the next update.

That's not correct to compare TAS. You need to know radial velocity (projection of closing velocity on line of sight) by which Doppler frequency shift is caused. First of all missile has relatively narrow FOV, so it's quite easy to go out of FOV at close range(when missile does not track target). Second, there is no point to track target that missile cannot catch up. There is no any difference between water and ground in fact.

Sorry, can't do a thing with current chaff mechanics. It's requires complete reworking to become more realistic. So that's not a bug, but a task for the future.

There is no any issue with missile. Bot drops lock for some reason before missiles goes active, so missile flies to the last predicted intercept point which is obsolete.

In your track target noticabley change its velocity - that's the reason of tracking fail. See discussion here for example Maybe we change speed of seeker gates opening later for unsupprted shots. Also note that AMRAAM model uses completely different technology and it's not correct to put all these missiles in one basket.

Hm, perhaps there is some difference between public and internal DCS version. In attached tracks I see player press the launch button and immediately begins rolling, so missile moves along the rail of already rolling aircarft.

In this particular case the problem is aircraft rolling at lauch. High roll rate causes intertial acceleration(see Coriolis theorem) which affects INS alingment. Noticable errors in INS data prevent target lock, because targeting data and real target data does not mutch.

This issue already fixed internally

In all tracks you have attached I see missile losing track due to almost equal velocities of missile and target. There is no any issue.

Seems like something had broken, will investigate. Thanks.

Known issue. Already reported

Known issue.

I will investigate this, but shots #4 and #5 definitely beyond missile abilities.. what behaviour would you expect?

This one caused by missing revision in 2.8. Will be fixed

And DCS missile do this expand because this is very possible when datalink is lost. But if datalink is present it looks like missile does not do such expansion. From document: The AMRAAM searches a volume, known as the uncertainty volume, around the data link provided point. If the targeting data is bad enough the target will never be seen by the missile, even if it's own robust Electronic Protection capabilities would allow it to track and guide on the jamming target. This means what if target inside of missile FOV but outside of uncertainty region it will be ignored. Good to know.

You are welcome. You may find some info in ADA355385 p.4-5. I do not see any big contradiction with reality. Cheapshot tactics in DCS works too. If target does not maneuver such tactics works well but quite not well if target does maneuver.

Hi GGTharos, First of all our model does "open" velocity gates if it can not find target near INS cue. But this opening is gradual and based on remaining TOF(to INS cue). So target acquisition is not guaranteed in case of cheap shot and depends on target motion params and interception geometry. Target may simply come out of missile FOV before velocity search range became wide enough to find it. There is also similar restriction on range search. Second thing is real AMRAAM does not do any gate opening. I have a research paper which claims that. We implemented gradual gates opening just for game pourposes. AIM-7 indeed have velocity search pattern that initially performs narrow and then wide sweeps, but that's a bit different weapon concept.

Sorry, but now is not the best time for such kind of discussion.