Ballinger French

Okay, so it basically goes through the motion but there's no actual radar return enhancement? Aspect angle would then be irrelevant at launch then as long as the missile is within constraints?

Big thank you to everyone for replying and sharing your knowledge. I'm starting to align with the missile INS (no pun intended) being somehow skewed at launch and/or the missile radar not being able to distinguish non-moving targets from one another at certain ranges. I am mostly trying to reconcile how the RF missile on the rail can be actively tracking the target before launch then seemingly lose the target and switch to another before impact. Do any of you guys know if the DCS Apache RF missiles actually model Doppler beam sharpening? In theory, if a RF missile is launched with an aspect angle to the target (rather than a direct line of sight), the missile's radar can achieve higher target fidelity by factoring in radial velocity to the target. Firing a RF missile in the direct line of sight (relative to the helo's longitudinal axis) presents a difficult task to the missile's Doppler radar in regard to non-moving targets. A fixed wing fighter uses this Doppler radar weakness when 'notching' or maintaining a constant radius from the attacking aircraft's radar in order to defeat an incoming enemy missile. The DCS Apache manual does go in to detail about Doppler beam sharpening but I'm just not sure the principle is actually modeled with RF missiles in the sim.

I'm seeing some weird behavior firing the 114Ls at radar targets correctly handed off to the RF missiles by the FCR. Specifically, I see this when doing a scanburst of a group of stationary vehicles that include several BMPs, along with a couple of ZSU AAAs and a SA-6. The FCR in default profile mode will typically highlight and target one of the air defense vehicles in the group (solid diamond over air defense radar target), then properly handoff target data to a waiting RF Hellfire on one of the rails. The High Action display indicates the relevant 114L is tracking the target in LOBL mode, along with the missile page on the Weapons Display showing a 'T' for target tracking on the bugged missile ready to be fired. I fire the missile (in automatic LOBL launch mode), but it utlimately tracks to a nearby BMP instead of the targeted air defense vehicle. I'm seeing this behavior over and over, and I'm absolutely sure the FCR has bugged the correct target and has properly handed off targeting data to a RF missile which again, indicates it's tracking the target handed off to it before launch. I originally surmised the Hellfire missiles were simply impacting untargeted vehicles that were somehow in their line of sight to a targeted vehicle, but when switching to F6 missile view before target impact I can clearly see the Hellfires track directly at untargeted BMP vehicles instead of the targeted air defense vehicles they are supposed to be tracking. I'm launching attacks basically at treetop level at a target group roughly 2km away on a sloped terrain if this scenario might be contributing to the problem. I've not noticed this missile behavior previously though and 99 percent of the time my RF missiles have up to now been extremely accurate and reliable. Thanks for any insight anyone can provide.

Wow, the current flight model of the Apache feels like part of the tail rotor has been shot off in terms of yaw stability at slow airspeeds. Transitioning from forward flight to a hover, especially in a high threat tactical situation, is a nightmare. This is simply not right. The flight model is not a little bit off; rather, it's in the realm of science fiction. Has anyone else noticed this? How can a three year old module have fallen into this kind of neglect?

I haven't found anything that a CBU-laden JSOW will take out, at least when launched from the F-16. Lots of smoke and fireworks, but I not even certain that JSOWS don't end up repairing targeted vehicles, lol, because they sure do not damage them in the least. Why haven't these completely useless weapons been fixed yet?

Hmmm, I may have completely misunderstood this situation then. I seem to be getting the TGP to properly handoff to the Mavericks in a recent mission I created, but I have certainly encountered the situation where the Maverick fails to look at the same area as the TGP after handoff attempt (this is what I interpreted as being too close in range at time of handoff attempt). It does get close as you mention, but far enough off that an auto lock doesn't happen. I'll attach the track file from my mission in which everything works like it's supposed to, although I now have no idea why it's working. Maverick PRE mode testing.trk

Hi, This doesn't actually appear to be a bug with the F-16, but rather a purposefully designed realistic limitation when using Mavericks in PRE mode with automatic handoff enabled from the TGP. Specifically, there appears to be a minimum range to target that the Maverick missile seeker head can be correlated with the target locked on the TGP in automatic handoff mode. If one is beyond this minimum range but within the Maverick missile's normal weapons engagement envelope, the Maverick seeker head will properly lock on the target designated by the automatic TGP handoff. However, inside a 'close range' to target but still within the Maverick's normal engagement range, there appears to be a minimum distance to target in which a TGP handoff to the Maverick cannot be accomplished (parallax error coincident with close range to target). This limiting condition doesn't appear to be documented in the official DCS F-16 manual, so I though I would point it out to others on here. I read through the F-16 bug list section, and one of the DCS Moderators participating pointed out that boresighting Mavericks with the TGP whilst airborne cannot be properly accomplished with a target in close range (3 NM or less?) due to normal parallax error. I assume the limiting range I described above is an extension of the programmed (correctly) parallax condition. Cheers.

Hi, With the very latest Open Beta, I'm encountering a bug with the Maverick (AGM-65D) when launching more than one missile during an attack run on separate targets. Condition: Mavericks are set to VIS mode. HUD target designator box slewed over target area and ground stabilized. First Maverick locked on a target, range scale appears properly on both HUD and on Maverick video MFD. After first Maverick is fired, subsequent Mavericks are locked up on separate targets, however the range scales never appear on either HUD or Maverick video MFD. As a result, it's not possible to determine missile in-range parameter after first Maverick missile is shot. Track file attached. Thank you. AGM-65 Symbology Error.trk

Overhead approach to runway 3L at Nellis, left break over the approach end. For whatever reason, I decided to actually flare this time.

Pretty sure there's a bump on the approach end of the runway at Tonopah. It might've helped if I flared the correct way too, but I'm sticking with the bump theory for now.

Left Closed Traffic runway 32, Tonopah, Nevada.

Aha, the culprit is already being hunted, thank you. Doesn't appear to be too high on the fix list at this time, so I guess the only viable workaround would be to carry an extra AMRAAM on a pylon and use it as a captive hostage to force the correct HUD symbology for the other missile(s) when they are fired. I mean, the hostage missile could still always be used for attacking a bandit at some point, just with the caveat that telemetry isn't possible after it's fired. I guess you'd be firing in FC mode (fingers crossed) in this situation.

Hi, When firing AMRAAMs, after the last AIM-120 missile on the aircraft is fired, the HUD symbology reverts to either Sidewinder missiles (if loaded) or simply goes back to basic air to air mode with no inflight radar guided missile telemetry displayed. The problem here is that the AIM-120 is initially data-linked to the firing aircraft for guidance to target before the missile's own radar activates and the AMRAAM becomes autonomous. Without any indication of when the AIM-120's own radar activates and the missile goes 'Pitbull', the pilot in the DCS F-16 has no reference as to when to break off tracking the target and must simply guess when the missile has either gone active or splashed the target. Again, this condition only exists after the very last AIM-120 is fired. When there are additional AMRAAM stores available on the aircraft after a AIM-120 missile is fired, the HUD provides time to missile activation and estimated time to impact. This information will however disappear after the very last missile is fired, leaving the pilot in the dark as to missile status. Is this actual F-16 logic or is the DCS F-16 perhaps a little bugged here? Thanks!

Thought this was one of my cooler shots.