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.

A friend and I have been flying a Liberation 8.1 campaign in the P-47 Thunderbolt (Caen-to-Evereux campaign). Twice now in three missions, I've been hit by 88 fire (and killed) while attacking a flak site. This is surprising to me, since I would think that landing a shot against a fast-moving Thunderbolt would be challenging for the big '88s. My assumption was that the 88s are designed for barrage fire against slower targets moving in a linear path (A-20s, B-17s) or perhaps a squadron of smaller aircraft transiting the airspace. E.g. a squadron of P-47s flying overhead and putting a barrage of fire at a known speed and altitude. Yet the '88s in DCS seem very accurate in shooting me down even on a curving or direct attack path at close range against a flak site. I suppose this is possible (they could level the guns and fire direct-fire down the sight), but I would have thought that close defense of a heavy '88 AAA site would be up to the Flak 38 20mm guns. Does anyone here know how real Thunderbolt pilots felt about attacking AAA sites with 88 guns only? Was that as dangerous as it seems here in DCS?

Thanks for the response. Can you help me understand exactly what you're doing with "recenter"? I just tried firing up SteamVR, doing the "Standing Position Setup" (where you center the HMD, then set it on the floor and calibrate). Then I fired up XRNS. Then DCS MT. I still get exactly the same problem. Past 90 degrees rotation, the view is flipped vertically and bordered with black rectangles that make it unusable. Are you doing things in a different order?

Hoping to get some help with XRNeckSafer and the MT build. SETUP Running XRNeckSafer Beta 5a with a Varjo in MT, with DFR mod. Note: my XRNeckSafer works fine with running ST. PROBLEM No crashes, but everytime the Autorotation activates, the image is inverted and shifted. Makes it unusable. WHAT I'VE TRIED Reinstallation Firing up XRNeckSafer, then DCS. Firing up DCS, then XRNeckSafer. Selecting 'Deactivate XRNS OpenXR API Layer'. Checking 'Show Active OpenXR API Layers' - which only shows XR_APILAYER_MBUCCHIA_varjo_foveated and XR_APILAYER_NOVENDOR_XRNeckSafer. No duplicate entries. Is there anything else I can do to get it working? It's such a critical tool, particularly for warbirds. Alternately, is there any other tool folks have found for checking six easily wearing a VR headset?

Yes it's strange that compressibility isn't modeled. There seems no reason to use the dive flaps in the DCS Thunderbolt. As for a 109 being able to follow, I wonder if the reduced elevator authority is modeled at high speeds for AI. Flying the 109 K-4 as a human player, you have to be quite careful in a high speed dive, since the ability to pull out is limited. That's not compressibility per se, but a function of an airframe being powered to speeds well beyond what it was originally designed for. I wonder if AI 109s can be led into maneuver kills by trying to follow a fast P-47 dive to low altitudes?

So we figured out the problem. Since DCS MT is a different .EXE, Windows Defender was blocking it, even though all Port Forwarding was correct. Disabling Windows Defender allowed us to connect. We're good to go.

My friend and I are attempting to fly a Liberation 7.1 campaign together in the new Normandy 2.0 map. When I host the mission using DCS in ST mode, he can see it and connect to the mission (he's in MT). However, performance for me is pretty choppy. When I host the mission using DCS in MT mode, he can't see my server (says Offline). Is there something we're doing wrong? Or should I report this as a bug in MT? A few extra details: We've confirmed we're using the same version (lower right of HOME screen) I'm hosting Multiplayer from within my instance, not running a Dedicated Server. Thanks for any suggestions!

Interesting. Can you pull RPM back to 2500 with the Prop lever on the throttle quadrant, then flip to manual to keep it there? I'm trying to figure out what I can do quickly under pressure, as a tactical dive (to get away from a bogey on my six or where I'm losing a turn fight).

Thanks for the responses. I wonder how this was missed, given how critical the dive is to the Thunderbolt's historical reputation. The current time you can run to 3050 rpm is probably measured in seconds. I don't recall seeing any mention of P-47 changes in recent OB releases. So I'm assuming this module is currently on the "backburner" and won't see adjustments any time soon. How do you deal with the current modeling of the P-47 in DCS? Any tips or tricks on how to leverage the diving capability that exists? (Don't get me wrong, I really appreciate the DCS Thunderbolt. Beautiful modeling, detailed systems, feels "great" - distinct from the other warbirds. It's just this area of the flight/engine modeling which is taking away one of the P-47s greatest strengths)

I've been spending the last month learning the DCS P-47. In reading about the Thunderbolt, a common theme is the incredible diving capability, a capability that could be used to get away when in trouble. I've read how Hub Zemke trained the 56th Fighter Group to focus on boom-and-zoom, or do a diving attack through a Luftwaffe formation and using dive speed to get away safely. The challenge I'm having is that the DCS P-47D 30/40 doesn't seem to behave the way I've been reading about from historical accounts. Diving seems very challenging in this aircraft, more so than any other DCS warbird I've flown (P-51D, Bf 109 K-4, Fw 190 D-9, Spitfire Mk IX). I'm well aware of managing the MP so I don't overboost the engine while diving into thicker air. The problem seems to be the RPM. The Double Wasp consistently breaks if it exceeds 2800 RPM for any length of time. Yet I'm struggling with keeping RPM below 2800 in a tactical situation diving away. If I have lots of time, I can throttle back first to 30", drop RPM to 2300, then dive at a moderate angle and keep RPM under control. But in any tactical situation where I need to dive NOW (or in the next 5-10 seconds to get away), I can't seem to find a combination that will keep my engine alive. If I start the dive at max combat power (e.g. I'm in a turning fight with a 109 and I'm starting to lose so want to disengage), the RPM seems to stay high even if I try to decrease RPM or throttle moderately once the dive has begun. If I chop RPM dramatically, then the entire engine stutters and chugs, causing a loss of power just when I'm trying to get away. How do you all dive the Thunderbolt quickly in tactical situations? I'm just surprised at how hard it is in DCS to use what was supposed to be the "trump card" of the Thunderbolt design.

Agree! Love the new .50 cal sounds. It might be a little less realistic compared to pilot reports, but we forget that they were also feeling the guns through the seat. The vibration was a key part of the feedback we don't get easily as flight simmers. I'm fine with bumping up sounds to compensate and give the virtual pilot the kinds of feedback they need. It's the same with stall turbulence. A pilot would feel a lot through the stick and seat, we need a little more amplified sound feedback to have the same cues.