Rosebud47

The feature to lock 45Hz ( hertz not FPS ) in the Tookit affects only how OpenXR repojection works. If Reprojection is set to off in OXR development tool, the feature in the toolkit shouldn´t affect anything at all. SteamVR Asynchroneous Reprojection ( it´s always mixed up with motion reprojection, which smoothes the head movement, but not the scenery movement, what Asynchroneous Reprojection does ) works only in one step: If asynchroneous Reprojection in SteamVR is activated, it kicks in when the FPS drops from 90 ( the optimum for 90Hz headsets ) down to around 80FPS, when at 80 instead of 90FPS it instantly reduces the FPS to 45 and interpolates on image to put between a real each really processed images ( 45 real processed images + 45 interpolated images = 90 FPS to meet the 90 Hz of the displays for a smooth visual effect of movements in the scenery ). To got this work perfectly, it needs to maintain 45 real FPS constantly, if the system can´t hold up to real 45 FPS and dips below, it results in ghosting effects ( the interpolated image is just a copy of the before real processed image ). The ghosting effect is pronounced to very fast changing object in the scenery, like very close buildings or other close flying aircrafts, just because the movement, respectively the change in position of ots place in the scenery of far away objects is not as fast as the change in position of close by objects. Now OpenXR comes with its own reprojection technique, which works in more steps, than only cut in half the real FPS like OpenVR ( SteamVR ) Asynchroneus Reprojection does. OpenXR Reprojection adds more steps with reducing to 30FPS and interpolating 2 copies to meet the 90Hz. If reprojection in OpenXR is activated and the system can´t maintain 90FPS it reduces the FPS to 45 and adds one interpolated/copied image. I assume it kicks in, when the real processed images are dipping below 90 at around 80 FPS. The next step in reprojecting a copy of a formerly real rendered image kicks in, when the FPS goes down below 45FPS ( I assume at 44FPS the 2nd step in OpenXR reprojection already kicks in ) and reduces the rendered FPS to 30 and interpolates two images to reach the 90Hz dispaly frequency ( to get a smooth , stutterfree image in VR ). That´s where the toolkit feature get´s active, where the 2nd step in reprojectio could be avoided by locking to 45Hz in the toolkit. OpenXR reprojection then works the same as OpenVR asynchroneous reprojection in only one step reducing to 45FPS. In my observation OpenXR Reprojection works much better with the Reverb G2 than OpenVR ( SteamVR ) reprojection by creating a butter smooth movement in the scenery, but for that it needs to be forced more to maintain the 45FPS rendered images, than OpenVR ... but that´s only an impression, maybe by noticing any stutter more pronounced in a buttery smooth image than in a scenery which got tiny stutters anyway. Of this it could be concluded that OpenVR handles significant dips below 45FPS better by AsynchroneousReprojection than OpenXR does, as OpenXR reprojection results in a stutterfest if it significantly dips below 45FPS when locked in the toolkit at 45Hz or when unlocked in the toolkit switches to the next step and reduces to 30FPS by interpolating 2 frames. Maybe that´s exactly the reason, why it got those additional reprojection with 30FPS and two interpolated images, because it´s more sensitive in the area of acceptable image quality off the exact calculated 90, 45 and 30 FPS. TIn my observation the visible advantage of OpenXR in comparison to OpenVR in DCS World with a Reverb G2 ( probably other WMR headsets too ) is a much smoother and better image quality at 45FPS with reprojection - but the 45 FPS needs to be maintained at any cost to get the advantage. I have explained to myself the issues I got with helicopters and locked 45Hz reprojection in the way, that the animation of the rotorblades is such fast by changing the places of objects ( the rotorblades ) in the image scenery, that reprojection is not fast enough to fill in the gaps with interpolated images and get somehow stuck, which results in a stutterfest then. Same maybe could be assumed to a general stutterfest at locked 45Hz in the toolkit, if the targeted 45FPS could not be maintained and permanently drops below 40FPS, where the OpenXR reprojection gets stuck somehow ( if unlocked it would instead reduce to 30FPS permanently ). The KA-50 seems to have a different rotorblade animation from the Apache or Hind, what makes the KA-50 maintaining 45FPS easily and not get "stuck" in reprojection.

Very nice improvement. Things look definitely much better and reveal more small details, like the geometry of the ball in the slip indicator. Horizon line and everything else got more depth as well. Reverb G2 using. What great time to fly in VR. @dburne really worth to get it run. I remember from the nvidia 3D Vision glasses I had before VR, that V-sync always needs to be off to get a clean 3D effect with it... maybe some small setting like that only, which need to be fixed...

I´ve now locked reprojection in the toolkit to 45Hz. 45Hz feels much smoother and does not cause eye strain to me, as it feels with 30hz. It looks like the reprojection is triggered from 45Hz to 30Hz, when it´s just below 45Hz - no surprise, but with the same settings as before, I´ve reached 38FPS - 42FPS with ocked 45Hz instead of permanent 30FPS when unlocked. So next step was to achieve constant 45 FPS by reducing clouds to ´high´ instead ´ultra´ and turning shadows completely off ( the mirrors in the cockpits are off anyways - in the Hornet the mirrors are a frame killer for my system ). ... much better now and I could keep up FPS above 40 and most time constantly with the Viper and Hornet in low level flight over large cities on Syria, Caucasus and Las Vegas. When locked at 45Hz the FPS down to 43FPS aren´t such noticable, but below 43FPS some stutters could be observed to left and right ( in low level flight over large cities only ). I could live with that, as most of the time the 45/46 FPS when locked could be maintained. On the Nevada map constantly maintained 45/46FPS even with 500 knots in low level flight over the strip with the Viper. With helicopters things are different a lot, when locked at 45Hz! Apache: around 30 or even lower - stutterfest. Hind the same: stutterfest low FPS. Surprisingly the KA-50 is not affected: NOE flight over Sukhumi with 250 Kph and between the buildings with a rocksolid 45/46 FPS. Another surprise was that the Huey is also affected of low FPS and stutterfest, when locked reprojection at 45Hz. ... then DCS was no longer playable as the low FPS didn´t return to 90 FPS, when going back into the main menu, what for sure has nothing to do with OpenXR .

You´re right! I´ve now deactivated NIS and was just going with Reprojection always, what resulted in same FPS but better image quality ( less grainy cockpit and less blurry symbology on the MFDs ) solid 30/31 FPS with the newer modules and some 45 FPS with Harrier, Ka-50, Huey with dips into 30 FPS depending on the scenery. 2x MSAA is something I´ve always activated and clearly improves visual quality on my side. I´ll take the performance impact on that as the effect of MSAA 2x is everywhere visible. I´m also keeping the tuning as slim as possible, as I think every additional image processing reduces the image quality a bit more. What I´ve observed is, that reprojection at 30Hz is not as smooth as reprojection at 45Hz, which is no surprise, but at 30Hz the image is still fluid, but not as buttery smooth as with 45Hz. OpenXR reprojection does a better job on the Reverb G2 than SteamVR reprojection anyway. I think OpenXR Reprojection could be locked somehow, but so far I leave it like it is now and go back to flight training instead. Let´s wait for an DCS World engine upgrade ... finally ... hopefully ... can´t believe that ED is not recognizing, that a better performance of the engine would give many more people access to DCS ...

Just to understand, how does NIS work? So far so good, I´ve set up OXRTK and got really good results. With MR always on, I got solid 45 FPS with the Harrier everywhere and solid 30 FPS with the Hind on Syria. Mariana Map pushed down the FPS in the Hornet from 30 to around 20, depending how many buildings are rendered in the view, but Marianas is not the usual environment, just for getting some FPS figures by putting heavy load to perform. Beside the 100% in OXRDT and the super clarity and detailed image, I´m also keeping the MSAA 2x in DCS. Tried no MSAA, which resulted in a "restless" image, with MSAA 2x the image is calm and nice. A really bonus for through the process is, that I´ve added flat shadows in DCS. Before via SteamVR I´ve left shadows off for perfromance reason, now I could add and still get a smooth flying without permanent stutters and shimmering effects. But how does NIS work exactly? I´ve set it on OXRTK to 88% for the moment, which indicates a resolution around 2700 x 2700. In OXRDT the res. is set to 100% which is around 3160 x 3060 ( can´t recall the exact res. ) Does NIS then reduces the original resolution set in OXRDT of 100% to 88% and then upscales from there back to the 100% resolution?

Yeah, you can´t have enough computer power to run VR. @DeltaMike I´m running a 3080Ti currently. John Carmack once stated that for human eye like perception in VR you need a native resolution of 16K ... well, we got some way to go to get there... Need to stop enjoying the forums now and getting back to work ... 77% for NIS activated is a good advice. Have to try the OXR Toolkit this evening. I´ll let the 100% in OXR developer tool as the image is brilliant and going on from there to improve performance. There are some questions, like if it is recommendable to set prerendered VR images in Nvidia panel to 2 or 3 as the OpenXR reprojection method works in more steps differently from SteamVR reprojection in one step, respectively interpolating one image at 45Hz. Fixed Foveated rendering I would only apply, if I can´t get good results to satisfy performance with other tools with less impact on visula quality. Actually I´ve stopped orientating too much on FPSVR or GPU timing figures and did indeed fly more, also with some stress tests until I feel happy. ED needs to come up with multithreading better sooner than later to improve performance in DCS VR! Every timing for the CPU to process a workload not necessary for VR imagery is a timing less we have for the performance in VR - it´s a good damn bottleneck we´re currently pushing through so much.

Yeah, but the space between the pixels is more noticable as a screendoor effect on lower resolution LCD panels at small FOV. I´m glad, that with the G2 there is no longer a screendoor effect visible and I think the Reverb has got really good panels according to the FOV of the lenses. After all criticism, I´m really happy with the HP Reverb and more than that after using the OpenXR mod. Seems to be hard for the industry to get the exact balance between the LCD panels and lenses through the VR compositor. It´s very interesting what you´ve observed by this: So it looks like HP had replaced the lenses of the G1 but not the displays for the G2 and then running into issues finding the right balance to distort the image to the new lenses, which now need to be compensated by supersampling to get the best results, who knows, it´s just speculation ... Do you remember this one company XTAL from Prague, Czech Republic which came up with a 200° FOV super expensive headset? In some interviews they mentioned, that they had a lot of lenses wasted until they found the right cut for the lenses to compensate the distortion correctly... it seems to be a challenge to get it right. I also like the idea of edge to edge clarity to eliminate the sweetspot. There are rumours around Valve is working on a new headset, but so far nothing concrete is known. For the moment the OpenXR connectivity in DCS made the G2 like a new headset to me and I could happily live with it for another year until it´s worn out.

I believe more in your actual experience, than in what the industry says. There is always a lot of marketing going on, especially for the VR headset consumer market, which the costumer can´t proove easily to be right or wrong or something in between. Relying on the uninfluenced experiences we share for ourselves, is better than on marketing influenced statements from the industry in my opinion. While running the G2 at around 70% slider setting, did not let me noticed any distortion effect. But for sure the overall image quality was less than with more supersampling, what is expectable. Actually I only noticed distortation of all the headsets I had only with the Pimax 5k+ and that was only when experimenting off the limits with FOV and POV settings in the according DCS .LUA files. While I do believe in your comparison that the G2 lenses are more optimized for higher resolution from the first iteration, I wouldn´t believe that the optimization would make such a massive increase in upsampling necessary. Also the FOV did not change significantly from G1 to G2, nor the native resolution. It´s weird, what there´s going on ... I believe the industry got cost intense problems by dealing with the distortion the higher the FOV is. Maybe that´s why we didn´t see so far a raise of standard FOV with new generations of VR headsets, but that´s only assumption... Valve´s Index came up with some double lens tech to balance the distortion and to achieve an edge to edge clarity, which is quite innovative. But HP didn´t invent the Reverb with significantly new tech, with the G2. ... I still believe there is more a marketing effect in the industry statements to make people supersampling by default or to cover some inbalance in design. A panel resolution of around 3000 x 3000 with an FOV of around 150° ( with more horziontal resolution ) would be something I would like more to deal with than with software adjustments on cost for the quality/performance ratio.

@nikoel First of all, thanks again for your perfect guide to lead through the OpenXR modding process. By following your guide helped me a lot getting a perfect result without problems in the process... can´t appreciate enough how you shared your knowledge here for everyone! In next step I want to deal with the OpenXR Toolkit for performance optimization. What came to the eye instantly, changing from OpenVR to OpenXR with the Reverb G2, was the so much better image clarity. Regarding the sliders to adjust the resolution in SteamVR respectively OpenXR developer tool, I´m not quite convinced how 100% are defined by HP for setting the hedset to its basic resolution. This causes a lot of confusion how we used to use terms like ´native resolution´ or ´supersampling´. Actually it´s the explanation of HP, saying "100% slider setting ( 3164 x 3092 ) is, as the G2 is meant be run in basic ( native? ) resolution. In additional explanation HP says "because to compensate the distortion effects". There´s no doubt about, that the image quality generally looks much much better through supersampling, but always comes with some disadvantages respectively with costs in performance. This is valid for every headset and we are dealing with it on a daily base to find the optimum for our individual settings. In my understanding the optimum for a crisp image always is the native resolution the LCD panels provide, which is a valid assumption for TVs, monitors, beamers, etc., but for VR things get more complicated as the viewing distance from the eye to display is so much closer. ...anyways this is nothing new for us, but I just want to get closer softly to my point of view regarding the 100% slider setting ... Now what I think about the 100% slider setting is, that it is just marketing of HP to make the HP Reverb look better than it actually is. Marketing is confusing terms to make you believe of this, like confusing "native resolution" or "supersampling". Like commercials for laundry detergent stating that their product is washing whiter than white. In fact, there os no whiter than white. White is white. Native resolution is the hardware resolution limit the LCD panels provide ( 2150 x 2150 for the G2 ). Upsampling is always going from the native resolution of the LCD displays. As long as HP does not give a more specific explanation for their 100% slider setting is "as it should be" and everything above or below "as it should be" is "upsampling" or "downsampling" is like stating ´our product of HP Reverb G2 makes your image whiter than white". Phuuu, okay, that may sound provocative to the discucssion and the explanation in the YouTube Video above, but it´s just mine point of view. I´m completely lost, when it´s coming up to subpixel technology and how this translates into VR images ... Furthermore the HP explanation includes the distortion effect in VR. Well, then the G2 would be the first and only VR headset, which needs such an amount of supersampling ( from 2150 x 2150 ) to balance the distortion effect. The distortion effect usually gets visible on the outer edges horizontally in the FOV, if it´s not balanced by a certain amount of additional rendered pixels on a subpixel level ( please correct if my understanding is wrong on this ) in this FOV area. Therefore, we always have a slightly higher rendered pixel count on the horizontal than the native LCD panels provide ( 3164 x 3092 rendered on a 2150 x 2150 physical resolution display for example ). This slightly higher amount on the horizontal depends on the FOV the lenses physically provides, but it´s definitely not 50% more rendered pixels necessary to balance the distortion. Now that you explained, that the 100% slider setting in OpenXR developer tool is identical in it´s effective resolution for the G2 to the 100% slider setting in SteamVR, let assume, that it is affected by a software setting possibly through the HP headset driver in the way the HP-driver is set to demand 3164 x 3092 as default resolution instead the native resolution ( +some more pixels horizontally ). Now why this? I assume it´s just to make the G2 look better than it is to last longer in the market, by making people believe, ´it is a as it should be´ only by supersampling the image in VR, which, in any case, results in a better image in VR. There´s no magical LCD tech with the G2 LCD panels, which would support the statement of HP, that ´it is as it should be´, only by supersampling, which in their case shouldn´t be recognized as supersampling anymore, but "as it should be". In comparison Varjo did another approach regarding display tech for VR. They don´t use usual LCD panels, but have put a high resolution LCD panels in the sweetspot and a regular LCD panel in the peripheral areas, what could be regarded as true innovation in VR display tech. HP didn´t invent anything new with their LCD displays, which could make us belive they should be treated resolution-wise any other than any other VR headset. Please don´t get me wrong, I´m not looking to expose others and others opinion, like it is a bad habit in the forums - I´m very much against this habit and am looking for communication in first place. This confusing slider setting in any frontend App also shouldn´t lead to stressful thinking, as we are anyway trying to find the best settings in VR for ourselves including supersampling. With the OpenXR mod things get so much better with regard to the image quality/ performance ratio, than it ever was through OpenVR and SteamVR for the HP Reverb headset on my side and I´m so much thankfull to you taking the initiative and come up with the guide how to do it.

Just switched over from Reshade 5.0.2 to OpenXR-Mod for DCS. Uninstalling Reshade 5.0.2 is easy: just run the Installation again and at the end of the installation routine, after you choose which DirectX, Vulkan or OpenGL you want to choose for installation, the installer asks to uninstall a previous installation of Reshade. Confirming. Done. Following the instruction of the OpenXR Quick Start Guide Thread - big thanks @nikoel for setting this up! - the installation of the OpenXR Mod went easy. I´ve also installed OpenXR Tool Kit, but left it deactivated for today, to see if the modding went well and everything is working as it should. It does works as it should. On a first glance, SteamVR / WMR for SteamVr is no longer needed - years of waiting for this to be done has come to an end! Also the flickering in the loading screens has gone completely. About the visuals I´m not quite sure at the moment. The improvement in clarity and visual fidelity is massive, shimmering has gone completely ( the AV-8B Harrier cockpit always is good indicator about edge shimmering ). But before going on euphorically, I have to admit, that in SteamVR I had a resolution running for the Reverb G2 at approx 70%, means around 2700 x 2700 or something. Now with OpenXR developer tool I´ve started with custome resolution at 100% and have no idea at the moment in which effective resolution it results ( will figure out later ), but I guess it´s a lot higher than around 70% in SteamVR ( native resolution for the Reverb G2 in SteamVr was settled at 50% there ). While the whole process of starting up DCS in VR now feels much more fluid and homogeneous, the fluidity in flight feels the same...just feels, but is not as smooth as I´m going to adjust finally. The more looking to the left or right out of the cockpit the more the stutters get noticable... something could be fixed to anyones preference by tuning with the tools at hand. Back for a moment being euphoric: the MFDs in the Viper and the map in the Hind have reached a clarity now, I´ve never seen before, everything is absolutely solid readable. The only shimmer I could have noticed was a random happy tree in the forest, which couldn´t decide, which side to face at me. So in my first impression the OpenXR mod is a must have for every WMR headset owner, to improve DCS VR. I liked Reshade 5, but in comparison it´s just a small mod you could play and fiddle with to get a more beautiful image. OpenXR brings DCS VR to a next level experience... at least for Reverb G2 owners.

I´m switching to OpenXR mod assuming that it is the better way to improve VR in DCS with a WMR headset. Finally you could get rid of the interaction with SteamVR / WMR for SteamVR and the colors and sharpness could be enhanced with OpenXR tool as well.

@actually_fred had expressed myself too quick and indiffirent with that. Didn´t meant that OpenXR is integrated in Vulkan, like DirectX is per se coming with Windows, but was refering to a presentation of Khronos Group representatives, I was watching some years ago, in which was talking about conceptual integration of OpenXR into Vulkan for extending the interface for VR, what was at that time more supported by Khronos Group developers for future application than OpenVR. Surely game developers could take use of whatever VR protocol they want, to extend the graphics interface for VR... By the way, I´ve recently installed Reshade 5.0.2 to improve the graphics in DCS. Would it be more recommendable to delete Reshade 5 and install the new OpenXR runtime mod for better improvements in DCS VR with a Reverb G2?

Sorry Bignewy, couldn´t find the news between a comment on this and that ...

The first take offs in VR with the ´64 were fine fps wise, but after starting the third and fourth instant action mission a massive fps loss kicked in and is now permanent. My system is a 3080ti, i9 10900k @4,9 GHz, no mods. Don´t have any fps problems with the other modules in VR. What I wonder about is, that the fps in the Apache were good in the beginning, but degraded massively at a certain point. I won´t change my graphical settings, as they are proven solid with the other modules and waiting for an update or Vulkan to get back in the Apache. Wonder if that right eye monocle changed to left or both would do a trick ... Edit: remember from yesterday, that the massive FPS drop kicked in, when I´d set the FLIR on to a MFD at the pilot seat for the very first time. But FPS drop now stays even I don´t have the FLIR paged...

Hmm, reversed logic doesn´t work for everything . With MSFS 2020 they a surely following their DirectX graphics API, as it is a Microsoft thing. Once the WMR headsets came out, Microsoft wanted to build up an independent VR API to Steam and Oculus, but somewhere on official statements for Vulkan was mentioned that OpenXR is an elemental part of newest Vulkan graphics API. But please don´t ask me to google it again . As far as it concerns DCS, I would say, it´s not absolutely sure, that DCS will support OpenXR through Vulkan. I guess you could implement Vulkan in different ways and with different integral features, but it would be a pity if ED would leave the OpneXR integration in Vulkan aside, when supporting Vulkan in DCS. Edit: Oh, Supmua just had some similar thoughts. Isn´t there a flight simulator, which does support Vulkan? Might be interesting to know, if that one flight sim with Vulkan also supports OpenXR... ?

OpenXR is a part of the Vulkan API, afaik, so I would assume OpenXR support in DCS be coming with the implementation of Vulkan.

Totally true. Actually another variant is not so much of interest as the MiG21bis. Moreover a variant, which really differentiate from the 21bis, makes things difficult, time- and costeffective - that´s not what initially was asking for. Better keep distance from the variation idea to keep things in a feasable frame. Also a Su-22 as a separate full fidelity module would be a better complement to the MiG21bis than another less capable MiG21.

Man, I´m meanwhile so much hyped for a renewed MiG21bis while reading through the thread. But we also have to accept, if Magnitude couldn´t agree because of a tight schedule with the pending projects or could agree earliest in 4 or 5 years to this. Anyhow, if Magnitude would accept to the proposals made in this thread, the MiG21 will become bombastic - that´s for sure. Yesterday watched a nice video about the MiG21 generations: If the idea of a variant would get real, I would vote for the early MiG21f-13. But also have in mind, that the F-13 would be the most work inside and outside to be done. Or a MiG21bis with after market additions ( in the end of the video he´s talking a bit about that ), which would mean less work and time to create a variant, as it could be based on the MiG21bis.

Political-social-systems don´t do anything. Economic laws don´t do anything. People do. People decide. Always. I decided for myself, that it is fairplay to pay royalty to Magnitude for an overhaul quality upgrade for the MiG21bis. And I will pay more if they would include a variant like the MiG21 - F13 to this upgrade.

@-Rudel- The MiG21bis has got a solid fanbase in DCS you definitely could count on! Also, I would say, the module has got a very important role in the entire DCS line up, which will get more important and demanded, when the F-4, A-7 and more cold-war-era-jets are out in the wild. Asking for a high fidelity upgrade for the MiG21bis to be on par qualitywise with the upcoming new modules is a more rhetorical than serious question. While DCS pilots are used to be patient, I really would wish you could manage such task in a schedule right after the F4U-Corsair and before the completion of the F-8, as Magnitude originally planned with the updates for the MiG21 cockpit. Better wait a little bit longer, but having then an entirely paid full-upgrade instead of some updates in the cockpit here and there.

So far the simple wedge avoids the wiggle of the TM stick. Surprising, that there is a kind of small business on ebay for it. As soon as the TM stick makes more problems, I will order the realsimulator F-16 stick as well, but so far and after all the years, the TM stick is still in good condition, so I´ll keep it, cause I like the metal grip of TM stick.

I´m using a small wooden wedge to stabilize the TM Warthog grip on to the FSSB. Works good and makes the hold solid. Here´s a video from a guy to came up with the idea by using a Lego brick.

@Hiromachi thank you for listening! Personally I don´t care about 20,- $ more or less; it´s like a decision one time within 8 years to eat a salad at home instead of going to McDonald´s and order a large happy meal. Finding the right price to justify the work which has gone into it, is up to Magnitude. After years of learning and getting used to fly the MiG21bis, an all over quality upgrade would be like a gift from heaven! @MiG21bisFishbedL surely is more an expert for variants, but a variant of the MiG21bis with some advanced modifications and a reference to real life would be in line with the upgrades for the A-10 and Ka-50. Mission builders and server admins then would have the option, if the original MiG21bis or a version with modernized capabilities would fit in the scenarios.

Well, Eagle Dynamics is doing it now for the 2nd time for the Black Shark module. It´s not about optimism, pessimism, wishful thinking, immersion or stuff like this. Developing a module and charging a few bucks for it is actually how the business works. I say: it´s a good thing to charge a few bucks for a module upgrade and should be done more frequently for the older-, as well for the older 3rd-party-modules. The thing is, that tasks without ROI will always be neglected in favor for new modules with ROI and once the ROI for those new modules is created, they will be neglected as well in favor for another new modules and so on and so on... Edit: just to avoid subtleties, we´re talking about the really old modules, like MiG21, F-5 Tiger, Huey, etc.

@MiG21bisFishbedL Another MiG21 variant of another era included into a module upgrade would be fantastic. The approach of Heatblur, Magnitude and lastly Aerges ( F1 Mirage + variants ) by announcing more variants included in a full module purchase or adding Essex carrier, Forrestal or ground assets is mostly welcome and make DCS World a much more richer experience. But honestly, while we did pay for maintaining each module by timely proper bugfixing, we did not pay for a technical module upgrade years ago to update to quality standards nowadays. If payable module upgrades ( including variants and additional assets ) would get more popular, the older modules won´t get lost through time and DCS would grow much faster and more consistent. Totally agree with you, that it might be difficult to make, for small studios like Magnitude especially with the ongoing projects they already announced, to improve the MiG21 module; chances will be much more less to do so, if they would put time in it for nothing. @Boosterdog The OP has trust in common sense, that the price range for a module upgrade is not mismatched with the price range for a new module.