Jump to content

Help getting highest INS accuracy for pre-planned popups


Nealius

Recommended Posts

I've been doing a lot of pre-planned pop ups as described in books like Vipers in the Storm, and I'm having trouble getting enough INS accuracy for the HUD symbology to get me on a good wire for the planned delivery. Everything ends up shifted some 200ft while the system tells me I have a delta of 0.00nm and accuracy high for both SYS and GPS. 200ft is fine for TGP work and guided munitions, but for pre-planned popups this shifts the VRP/VIP, the PUP, the pulldown (OA1) and the AOP (OA2), as well as the TD box, enough that major corrections are required to get on a good wire for delivery, when we should be able to line up the FPM on the OA2 triangle, on the wire intersecting the TD box, then switch CCIP without having to do so many last-second corrections. After all, that's the whole point of the VRPCCRP/VIPCCRP system, as I understand it from written pilot accounts. Prior to the new INS/GPS features, I was able to follow the popup symbology bang on and hit every number as calculated.

Setup: 2005 mission, unrestricted SATNAV, Kola, steerpoints on centerpoint of bridges for easy nav fixes, target not more than 100 or so miles from departure field, first STPT/fix point on center of bridge 35nm from target, second STPT/fix point on center of bridge 16nm from target. Running a fix on these two points should make sure everything's good, but for some reason it's not working for me.

When checking my first fix point, using the TGP the pod is exactly on the bridge centerpoint, FIX delta 0.00nm, SYS and GPS accuracy HIGH, so I don't run a fix yet. I go low, pulling no more than 3G perhaps, and when approaching the bridge the STPT diamond is shifted away from the centerpoint and on the end of the bridge, some 200ft off from where it should be. FIX delta still says 0.00nm, SYS and GPS accuracy HIGH, but I do a HUD fix by slewing the diamond over the bridge center and press ENTER (per Wag's YouTube tutorial), however the diamond snaps back to the edge of the bridge, as if the fix didn't take.

Approaching second fix point, same issue. STPT diamond in the HUD is shifted to the end of the bridge. Slew diamond over center point, hit ENTER for a HUD fix. Diamond reverts to old position. FIX still says delta 0.00nm, SYS and GPS accuracy HIGH.

Execute my pop, ID target, roll in and put the FPM on the AOP triangle, notice TD box is shifted a ways behind the target. Thus my AOP is shifted behind where it should be, my dive angle is shallower than it should be, and my track time (calculated to be 5 seconds) is now about 2 seconds because the symbology is so far off of the actual target. On egress, another one of my bridge waypoints was shifted about the same amount as well, this time checking the FIX as delta 0.00nm, SYS accuracy MED, GPS accuracy HIGH. 

An interesting pattern I noticed with this drift is that it always drifts in the direction of my origin airfield. E.g. if the target area is 150 from where I started, the symbology shift is roughly the reciprocal, 330, from the actual STPT. Starting from a field on the opposite side of the map, the drift is observed to also be opposite. 

Sometimes I think it's not the INS/GPS itself shifting, as the TGP seems to get on point just fine, and there are times where the TGP is right on a taret but the HUD/HMD TD isn't quite in the right spot, so it seems like the HUD symbology is the only thing actually being shifted. Is there something I'm missing to get the HUD symbology more accurately on my STPTs and/or targets?


Edited by Nealius
  • Like 1
Link to comment
Share on other sites

More observations after research and retries:

Chuck's guide mentions TMS-up is required before pressing ENTER on HUD and TGP fixes, however Wag's video only mentions this for OFLY and FCR fixes. He omits this step on the HUD and TGP fixes. The DCS Viper manual does not have a section for the FIX page at all.

Now knowing I need TMS-up, I reflew the same profile using both HUD and OFLY fixes to update the INS, and the STPT diamond properly adjusted itself for the fixed STPT only. It did not update any of the other STPTs in the flight plan. Even after fixing the first two STPTs, the next three were still drifted, consistently 0.04nm (243ft). 

Is there a known issue with FIX only updating the selected STPT and not the entire flightplan?


Edited by Nealius
  • Like 1
Link to comment
Share on other sites

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


Edited by Nealius
Link to comment
Share on other sites

20 hours ago, Nealius said:

Procedure can't be made any clearer than this.

Videos/tracks are just very, very useful to rule out user error.

At least previously (before April's INS+GPS+Kalman filter overhaul), doing FIXes with GPS on was pretty much useless. The GPS would just override any changes you made. I don't know if this specific detail has been changed or if it still works like that, and FIXes with GPS are still counterproductive. The system should likely take into account the better accuracy of a recent FIX instead of simply overwriting it with GPS.

So if your mission has the steerpoints offset to begin with (to simulate an INS drift), try disabling GPS and try again. Do a FIX on the first one and then see how the rest are. For video and track purposes it helps to make the offsets or corrections large enough for them to be really noticeable.

Link to comment
Share on other sites

  • ED Team

Hello @Nealius

On 10/13/2024 at 6:45 AM, Nealius said:

Prior to the new INS/GPS features, I was able to follow the popup symbology bang on and hit every number as calculated.

I'd assume you're referring to non-precision weapons using CCRP. This was in fact the case when there was no realistic INS drift introduced and subsequent new GPS navigation. What we had before was an "impossible" accuracy of the GPS/INS data, that is now much, much closer to reality.

On 10/13/2024 at 6:45 AM, Nealius said:

Setup: 2005 mission, unrestricted SATNAV, Kola, steerpoints on centerpoint of bridges for easy nav fixes, target not more than 100 or so miles from departure field, first STPT/fix point on center of bridge 35nm from target, second STPT/fix point on center of bridge 16nm from target. Running a fix on these two points should make sure everything's good, but for some reason it's not working for me.

This is your first problem that I can perceive. With INS + GPS reception enabled, your position is set using BOTH sources, having the Kalman filter making the necessary merging of data. GPS data has inherent noise to it and it introduces small errors due to various factors, and that's the drift you observe on your sensors.
On the other hand, the FIX procedure is there to correct INS deviations only, not GPS. 
Therefore, performing any kind of fix is rather pointless because the Kalman filter will always correct any INS point you create or adjust with the (noisy but more reliable) GPS data. This is why this happens:

On 10/13/2024 at 6:45 AM, Nealius said:

Approaching second fix point, same issue. STPT diamond in the HUD is shifted to the end of the bridge. Slew diamond over center point, hit ENTER for a HUD fix. Diamond reverts to old position. FIX still says delta 0.00nm, SYS and GPS accuracy HIGH.

---

On 10/13/2024 at 6:45 AM, Nealius said:

Sometimes I think it's not the INS/GPS itself shifting, as the TGP seems to get on point just fine, and there are times where the TGP is right on a taret but the HUD/HMD TD isn't quite in the right spot, so it seems like the HUD symbology is the only thing actually being shifted. Is there something I'm missing to get the HUD symbology more accurately on my STPTs and/or targets?

No, a SPI is a SPI is a SPI, therefore, the Targeting Pod will always follow it as it won't generate another point on its own. It can, however accumulate Deltas and it's good practice to verify if there aren't any by hitting the famous CZ or Cursor Zero button to make sure the TPOD is looking in the right direction. 

I hope I could help. If you search this forum and the Viper Mini-Updates, you'll find a lot of information regarding the new items and refinements introduced with the new INS+GPS system, making it a lot more true to life. 

  • Like 3

dcsvader.png
Esquadra 701 - DCS Portugal - Discord

Link to comment
Share on other sites

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.


Edited by Nealius
  • Like 2
Link to comment
Share on other sites

12 hours ago, Lord Vader said:

I'd assume you're referring to non-precision weapons using CCRP. This was in fact the case when there was no realistic INS drift introduced and subsequent new GPS navigation. What we had before was an "impossible" accuracy of the GPS/INS data, that is now much, much closer to reality.

AHAHAHA

That's a good one. 

  • Like 2
Link to comment
Share on other sites

  • ED Team
5 hours ago, Nealius said:

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.

Technically speaking, you can perform any FIX with GPS on, but the Kalman filter will always resume its corrections, making it a bit pointless. 

If you want to test the FIXes without GPS, you can always set your source to INS only in the DED and/or just turn off the GPS switch. Just a tip. There's no point in doing this on normal operations in a modern scenario, of course, it would only allow you test this without the Kalman filter forcing the GPS updates. 

Regarding my suggestion, I was only saying so in order for you to acquainted with the changes. That's all. 

dcsvader.png
Esquadra 701 - DCS Portugal - Discord

Link to comment
Share on other sites

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.


Edited by Nealius
  • Like 4
Link to comment
Share on other sites

I am confused. GPS and INS are fighting against each other? If I use an INS drift correction, no matter which, the GPS "says": doesn't matter because I know better, but I am drifting like hell too and can't or will not correct myself? What?

For what exactly is GPS good for in the F16? Even my car can correct the GPS data much better than what we get in DCS. And my car is not using military GPS information. And why we have two systems in a fighter jet fighting each other? Doesn't make any sense to me.

I can drive 500+ Miles with my car, and I find exactly the house I have preplanned as my "target destination", but the F16 can't do that with all the top secret extra data? Really?

That's like you have to disable your Handy, because if you don't the navigation system of your car can't find the preplanned destination anymore. That's out of my mind! I can't believe, that's that the way how the F16 system will work. No way!

Is this here a degrading because ED will not give a special country a look how the F16 can be used and will work?

I can't believe, in any way, that one would have given the F16 such an idiotic navigation system. Not yet and, for sure, not in the future.

If the US-Army is looking for a real good and by 100% better navigation system for their jets. Please let them contact me. I can sell them a few from a well known seller in my country.

Even the GPS driven Bombs can correct themselves, but the "big" plane can't? That's so laughable.

 

  • Like 3

CPU: AMD Ryzen 7950X3D, System-RAM: 64 GB DDR5, GPU: nVidia 4090, Monitor: LG 38" 3840*1600, VR-HMD: Pimax Crystal, OS: Windows 11 Pro, HD: 2*2TB Samsung M.2 SSD

HOTAS Throttle: TM Warthog Throttle with TM F16 Grip, Orion2 Throttle with F15EX II Grip with Finger Lifts

HOTAS Sticks: TM AVA Base with TM F16 Stick, FSSB R3 Base with TM F16 Stick

Rudder: WinWing Orion Metal

Link to comment
Share on other sites

54 minutes ago, Nedum said:

 

I am confused.

 

Perhaps this would have been sufficient in your reply.

I hope the thread won’t get locked quite yet, because there are likely some implementation details and nuances worth discussing. OP’s problems are solved but to me it seems there might be some details worth proper discussion. 

Link to comment
Share on other sites

1 hour ago, itn said:

OP’s problems are solved

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.


Edited by Nealius
  • Like 1
Link to comment
Share on other sites

50 minutes ago, Nealius said:

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 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 test if FIX works or not, there are two easy ways

1) Active Pause and time acceleration. You can literally see the diamond moving in HUD. Wait for it to drift enough and try doing a FIX. [EDIT: This worked previously, haven't tested with current version.]

2) Purposefully offset steerpoints in mission.

  1. Add an air-spawn airplane group and put the steerpoints exactly on the targets (the correct position, atop the target or on runway threshold or whatever)
  2. Copy the group and paste it offset from where the original group was. Make the offset large enough for you to notice, and for anyone to notice it visually looking at the track or video.
  3. Optional: If you want to do this from cold start jet, set the spawn point to Start from ramp.
  4. Spawn, fly and try using FIX.

FIX did work in e.g. 2022 and early this year before the INS upgrades (in Caucasus and Syria).


Edited by itn
  • Like 3
Link to comment
Share on other sites

29 minutes ago, itn said:
  • dd an air-spawn airplane group and put the steerpoints exactly on the targets (the correct position, atop the target or on runway threshold or whatever)
  • Copy the group and paste it offset from where the original group was. Make the offset large enough for you to notice, and for anyone to notice it visually looking at the track or video.

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?

Link to comment
Share on other sites

9 minutes ago, Nealius said:

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?

Yes, fly with the copied group. You could just manually place the steerpoints in wrong positions, in order to then fix them using FIX and see if it works. The nice thing when you copy the group, you get the exact same offset for every steerpoint (happens when you paste it to different location). This can sort of simulate INS drift (i.e. your plane thinks it's XXX feet off to direction NNN).

  • Like 1
Link to comment
Share on other sites

Just to put some visual examples up for everyone:

Clip showing HUD FIX used whilst GPS is active. It can be seen that the jet doesn't take the full update because, as vader says, its just feeding into the kalman filter and so is blended into the existing solution.

 

Clip showing HUD FIX used without GPS. It can be seen that the jet takes the full update and that FIX is working as first demonstrated in Wags' video.

 

Clip showing a 5x time accelerated 1hr orbit of a target. It can be seen that the inertial position varies from the true position as expected, but it can also be seen that the GPS is holding the inertial solution roughly on the true position. The maximum error observed was about 18m and was seen only briefly. For 90% of the time the inertial solution was within 10m of the true position. Giving an approximate CEP90 of 10M/33ft horizontally.

 

I would love to see if anyone has a track/video of this alleged 200ft disagreement between inertial and true position. As I haven't been able to reproduce that condition.

  • Like 2
  • Thanks 1

476th Discord   |    476th Website    |    Swift Youtube
Ryzen 5800x, RTX 4070ti, 64GB, Quest 2

Link to comment
Share on other sites

16 hours ago, Swift. said:

Clip showing HUD FIX used without GPS. It can be seen that the jet takes the full update and that FIX is working as first demonstrated in Wags' video.

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.

Quote

I would love to see if anyone has a track/video of this alleged 200ft disagreement between inertial and true position

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.


Edited by Nealius
Link to comment
Share on other sites

19 ore fa, Swift. ha scritto:

Clip showing HUD FIX used whilst GPS is active. It can be seen that the jet doesn't take the full update because, as vader says, its just feeding into the kalman filter and so is blended into the existing solution.

Yep and as i tested, if your video would been longer we would have seen the fix's corrected position moving towards the original position in a number of further updates.

Link to comment
Share on other sites

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.
uBzM13I.png

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.
LyEZHSS.png

STPT 3 and OAP also shifted; purple circle indicates where they should be. Note: attack heading was calculated as 250.
ISOs7Dh.png

Approximate distance measured from programmed STPT 3 and actual STPT 3.
hUcKIaD.png

STPT 4 has been shifted all the way to the bridge ramp.
41d6W5x.png

Approximate distance measured rom programmed STPT 4 and actual STPT 4.
OOon3jK.png

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.

 

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

On 10/20/2024 at 3:51 AM, Nealius said:

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.
uBzM13I.png

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.
LyEZHSS.png

STPT 3 and OAP also shifted; purple circle indicates where they should be. Note: attack heading was calculated as 250.
ISOs7Dh.png

Approximate distance measured from programmed STPT 3 and actual STPT 3.
hUcKIaD.png

STPT 4 has been shifted all the way to the bridge ramp.
41d6W5x.png

Approximate distance measured rom programmed STPT 4 and actual STPT 4.
OOon3jK.png

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.

 

Interested to see how much of a difference GPS and fixes make!

Link to comment
Share on other sites

I have a question about JDAM accuracy, as I've been having issues with hitting them.

Let's say you are dropping on a preplanned STPT target - due to INS drift, you can't just drop on this STPT, because you will miss.

What is the best action to correct this?

When I used my TGP to move perfectly on the target and TMS UP, I still missed a building.

Do I need to take a fix on that steerpoint instead to actually hit the target?  That is, is INS drift still affecting the JDAM if I'm designating a target with my TGP?

Link to comment
Share on other sites

On 10/16/2024 at 9:36 AM, Nedum said:

I am confused. GPS and INS are fighting against each other? If I use an INS drift correction, no matter which, the GPS "says": doesn't matter because I know better, but I am drifting like hell too and can't or will not correct myself? What?

For what exactly is GPS good for in the F16? Even my car can correct the GPS data much better than what we get in DCS. And my car is not using military GPS information. And why we have two systems in a fighter jet fighting each other? Doesn't make any sense to me.

How can your car correct GPS data? Does it have an INS? I've never seen a car with INS 🤔

Have you ever thought about, that for military navigation, you need to consider that:
1) GPS might not be available (either because the enemy has shot down the GPS satelites or is jamming their signals).
2) GPS might give you wrong position data due to enemy spoofing activity (as is already happening in certain parts of the world today).
What's your car going to do then? Right, it will just not be able to provide you a position (#1) or will just provide you a completely wrong position (#2).

That's why (military) aircraft and ships have two different nav systems (GPS+INS) and filters to ensure valid position data even in situations with GPS interference.


Edited by QuiGon
  • Like 1

Intel i7-12700K @ 8x5GHz+4x3.8GHz + 32 GB DDR5 RAM + Nvidia Geforce RTX 2080 (8 GB VRAM) + M.2 SSD + Windows 10 64Bit

DCS Panavia Tornado (IDS) really needs to be a thing!

Tornado3 small.jpg

Link to comment
Share on other sites

1 hour ago, QuiGon said:

How can your car correct GPS data? Does it have an INS? I've never seen a car with INS 🤔

Have you ever thought about, that for military navigation, you need to consider that:
1) GPS might not be available (either because the enemy has shot down the GPS satelites or is jamming their signals).
2) GPS might give you wrong position data due to enemy spoofing activity (as is already happening in certain parts of the world today).
What's your car going to do then? Right, it will just not be able to provide you a position (#1) or will just provide you a completely wrong position (#2).

That's why (military) aircraft and ships have two different nav systems (GPS+INS) and filters to ensure valid position data even in situations with GPS interference.

 

Cars don't have INS as such. But they do augment the GPS signal with direction and velocity sort of like planes. Which is how cars, to an extent, are able to keep track of where they are going inside tunnels. And stay decently accurate in intersections and roundabouts and such without suddenly appearing in the wrong lane.
Also they do actually have IMUs for use with their ESP systems. Not sure if that is integrated with the GPS systems though.

  • Like 1
Link to comment
Share on other sites

38 minutes ago, Tenkom said:

Cars don't have INS as such. But they do augment the GPS signal with direction and velocity sort of like planes. Which is how cars, to an extent, are able to keep track of where they are going inside tunnels. And stay decently accurate in intersections and roundabouts and such without suddenly appearing in the wrong lane.
Also they do actually have IMUs for use with their ESP systems. Not sure if that is integrated with the GPS systems though.

Looks like cars do have evolved since I last bought one 😅

Intel i7-12700K @ 8x5GHz+4x3.8GHz + 32 GB DDR5 RAM + Nvidia Geforce RTX 2080 (8 GB VRAM) + M.2 SSD + Windows 10 64Bit

DCS Panavia Tornado (IDS) really needs to be a thing!

Tornado3 small.jpg

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...