Lennykka

Ok, thanks for the info!

Hello, I've been trying to configure Play for Drenullam headset for my mixed reality DCS setup. When I start the flight, I always have some unknown stuff at the top of my VR view, as shown in the attached figure. The top-thingie follows at the same relative position wherever I look. This happens in both tested planes, i.e. F/A-18 and F-16. I'm using Virtual Desktop to connect Play for Dream and the PC. If I do the same test with Quest 3, I don't see the top stuff at all. Is this bug or feature?

Ok, good to hear that you are happy(ish) with your WinWing setup! Mixed reality with WinWing displays is definitively not perfect (yet), but good enough for my liking. Basic principle illustrated in the attached pic below with Quest 3 (I have RTX 4090 based system). I can easily operate the displays through the camera, I would say WinWing displays through mixed reality are at least as good quality as the ones in the virtual cockpit. Unfortunately, quite a lot of tinkering needed to setup the system initially, so far from out-of-the-box solution. But that's part of the fun!

If you are solely using 2D, then I would use SimAppPro to manage the WinWing displays (that's what I did before entering to the wonderful world of VR), and forget using custom-made monitor configuration .lua file. But before worrying about WinWing displays, I would first make sure that your main monitor is working properly. I'm not fully sure what you mean by not getting the main monitor working: is Windows recognizing it? Or is the issue only in DCS? I have unfortunately Finnish Win11 installation, so screenshots from my system may not be that useful. Anyhow, when you right-click on free space on your desktop, you can get to your Screen Settings menu on Win11. I would first disconnect the WinWing displays, and then try to make the main display working fine within Windows and DCS. When the main display works fine, then you should connect the WinWing display next to each other on a USB hub, and again enter the Screen Settings menu in Win11. Then, it should be enough to do all the WinWing screen configurations once on Screen settings: Turn each WinWing MIP display into portrait mode Drag and drop each display on Screen Settings visual configuration so that screen layout corresponds to your Re-Shade filter image. I have the WinWing displays on the right side of my main monitor, as shown above, but the WinWing displays can be dragged also e.g. to be located below the main screen as well. It does not matter where the WinWing displays are on Win11 Screen Settings view, the important thing is that you know what display is what in Windows and in the physical world, and that the screen layout corresponds your Re-Shade filter .png. You can use the Identify Display (or whatever it is called in English) to verify what display is what. Tick the box "Remember display locations" (or something like that), under Multiple Display section on Win11 Screen Settings view. Do the screen mapping on SimAppPro on Game Peripheral Display tab so that all the steps are green. Note that you need to pick the aircraft you are going to use in DCS, but if it is F/A-18 you are only using, then this part is straightforward. I'm using WinWing MIP display for both F/A-18 and F-16. For F-16, I've exported RWR and EHSI to the WinWing middle display with manual monitor config .lua file (but that part was not in the file I shared above). After this, you should be good to go on 2D + WinWing displays.

Yes, I had the same 'WinWing MIP displays messing around after each reboot' issue on my Win11 system, and I was struggling with that quite some time. Eventually, I bumped somewhere here in the forums into this advice: connect the three MIP displays next to each other on the same USB hub. I had doubts for this advice, but it really worked at least for me! I have installed my WinWing MIP displays into Monster Tech's desk mounts (highly recommended!!!) so that I also have 7-port USB 3.0 hub attached to the Monster Tech's MIP desk mount. I only connect the USB hub to my PC with single cable, when turning the office desk into (sort-of) cockpit. On the 7-port USB 3.0 hub, I have MIP displays connected to ports 3, 4 and 5. This way, the display configuration can survive Win11 reboots. To improve MIP displays brightness, I also use ReShade with the proper screen filter image, i.e. re shading thing only affects the MIP displays, and not the other displays. Probably you have got it configured already, but I've used these configurations: Activate only these filters in this order: UIMask_Top [UIMask.fx] Tonemap [Tonemap.fx] Levels [Levels.fx] UIMask_Bottom [UIMask.fx] Levels.fx parameters: Black Point: 16 White Point: 120 Tonemap.fx: Gamma: 0.560 Exposure: -0.100 Saturation, Bleach and Defog on default values (==0.000) In my system, I only use SimAppPro to enable backlight adjustment from DCS aircraft control knobs in the cockpit, but that's all. So, I don't use SimAppPro to configure the MIP displays. In practice, I leave Game Peripheral Display tab into non-complete state, i.e. not all 1 - 8 steps are green (can't check right now where the green states stop, and reds start) Instead of letting SimAppPro to handle the MIP display configurations, I do it manually with my own MyVRSetup.lua script file stored into directory \Users\[username]\Saved games\DCS.openbeta\Config\MonitorSetup, attached: MyVRsetup.lua The contents of that file must match your display configuration on Windows. I've configured my displays like this in Win: -------------------------------- | Main display || L || C || R | | ||dis||dis||dis| | |--------------- ---------------- My main display is of size 2560x1440. [1,1] pixel is on the top left corner. So, the top left corner of Left MIP display ("L dis") is at [2561,1], but since the WinWing MIP display visible part is square with resolution 768x768 (unlike the panel itself, which 1024x768), I need to cut the non-visible part off, so I get top left pixel of Left MIP display at [2561,256], i.e. like this: LEFT_MFCD = { x = 2561; y = 256; width = 768; height = 768; } And same goes for Center and Right displays as well. VR_MIRROR is the display that is visible on your main display when you have VR headset on. I've configured that to the minimum size, because in my own tests bigger you make it more resources it consumes. This might not be the case with VR headset connected with display port cable, but with Virtual Desktop I found the minimum VR_MIRROR size to be better option. On the game itself, I have configured Resolution and Monitors like this: nullOk, long post, but should now cover how to configure WinWing screens to be "VR-ready". Hope this helps!

@SKYWARRIOR, I just checked this thread and noticed your questions few weeks back on mixed reality setup with WinWing gear. I have similar setup myself, and I've managed to make mixed reality to work with Meta Quest 3 and WinWing MIP panels + other panels very well. In my view, Quest 3 passthrough is good enough, it is possible to use and and operate the MIP panels with passthrough functionality. There are bunch of steps to take when configuring the system and needed SW, but once that part is done, using the system is really straightforward. Also, Quest 3 is very stable platform together with Virtual Desktop, works pretty much every single time. If interested, I can provide instructions how to setup similar system. I just received new Play for Dream MR headset, I'm now trying to make that work in my system as well. That project is far from finished, but the same generic approach can also be applied with that. However, PFD is much pickier to Wi-Fi quality and decoding takes more time among other things, so definitively Meta Quest 3 is more polished and easier to work with for MR scenarios. Anyway, let's see how my current PFD project proceeds!

I experienced this issue as well, with the latest available DCS World version 2.9.20.15384. However, I think I did the reporting stuff before being back at WP3/IP (maybe around ~10 nm, or so), so maybe it helps to do the reporting exactly at the WP3/IP point, as indicated by YoYo above. Anyhow, now the mission got stuck after getting the radio message from Ghost: "Weasel 31, Ghost, read you 5 by 5, send it." I'll re-try when I have chance.

I can confirm this behavior. Instant action mission Air refueling for F-16C in Caucasus map (and probably for the Persian Gulf map as well, but tested that very briefly) stopped working with the latest patch (DCS 2.9.17.11733).

Thanks for a great campaign!! So far, everything has worked perfectly, but with the latest update on 19th of June (DCS 2.9.17.11733), I encountered an issue: while taxiing to takeoff, plane #4 / Weasel 74 cannot cross the runway at Rovaniemi airport. Weasel 71 & 72 (and me) proceed to the end of the runway, but due to Weasel 74 stuck next to runway, the flight lead does not proceed to takeoff. Workaround: bypassing Weasel 71 & 72 and taking off as the first plane, I can trigger the others to take off. However, 74 keeps hanging around somewhere and gets seriously late, but is able to catch the flight eventually.

Not sure where I should report this, spent already some time searching forum contents with no increased wisdom. So, with the latest patch, at least F-16C instant action Refueling mission on Caucasus map stopped working: the two F-16s already on refueling tanker keep alternating on fueling with the tanker and seemingly never completing / finishing the refueling. Thus, "chicks on tow" remains as the status. I waited something to trigger the mission to proceed, but at least in 10 - 15 minutes no change to AI plane behavior.

So is the fix for "Failed to get authorization data. Error code is: 502" to wait for undefined amount of time? Or something else?

Just to record a solution for my issue: since SimAppPro started to behave in an undefined way, I wanted to try to do a clean re-install for SimAppPro: Un-install SimAppPro with Windows "Remove app" Remove ..\Users\[username]\AppData\Roaming\SimAppPro directory Remove ..\Users\[username]\AppData\Local\simapppro-updater directory Fresh install of SimAppPro It turned out that this method was good enough to overcome issue on my setup, and now SimAppPro and DCS are working perfectly together! However, it still remains a mystery what caused the issue in the first place, perhaps updated anti-virus program messed up with SimAppPro update, or then just some file got corrupted.

WinWing support suggested to remove %appdata%/SimAppPro/ folder(s) in addition to removal of the application itself for a clean un-install. I removed just in case both ..\Users\[username]\AppData\Roaming\SimAppPro and ..\Users\[username]\AppData\Local\simapppro-updater directories after un-installing SimAppPro app itself. However, SimAppPro still stores configuration data some elsewhere, probably in Windows Registry: it seems there is over one kB of data stored there for SimAppPro. But since it is generally bad idea to manually edit Windows registry, I just left that intact and removed the app plus the above mentioned directories before new re-install.

SimAppPro stopped working properly for me suddenly without any explicit changes to my system, neither for HW nor for SW. After trying everything else I can figure out, I would like to try to remove earlier SimAppPro installation completely on my system. If I use Windows "Remove App" thing, I can see Export.lua contents untouched, including also ..\Saved Games\DCS.openbeta\Scripts\wwt directory + .luas there. As well, Users\[user]\AppData\Roaming has untouched SimAppPro directory there. Further, if I re-install SimAppPro again after "Remove App", SimAppPro reads from somewhere all the old settings. So, does anyone know how to do a complete, clean re-installation of SimAppPro?

Still struggling with this. I contacted WinWing support, and they kindly organized remote debugging session. WinWing engineer tried pretty much the same stuff I've already tested, so no root cause identified. Anyway, after > 100 test runs (start SimAppPro, try "Repair Lua", start DCS, try different order, wait for different amount of times between actions, etc.) I can say this: I can make everything working fine about 1 out of 20 test runs - but completely randomly - with these steps: start SimAppPro, hit "Repair Lua" button, start DCS. However, WinWing UFC + panel lighting ONLY work for the first flight during the same DCS session, on the consecutive flights WinWing loses the link to DCS and lighting + UFC stop working. Since it is possible to make it working in ~5 % test runs, it is not a hardware issue Since lighting and UFC work only randomly, it sounds to me it is timing issue / race condition between some SW components (unknown to me) on some resource (some .lua file?). The issue emerged between two different DCS sessions without doing anything explicit to the setup, neither for HW nor SW. So, either some SW was automatically updated (not WinWing, not DCS) or something got corrupted. I hope WinWing people can come up with some new ideas to resolve the issue.