yumemi5k

@NineLineThanks for looking into this. However I'm still not convinced: 1. Why should there be "calculation differences" caused by different ground elevation beneath player aircraft? The jet has many other better ways for working out its navigation solution and SPI coordinates, radar altitude shouldn't even matter at all. 2. The maverick remains perfectly on target if not slewed, why should a tiny amount of offset suddenly send it quickly veering off target? 3. OK let's say that a tiny bit of offset is indeed, somehow, treated entirely differently in the jet's computer. Then still, the jet's MMC does an gargantuanly bad job at ground stabilizing the missile. Simply adding the player induced offset angle to where the jet thinks the SPI is would have produced a much better result than the current situation. I think this started after the "CCIP dropping short fix" patch for the F-16. Could you go to the guy that did the fix and ask if this rings a bell? I have no documents to support my points, I just find the current implementation extremely bizarre. If you still find no problems, I have nothing more to add.

I think at least it is quite likely that there is a bug, because: 1. Terrain elevation directly beneath player aircraft affects Mav stabilization behavior, which makes no sense. 2. The Mav seeker veers wildly away from SPI square in the 'bad' tracks, which again, makes no sense, as no sensible stabilization effort should produce such a movement. As for whether the Mav should ground stabilize in VIS mode, my speculation is yes. When you designate a SPI using HUD as SOI, the jet's computer calculates the offset angle from the jet's axis to the SPI, and tells the mav sensor to look at that offset. The mav is just being slaved to onboard MMC and is not performing any tracking at this point. This already is a form of ground stabilization. If you then slew the mav sensor, you merely add an further offset to the aforementioned offset. Whether this new pilot commanded offset equals zero or not shouldn't fundamentally change how mav ground stabilization behaves.

Thanks for the response. However, the unexpected behavior appears NOT when the mav seeker is slewed to look at a point higher than the SPI, but when the player aircraft is flying over ground higher than SPI. In other words, ground elevation directly beneath you affects mav ground stabilization behavior. I find this very bizarre - I understand mav simply looks at a point the jet tells it to, and the jet calculates the angle it needs to look at using its navigation solution and the 3-dimensional position of SPI. The jet might use radar alt as a last resort if the navigation solution is very bad, but that is not the case for a default mission air start. As you can see from my OP track and the 'bad' track in reply, the mav seeker circle starts drifting away significantly from SPI square once the seeker is slewed a tiny bit. I really can't think of a valid reason why the ground stabilization should behave like that. To top it off, once you are flying over terrain at the same elevation with SPI, ground stabilization starts working perfectly, which is my main conviction why this is probably a bug.

Thanks for the quick response. I've uploaded 2 more tracks with TGP point track showing the same behavior. Mav in the 'good' track taken on flat ground stays ground stabilized after you slew the WPN SOI, and the mav sensor picture doesn't drift. In the 'bad' track where I come from the mountains, the mav picture starts drifting the moment I slew the mav sensor a little bit. What is even more bizarre is that in the 'bad' track, when I later swing back from the sea, the mav sensor stabilizes just fine like in the 'good' track, probably because terrain beneath me is on the same elevation as the point track. F-16 bad mav ground stab with large elevation diff.trk F-16 good mav ground stab on level ground.trk

Problem: In VIS or PRE mode, mav sensor circle starts gradually drifting away from SPI (TGP square) once you slew the mav sensor even only very slightly. Reproduction: Vanilla DCS at newest version, F-16 in Syria or Caucasus, new mission with default weather, pressure, etc, air start at 12k feet, 2x AIM9M, 2X A120B, 2x500lb GPU, 2x AGM-65H (The CCD variant), 2 wing tanks, TGP, HTS, Long ECM pod. (See track) Air start over high ground, HUD as SOI, move SPI to somewhere where the ground is much lower than the ground directly beneath you. Do not fly directly at SPI but at an slight offset. Maverick WPN as SOI, slew the sensor slightly, notice the mav circle drifts away from TGP square. TMS down on WPN, sensor snaps back to SPI and stays there perfectly, but once you touch the RDR CURSUR joystick it starts drifting again. Note: If ground beneath you and SPI are on the same elevation, this bug does not seem to manifest. I believe this started since the patch that fixed F-16 CCIP falling short problem. To be honest I agree that this bug sounds crazy so I'm not sure if it's error on my part. Apologies if it is. F-16 mav ground stab bug.trk

Not sure if intentionally designed this way, but I think there are red herrings in the way the mission is presented:

Mostly identifying which is which. At long range everything is just a faint dot and I often get the wrong one like a TEL or even a truck. By the time I can see a distinctive silhouette I'm usually already at 3~4 nm.

Sorry for sidetracking, but how do you engage SA-6s with TV Mavs effectively? Max range is like 8 nm and I usually only manage to reliably target the radar within 3~4 nm, which always felt like bringing a knife to a gunfight. I could cover my approach with a HARM so the SA-6 eats either a HARM or a Mav, but that's undesirable if there aren't enough shots to go around.

That could be the case, Rotor called missile in the air out of the blue before heading back to WP9 in my case.

I got the same bug in the patched version. I did the recent update, and missions 1, 10 and 13 .miz files show a more recent modified time in windows than the rest, so I believe I do have the updated version correctly. The behavior was just like @Gilligan described in his original post.