Jump to content

[FUTURE FEATURE] CCPL PI INS update bug


myHelljumper

Recommended Posts

When doing a CCPL PI bombing run, the INS update on the PI point is not working correctly and is impossible to do.

 

You can see in the track, i'm updating very close to the HUD waypoint position marker but the PCN tells me i'm aiming more that 15 nm from the point which makes it impossible for the INS to use the update.

 

Track : CCPL_PI_update_bug.trk

  • Like 1

Helljumper - M2000C Guru

 

Helljumper's Youtube

https://www.youtube.com/channel/UCK3rTjezLUxPbWHvJJ3W2fA

Link to comment
Share on other sites

I just did a PI bombing run and it worked. The problem you may be having is that your accumulated INS drift is >15nm which means you cannot do a direct single INS update putting the diamond over the update landmark. With a full quality align it should take many hours of flying to get drift this high so it's a rare challenge.

 

What you can do is do a pre-attack update to get your INS drift down to a manageable amount so that you won't be outside the 15nm limit. Ahem, also because the INS update is not real in its implementation what you can do is just follow your INS and update anywhere of any quality within 15nm of your drifted INS waypoint and it will zero out all the drift.

 

That's what a real pilot would do (update before the attack) if their drift was so extreme that they couldn't do their INS bombing in a single update, that or abort because if their INS drift is that high it's probably not a good idea to go flinging explosives willy nilly.

Link to comment
Share on other sites

Thanks for the input Fred. Heli, despite the INS update logic can you confirm or not that you had =15Nm of drift on the ins system here? Just want to check all the bases first is all.

Know and use all the capabilities in your airplane. If you don't, sooner or later, some guy who does use them all will kick your ass.

 

— Dave 'Preacher' Pace, USN.

Link to comment
Share on other sites

I've reported the issue long time ago: https://forums.eagle.ru/showthread.php?t=279185

 

It's not linked to accumulated drift as i could reproduce this issue with drift disabled and from airstart near the target with drift enabled.

Also, when doing INS Update with OBL mode or PI mode, when clicking on REC on the PCN to reject the update, you'll see a second Drift value displayed on the PCN, you have to click REC a second time to reject the Update.

 

Displayed drift on PCN, doesn't correspond to the drift of the + mark on the HUD. Seems the value displayed is way off, and if it's >15Nm you won't be available to validate the Update. If you keep spamming the INS Update function while targeting the same update location, drift value will go down and eventually goes above 15 Nm, enabling you to validate the update and set drift back to 0 (as currently a validated INS update set drift back to 0, whatever the quality of the update)

 

I'll let Helljumper answer your question, just wanted to give some extra input on this issue that i could reproduce on numerous occasions.


Edited by Steph21
Link to comment
Share on other sites

Thanks for the input Fred. Heli, despite the INS update logic can you confirm or not that you had =15Nm of drift on the ins system here? Just want to check all the bases first is all.

 

Just take a look at the track, It's an air-start and the track duration is under 15 minutes, so it's not a INS drift problem.

 

If I take the RB M-2000C manual procedure "Bombing with initial point" :

 

  1. During mission preparation phase, or already in the cockpit, you need to create an Initial Point (IP) - waypoint placed over a landmark with a well known position.
  2. You need to create an offset point from the IP using the BAD function and ΔL/ΔG or ρ/θ. Please see OFFSET POINTS chapter in Section 12-5 for more information. Do not forget about setting the altitude difference in Δ ALT.
  3. Prepare your plane for the attack run. Check that your radar is working and emitting and that your radar altimeter is set to on. Select the weapon you will want to use on the PCA and set the MASTER ARM switch to ON (4). On Weapons Control Panel set the fusing, dispersion and release quantity according to your preferences. Finally, press both TAS and RS on the PCA (1, 2).
  4. Set the waypoint that you want to use as the Initial Point (IP) as your DEST and then press the PI button on the PCA (3).
  5. The following cues will appear on the HUD:
    • A diamond at the bottom of the HUD for IP position update purposes.
    • Normal NAV cues: "House" track error cue and "Cross" position cue when distance is below 10 NM.
    • HSI will display bearing and distance to IP.
  6. Turn towards the IP.
  7. When you get close enough to see the IP, update its position by using the diamond to determine exact distance. Remember that you should place the diamond over the landmark, and not the marked position of the waypoint by the INS. When you do so, HUD will display radar range to IP. You can keep updating IP position as many times as you wish to increase accuracy. Please refer to the INS POSITION UPDATE chapter in Section 12-4 for more information.
  8. After the first update, BAD, REC and VAL lights turn on in the PCN when IP is selected - remember not to press the VAL button before finishing the bomb run. Continue flying to IP using the NAV cues.
  9. Once you are over the IP, HUD diamond will disappear and wings will appear on the FPM (1). They will provide steering cues towards the BAD. Radar range will display the range to target (2), nav cues will shift to BAD position (3) and HSI will display bearing and distance to BAD.
  10. As you are almost directly over the IP, follow the navigation cues and turn towards the offset point. Try to keep the wings on your FPM level as you approach your target.

 

The number 8 is not possible because the plane does not use the IP as a reference when we try to update. Then the fix range is too high and the fix is not taken into account by the plane.

 

It's a bit tricky to see, maybe it would be easier if we could talk about it on discord, I'm available for that if you want :).

Helljumper - M2000C Guru

 

Helljumper's Youtube

https://www.youtube.com/channel/UCK3rTjezLUxPbWHvJJ3W2fA

Link to comment
Share on other sites

Which button that is pressed seems to be the difference. In the track at 2:28 the PCN shows 22.302/159.5 and invalid update. Taking control at 8:02:27:

 

  • Press NAV Update/MAGIC unlock button 09.041 159.5 valid update
  • Press Magic Slave/AG Designate/INS Position Update 19.886 159.5 invalid update

The manual doesn't really help. On page 277 in section BOMBING WITH INITIAL POINT, the manner of position update is hyperlinked to page 142 INS POSITION UPDATE which describes overfly and oblique updates but not in the bombardment avec PI context. It's similar but all the different contexts use the different update inputs slightly differently.

 

For overfly the name "Magic Unlock / Position update" is directed even though the actual button is called "NAV Update/MAGIC unlock" in the action list. Please devs, use exact string matching between the manual and the sim. Both are searchable and don't tolerate fuzzy names. I'm guessing we can do overfly update but only with the REC button on the PCN as the other HOTAS buttons do different things.

 

For radar ranging update section it tells you to press the "TAS Ranging keyboard bind" which I have no idea what that is. Nothing in the action list is remotely close. I'm guessing it's "PCN REC Button" (again, please exact string matches only) since it says or the button mapped to your throttle/HOTAS. Indeed it is the throttle button which results in an update vector appropriate to the radar. The stick does an update vector too but it appears to be overfly vector.

 

There are also ways to use offsets in NAV and AG attack which is not "avec PI". According to the manual each button should reference different points that the update is being made relative to. We should find that the throttle button references the BUT and the stick button references the BAD.

 

All in all there are 3 update trigering buttons and 6 INS update contexts. The inputs are REC PCN key, stick button, throttle button and the contexts are NAV overfly without BAD, NAV overfly with BAD, NAV oblique without BAD, NAV oblique with BAD, AG overfly without BAD, AG overfly with BAD, AG oblique without BAD, AG oblique with BAD.

 

[TABLE=head]Button|NAV Overfly|NAV Oblique|NAV Overfly BAD|NAV Oblique BAD|AG|AG BAD|AG PI Pre-flyby|AG PI Post-flyby

REC|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|

Magic Unlock|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|

AG Designate|no action|BUT oblique|no action|BUT oblique|target designate|target designate|PI oblique|radar to BUT?

[/TABLE]

 

The manual on page 35 says the AG designate button should "INS Bombing (IP/BAD): It works similar to NAV Mode, except that it is the IP

position that is updated." I don't know if this means this button should be used in AG BAD or in PI. Right now in DCS pressing this in AG BAD simply designates the target directly and does no INS updating. In PI pre-flyby it updates the INS based on the offset target and not the BUT (presumably the BUT is the IP for an attack). Unless by "IP" they mean "PI" aka the target location which is what DCS behavior currently is.

 

Right now there doesn't seem to be able to put a BAD on a point and use it as an INS update location because the valid/invalid 15nm criteria is always applying to the BUT and not the BAD. If you fly directly over a BAD and try to INS update it will fail if you're >15nm away from the originating BUT. I don't really know what the use of the BAD was intended to be and if it should be possible to INS update off of a BAD.

Link to comment
Share on other sites

Which button that is pressed seems to be the difference. In the track at 2:28 the PCN shows 22.302/159.5 and invalid update. Taking control at 8:02:27:

  • Press NAV Update/MAGIC unlock button 09.041 159.5 valid update
  • Press Magic Slave/AG Designate/INS Position Update 19.886 159.5 invalid update

The manual doesn't really help. On page 277 in section BOMBING WITH INITIAL POINT, the manner of position update is hyperlinked to page 142 INS POSITION UPDATE which describes overfly and oblique updates but not in the bombardment avec PI context. It's similar but all the different contexts use the different update inputs slightly differently.

 

For overfly the name "Magic Unlock / Position update" is directed even though the actual button is called "NAV Update/MAGIC unlock" in the action list. Please devs, use exact string matching between the manual and the sim. Both are searchable and don't tolerate fuzzy names. I'm guessing we can do overfly update but only with the REC button on the PCN as the other HOTAS buttons do different things.

 

For radar ranging update section it tells you to press the "TAS Ranging keyboard bind" which I have no idea what that is. Nothing in the action list is remotely close. I'm guessing it's "PCN REC Button" (again, please exact string matches only) since it says or the button mapped to your throttle/HOTAS. Indeed it is the throttle button which results in an update vector appropriate to the radar. The stick does an update vector too but it appears to be overfly vector.

 

There are also ways to use offsets in NAV and AG attack which is not "avec PI". According to the manual each button should reference different points that the update is being made relative to. We should find that the throttle button references the BUT and the stick button references the BAD.

 

All in all there are 3 update trigering buttons and 6 INS update contexts. The inputs are REC PCN key, stick button, throttle button and the contexts are NAV overfly without BAD, NAV overfly with BAD, NAV oblique without BAD, NAV oblique with BAD, AG overfly without BAD, AG overfly with BAD, AG oblique without BAD, AG oblique with BAD.

 

[TABLE=head]Button|NAV Overfly|NAV Oblique|NAV Overfly BAD|NAV Oblique BAD|AG|AG BAD|AG PI Pre-flyby|AG PI Post-flyby

REC|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|

Magic Unlock|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|BUT overfly|

AG Designate|no action|BUT oblique|no action|BUT oblique|target designate|target designate|PI oblique|radar to BUT?

[/TABLE]

 

The manual on page 35 says the AG designate button should "INS Bombing (IP/BAD): It works similar to NAV Mode, except that it is the IP

position that is updated." I don't know if this means this button should be used in AG BAD or in PI. Right now in DCS pressing this in AG BAD simply designates the target directly and does no INS updating. In PI pre-flyby it updates the INS based on the offset target and not the BUT (presumably the BUT is the IP for an attack). Unless by "IP" they mean "PI" aka the target location which is what DCS behavior currently is.

 

Right now there doesn't seem to be able to put a BAD on a point and use it as an INS update location because the valid/invalid 15nm criteria is always applying to the BUT and not the BAD. If you fly directly over a BAD and try to INS update it will fail if you're >15nm away from the originating BUT. I don't really know what the use of the BAD was intended to be and if it should be possible to INS update off of a BAD.

 

I'm totally lost by your post, but I will try to explain how it should work.

 

There are 2 ways to update the INS during navigation:

- vertical overfly: REC (Recalage) on PCN or "NAV Update/MAGIC unlock" on stick.

- designation = OBL selected on PCA (oblique): "Magic Slave/AG Designate/INS Position Update" on throttle.

 

To perform an offset attack:

- you entrer the Initial Point in the PCN as a "PREP" waypoint ("but" in French)

- you define the target as BAD ("but additionnel" in French).

- select the Initial Point as DEST on PCN

- select "PI" (Point Initial in French) on PCA.

- when in range, designate the Initial Point with diamond at the bottom of the HUD and use "Magic Slave/AG Designate/INS Position Update" command on throttle (same command as CCPR designation, because indeed it's using TAS sensor).

- then you will be guided toward the target which is the BAD point.

 

During the attack:

- don't use the BAD button on PCN

- don't hit VAL button before the end of the attack.

 

After the end of the attack, you should be able to use VAL button to update INS position, because indeed, Initial Point designation is like OBL update.

 

On the other hand, if you don't select "PI" option on PCA, you can perform vertical overfly or OBL update on Initial Point, and after VALidation, hit "BAD" button on PCN and perform a classical CCPR attack on the BAD poisition.

 

This is how it should work at least...

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

The DCS module behavior right now is that before overfly of the PI during an attack you should use the stick button to capture the vector under the radar diamond. If you use the throttle button you'll get myHell's issue.

 

The manual text describes using different buttons (stick/throttle) to update the INS based on different points (BUT/BAD). I.e. you have BAD enabled and you can pick which point your update is relative to based on which button you use. I haven't found that to be the case in the DCS module currently though.

 

Behavior you're describing makes more sense to me. It's more consistent with other behavior (stick being always a REC mirror, oblique always done with throttle button), allowing you to choose how to update during PI attack either obliquely or overfly using the throttle or stick/REC button respectively. I don't know how that would work with the behavior change from update to attack mode based on flying past the PI. If the unupdated PI was prior to the PI landmark it would have already switched into attack mode before you did your update. Maybe that's fine and you can update post-flyby. I don't even know if overfly update is a valid option for PI attacking.

Link to comment
Share on other sites

The DCS module behavior right now is that before overfly of the PI during an attack you should use the stick button to capture the vector under the radar diamond. If you use the throttle button you'll get myHell's issue.

 

The manual text describes using different buttons (stick/throttle) to update the INS based on different points (BUT/BAD). I.e. you have BAD enabled and you can pick which point your update is relative to based on which button you use. I haven't found that to be the case in the DCS module currently though.

 

Behavior you're describing makes more sense to me. It's more consistent with other behavior (stick being always a REC mirror, oblique always done with throttle button), allowing you to choose how to update during PI attack either obliquely or overfly using the throttle or stick/REC button respectively. I don't know how that would work with the behavior change from update to attack mode based on flying past the PI. If the unupdated PI was prior to the PI landmark it would have already switched into attack mode before you did your update. Maybe that's fine and you can update post-flyby. I don't even know if overfly update is a valid option for PI attacking.

 

I need to retry. Last time I did it, I designated the IP with throttle button as expected.

 

When going into attack mode, the HUD switch to "OBL mode", so I don't know if you can still perform overfly update in this mode ?

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

I did a first rough try with INS drift. It was a short flight time. I will do another try from take off to target.

 

I didn't verify the drift vector or update quality, but even if INS update cancel the drift instead of performing a "real" update, vertical overfly with HOTAS did work.

So I performed an overfly update 1mn before IP.

 

The first problem I had was on the IP. From low altitude (300ft AGL) the system switched to target guidance before I had time designate with the TAS.

 

The guidance to release was fine, the first bomb landed close the intended target.

The problem is the bomb spacing.

I set NB = 4 and DIST = 8.

So the bomb impacts should have spread across 240m, but it spread across 722m.

I think we can see similar issues with direct CCRP and CCIP, the system doesn't handle very well changing flight parameters.

During CCIP we can try to fly steady, but CCRP and offset CCRP require a release during pull up, so we can't fly steady...

 

The release consent seems to work = I can squeeze the trigger and wait for the release.

 

Side note: the “roll order” during “offset CCRP” works very nicely.

I already posted in the CCRP bug thread, but I really think it doesn’t make sense that the roll order would be reversed between direct CCRP and offset CCRP, there must be a misunderstanding somewhere...


Edited by jojo

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

The 15nm limit is between the designated point (which is under the airplane for overfly and at the end of the radar LOS for oblique) and the waypoint. If the airplane is outside that radius but designated point is inside the radius then it is allowed. Alternatively if you are inside the radius but designated point is outside the radius then it is not allowed. There's another possible issue. Unfortunately the vector displayed on the PCN is between your actual (not assumed) position and the waypoint and not your assumed position and the waypoint. So if the designated point is actually within 15nm of the reference point but the assumed position is outside that radius then the update will be valid instead of the correct result which would be invalid (and vice versa). Due to this reason it's possible for HSI to read inside 15nm but for an overfly update to be marked invalid since the HSI shows the assumed relationship. Lastly it should be checked if the update vector should be in true or magnetic. Currently the displayed vector is in magnetic. I did check if the displayed vector length is slant range or 2D and it appears to be (what I think is the correct) 2D.

 

I should be more careful. You're right that stick button and REC do overfly during PI bombing. The issue is that the throttle update button produce very strange update vectors. For a sanity test I flew 90nm away and checked vector with REC and throttle button. REC gave ~90nm and the direction toward the waypoint. Throttle button gave about 90nm when pointing straight down and about 50nm with the diamond above the horizon suggesting that the radar LOS ends at ~40nm if it doesn't intersect the terrain. I turned around to check if I could get updates farther away than REC and did a few during the turn... I got up ~730nm or so half way through the turn and down to 36nm when pointing the wrong way (should have been >90nm). Pointing away but nearly straight down I was near again to 90nm but at the horizon the wrong way I got as low as 20nm.

 

Anyway I'm flying back at 56.8nm (did an update and checked to 00 matches reality well) and designated something between me and waypoint. It say 47.338. I'm 56.8. I check the ruler and it's really 49.2 from my designated point to waypoint. I look what is 47.4nm from waypoint to see if HUD is misaligned or something. And I find the terrain under that point is the HUD pull up bracket. I did the math to see if slant range makes a difference (e.g. subtracting my slant to designated point. No the magnitude of the slant-2D issue is much too small to explain it. OK I'll just keep the diamond on this landmark and keep spamming designate and see what happens. Hmm, as I get close it stabilizes at very good what the distance from this point to waypoint. Maybe it's inaccurate up high?

 

OK try something else, pitch up and down while spamming designate. Interesting. I keep getting my distance to waypoint +-10nm. When I pitch down and the radar LOS intersects in front of me I get 30nm and when I pitch up and the intersection is behind me I get 50nm (I'm 40nm). The changeover seems to be when the diamond is above/below the -6 degree pitch ladder. Very weird.

 

Later I get inside 13.3nm and turn away 60 degrees and designate semi close. Vector says 1.2nm. I turn 130 degrees away and designate farther than I am (13.7) and PCN shows 5.2. How is that possible? I designate away from the point and the update vector magnitude is less than my current distance. I get close enough ~3nm and put the diamond on the landmark and PCN says 6.3. Whatever's happening it's not Kosher.

 

My previous conclusion was based on taking control of that track file and pressing different buttons. I can state concretely that pressing the throttle button on that track file at the same time he did gives a >15nm invalid-flagged update and the stick button update was valid (but perhaps it was just because it was an overfly). I didn't do any careful analysis.

 

---

 

You can perform a regular navigation update with oblique selected by using stick button or REC. It's hard to verify the correctness of this mostly because anything which is valid resets the presumed to actual coordinates no matter how it is done.

Link to comment
Share on other sites

You can perform a regular navigation update with oblique selected by using stick button or REC.

 

@RAZBAM_ELMO

This is a good question, I don't have the answer: is it possible to perform overfly update with REC on PCN or stick button while OBL had been selected on PCA ?

 

Yet, this is a minor issue...

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

So the SME has had a look over here and has some choice words about the system lol, so I'll try to summarize here.

 

'Last time I checked PI was not active...its not in use anymore because its a useless piece of software, makes no sense in any form of collateral damage real world. It is a very complex mode and will take time but it's * useless.'

 

Based on the feedback from the SME, RAZBAM has decided that due to its antiquated use, it will not be a priority function in the Mirage.; If at a later time RAZBAM decides to take the time away from other modules they may implement it but as it stands it will remain as is.

 

Moving to resolved as FUTURE FEATURE.

Know and use all the capabilities in your airplane. If you don't, sooner or later, some guy who does use them all will kick your ass.

 

— Dave 'Preacher' Pace, USN.

Link to comment
Share on other sites

I perfectly understand the reason behind this decision regarding a 2020 Mirage 2000C module simulation. But I can't help myself thinking about the vast majority of the missions I fly in a mid 90s early 2000s settings where this function could still be relevant.

 

I'm also a little worried about other functionalities receiving the same treatment. Let's hope Razbam will find time in the future to round up the Mirage and offer all of her features.

 

Thank you for taking time to investigate these issues with the SME(s).

3rd Wing | 55th Black Alligators * BA-33

Εις ανηρ ουδεις ανηρ

Link to comment
Share on other sites

I'm not happy about this but if it's fixed later it's okay then I guess...... at least you are honest.

 

The SME sees it form today's battlefield perspective, as Tugais said, in the 80s-90s that mode could've been relevant to the aircraft mission. It sure is in DCS, we don't have 2000D to tell us when to drop the bombs....

 

You guys would need to add this to the manual so newcomers know that the PI fix is bugged and won't be fixed for some time.

Helljumper - M2000C Guru

 

Helljumper's Youtube

https://www.youtube.com/channel/UCK3rTjezLUxPbWHvJJ3W2fA

Link to comment
Share on other sites

Yeah, I understand the reasoning for RB's decision but this is kind of why the feedback from today's Mirage pilots is not the end all be all for what to do with the module. By that same reasoning, the Mirage should also not carry the Super 530 since it was retired years ago by the AdA and it isn't really a competitive missile anymore. That doesn't mean there is no value to having it in DCS, and the same is true for a good representation of the INS bombing modes (and the INS in general, but that's a whole other can of worms...).

Link to comment
Share on other sites

So the SME has had a look over here and has some choice words about the system lol, so I'll try to summarize here.

 

'Last time I checked PI was not active...its not in use anymore because its a useless piece of software, makes no sense in any form of collateral damage real world. It is a very complex mode and will take time but it's * useless.'

 

Based on the feedback from the SME, RAZBAM has decided that due to its antiquated use, it will not be a priority function in the Mirage.; If at a later time RAZBAM decides to take the time away from other modules they may implement it but as it stands it will remain as is.

 

Moving to resolved as FUTURE FEATURE.

 

I missed that.

 

As said, the only relevant weapons for the module should be guns, Magic 2, Mk-82 and GBU-12. Then Razbam M-2000C will follow the same path as real Mirage 2000C RDI...useless :no_sad:

The most interesting part of the M-2000C for us may not be what they do with it today.

 

That's the problem with active duty pilots, very focused on what they do, they don't care about anything else...

 

Offset loft bombing was used by

- British Sea Harrier harassing Argentineans troops on Port Stanley airfield in 1982.

- French Super Etendard agains Hezbollah in Lebanon in 1983.

- British Tornado against Iraqi airfields during Desert Storm.

...

 

Even if it isn't relevant anymore, for us gamer it's interesting to play with, especially for pre-GPS era missions.

 

Luckily, it isn't that bad currently.

The most interesting improvement would be a proper INS update, this is mainly due for navigation anyway :thumbup:

  • Like 1

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

  • Recently Browsing   0 members

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