Leaderboard

Few things that may be useful. With OpenXR supported in the game, you do not need OpenComposite anymore, regardless of what headset you use. The goal of OpenComposite is to bridge OpenVR to OpenXR. Using OpenComposite now would be redundant. With OpenXR, you may have the opportunity to either USE or NOT USE SteamVR. See the table below for headsets capable of native support (bypassing SteamVR): Headset brand Has native OpenXR support? (without SteamVR) Windows Mixed Reality (HP Reverb, Samsung Odyssey…) Yes Oculus (Rift, Quest, Quest 2, Quest Pro…) via Link Yes Oculus (...) via Virtual Desktop No Varjo (Aero, VR-3…) Yes Pimax (5K, 8K…) Yes (via PimaxXR) HTC Tier 1 (Vive original, Vive Pro, Vive Pro 2) No HTC Tier 2 (Vive Cosmos, Vive Focus) Yes (via VIVE Console) Valve Index No Pico (Neo 3, Neo 4) No NOTE for Oculus users: if you are using Virtual Desktop, you MUST USE SteamVR (as of date of writing 2023-01-26). Only Link cable and Air Link will work with Oculus native OpenXR support. NOTE: headsets in the list above without native OpenXR support can still use OpenXR, but you MUST USE SteamVR as your OpenXR runtime, as explained directly below. If you want to USE SteamVR with OpenXR Why/when to use SteamVR OpenXR? - I have a headset that does not support OpenXR natively (eg: Valve Index). - I rely on SteamVR features (like overlays or controller button bindings). - I rely on SteamVR 3rd party apps (like fpsVR or OVRMC). You must set SteamVR as your OpenXR runtime and run DCS.exe with --force_OpenXR (see BIGNEWY post above): If you wish to revert to using OpenVR instead of OpenXR Why/when to use OpenVR? - I rely on OpenVR 3rd party injections (mods) like ReShade or vrperfkit - I could not get OpenXR to work You must run the game with the extra command-line argument: DCS.exe --force_steam_VR If you want to NOT USE SteamVR at all Why/when to use OpenXR without SteamVR? - I have a headset that supports OpenXR natively (eg: HP Reverb). - I want to remove the overhead of SteamVR (lower memory usage and possibly higher image clarity). The procedure varies by headset/brand, and you must run DCS.exe with --force_OpenXR (see BIGNEWY post above): WINDOWS MIXED REALITY (use EITHER method) From Mixed Reality Portal: From OpenXR Tools for Windows Mixed Reality: OCULUS (Link cable or Air Link only) From the Oculus app: VARJO From Varjo Base: PIMAX You must download unofficial Pimax OpenXR support: Home · mbucchia/Pimax-OpenXR Wiki · GitHub Then from PimaxXR Control Center: HTC (Vive Cosmos and Focus only) You must install the HTC Vive Console For SteamVR. Once opened: To inspect the current configuration on your system (and make sure OpenXR is properly installed and configured), you can use OpenXR Explorer. It will show you the currently active OpenXR runtime (which should match your device if you want things to work!):

The Good After a few mission cycles I beiieve this issue has been fixed. Ballistics are not accumulating, server FPS is not degrading and CPU usage is not climbing. It is possible that this was the sole root cause of the ballistics leak and there are no others. If I come across any then I will create a new thread. So congrats to @Flappie@abelian@Moezilla, the others who helped, and the ED staffers who fixed and tested. The Bad While I am happy the issue has been resolved I still believe that ED's handling of this issue has overall fallen short of acceptable standards and I want to go into detail here so that, maybe, things can improve. Server Owner <-> ED Relationship I posted this issue on 2022/09/01 however the general issue of a ballistics object leak was known about by the Hoggit admins for a long time before that with posts in the Discord describing the general issue from 2022/06/01. Now I don't know if anything was reported or not but, having spoken to many different server admins, the general concensus I hear is "It is a waste of time to report server issues to ED" along with a general lack of support, debug tooling etc. This is an awful situation. If a server is having an issue that usually means all the clients on that server are having a suboptimal experience. In the case of this issue it meant players suffering lag, warping and otherwise unfavourable conditions. How many ED customers on the various multiplayer severs have left with a sour experience due to this bug in the course of the 6 months or so it took to resolve it? I am willing to bet that it is thousands of customers and thousands of hours of flying time where customers have been left with a bad taste in their mouth at the end of a session . My suggestion to ED to improve this situation is: 1. Provide a formal way for mutliplayer server admins of servers with large player bases to contact you to report issues. Either a forum or a discord channel explicitly for communicating issues to ED and collaborating on fixing them. You have stats on which servers are heavily populated I am sure so invite their admons. Admins having to rely on "Try pinging @NineLineor @BIGNEWYand hope for the best" doesn't cut it. 2. Having created this formal communication method. Listen to them and accept that things like "please provide trackfile" is not always feasible on servers with scripts that run for hours with 10s of players on them where an issue may be inconsistent. Work with them collaboratively to try and find the issues which leads me to the last point: 3. Provide them with the tools they need to be able to perform this kind of investigation. I know this has been requested because multiple people have complained to me about these requests being ignored. The handling of this issue by ED, aka "Cannot Reproduce" & Radio Silence I am going to go out on a limb here and say that this bug report was about as good as ED can expect without deep-diving and finding the root cause itself. It contained lots of information, it pointed to exact syptoms. It included 4 different trackfiles from two completely different setups. Including an AI only tiny trackfile. Despite this the response was "Cannot reproduce". But when @Flappiestarted looking into it he appears to have been able to reproduce it from the small AI trackfile I provided in short order. So the questions that ED needs to answer, at least to itself is "Why couldn't ED staff reproduce something that was reproduced by a volunteer in short order using submitted data.". If ED cannot reproduce things via trackfiles then why should the community spend time and effort to provide them? My next issue is that, once the "cannot reproduce" status was entered that was basically it. The issue languished for months and there were no updates; I had to literally contact ED staff on discord to try and get an update on what what was going on. Had @Flappienot taken the effort to root cause this I have no doubt that this would still be unresolved and ED customers would still be suffering. This ties into the linked post which I think ED needs to consider a lot more carefully.

Dear AH-64D virtual pilots, Although the DCS: AH-64D was released with a rich set of features, there are certainly important features that will still be provided during the Early Access period. To help understand what is still planned and the status of each, we’ve created a roadmap to ensure clarity. As with other roadmaps, we will color-code items based on their status: Green – delivered. Blue – in development. Gray – to be developed. Our roadmap features are as follows: Auxiliary Fuel Tank / Gun Ammunition Option AGM-114L Radar-Guided Hellfire Laser Spot Tracker (LST) Improved Flight Model and Stability and Control Augmentation System (SCAS) Improvements (continuing improvements) Datalink Laser Warning Receiver FARM Reports BDA/SHOT Reports Fire Control Radar (FCR). GTM first being developed. AI Damage Model Improvements Priority and No Fire Zone Data Transfer LINK Mode ZOOM C-Scope FCR RMAP Mode FCR Air-to-Air Mode FCR Multicrew Synch TPM FCR Mode After Early Access Continued Flight Model and Flight Control System Tuning Campaign Data Transfer Cartridge Anti-Ice System Radar Frequency Interferometer (RFI) Radar Jammer Selectable Pilot Patches Automatic Pedal-Input Assist Option Kind regards, Wags

DCS now supports OpenXR natively Depending on which headset you have select the openXR runtime and DCS will work without any third party apps. Edit: OpenXR is removed from autosearch. DCS has a chain of VR vendors in priority oculus, OpenVR, Varjo, etc. OpenXR was in that chain in top priority, now it is removed from this chain and only available when you explicitly specify it in command line of DCS. If you need to force openXR in DCS command parameter is --force_enable_VR --force_OpenXR Please ensure you are doing the command parameter on the DCS.exe or a shortcut from the DCS.exe (NOT the DCS_updater.exe) for multithreading it is the same process but you are using the bin-mt DCS.exe thank you

Liveries Textures passed to Mod Owner to include as he sees fit.

Liveries file passed to Mod owners for inclusion as they see fit.

as we have already mentioned we are working on the shadows issues and VR performance, we also have multithreading, DLSS and other core features on the horizon. With that said please dont derail this thread, keep it for the openXR native support topic thanks

You guys should probably ease up on disrespecting your own members, also making misguided assumptions about matters while evidence suggest otherwise. Neither is an effective way to defend the hard work put into these modules. Some of us have been engineering aerospace systems and components for decades and know a thing or two... Why not just forward the concerns to the relative individuals and leave assumptions out of it?

Dear all I have just tested and set to merge a fix for this issue. I hope to see it in an upcoming update. Thanks for your extreme patience on this, and sorry for the time it has taken to get corrected.

It broke again?! I'll probably have a look in the coming days. Thanks for the heads up.

For pity's sake. What a load of histrionic bovine excrement. Grow up.

nullnullnull

As mentioned in other comments yes it should have been in the notes, and it slipped under my radar as I was already using openXR, I have mentioned it to the team

Hi, thanks for reporting! We caught it a bit too late but it's already fixed and will be in the next update.

You may forward to dev team: the game is doing 2 back-to-back xrWaitFrame() from the same thread, which causes a deadlock. nullThis condition is probably exacerbated by the frame timing of motion reprojection. Read more about xrWaitFrame() deadlocks here: OpenXR-Guide/frame_submission.md at main · KhronosGroup/OpenXR-Guide (github.com) Happy to find a more official channel to discuss. Thanks.

Hello ladies and gentlemen, The changelog for the AV8B Harrier did not made it to ED for this update, here is what it contains : DCS: AV-8B N/A by Razbam - Fixed: Fuel boost pumps switch should be on for cold start - Fixed: RPS switch should be on for cold start - Fixed: AFT EQUIP switch should be on for cold start - Fixed: Anti-Skid switch should be on for cold start - Improved: Minor adjustments to dry engine performance based on hover performance checks for 0 datum engine - Fixed: Water loaded/unloaded in mission editor sometimes not taking effect properly - LOADOUT REWORK : See the forum post - Fixed: Rocket rippling -Changed : Can now change GBUs/APKWS laser codes and rocket pods modes with engine hot Apologies for the inconvenience. Cheers, Alpha Juliet

WARNING : The 2015 date is mentioned as a reference to the documents used to build the authorised loadouts. No load is tied to a particular date in the DCS mission editor other than Eagle Dynamics already enforced dates. -Added AIM-9L (not on the USMC authorised loadouts for 2015-ish N/A, added because compatibility is known) for station 1,2,6,7 (as for the aim-9M) -Added 19 rocket pods (station 2,3,5,6) (not on the USMC authorised loadouts for 2015-ish N/A, added because compatibility is known), as a legacy from AV-8A and AV-8C, and day attack variants, and to roleplay british Harrier II's CRV-7 rockets. -Changed the GBU-12 500lb Paveway II loadouts according to the USMC authorised loadouts for 2015-ish N/A: -2xGBU-12 on D/ITER on cheek stations only are only allowed on stations 2/6. -2xGBU-12 on D/ITER on chin and cheek stations are not authorized. -3xGBU-12 on D/ITER are not authorized. -No loads are allowed on stations 1/7 if GBU-12 are mounted on D/ITER (double racking GBU-12s means no sidewinders!) -2xGBU-12 on D/ITER is authorized on stations 2/6 with tanks on stations 3/5 -GBU-12 mounting on stations 1/7 is not authorised according to the USMC authorised loadouts for 2015 N/A, but we let that possibility in to roleplay british Harriers (and these stations are known to accept dumb bombs, and the GBU-12 is authorised there on british Harrier II's. The loading of PWII kits is probably not authorised on 1/7 in the USMC pubs because it was not tested either due to lack of funding and/or need for it) -Changed the GBU-38 and GBU-54 500lb JDAMs loadouts according to the USMC authorised loadouts for 2015-ish N/A: -FYI : The JDAMs can only be triple racked on BRU-70 D/ITER triple racks. In DCS, only the BRU-42 ITER (non digital) rack 3D model is available. However, we simulate the use of BRU-70 to enable triple racking JDAMs, which are an important loadout for modern AV8B N/As. -2xJDAM on D/ITER is authorized on stations 3/5 only in a chin and cheek configuration (D/ITER mounting location closest to aircraft is empty) -2xJDAM and 3xJDAM on D/ITER is authorized on stations 2/6 with either inboard or outboard station full. -2xJDAM and 3xJDAM on D/ITER is authorized on stations 2/6 with tanks on stations 3/5. -Changed Fuel tanks loadouts according to the USMC authorised loadouts for 2015-ish N/A: -D/ITER authorized directly near fuel tanks -Bombs are not authorized on stations 1/7 with tanks on stations 2/6. -AIM-9 is authorized on stations 1/7 with tanks on stations 2/6. -Changed ITER 500lbs with bombs loadouts restrictions according to the USMC authorised loadouts for 2015-ish N/A: -On station 2 and 6, if the outermost cheek station of a D/ITER (BRU-42 or 70) is full, only bombs with regular fin kits (so no GBU-12) can be mounted on station 1 and 7 (meaning no sidewinder with a full triple rack)

I have reinstalled the mod and it works perfectly.

Would be very nice if a few things could be added to the kneeboard now that we have the first semi complex version : Kneeboard adjustable GBU codes (in line with other modules like AV8, M2000 etc.) Starting position listed on kneeboard for ground align. Would also be cool if, like in the M2000, the tanker tells you how much fuel it has transferred, perhaps also with the total once it tells you to disconnect. Presets for the radio being listed on the sightblock as it very clearly should would be very nice indeed as well, especially for SRS MP use and such.

Afaik the info we have says it's basically the USN AIM-9 variants from the AIM-9D onwards that it carried. But adding them as a 3rd party doesn't really make sense but if they're added by ED we might as well imo. Afaik the "complete" list would be the AIM-9D, AIM-9G, AIM-9H, AIM-9L and AIM-9M.

I feel sorry for HB for all the work they've put into the Aim54, which nails the studies done by NASA on the AIM54 flight envelope, they've put a lot of painstaking effort into recreating the F14's radar, but they have to suffer the Very painful performance of the missile due to guidance issues, which is centralized in the hands of ED and out of its reach. Im done with this missile.

I sketched up what this changes for Oculus Link users; as for how to use it, mbucchia's comment covers everything on a fresh install; mods/past optimizations can make things *much* more complicated. Virtual Desktop users must use SteamVR or switch to Link/Airlink.

That's an unsat right there in fuel management

Who would have thought the biggest item in this patch had no mention and was forgot about (OpenXR) and didn't work very well, hopefully a patch will fix the use of MR very soon as its now unplayable in VR with it off.

So this is a thread about not finding the manual that changed to why the products manual aren't in the same place as the purchased modules and eventually ending up in some casual moaning about how much they are advertised to the surface. The part that irks me is when folks don't look and make the assumptions based on what they could see without looking first, then backtrack to find anything else to moan at to cover the fact they were in error and should not depart from that path with a simple "Ignore me, i found it, thanks for your help". Having written manuals, and being a techical writer with access to the analytics that show who reads them, I know exactly where the problem is. So when people say that ED needs a good <expletive> manual, I disagree. With evidence.

Hmm, the command line options works here. I even got the vrperfkit working. Just the fact that turning reprojection on completely breaks DCS now shows you how little attention and testing was involved.

What is strange and incomprehensible to me is the fact that there was no official information about it, not even in the changelog. The change is huge and requires some procedure for DCS to work again. From what people are reporting here, the problem is Oculus and Pimax, which has now started requiring SteamVR, while WMR and Reverb owners should now use OpenXR (forced by a dll change). This causes a lot of frustration as some DCS stops starting, freezing when loading missions (while loading map), or slows down to menu to slides show. On the other hand, for people with Pimax stopped working reprojection (perhaps also people with Oculus). For me, on WMR and OpenXR, reprojection works without a problem but not from the beginning. This causes a lot of frustration and the change should be officially announced with instructions on what to do. I spent an hour or more wondering what was going on (of course like most I thought the patch broke my DCS due no any info about changes for VR users). I repaired the DCS and finally got to the options in SteamVR (only this is required: settings > advanced options (hide tab) > deafult setting "set steamVR as OpenXR runtime") and it gave me a solution to make DCS work properly with OpenXR now. But this requires instructions on how to proceed, not making such a final change without even mentioning it in the changelog. Unfortunately, in this case, ED presented itself as an unprofessional company, suddenly introducing such a significant change without any communication, prior notification and providing a solution. Again, it turns out that VR users are basically omitted in thorough tests and diagnosis . It wasn't a nice move.

I think it should be a compromise: Real life historical liveries should be downloaded with the module - when fictional ones should be optional, selectable in module options, man could skip them if he wants to i.e. save space.

Testing is going on right now. Most likely it wont require an update but rather just a new updater. I just tested the initial install and you are able to install with selected maps or no maps, same is going for the server install. We should be seeing it soon.

I'll give you some dos and don'ts. Viper wins acceleration from 300-400 knots, so you really want to use that range unless winning the rate fight is easy. Sure the Viper accelerates great above that but so do most other aircraft. The Viper is very powerful when the pitch is a little below the horizon, probably 5-20 degrees down. Turning in that range is called a slice and it is a very powerful maneuver for the Viper. Unloading to under 1G ASAP (stick forward) with the nose 5-20 degrees under the horizon accelerates you like crazy. 10 degrees down and 0.5 G at 300 knots will get you to 400knots in a couple seconds. This is the check and extend and is very powerful for the Viper. This maneuver is mostly about reducing the induced drag by reducing AoA so it is less effective above about 400. Very good at 300 though. Don't turn with the nose above the horizon unless you need to slow down to make turning room. This is a high yo-yo and a very common maneuver for the Viper. A typical error is to bring the nose too far above the horizon causing undue speed loss. As long as you finish this maneuver above 300 knots with the nose below the horizon then you can check and extend to get back your speed. The usual thing that happens after a hi yo-yo in the Viper is a low yo-yo (acceleration maneuver). Out of plane maneuvering is typical for energy fighters like the Viper. If you want to go over the top, do it EXACTLY vertically. Angles fighters like the Hornet and Eagle won't follow you unless they have energy on you, in which case you should have done a check and extend first. Do not accelerate while going vertically but try to sustain your speed as long as possible. In the vertical, roll to whatever angle you want against the target in their turn (aim for a point above and behind them). Make sure you account for enough radius in the turning circle from the target because you are going to come down on them hard and fast and don't want to waste speed trying to get turning room on them. In other words, make sure you don't end up going too fast to turn in behind them. 250 at the apex is what you're aiming for and probably 230 knots at the apex would be the minimum. Much slower than that and you should have started the over the top faster or spent less time in the vertical. (The Viper typically loses pointing straight up vs things with two engines). This sets you up for a check and extend as your nose falls 5-20 degrees below the horizon. Don't go too fast though, else you will waste altitude. 300-330 is plenty fast here and is the minimum turn radius for the Viper so it will preserve your altitude as you pull through the vertical and away from the earth. You have the option to check and extend again as you're coming out of the loop 5-20 degrees below the horizon. If you are going, for example, 450 knots and you want to do an instantaneous turn into the targets turn circle, bleed off speed at a rate that will leave you at around 330 when you are closest to them. (330 is the minimum radius turn speed for the Viper.) When coming close to the target SUSTAIN 330 knots to get behind, even if the target begins to extend away in his turn circle (your line of sight is moving up your canopy). As long as you are directly behind the target spatially (low aspect angle), the increasing HCA (Heading Course Angle, aka angle off) isn't a big deal because you can just check and extend to a lag pursuit. Practice maintaining full pitch deflection at 330 with a really deep slice but be careful not to let the nose get too low, it takes a lot of energy and time to get back up. A split-s is a good maneuver for the Viper at 330 (minimum turn radius). Have a nice check and extend before you come out of it. You will notice the Viper is very powerful 5-20 degrees below the horizon but most angle fighters like to climb in an oblique maneuver (climbing turn). Don't follow them into this as you will eventually lose. It is best to allow a vertical separation. A quick check and extend can get you over 500 knots fast while they're still at corner speed and you can do a hi yo-yo or even an over the top to get back on them, with energy. This might surprise them because they think they're beating you due to the expanding vertical distance and your check and extends are gaining them angles. If they're inexperienced they are probably getting too slow because it looks to them like they're beating you and they get excited and start pulling too many Gs. For an IR fight you do want to get into a 1 circle (I prefer the term nose to nose) but get out of the flat scissors asap by converting it to a rolling scissors. The airplane at the top is going slowest and the airplane at the bottom is going fastest and you want to get behind them. I'll let you figure that one out but don't forget about check and extend. If the target gets an angle on you pop flares and disengage the afterburner even before they Fox2 you. Hopefully you are going well over 400+ knots at that point. I think this covers all the Viper's most obvious strengths and weaknesses that I've noticed. Obviously do the don'ts if you have energy on the target but you might be surprised at how much doing the don'ts will ruin your energy management. I didn't really talk about aspect angle but you should be able to work it out with the info I've given. BTW, turn circle is the geometry of an aircraft's sustained turn and turning room is the ability to turn into their turn circle (get behind them).

Developers for a start... It's also a great way of making sure aircraft take way longer to develop and research, or even ensure that they don't get finished at all. Again - we already have enough problems getting stuff wholly constrained to the current, narrow scope of some aircraft, without needing to add any more. And it gets worse when you consider items that fit within said scope, but are otherwise not planned or removed from the planned features.

wonder where you got that information, I have never seen ED behaving as you say … please provide actual evidence.

Ok now since I can tell what APR39 speaks - I`ve noticed it always says "SA SA UNKNOWN" After some poking in scripts i`ve noticed function getSAMType(samData) local samType if samData.unit_type_sym:get() == "a8" then ... when it should check for 8a made a quick fix for that part and following SAM types and now it speaks correctly. Attaching fixed script APR39_typefix.7z

No, no. That is not the case. The Ropucha mod was based on an unused ED model that's been part of the DCS installation for some time (it was removed in later versions though). By some unknown reason ED decided at this point to update the old (unused) 3D model with correct connectors and implement it in game. Unfortunately they don't seem to make use of the front hatch for deployment of vehicles. I made it quite clear in my readme's that the 3D model used in my mod was EDs.

RAZBAM F-15E Twitter

Wut?

The Mirage F1 Flight Manual.pdf has a section at the very end covering the changes for the EE version.

Hi @St4RgAz3R I watched your track and observed that you are using a vehicle at the end of the runway opposite to your starting point. That's is a pretty valid boresight target, but it's at approx. 1.20nm. That may seem enough to boresight, however, remember that if you pick close targets to aim, like aerodrome off ground items such as antennas or even scenery objects as in this case, there's a slight chance ground boresight alignment becomes offset due to parallax. When I took over your track, that's what I observed, a parallax induced error that's not at that far off, but is noticeable. In combat, targets are usually more than 3 miles away, so it's advised that you pick farther targets to align. I did just that by taxiing to the left and picking on of those houses in the hills at about 2nm, still not optimal, but the alignment was flawless. We will continue to monitor the boresight alignment and may tweak it in the future if necessary. But for now, we believe this is accurate.

Precisely. Using the tgt size switch for "stealth" is a pure DCS-ism. IRL it defines basically the range at which a certain type of target, small, normal, or large is most likely to be seen by the missile. Misjudging that will have the missile not see the target properly, which goes both ways. Set a bomber sized target to small, and it won't find it. Set a fighter sized target to large, and it won't find it. But this is beyond the scope of missile seekerhead simulation necessary for a consumer sim.

Thanks. Can you also check with the dev team if there is a way to disable usage of XR_VARJO_quad_views for Varjo users, via a command-line argument for example? That's an atypical mode and it is breaking some of the mods out there. Cc @zildac Also, apps should always check for view configuration availability via xrEnumerateViewConfigurations(). That doesn't seem to be the case here and DCS seems to activate XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO regardless of whether it is enumerated, as long as XR_VARJO_quad_views is available from the runtime. This is not a conformant behavior when using OpenXR.

I spent all afternoon thinking the problem was my computer when DCS kept crashing in the menu or the mission load screen. I went through reversing a whole lot of changes I made to my setup and even did a windows restore...of course that was all pointless and a waste of time because as you've all described above the issue was the update. I mean, it's great and all that they've integrated WMR headsets but some heads up would've been nice and even some info to let us know to turn off Motion Reprojection to avoid the crashing. With that said though, I cannot fly anymore without reprojection. The stuttering is too much on my system. If I had advance warning I would not have updated... Anyway, hope they'll implement reprojection soon but I have my doubts as they've taken this long to get basic WMR integration. I will hold of on any new module purchases or pre-orders until then. Honestly, DCS was working fine before this update. I had no issues copying over the dll file after an update in the past. Would have much preferred that over the state it's in now...

Eagle Dynamics devs, Thanks for the OpenXR support but you should have added a callout in the release notes - and at the very top, as it was a major change for Steam users I found that I need to launch DCS directly, not from Steam, for things to work, and if I launch anything that triggers SteamVR (like VRK) then DCS shuts down For folks using VRK - check on their Discord channel and install version 2.0 builds (in Beta) so you can have the kneeboard in VR DCS Open Beta 2.8.2.35632

Waiting ED implement the WW2 damage model on modern aircrafts with pilot moel.

It seems that I'm not the only one downloading the beta just for S&A...hope it's a success for you RS.

Dear gentlemen (and perhaps ladies), I am trying to build an F14 simpit for VR as well. It should complete the setup for my DIY G-Seat in the end. So long story short, I tried to get into CAD, 3d printing, metal amd wood-workand all the rest tbats needed. I really enjoy reading about your progress. At the same time I know, that my pit willnever reach the level of Mumbles, LAsooner or Gunslinger (what a genius..) Anyway, I did some basic work for the cockpit and I wanted to share my experience and ideas so far, if needed. As I could not find a suitable ACM panel and an emergency wing sweep with the push/pull,I designed it by myself. Please take into account, that these things are still prototypes till the pit is alive and, for example, the size of the lever is not final! I am trying to design the pit with its panels and the seat to a level, that all of it comes together and is usable in VR. Further more, my pit should mainly be reflecting the F14, but also house a collective for helicopters and MFDs for other, more modern planes. I will share my CAD files and ideas for the construction as the project comes alive. Cheerio, Ragnaroek

I ran BeyondCompare (a diff tool) on my 2.7 install and compared it to my 2.8 install and looked for differences in the A-10C_2 files between the two versions. From the install folder, the following script was changed in 2.8 - DCSWorld\Mods\aircraft\A-10C_2\Cockpit\Scripts\MFCD\indicator\BAKE\page.lua The change was to enable SRGB on the MFDs. I have commented on the lines that were added with 2.8. picture.input_space_SRGB is the culprit. Removing the line will resolve the problem. Why was SRGB set at the MFD base? In all other aircraft it is only set at a weapon or system level, such as TGP, SLAM, MAV, FLIR, PNVS and TADS. Although for the latter two it's commented out (disabled) SetScale(1) function addPicture(left) local verts = {{-1, 1}, { 1, 1}, { 1,-1}, {-1,-1}} local inds = {0, 1, 2, 0, 2, 3} local hud_only_background = CreateElement "ceMeshPoly" hud_only_background.material = MakeMaterial("",{0,0,0,255}) hud_only_background.vertices = verts hud_only_background.indices = inds hud_only_background.additive_alpha = false hud_only_background.controllers = {{"render_purpose",1,2,3}} Add(hud_only_background) local picture = CreateElement "ceTexPoly" picture.material = MakeMaterial("ccMFCD_Bake_SRC",{255,255,255,255}) picture.vertices = verts picture.indices = inds picture.input_space_SRGB = true -- Added in 2.8, remove to fix the issue picture.additive_alpha = true if left then picture.tex_coords = {{0, 0},{0.5, 0},{0.5,1},{0, 1}} else picture.tex_coords = {{0.5, 0},{1, 0},{1,1} ,{0.5, 1}} end picture.controllers = {{"display_backlight"}, --[[Added with 2.8, doesn't contribute to the issue--]] {"render_purpose",0}} Add(picture) --[[ picture2 variable and logic added with 2.8. Does not contribute to the issue. Removing this has no noticeable difference. Is it serving a purpose? --]] local picture2 = Copy(picture) picture2.controllers = {{"display_backlight"}} picture2.parent_element = hud_only_background.name picture2.input_space_SRGB = false Add(picture2) end If this isn't enough evidence that the issue was introduced with 2.8 then I have absolutely no idea where to go next with this bug report. Furthermore, if this issue isn't going to be fixed then at least don't make it any worse. At the very least I'd like to be able to use OvGME to fix this myself by patching over this file. Before and After pictures.

Quite. This is probably the most impacting thing in the patch for VR users and snuck in without a mention!

Would you kindly include things like that in the changelog next time? Thank you.

Baltic, great campaign. Hey- just to clarify, Fahrenheit is used for sea surface temperature because that is what the national data buoy center uses. Every squadron has a slightly different SOP, but when operating in warning areas over the ocean or any international waters with buoy data, we have to check sea surface temperatures. https://www.ndbc.noaa.gov/ Basically, when windchill is below a certain temp and water temps are below 50s in Fahrenheit, we are required to wear exposure suits. That way we have a chance of surviving post ejection based on SAR asset recovery times. FYI- I am a former Tomcat RIO, still flying as a reservist. Currently attached to NAWDC. FYI x2 - we all HATE these suits.