Lennykka

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.