Actium

Unfortunately, DCS 2.9.15.9408 just broke the a_do_script() return value pass-thru. Thus, code run in the *a_do_script environment will always yield an empty string as the result, until the issue is fixed by ED. I sincerely hope a fix will come quickly, so I won't have to bring back the previous, cumbersome workaround, which used a temporary file to pass along the serialized return value.

@Flappie I can confirm that the fix presumably broke the underlying scripting feature entirely. Removed the solution mark. @MarcosR I took the liberty to create a separate bug report for the issue you discovered, as it is kinda off topic here:

DCS 2.9.13.6818 introduced return value pass-thru for a_do_script() and a_do_file(): This worked up to and including 2.9.14.8394. However, DCS 2.9.15.9408 fixed a segfault within that function: Unfortunately, now the return value pass-thru does not work any more. Presumably a regression introduced by above mentioned fix. Steps to reproduce: Run the following code in the hooks (gui) scripting environment, e.g., using my WebConsole.lua: return {net.dostring_in("mission", "return a_do_script('return 42')")} Since 2.9.15.9408, the return value is: ["", true] However, the return value should be: ["42", true] This issue was first reported here by @MarcosR. P.S.: @ED Please implement proper unit testing in your CI/CD pipeline! The described regression seems like a bug that could have been easily caught by a very simple unit test.

Unofficial: https://wiki.hoggitworld.com/view/Running_a_Server#AutoExec.cfg Dunno. But start.exe has the /affinity parameter that you could use for that. Works similarly with PowerShell.

I'd keep that system air gapped or better yet, scrap it. Windows Server 2008 has been without security updates for several years now, unless you're on Premium Assurance.

Exactly. I'd consider it a no-brainer to fix an issue that'll boot all clients and brick all servers if the master server takes a break. Good point. But still shouldn't be a problem to track these. So that's once a month on average. I'd call that quite often. Too often to forcibly terminate all currently logged in sessions, IMHO.

Universal, straightforward solution: If the master server responds 401 – for whatever reason, e.g., an expired token – the client (or dedicated server) should simply try to log in again in the background (no interaction required), instead of terminating itself. The regular 3 day grace period should start automatically (i.e., no popups that need manual acknowledgment). Only after it expires without ever reaching the master server again, the client (or dedicated server) may terminate itself. The grace period should reset after successful (re-)login with the master server. The current situation where when the network goes down on either end, all affected clients (or dedicated servers) will terminate themselves, results in a terrible user experience, which should IMHO be of utmost concern. Good user experience, leads to customers willing to spend money on the product, which is presumably the primary revenue source. An expired session token, which could simply be renewed by logging in automatically in the background, as suggested above, is no justification to unceremoniously terminate the game. Irrelevant wrt. above suggested solution, but just for the sake of argument: Why not? A session token should take no more database space than a properly salted and hashed password. I see no technical difference between keeping session tokens for up to 30 minutes (should be in non-volatile memory, anyway, for the sake of master server crash resilience) or retaining the most recent session token for each account, indefinitely.

Yeah. Nothing wrong with your computer, just the ED master server that took a nap.

Updated the first post. The following issue also results in a dedicated server bricked by a popup that must be manually acknowledged:

You do need to install the terrains on the dedicated server using the updater, as detailed here.

@Toumal Short of resorting to sslplit, having a look at the communication with the master server may shed some light on the communication with the master server. I ran the tcpdump for the last couple of days to see whether anything stands out (run as root, adjust eth0 as necessary): tcpdump -ni eth0 "host 185.195.197.4" Already found out the master server took a nap for half an hour shortly after midnight UTC. That resulted in symptoms very similar to what you describe. Maybe worth a shot to run tcpdump and compare its output and the dcs.log to what I posted here.

This occurrence is actually not related to the previous DNS issue. The master server went down for half an hour shortly after midnight UTC. Unfortunately, DCS has a bug/feature that will result in all clients and servers terminating once the master server comes back up:

The master server was down for half an hour shortly after midnight UTC. That took down all clients and dedicated servers. I've reported the issue here a month ago:

Takes down all clients and servers. Reported this a month ago and it has been wishlisted:

Master server was down unannounced this morning for ~29 minutes from 00:02Z to 00:31Z. See attached dcs.log excerpt and associated tcpdump.log. As described above, my dedicated server decided to die only after the master server came back up: 00:33:57 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused 00:34:12 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused 00:34:27 hostname dcs-watchdog.py[794795]: No response from server: [Errno 111] Connection refused 00:34:27 hostname dcs-watchdog.py[794795]: Terminating after 3 missed responses. 00:34:27 hostname systemd[1395]: Stopping dcs-server@server1.service - DCS Dedicated Server... 00:34:28 hostname sh[804672]: Close message sent to top-level windows of process with PID 19873904. 00:34:30 hostname systemd[1395]: Stopped dcs-server@server1.service - DCS Dedicated Server. 00:34:30 hostname systemd[1395]: Started dcs-server@server1.service - DCS Dedicated Server. 00:34:30 hostname systemd[1395]: Started dcs-watchdog@server1.service - DCS Dedicated Server Watchdog. Same happened to all dedicated servers on all discords I checked (4YA, TDCS, DFA/Grayflag) as well as to presumably all clients [1, 2, 3, 4]. @BIGNEWY Bringing this to your attention again. This issue takes down all clients and servers absolutely unnecessarily. This is not a nice-to-have wishlist item, but an undeniably serious bug that affects all players and server admins. It is exacerbated on dedicated servers, by requiring manual acknowledgment of above Login session has expired error popup (also see here). This prevents most automatic crash recovery scripts from restarting the servers, because the server process is blocked on the popup message and does not crash/exit. The process terminates after acknowledging the popup.

From my experience, the mission size has only limited impact on the dedicated server RAM usage. Primary factor appears to be the terrain, because the dedicated server loads all or most of it into RAM when starting. Additionally, when running multiple dedicated server instances on the same terrain, the file mappings that DCS partially relies on may result in memory being shared between processes. I don't know how Windows does the memory accounting in that case, but I could image that the memory is only accounted to the first process. Take this with a grain of salt, I use Linux, so I'm not familiar with Windows memory management.

@CassieGiang Specs look good, however you may need a 2TB SSD to install all terrains, even if just for future proofing. Otherwise, pretty decent bang for the buck. CPU single-thread performance is key and the 8845HS is only 20% below the 9950X3D, so you're fine. 32 GB should suffice for a single dedicated server, but is already too little for two server instances. Alternatively, you could just run the dedicated server on one of the clients (with 64G RAM or more). Neither the dedicated server nor the client currently max out many CPU cores. Even on an 8-core CPU, there may be no noticeable performance impact when running server and client in parallel. IMHO, worth a try before you spend half a grand.

Are you using a separate server account? AFAIK, no more than 3~5 server instances are allowed to run on the same account. The error codes given in the DCS log are HTTP response status codes, with 401 meaning Unauthorized. I'd be curious about the communication with the master server when that error happens. If you'd like to dig into it, you'd have to resort to sth. like sslsplit to intercept the communication between your dedicated server and the ED master server.

@Arcc You need to run the following in a command prompt to downgrade to a specific DCS version: cd C:\Program Files\DCS World OpenBeta bin\DCS_updater.exe update 2.9.13.6818.2 Adjust the path after cd to your DCS installation folder. Alternatively, download dcs_downgrade_2.9.13.6818.2.bat.zip, unpack it into the DCS installation folder, and run (double click) the .bat file. P.S.: You should never run any .bat files that strangers tell you to run without checking them first (right-click -> edit will show that it contains just above DCS_updater.exe command).

The steps to reproduce from my first posts still trigger the crash on both client and dedicated server. dcs.20250320-214042.crash

This issue has been fixed in DCS 2.9.14.8222. Unserializable values will now be substituted with null. The following example code local t = {a = 1, b = 2, d = 4} t["c"] = t return net.lua2json(t) now returns {"a":1,"d":4,"c":null,"b":2}.

@Flappie While said former issue has been fixed with 2.9.14.8222, above issue is still present.

https://en.wikipedia.org/wiki/Nothing_to_hide_argument

NOTE: This does not apply to you if you first installed after the 20th of March 2025. The login failure bug has been fixed by 2.9.14.8222 (absent from the changelog). The previous workaround (adding 185.195.197.4 api.digitalcombatsimulator.com to etc/hosts) is now a liability that will break the login if the master server ever changes its IP address. I've modified install_dcs.sh to remove the workaround. Either re-run the updated install_dcs.sh or execute the following code from a terminal to undo the workaround: WINE_ETC_HOSTS=${WINEPREFIX:-$HOME/.wine}/drive_c/windows/system32/drivers/etc/hosts if grep -q "^185.195.197.4 api.digitalcombatsimulator.com" $WINE_ETC_HOSTS ; then sed -i "/^185\.195\.197\.4 api\.digitalcombatsimulator\.com/d" $WINE_ETC_HOSTS fi

It is indeed multi-threaded, as it does use multiple threads. However, as I wrote previously, the main thread is the apparent bottleneck, which uses up considerably more CPU cycles than all other threads combined. On a multi-core CPU, that will result in a low overall CPU usage. See this Process Explorer screenshot (right-click DCS_server.exe -> Properties):