Nealius

Outside the scope of this thread, but (contact-BRA-long pause with mumbling-friendly/hostile/unknown) clogs the comms. I don't know what "proper brevity" would be but a more effective and common-sense communication would be (friendly/hostile/unknown-BRA).

I recall in the Fighter Pilot Podcast episode on carrier recoveries, interviewing the CATCC that voiced our supercarrier, it was also mentioned that CASE III night was 30 minutes prior to sunset, though I'll need to find a timestamp for that. Thinking critically, 30 minutes after sunset does not give enough illumination for a safe CASE I recovery in DCS, though that could be the lack of dynamic range we get in a video game versus what the human eye is capable of in real life.

Another short track, GPS-era, GPS on, hitting ships spaced 5nm apart. Starting aircraft has waypoints shifted about 10nm away from where they should be. As can be observed, each fix gradually moves the STPT closer to where it should be (note delta ranges getting smaller, but still miles off), but it is not where it should be until I've taken six fixes. It isn't even shifted far enough to be visible in the HUD until the 3rd or 4th fix. After conducting six fixes, STPT 7 is finally on target, however STPT 8 and 9 are for some reason still drifted a few hundred feet. Why is the same delta not being applied to all steerpoints on the first fix? And here's an example where it works as I would expect it to (INS era, "drift" of about 250ft as I frequently get in my missions). This is exactly how I expect it to work, but in my ramp-start Kola missions it does not; per this track. I assume that if there were an issue with my alignment during startup someone would have pointed that out by now. Though it seems I'm supplying tracks that no one bothers to check.

The absolute irony of this statement. "Works for me then it must be a you problem." Knock yourself out with this track. Or any of the other multiple tracks I've supplied in the thread.

Continuing my test from this post, same mission, date 1994, unrestricted SATNAV off, GPS switch off, stored heading align for the sake of test consistency (5.2/10 when NAV selected). Takeoff and STPT timing +/- 3 minutes of original test. FIX still does not update the entire flightplan. It will update the selected STPT, but it will not update the position of subsequent STPTs. E.g. making a FIX with a delta of 0.08nm on STPT 1 requires the same 0.08nm FIX to STPT 2~6. STPT 2~6 should have been adjusted by the same 0.08nm delta, however they are not. Despite taking two fixes before my attack run, VRPCCRP symbology, TD box, and aim-off-point were still hundreds of feet off target, and not within tolerances to be used for their intended purpose.

For the most part it only affects the F-14 and multiplayer. Two things ED cares the least about, on top of the SC being more or less abandoned except for the recent PRIFLY station.

1000% this. Most of my issues with Jester are his horribly inefficient communication style. This isn't a matter of brevity but of common sense communication that any individual should pick up on and tweak on their own initiative regardless of existence or absence of prescribed brevity. Even today, brevity doesn't account for all radio/crew communication.

Per -34 documenation, the Kalman filter only adjusts deltas that exceed 300ft. Doing a FIX only sends delta data to the Kalman filter, without actually fixing anything unless that delta exceeds 300ft. And since the currently modeled system doesn't ever seem to exceed 300ft, but regularly exceeds 200ft, FIX is effectively INOP when GPS in on even though it is technically functioning.

And CNATRA T-45 training materials state what I did. Which of them is correct? P-816, p2-4:

IIRC JDAM "drift" is a separate issue where JDAM takes into account the jet's INS drift instead of using guidance from the GPS satellites once released. This thread is about INS accuracy itself and if the fixes work for old-school weapons delivery. "Fixing" the JDAM accuracy could be a byproduct of this but I'm not sure that it's the cause.

Interesting that it's set 12 minutes prior to sunset when CNATRA states:

Re: doubting the amount of INS drift (200+ ft) Testing with a standard GPS-on flight, no fixes done. STPT 1 was about where it should be at 13 minutes after takeoff. STPT 2 had already shifted at 15 minutes after takeoff; purple circle indicates where it should be. Unable to measure as I can't see the support columns in the map/editor. STPT 3 and OAP also shifted; purple circle indicates where they should be. Note: attack heading was calculated as 250. Approximate distance measured from programmed STPT 3 and actual STPT 3. STPT 4 has been shifted all the way to the bridge ramp. Approximate distance measured rom programmed STPT 4 and actual STPT 4. As you can see they are deltas of approximately 200ft, possibly a smidge more, and the drift appears to happen at a hardcoded time. Mission start was 0600, wheels up 0611. Drift occured somewhere between 0624 and 0626. Next flight will be no GPS to see if I can get fixes to work.

That's definitely an interesting observation. I always exit normally and noticed that the "lastmission" track that automatically saves is also corrupt if the manually saved (SP) or auto-saved (MP) track is also corrupt. I will test out the brute force method on SP and see how it works.

In LAlt+F1 HUD only view, the Viper's MFD display size changes with resolution. Other modules do not. Viper in 1080p, the MFD displays take up roughly 43% of the vertical screen space: In 4k, the MFD displays are shrunkedn to take up roughly 22% of the vertical screen space: Compare to the Hornet, which is representative of all other modules, the DDI displays remain the same relative size regardless of resolution. 1080p: 4k:

This is where I'm having the disconnect, as the fix is not being taken when the GPS switch is off and the nav priority given to INS in the DED. I have a gut feeling it's because I did a stored heading alignment with GPS on, then turned GPS off. Will be some time before I can test again. Fly the mission from the track linked in this post; take control and fly the waypoints with GPS on, STPT diamonds should be on centerpoint of bridges, and right on an SA-3 Low Blow. Instead they are always shifted. When taking a fix to move them back to bridge centerpoint, DED shows a delta of 0.04nm, which converts to 243ft. Will be a few days before I can fly it again, and hope the replay doesn't get corrupted with the "missing data" bug that's going around so I can get screenshots.

And fly the route on the copied group? I'm guessing that purposely placing the steerpoints in the wrong location and then adjusting to the right location wouldn't be a valid test?

They're not; I have better understanding of what's going on but the problem itself is not fixed (and whoever assigned the "solution" post wasn't me). FIX doesn't update the STPTs in the flight plan, meaning the CCRPVRP/CCRPVIP+OA1/OA2 symbology is not accurate enough for the pre-planned POP and HADB iron bomb delivery profiles for which that system was designed. With GPS on we get a fairly high drift error which doesn't get updated by FIX because it's within the Kalman filter's threshold (correct). With GPS off and using INS, we get higher drift error (correct) but the FIX does not fix that error. Underlined point is still waiting on a verdict on whether FIX not functioning is a switchology error on my part, or a bug. I doubt many of the closed beta testers test a full ramp-to-ramp 1990's style pre-planned pop that requires all the calculations for the DED data input and INS fixes, so it could go either way. Hell, it could even be something funky with the Kola map considering how far north it is. I haven't tested on other maps yet. I would like to demonstrate it with a short track that doesn't require all the ramp start and 10 minute flights to the first fix point, but I don't know if there's a way to induce INS drift via the mission editor to adequately demonstrate what's going on.

To which one should reply: "So can you if I pull this yellow handle."

Yes, firing the laser prior to commanding point track. Regarding scripts, they're often the only way we can get any actual gameplay, otherwise we're left with a cockpit simulator and not much to do with it.

It kind of makes sense, but the degree of error (243ft observed in one mission) is throwing me off when the -34 states horizontal CEP of way, way less than that on mil and civ GPS services used by the jet's systems. Digging through the same -34 (p. 1-285) I found some info on the Kalman filter that makes it make more sense: The fixes do update INS and add to the Kalman filter's data of system accuracy, but deltas are applied only if they exceed a threshold of 300ft. All of my deltas so far have been less than 300ft, so the deltas don't get appllied. Also it seems that not all HUD symbology is updated, sometimes only the STPT steering cue gets updated. Apparently. EDIT: @Lord Vader are we still sure there's no issues with the nav fixes, because even with the GPS switch off the nav fixes are not taking. Here's a slightly long track (relevant portion maybe 30 minutes in; 45nm from STPT 1) on Kola where I did a TGP fix and then two OFLY fixes. The initial TGP fix on STPT 1 appeared to work, as CZ snapped me back to the fixed position, however when I flew over it the HUD diamond was still in the old position. I retook an OFLY fix on STPT 1 and noted about a 0.12~0.13nm delta. STPT 2 should have taken that same delta but the diamond was still displaced, so I did an OFLY fix on that one too, again with a delta of about 0.12-0.13nm as if the STPT 1 fix didn't update the INS at all. The way it currently seems to work is that I have to perform a fix on every single STPT, then fly the route over again from the beginning. I could be doing something wrong during my alignment, but I would think the fixes would still take even if that were the case...the alignment in the attached track was 9.1/10.

Main issue seems to be where the missiles in DCS impact the jet vs. where they impact in real life, as opposed to an issue with the damage model itself. There have been a number of real-world ejections from Vipers hit by SA-2, -3, and -6; one instance in which the airframe was cut in half.

I have deadzone of 3 in axis tune and 0% in special options. Same deadzone for the Hornet’s AP as well. On an extension that deadzone is not noticeable at all, but I don’t know how that would translate to a short-throw stick.

So the fix only works with GPS off? That certainly wasn’t mentioned in Wag’s video. I was going to give a try pre-GPS era to see how it worked anyway but haven’t had time to check. The Viper mini-update post on the INS updates only talks about alignment, and does not mention FIX not working with GPS or GPS overriding FIX. Neither does this whitepaper on the new INS/GPS implementation.

When the game changes to Digital Cockpit Simulator, which is exactly where we'd go with all these pedantic restrictions that the AI are not subject to.

1. STPT 1 drifted from desired location 2. 8 (FIX) on ICP > SEQ to select HUD FIX 3. HUD SOI > slew diamond over desired point 4. TMS-up to set delta (0.04nm) > ENTER to accept > STPT 1 diamond shifts closer to desired position 5. STPT 2~6 should be updated by this 0.04nm delta yet are not Procedure can't be made any clearer than this. Adding a crude test using container crosses. I deliberately put the STPTs 100ft south of the centerpoint. I conduct HUD FIXes by slewing about 0.02~0.03nm north on STPT 1 and 2. STPT 3 was not shifted (I did not update it). My understanding is that if I had slewed STPT 1 0.02~0.03nm for a fix, ALL of my STPTs should have also been shifted by the same amount in the same direction. Otherwise the FIX function would be useless. FIX.trk