GeoS72

I've been in a dialog with several members (11 so far) of the NordVPN customer service department. Right now, they recommend disabling the VPN when playing DCS. After dealing with this issue for the past 2 months and providing information along the way, these responses sum up their approach. I bold faced the important part: "Unfortunately, we are experiencing issues with gaming and VOIP services at the moment, which in return cause issues with the services you are trying to access. " "While we are actively working on this, providing a definitive update within the next few months is not realistic given the complexity of the problem." For NordVPN customers & DCS Players, I would encourage you to submit a ticket. The more people to complain about the problem may help escalate the timeline for a solution. Follow the squeaky wheel gets the grease approach. See my screenshot below to easily report the issue. Please be respectful and do expect to be frustrated with their generic "we're currently working on the issue" replies and the number of different people with whom you will dialog.

@sleighzy, I removed XMP from my BIOS settings. Thanks for the tip! I provided a myriad of info to NordVPN and I am waiting for a tech to get back with me. I also had a chat with a WinWing technician. He suspects the port number was closed by the VPN. The port number in particular is 16537. However, that does not explain why SRS and TheWay are also blocked. Break, break: Any moderators, you may merge this thread with the thread provided by silverdevil in the 2nd post.

When I ran my DCS.log file in the ED Discord Log Analyzer, it provided this bit of information in the Errors Tab: (edCore): setClipboardText + 0x3B3 (edCore): Lua::CheckedLoader::loadFile + 0x4F1 (edCore): Lua::CheckedLoader::tryLoadFile + 0x9 (DCS): SW + 0x59C5F3 (DCS): SW + 0x45AA94 I have no idea what this means.

@silverdevil, thanks for the link. I will read through it and also reference it when dealing with NordVPN reps. I'd also like to point out that I have split tunneling enabled for the DCS.exe file in the \bin and \bin-mt folders. Split tunneling is also applied to SRS and TheWay too.

After the mid-March (17 Mar), I started to experience a CTD moments before DCS would load into a mission. This affects single player and multiplayer missions. See the attached DCS crash log. This occurs when using my VPN service; which rhymes with BoardVPN. When VPN is ON, the game would crash during the "Export Start" phase of the loading screen (Single Player or Multiplayer). Part of the problem rests with a script in my Export.lua file. Specifically, the game crashes to desktop when the Export.lua file tries to run the script: "dofile(wwtlfs.writedir()..'Scripts/wwt/wwtExport.lua')". That script is for my WinWing/SimAppPro HOTAS setup. When I remark out that line, DCS does not crash, even when the VPN is on. Other observations: 1. DCS-SRS and DCS-TheWay applications will not work when the VPN service is on. This is true even when the SimAppPro script is disabled. When the VPN is off, then SRS and TheWay applications work as advertised. 2. The VPN software had an update and the same with Windows 11 during this time. All my video and audio drivers are current too. 3. I contacted both VPN provider and WinWing to troubleshoot this problem. 4. DCS would encounter CTD even before the Mar 19 and Mar 26 updates (DCS 2.9.14.8222 and DCS 2.9.14.8394, respectively). 5. Before 17 March, DCS would run normally when my VPN was on or off. I have 2 workarounds but I would like to find the cause and potentially fix this problem so I may continue to use my VPN service. 1. Remark out the WinWing code in the Export.lua file. 2. Turn off the VPN while playing DCS. Has anyone else experienced this issue? dcs.log-20250401-010302.zip

Hooray! The detailed scoreboard is fixed. Thank you, @Flappie and the other moderators who championed this bug to get attention. @Yuma, the cake is a lie.

Thank you for the note, @Flappie! I look forward to the next core update.

Aside from waiting in excess of 2 minutes for the server to refresh (covered in another bug I submitted), here are some screen shots that I took over the past 10 minutes. The screenshots were taken at key stages of the restart process. 1. Server status prior to selecting Restart button. 2. Restart pressed, server indicates loading the last MIZ file. 3. While loading, the server now shows the 1st MIZ file loading. 4. While waiting ~2 min, I get a Server Not Responding error. 5. After waiting a bit more, the 1st MIZ file is now running; not my desired MIZ file! 6. I had to press the Run button on the desired MIZ file (last one), then waited another 2 min to have it load & run. So, what is being done behind the scene? If it is potentially a server provider issue, then give me some information to bring back to them. Simply finger pointing will not help. Is there someone at ED that I could direct my provider's attention to address this issue? This really became an issue after the last DCS update.

Thanks for the feedback, Flappie! I'll be curious to see how the next update addresses this sound problem.

Here is a message that I received from the automated server reboot. The message was sent to my Discord channel. The restart process automatically occurred at 05:04 EST. This MIZ file (BSGColdWar_025.miz) is at the top of list and is set in the Caucasus map. The MIZ file that was previously running was set in the Persian Gulf map. I manually ran that map at ~00:20 EST (3 Mar 2025). The server should have reloaded my Persian Gulf map when it automatically restarted.

Flappie, Thank you for reporting the issue and asking about an automated server restart. If the server reboots and reloads the DCS server based on time, i.e. every day at 9am then the MIZ file would randomly change.

Bumping the topic for greater visibility and more input from other clients who use multiplayer servers.

I would also like to add that MIZ files are randomly selected after an automated server restart. For the record, shuffle and loop options are NOT selected in my server settings.

I noticed that any time I use the "Reset" server button from the WebGUI, the server would load the first MIZ file in the list instead of loading the last/current MIZ file. Has anyone else seen/experienced this bug?

May the testers have good luck with the potential fix.

Yet another update and no resolution to the detailed scoreboard in MP.

@LorenLuke, Excuse me. I wasn't sure what you meant-setting Master to ARM or STBY. I did reply to your post on 30 Jan though.

@Benom8, Yes, thank you! Changing the LAUNCH parameter to STBY allows the laser codes to be changed. It can also be used to cycle between Pri and Alt laser codes for the missiles. It will "advance" any missile with ALT code to PRI code when cycling STBY to NORM.

Flappie, I use a Fox3MS server and my missions are stored on their NextCloud server. Here are my results: Adding a new mission to the list: 3 - 6 sec Removing a mission from the list: 3 sec Changing a setting, tested with Advanced Settings - Selected "Crash" in Show messages in Chat option: 1:10 min, 1:15 min, and 1:16 min (tested three times), after the restart, it also changed the mission to the first listed mission! It loaded the first listed mission twice. When changing the advanced settings for a second time, it failed to deselect the same Show "Crash" message in the chat room. I had to reset the server for a 3rd time to remove that message option. That equals more time wasted on a server restart. Loading a mission file: 2:13 min & 2:40 min, got a "Server not responding message" Adding a new file via the Add Mission button: 1:24 min. It took this much time for the list to repopulate with a brand new file. Changing the Observer Name: 5 sec

Thank you! If you need a demonstration, then I am available to help.

Hi Flappie, When I say change to a new map, I mean that a new MIZ file is loaded. So, when a new mission is loaded. I have also seen the WebGUI lag when making changes to the server settings. Does that help?

Bumping the thread to garner some attention from the moderators.

Benom8, So change the constraint from NORMAL to MANUAL. Then the code could be changed? And afterwards, switch the constraint back to NORMAL?

Yes, set Master Arm to Stdby in an attempt to change codes. No joy.

I experienced a bug with the OH-58 when firing Hellfire missiles in a multi-crew environment. The problem: After reloading with a fresh set of missiles, the Pri/Alt Laser Codes cannot be changed. Once the user changes laser codes, say, Pri set to C and Alt set to A then these codes cannot be changed. The option is available with Weapon Select Switch-FWD and the OSD Button is pressed with no effect. Basically, the aircraft is forever stuck with the laser code settings once they are changed from the default setting. There is also a problem when switching the Laser Pri/Alt codes on the missiles. The laser priority is difficult to switch; I've had to cycle it at least twice in order to get the Hellfire to fire using the Alt code. Helicopter config: 1. Master Arm switch to Arm or Stdby 2. Configure helo with 4 AGM-114K missiles. 3. Pri code set to C (1666), Alt code set to A (1688). 4. Missiles set to Pri: 2, Missiles set to Alt: 2 5. Constraints: Normal, LOBAL selected 6. Missile would not fire; launch priority codes swapped from Pri to Alt but does not take affect on the first (or second) attempt. See the attached DCS logs and track file in the attached archive. There is also a copy of the MIZ file used to obtain these files. I also included the DCS log from the server as well as the pilot's DCS log. The track file is from the pilot too. OH-58_Hellfire_Test.rar