Muchocracker

Observed in your track and reproduced in my own. Internal reports made. FACQ seems to work okay and will command STT on TUC's so i would reccomend using that for now or TWS until fixed. For future reference please make tracks in caucasus. That is the preferred map for the devs to use for debugging.

Its's known issue that currenthill has confirmed elsewhere.

There is a known bug with the undesignate logic in MP. It effects RSET as well effectively paralyizing you from switching targets

been using TDC depress today with no issues. What map is this the trk doesnt appear for me in the replay list.

i am well aware of TWS centroiding. His question was specifically in the context of the SURV tracks which you can only have 2 at maximum designated at this time.

AUTO should be centering the volume on the L&S At all times, no matter if the trackfile has radar contribution or not. As long as the radar is on and transmitting (not in SILENT) it should still provide command link's to the amraam. If it's not it needs to be reported what conditions is causing it not to.

find a SURV track on the RDR ATTK page, and TDC depress to designate as Launch and Steering

It was added a long time ago i dont even remember when.

I dont really understand what the issue is here. What are you meaning when the missile does reach its target?

FLIR trackfiles are pretty explicity not MSI trackfiles if you read the sources. You can desigate them to slave other sources to them to create MSI trackfiles. They are not MSI trackfiles onto themselves. It applies just the same to AOT's.

This is by design and is how the TA mode works, it's not meant to be a terrain following system stabilized to the horizon like LANTIRN or other TFR systems. The antenna is roll stabilized to the horizon but is aircraft stabilized in pitch and will depress with the velocity vector during dives. This is so the antenna has visibility of terrain protrusions when diving down.

HARM only produces AOT's, so you can't. FLIR is also in a similar boat, but it does hve its own separate FLIR trackfiles that it can produce (up to 8). They don't contribute to MSI so you can't L&S those either but they can be correlated to MSI trackfiles.

Forward complaints to mcdonnel douglas on that one.

The amraam command links wont be transmitted by off-board source. The only US interceptors capable of this even today to my knowledge would be the NIFC-CA enabled Standard ERAM and IBCS enabled patriot missiles. For our hornet it's going to be your own radar sending the links no matter what. The only difference is just where the track data comes from, and MSI is built to be agnostic in that respect. The offboard trackfile gets passed to the shooter, who then fires his amraam. Shooter receives new SURV data over link, and re-transmits it over the missile link to the amraam. And theoretically (as wags has alluded to in the TA video) the radar itself can be in silent mode during all of this. With it periodically breaking that silence to transmit the command links. And yes the quality of that data would vary depending on the source observing that target. Another hornet and its X band radar will provide a higher accuracy track than the UHF radar from a hawkeye. Not to mention slower update rates that happen over link-16 (inherent to its TDMA protocol)

i always just used helmet designate over snowplow. Then scanned the horizon as i needed

Changes get missed all the time (case in point the mk-80 series warheads change) I honestly never used snowplow when it did exist. Who knows when it got removed. Could have been years.

It may have been removed as an inaccuracy at some point. Documents on the ATFLIR do not mention any snowplow function, only VVSL. At least the one that i have.

There was a known issue with some other SAM systems that would get paralyzed when there were an amount of targets over some threshold. Could be a similar case here.

The GPS and INS are 2 disconnected systems operating concurrently. The Mission Computer will initially just output a position estimate based on the INS alone, but it is observing the position errors between it and the GPS. When it recognizes that the INS exceeds 300 feet of error it will then introduce the GPS data into the kalman filter and correct the blended positiong estimate in the MMC. There is no actual automatic fixing going on in the INS like you would see with EGI. For the kalman filter, the GPS is just there to be a reference (a noisy one) that it uses to corral the blended position estimate to under 300 feet. When running a FIX it should then correct the INS back to an accurate error state. The kalman filter will at that point stop blending the position estimates and go back to trusting the INS alone again, until the error accumulates back up to above 300 feet and the cycle repeats. I have not flown the F-16 in quite a long time, but that is my recollection of how the FIX function should operate.

important clarification to make here is the numbers for the 18 and 16 are its 1% single dwell time probability of detection range (the 18's range was definitely not 95 before the phase 2 overhaul btw, more like 55). All of the others you listed except maybe the 14, and m2000 do not model probabilities of detection and presumably have guaranteed detection distances corresponding to their real 50% criteria. This skews the data a lot. It's pretty much guaranteed that the modelling work done by ED will carry over to the 29A. It will thus get a significant "Effective" detection range increase from that Pd spread.

Do i have to be a broken record? This thread is not about the warhead's kill radius. Make another thread and make arguments for it there. If you have some new evidence that missiles can perfectly compensate for target glint and live adjust their tracking filter weighting for maximum reaction time then by all means. Post it.

Again. It's an entirely irrelevant debate to this thread. The proximity radius was increased to be more accurate and to secondarily fix the over-effectiveness of the HGB. Debate the kill radius elsewhere.

What? The "fix" was making the proximity fuse radius more accurate (it was the same distance the aim-9 mind you. A warhead half the weight) and make the HGB not a 100% defeat chance exploit. It was not to make the maneuver useless. The damage performance and the damage models of the aircraft had nothing to do with that. The proximity radius /= 100% kill radius. ...He didnt say that? Hobel is bringing up a point (which was emphasis of the original debate) that the energy state matters. What solution? There is no solution where there is no unrealistic problem. Both of us have already been over this. The HGB in of itself is not an unrealistic tactic.

Is this not you disputing the desync issue as just players cheating? The debate on the maneuvers realism had already long ended brother. That's why the thread shifted focus to the proximity fuse. You can check my other replies in the thread i backed the opinion that it was and reinforced maestro's reasons for why it is. Lol, the current state of amraam notch width is also completely realistic but nobody wants to hear the hot take. I dont think you quite read the whole history of this thread, might wanna do that and get up to date.

The desync in MP caused by the loaded barrel rolling is well known and has been repeatedly domenstrated, i don't know why you're trying to dispute that it doesn't exist. The main issue was the proximity fusing being too short (also inaccurate) and it made the HGB too effective to the point that it was an i-win card. That got fixed with the PF increase to 15m. Now it's risky, as it should be. The one that has not been remedied is the desync in MP. That is why people are distinguishing the MP rolling and SP rolling.