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.

Good point! Hitting "Repair Lua" button in SimAppPro clears Export.lua file contents, except for WinWing stuff. So, I indeed got Tacview entry removed from Export.lua. Saved Games\DCS.openbeta\Logs\dcs.log shows bunch of lines for TacView, even if the proper configuration is missing from Export.lua. But it seems I always get the line 2025-03-30 17:47:55.135 INFO TACVIEW.DLL (Main): Discarding [[configured_path]\Tacview-20250330-204522-DCS-Persian Gulf FA-18C Aerial Refueling.zip.acmi] (because its duration of 0.00s is shorter than the minimum of 10.00s configured in the options.) in dcs.log, if Export.lua does not contain the proper TacView entry., thus no TacView file generated. Anyway, I should be working with correct directories and files. But what I'm now wondering is that when I start SimAppPro, I can see on "Environment Check" tab that "Program initialization phase" shows all green. But when I start DCS launcher, it seems "2. Game launching phase" and "3. Simulation initialization phase" do not complete successfully (or at least not all entries are green). Should I get all three phases to green?

Tried to remove SimAppPro with Winows remove app functioanlity, and re-installed the latest SimAppPro version. This did not help to fix my issue. I noticed that if I have "Repaired Lua" with SimAppPro button, or manually edited Export.lua contents to this local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') then every time I re-launch SimAppPro, it automatically modifies Export.lua contents to his: local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') I'm not sure if that is related to my issue, but looks like SimAppPro does not recognize existing contents it has created, Updating to the latest SimAppPro version did not have any impact on this behavior, i.e. it was there with the earlier version and it is there with the latest version.

After hitting "Repair Lua" button in SimAppPro, this is the complete contents of Export.lua file in Saved Games\DCS.openbeta\Scripts directory: local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') I have TacView installed, but no references for that in Export.lua, only separate TacviewGameExport.lua file in the same directory. I have not manually touched Export.lua, so not sure what writes stuff there or when. Anyhow, I also checked Export.lua contents while DCS is running, it remains what is listed above. For mixed reality, I use OpenKneeBoard and there seems to be one .lua and .dll in Hooks sub-directory as well. Other than that, clean DCS installation. I tried to update SimAppPro, but that seems to never finish / complete, so perhaps re-isntallation is the best bet.

I have WinWing-based setup with MIP, HOTAS Orion 2 and PTO2 panel. I run my system in Mixed Reality mode with Quesst 3, and I've created my own .lua configuration file for the monitor setup, so that I only use SimAppPro for lighting and UFC control. My system has run perfectly this way for several months, until yesterday. Now, WinWing devices' lighting control with DCS is lost, and UFC displays (few character displays next to the round buttons) only show the initial 'XXXX's. All other functionality works fine, i.e. all the switches and buttons do their thing (I guess over standard USB drivers), and MIP-displays also work fine (over their display driver presumably). I tried few "Fix" buttons within SimAppPro, but with no help. For example, my Export.lua file only contains calls to WinWing's own lua configuration file, so there is not much to fix. Interestingly though, SimAppPro (?) seems to generate double calls for wwt scripts: local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') local wwtlfs=require('lfs') dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua') Anyway, after some testing, I noticed that behavior within DCS is exactly the same as when I don't have SimAppPro running at all. So, somehow DCS stopped recognizing SimAppPro. Any hints how to fix this? Re-install SimAppPro?

First things first: great campaign so far! I'm using the latest non-Steam version of DCS. I've tried to complete the mission 3 multiple times, having always issues with the targeting pod: Maverick tends to acquire different target after Uncaging on the Maverick page compared to what is selected on the targeting pod, either previous or next vehicle on the column typically gets selected. Also, the correct vehicle may get selected, though. This issue seemed to be reported by others as well. When trying to drop the laser-guided bombs, the target point the pod lases is offset ~100 meters from what is selected on the targeting pod. I found similar issue reported on the forum, but I guess on the different plane: https://forum.dcs.world/topic/358383-bizzare-targeting-pod-and-laser-designator-behavior-cannot-designate-slew-guide-bombs-in-slaved-mode/?do=getNewComment I've tried different methods to assign the target: select the target with HMD, set Markpoint, define Offset Aimpoint from existing waypoint, or create new waypoint from the provided coordinates and designate that as the target. End result is always such that the targeting pod targets the correct target (Area Track -> Point Track -> TDC Depress), but the real lasing point is some elsewhere, with few hundred meter random offset. On the HUD, this shows so that the vertical targeting line (ASL) points to the randomly picked target/lasing point, and does not align with the target selected on the targeting pod. Laser code is set correctly, laser is armed, and lasing is done as it should, but the bomb goes to whatever random offset point, not to the selected target on the targeting pod. To overcome this, I've tried to unselect the target and select it again (from waypoint/markpoint designation, TDC depressed again, etc.), go back to NAV and then to A/G mode, master arm to off/on, but with no luck: my precious bombs go to the Finnish forest harmlessly. Is anyone else having similar issues? How to go around it?

Interestingly, MustangSally's tip "Connect your screen usb connectors side by side into the same hub." above was the fix at least for my Win11 setup! Maybe it is related how Windows allocates USB device IDs in the startup...? Anyway, didn't try to debug the issue, I'm just happy that USB cable re-shuffling seemed to fix the issue.

I'm having similar issues with mission 2 as described above. Slight difference for the item 3 was that Smoke flew towards south and keeps circling above sea level at 200 feet. It looks like all missions with AAR are not working properly now, reported issues on the Dominant Fury campaign missions 14 and 15 as well. I guess these issue comes from ED side, hopefully they can provide the fix soon.

Tried both missions 14 and 15 of Raven One: Dominant Fury campaigns with the latest DCS open beta versions from Friday 16th of Aug, 2024. I've tried mission 14 four times, out of which only once the SAR mission was triggered. On the three failed cases, after air refueling I've headed to WP3 Madonna, two times directly and once via WP2. I've tried to buzz around on different altitudes on WP3, but no trigger for the SAR mission. Flying back to the mother on fumes, SAR mission was eventually triggered, but without fuel and 70 nm from WP3, no can do. On mission 15, after performing the first air refueling, my flight (Sledges) does not proceed anywhere, just keeps following the tanker. Other flights go on with the mission seemingly fine. So, there seems to be some triggering issues in both missions, perhaps ED has made some changes. Nevertheless, great campaign! Thank you, Baltic Dragon, for putting this and all the other campaigns together! I'm especially waiting for your new Finland campaign, hopefully it will get released in near future.