Istari6

All - bumping back up for visibility in the Bug queue. I've attached a Track file (as requested) on Friday. Hope this demonstrates the problem sufficiently to help investigate (or let me know what we're doing wrong in setting up the F-16). Thanks!

OK thanks Moonshine. I've seen that with higher level CCIP bombing in the past, but that also clarifies it shouldn't be wind causing these significant "overshoots" when I pickle. All the more puzzling.

Thanks to you both for trying to duplicate on your side. I didn't realize that you needed the Track Replay in DCS instead of TrackView. Moonshine - I've reflown and confirmed that fins are opening, and I'm dropping in the high 300s for speed, my understanding is the Snakeye is good to 450 KIAS in real life. Lord Vader - here's a Track I just created, reflying the start of the mission to show the problem. I'm pickling in CCIP when the "death dot" is on the runway from about 250 AGL, every time the Snakeye sails long and hits well beyond the runway. This is true approaching from both directions, so I don't think it's the wind, and doesn't the computer on the F-16 compensate for wind at this low an altitude? F16SnakeyeLongDropsCCIP102023.trk One additional note that might help. We're flying a "Final Countdown" campaign in Liberation to learn the F-16 in a 1944 WWII environment first, before tackling modern settings. It's been fun to use Normandy to really learn the F-16 from the ground up, and we're trying to simulate mid-1980s F-16Cs in this campaign. Since we're in 1944 and we only have mid-1980s Vipers, we turn off GPS, DL, MIDS and rely upon INS Fix updates for accuracy. Don't know if that could be contributing to the Snakeye performance here?

BTW - I've retested this under 2.9, and the issue is still present. Also reconfirmed that the M82S are set to NSTL, so it's not an issue of accidentally setting to NOSE only, which would fail to retard the bombs.

Several friends and I ran a DCS Liberation mission tonight in our F-16s. We're still learning the Viper, but we have moderate experience using Mk 82 Snakeyes in the AV-8B and F-14A. To our surprise, all of our Snakeyes were dropping long in this mission. It really messed up our attacks, and I promised to look into it. I reflew a test mission I have and CCIP Snakeyes seemed to work fine in low-level level deliveries. Then I refired up our Liberation mission and just ran passes at Carpiquet airfield to show the problem. Please see the attached TacView track. I'm crossing the runway from alternating directions and hitting pickle with the "death dot" on the runway. Every time (5 in this track) the Snakeye falls long and impacts well beyond the target. This is exactly the behavior we were seeing in the mission as well. Is this a bug? Is there something else happening with wind, FCR, etc that can be addressed by pilots to restore accuracy? Thanks for any guidance. Tacview-20231018-213456_BuggedSnakeyes.zip.acmi

Previous to 1994 I believe is the cutoff for GPS.

Resurrecting this thread for the following question Twistking asks. I have the same question here in 2023 as I'm trying to learn the Viper: "With the video about A-Cal now being up, i wonder what purpose Fix has anyhow. A-Cal seems to be able to do position fixes AND altitude fixes seperately or at the same time. Why is FIX needed in the first place when you have A-Cal. What am i missing?" I've learned INS Fixes and have that working well. Then I moved onto A-CAL and find that you can set it to BOTH (Altitude and Position). Given this, why isn't the default for the Viper to just do an A-CAL/Both and be done with it?

Thanks all. I'm definitely not changing any loadouts once I start the INS NORM align process. Good to know that we can use STORED on a typical Cold Start. I'm coming from the F-14, where that option had to be set in the Mission Editor. Sounds like it defaults for the F-16 to have STORED data ready to go. Also helpful to know the -1 has the altimeter check and calibration done before INS knob is set to NAV. I was wondering if there was some reason why it had to wait for the end after INS calibration, but it sounds like it can be done during the general cockpit setup while waiting for INS alignment.

In learning the F-16's Cold Start, I'm confused on the following two questions. Hoping someone else here understands what's happening: 1. INS NORM Alignment - I see in Chuck's Guide and Wags' video that we're supposed to "confirm" the Lat and Long by pressing ENTR on each field within the first two minutes. I have not been doing that and the INS still proceeds to 10 and flashes RDY. So I've assumed that this confirmation step isn't important or was changed during Early Access. Bullseye seems to work fine, yet OFLY for Markpoints is screwed up. HUD does not show Nav STPT info (distance), but other functions work. So is it normal that the INS system counts down to 10 and suggests that it's fully aligned even without confirming the Lat/Long fields? I would have thought that if it's needed, it would stop at 70 (degraded) or otherwise indicate it's not 100%. 2. PNEU/ELECT Altitude - In one of the Cold Start guides (Wags video I think), he calibrates the altitude (to QNH) and does a test of PNEU vs ELECT to check difference before setting to ELEC for flight. But he does this right before taxiing, after all other tests are done and INS is calibrated. It seems strangely out of place doing this at the end, rather than as part of the standard cockpit setup while INS is aligning. Is there a particular reason in the F-16 why altimeter is done after INS alignment, or can it be done anytime as part of the normal cockpit flow?

OK thanks. When I was first starting out, I was finding that D models' thermal seeker head was sometimes quite a bit off from the HUD SPI, and was having a hard time finding the target when I looked down to WPN view. That has been less of a problem in my last few training flights. So I'll go ahead without trying to Boresight the D against the HUD SPI. Good tip on the 5-7nm distance for getting the TGP and Mav aligned, looking forward to doing that next.

(Apologies if this has been answered, I missed it in looking back through all forum posts to April 2021. Haven't looked further since I know much has changed with the F-16 over time, not sure much older is helpful) My group is trying to learn the F-16 in stages, by starting with a 1986 scenario in Liberation. We're learning all F-16 weapons and sensors to that time (AIM-9L/M, CBU-87, etc), but we'll save the more advanced features like AIM-9X, JHMCS and Link-16 for the future. Question about using the AGM-65D in an era before the LITENING targeting pod became available: 1. If we load AGM-65D to our aircraft after mission start (swapping out another ordnance load), do we need to boresight the AGM-65D to have accurate correlation between the HUD SPI (VIS mode) and the actual AGM-65D crosshair? 2. If so, how do we do boresighting of AGM-65D when we can't start the IR cooling on the ground (due to Weight on Wheels cutout)? Are we supposed to do the boresighting of AGM-65D to HUD SPI once we're in the air?

Sorry - I misspoke. I meant manual fuses couldn't be set properly for such a small moving target closing rapidly. I know that the first proximity fuse was from the Americans in 1944, used out in the Pacific. So an 88 could pull off the kind of accurate shellbursts we see now for a rapidly closing target.

I understand how flying straight at an 88 gun, within maybe 500-1000m (boresight range where shell drop isn't really happening yet), with a gun crew that's ready and has the barrel aligned with an attacking aircraft, could get a direct hit. The biggest factor here seems to be getting a big 88 cannon to lay properly and accurately in the time that a P-47 is leveling out and attacking (usually within say 1 -2nm). So it's not saying it's impossible for an 88 to hit an attacking Thunderbolt at 300mph, just that in real life it would have to be a direct hit since there's no way proximity fuses could be manually set properly for such a dynamic target. Does anyone here know how the real USAAF and RAF dealt with 88 batteries in WWII? Were they ever attacked directly?

All - as a follow-up, I was able to get XRNeckSafer working! The problem was the Varjo Foveated Rendering API layer. Once I uninstalled that, and had only XRNeckSafer running (confirmed by clicking on Show Active API Layers in XRNeckSafer), it's working properly. Thanks to all who replied on this thread trying to find a solution. Hope this helps others.

Thanks for the replies. Great point about the 10 person crew for a Flak 88 and the difficulties with quickly laying on a small fighter bomber, even one boring straight in. Also agree about the aimbot being common across all kinds of ground fire. I've been holding off on getting into DCS helicopters until the aimbot is reduced somewhat. Just heard horror stories from the Apache and Hind pilots about getting cranial sniped at 1500m by a BMP-2. Good to know I'm not crazy for thinking my death rate is unrealistic.