ColinM9991

In the changelog they mentioned that the ARC-210 will release in the Feb update. The LUA files are in place so I assume it's just a case of testing further and switching the model in on the cockpit.

Just peeking through the LUA files. It's interesting you say that the HUD brightness has been fixed. I'm not familiar with this issue, but I can't see any changes with regards to hud brightness. In the following screenshot you can see a diff tool. On the left is 2.7, on the right is 2.8. There have been no changes to Cockpit\Scripts\HUD. The only changes are the bizarre update to the MFCDs to use SRGB, for whatever reason, the the inclusion of the ARC-210 LUA scripts, and also the removal of LockOn_Options.flight.easy_radar support (Arcade mode) - which I don't quite understand enough to know if this is intentional.

I'll apologize as I spoke too soon - I have a habit of doing that, I'm sure some have noticed. There are some issues depending on the headset. Mbucchia, a Microsoft developer who worked/works on OpenXR, appears to be offering his assistance on the matter. As a workaround, in themeantime, you should still be able to use OpenComposite with --force_steamVR

Ah, okay - excellent. I was going to do a diff to see if I needed to post anything here to help your case. Not sure if you've seen, but thankfully I did find the root cause for the MFCDs being darker.

Is the issue that MFDs aren't bright while the hud is, or that the hud is brighter than it normally is/was?

Native support for OpenXR is a general quality of life improvement for non SteamVR users which resolves issues such as the epilepsy inducing server browser. Those using OpenComposite won't notice much of a difference, since we've been use to the lack of in-game stuttering for some time, but it does mean that any DCS update won't prevent players from using OpenXR as it is now baked in. Not all QoL updates are in the form of performance boosts.

Oh okay. Is this not one of those times? To have native support for OpenXR?

One more thought, excuse the spam, is that it could be related to these bug reports, since this affects both the A-10C and A-10C_II modules as they share files in a lot of areas.

From that perspective I agree. Using the former approach, whereby SRGB is assigned on a page by page basis, is simply an inheritance chain which can become cumbersome to maintain. The only caveat is it's now inconsistent with the approach that all other modules are taking with regards to SRGB. It also isn't just affecting the video on the page, which wouldn't be as much of a problem as we can see in other modules, such as the MAV page in the F-16 where all text is perfectly readable without extra zoom. I did also consider a special option. I could even implement one myself as a proof of concept where a variable could be read from autoexec.cfg. It depends on the use case for SRGB though and why it is that ED want it enabled for this particular module over every other. The only reason I could possibly think of is the ARC-210 radio and whether that also inherits properties from MFCD\indicator\BAKE\page.lua. Otherwise all that we can do, at this point, is to wait and see what ED say about the change and why it's necessary. As mentioned previously, I now know what the issue is so I can just patch it out myself using OvGME, if the final decision is that it will remain as it currently is.

That's all at the risk of making it harder to see certain phrases, characters, symbols and so on. Especially in VR. As this wasn't mentioned in the changelogs and there has been no explanation so far, it looks more like an unexpected change. To my point above, the A-10C and A-10C_II modules have both had SRGB applied to the MFCDs in their entirety which has caused a degradation in visibility. No other module does this. Why has this been applied at an MFCD level rather than a weapon or sensor specific level, such as TGP or MAV pages? This is how it's done on all other modules so that, when you choose a specific page like TGP, the SRGB space is applied then. You can see this for yourself by searching for input_space_SRGB in Installation - Mods - Aircraft directory, specify a file filter for *.lua.

@BIGNEWYApologies for pinging you directly. Please see my message above. It should contain all you need to see that this is an issue with A-10C_2\Cockpit\Scripts\MFCD\indicator\BAKE\page.lua

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.

In terms of the mission, I created a test mission via the Editor that spawns you in an A-10C II at a fixed altitude. This was used for screenshots on both 2.7 & 2.8 back when this issue was originally introduced. Also, it has just occurred to me that it's possibly worth me updating the main post to include a list of tried and tested steps. So far, the following steps have been performed as an attempt to resolve the issue. None have yielded a successful result: Repairing the game Deleting the DCS directory from Saved Games, to start with a clean slate Deleting FXO and Metashaders (I perform this after every update, naturally) Tested on 2.7 and 2.8 with no graphical or setting changes, to demonstrate the issue being present only in 2.8 and onwards. Adjusted Resolution of Cockpit Displays to various values Adjusted brightness values as you've mentioned above. Several other users have provided their results in this thread too, the displays can't be returned to their original 2.7 brightness. Haven't changed any Nvidia Control Panel settings and I'm loath to do so as the A-10CII is the only aircraft with this issue. So I'm of the opinion that this isn't related to anything external of DCS, since none of that has changed.

I have prescription lenses mainly for my left eye. However, this issue simply isn't there in 2.7. It has only become a problem since 2.8. I run a fixed install of 2.7 where I can start the game up, hop in the A-10C II and notice a clear difference in the quality of the text. My eyesight can't fluctuate that wildly between two versions of the same game Take these as an example. notice, in the 2.8 picture, how hard it is to see the decimal point on the left MFD next to OSB 8 (SLEW 5.0)? Now look at that same decimal point in the 2.7 picture. 2.7: https://forum.dcs.world/uploads/monthly_2022_10/2.7_4.jpg.1716526e94d50661473ca198de7f9550.jpg 2.8: https://forum.dcs.world/uploads/monthly_2022_10/2.8_4.jpg.0af7022994c0ed099a0d2c1acfdab6ec.jpg

I've personally tried this - not sure about anybody else, on both 2.7 & 2.8. This was one of the first things suggested in Discord back in October. Unfortunately it doesn't solve the issue. The only working I've found, for now, is to bind VR Spyglass Zoom and use this when viewing the MFDs.

Pinged BN on Discord. BN is unable to reproduce, though I don't know the test conditions and depth of testing. I did mention that everybody else here is seeing the issue beside him. Will see how it goes. As mentioned before, it's disheartening to see a bug be introduced in a non-EA module, especially when said bug isn't given the time of day and is a big visibility issue for VR. Although I appreciate this is a low-priority issue given it doesn't affect the usability of the module.

Any updates?

Wrong forum section

Wrong forum section

I had similar issues with the 5-way hat with rotary dial as what @Readyis describing but I've gotten used to it over the past year of usage and now I'm able to push aft or fwd without activating any other buttons. The quality of the hats isn't great it seems all 4+ way hats suffer from the same issue. Still, one day there'll be a better product on the market.

Updated my quote. In terms of the disadvantage, if it were a configurable option then that would be down to the user to accept the consequences of enabling this. Maybe another option is to allow better in-game configuration of the dots as currently that can only be done by manipulating some LUA files.

Syria and Sinai are made by two different 3rd party developers. It won't be possible to merge together as a result of this as it steps on the toes of both teams.

The solution here, really, is for a smart-scaling solution to be implemented (which some other combat flight sims do), maybe as a difficulty option, while being done in such a way that server admins can override a players choice to ensure all players conform to their servers standard. That way, casual or PvE servers can allow smart scaling whereas PvP servers can disable it. Every time smart-scaling is suggested you get the "blowhards" who try to dictate how others should play the game. The option should be there and it should be configurable.

Mods, this is an easy but recurring mistake that people make. Is it worth moving the following section to the top of this subforum under 2.8? Or maybe consolidate the two. "DCS World Core Features" is the same as "DCS: Wish List" null

I agree. I work in the industry and it irritates me when excuses are made for poor quality. However, considering this issue has been here since the dawn of time, I think it's better to also temper your expectations on this being resolved.