Actium

It is (DCS fails to resolve api.digitalcombatsimulator.com). ED are working on a proper fix. Changing DNS server typically resolves it. If it doesn't, editing your etc/hosts is another temporary workaround. More details here:

Recently stumbled over the DCS.getConfigValue() function while digging inside DCS' Lua guts. The undocumented function will read values from the "config" Lua environment/state (net.dostring("config", ...)), e.g., values set in autoexec.cfg. As this enables much simpler configuration than setting environment variables, I've modified NoErrPopup.lua to use it. Thus, the optional configuration is now handled via autoexec.cfg. Updated the first post accordingly. Also removed the attachement and linked to the script on my Github account, to facilitate minor updates.

Recently stumbled over the DCS.getConfigValue() function while digging inside DCS' Lua guts. The undocumented function will read values from the "config" Lua environment/state (net.dostring("config", ...)), e.g., values set in autoexec.cfg. As this enables much simpler configuration than setting environment variables, I've modified FPSmon.lua to use it. Thus, the optional configuration is now handled via autoexec.cfg. Updated the first post accordingly. Also removed the attachement and linked to the script on my Github account, to facilitate minor updates.

@Clawhammer Great use of the resource monitor The .miz mission file is presumably fully loaded into memory. I'd be more worried about object models that will only be loaded once new units spawn, terrain sections that will be loaded when units enter the area (like Clawhammer just showed), etc. Opting for an NVMe SSD will give you the peace of mind that you're using the best tool for the job at hand. I've written a small script for server performance monitoring, which will warn you via global chat if the server performance deteriorates. That will at least warn you if the server performance is becoming problematic.

TL;DR: Considering current NVMe SSD prices, everyone recommends against HDD use.

The newest DCS update to 2.9.13.6816 brought a significant change to a_do_script(): This newly introduced return value pass-thru obviates the workaround I had implemented to get return values from a_do_script() via a temporary file. This implies that modification of MissionScripting.lua is no longer necessary. You may remove the modification manually or by repairing DCS via the updater. As a pleasant side-effect, installation is now significantly easier. Drop WebConsole.lua in the Scripts\Hooks folder and you're set. I also improved the description for clarity.

@aterfax: I've figured out how to install DCS without innoextract'ing the updater and how to get SRS up and running. Also set DCS and SRS up as systemd units that support multiple instances. Have a look and give me a shout. I would like to collaborate on this.

TL;DR: Currently experimental git repo of configs and scripts intended to automatically install and manage multiple DCS and SRS server instances on a single headless Linux server using systemd. I've been using the code to run a dedicated DCS server along with an SRS server for a couple of months. It's been smooth sailing from DCS 2.9.9 all the way thru 2.9.14, so I'm releasing this into the public to get some feedback. Please do not hesitate to ask any questions in this thread and also feel encouraged to create issues or pull requests on Github. Features Fully automatic installation and upgrades of DCS and SRS Plug & Play: DCS and SRS are usable immediately after installation Pre-configured with reasonable defaults Auto-starts a default mission (Caucasus with dynamic spawns) Ships with useful helper scripts Minimal overhead: ~200M RAM on Debian 12.9 (kernel + user-space) Built for headless (non-GUI) Linux servers: Does not require a desktop environment (e.g., Gnome, KDE, XFCE, ...) DCS and SRS windows accessible via VNC (serves minimal GUI) Runs Caucasus, Marianas, and Syria on servers with 16G RAM (other terrains unverified) Convenient management of all server processes through systemd user services (systemctl --user start|stop|status dcs-server|srs-server) and automatic restart of failed services (to the extent DCS enables it ...) Supports multiple DCS server instances (DCS_server.exe -w DCS.*) through systemd unit instances Installation Instructions Check the README.md. Screenshot

As of DCS 2.9.13, a_do_script() finally has return value pass-thru: Example code for the control/hooks environment that fetches a string value from the mission scripting environment: return net.dostring_in("mission", [=[ return a_do_script([[ return "42" ]]) ]=]) P.S.: Sorry for necro-posting. As these forum posts are DCS' scripting "documentation", it appeared appropriate to update said docs.

As of DCS 2.9.13, a_do_script() finally has return value pass-thru: Example code for the control/hooks environment that fetches a string value from the mission scripting environment: return net.dostring_in("mission", [=[ return a_do_script([[ return "42" ]]) ]=]) P.S.: Sorry for necro-posting. As these forum posts are DCS' scripting "documentation", it appeared appropriate to update said docs.

Absolutely. My intent was not to push it. Just posted my report here to inform the other players affected by this.

@SKYWARRIOR: Only editing etc/hosts as suggested by OP and explained here by me must be reverted once a fix is out. You can keep using the Google DNS indefinitely without fear of it breaking DCS in the future*. *) Off-topic: There are however pros and cons to using Google DNS. I personally use Quad9 with encryption, as I value privacy over raw performance.

Thanks. I really do consider this a crash-like situation, as the game decides to intentionally terminate itself, for no logical reason whatsoever. While IMHO still entirely unreasonable(!) from a usability and stability perspective, it would have made more sense to terminate when losing the master server connection. However, terminating when regaining the master server connection appears so extremely illogical that it can only be a bug*. Hope the Devs agree *) Even for an always online title, which DCS -- fortunately -- is not, termination after successful reconnection and reauthentification would not make sense, unless its intent were purely punitive in nature.

Absolutely. Exactly for that reason the DCS client should handle that situation gracefully and not just boot people from their game. I've investigated, reproduced, and reported the underlying issue for DCS version 2.9.13.6818. This wishlist item contains additional information when and how it occurs:

TL;DR: The DCS client/server terminates with a "Login session has expired" error popup only when reconnecting to the DCS master server after the connection had been lost for 30+ minutes. No error occurs, if the connection stays lost. This makes no sense and harms user-experience unnecessarily. Technical Details The DCS client* must authenticate with the DCS master server (api.digitalcombatsimulator.com) when starting. As part of a successful authentication, the client will receive a temporary session ID from the master server. The client uses that session ID to periodically check with the master server every ~10 minutes. Clients and master server communicate via encrypted HTTP. The periodic session check is an HTTP POST request to which the master server normally responds with status code 200 (OK). *) Here and subsequently, "client" refers to a client of the master server. This includes the DCS dedicated server, which also performs authentication and periodic session checks with the master server. The master server session cache expires within ~30 minutes: If the master server has not received session checks from a client for ~30 minutes, it will forget the respective session ID. Afterwards, the master server will respond with HTTP status code 401 (Unauthorized) to any session check from a client with an expired session ID. This will be logged in dcs.log as: ERROR ASYNCNET (192): The session has expired (401). Exiting... The affected DCS client will not try to reauthenticate, but instead terminate with a "Login session has expired" error popup. This issue is likely not restricted to re-establishing connection with the master server and HTTP error 401. Other master server-side errors trigger the client-side termination, too. If the master server (or the reverse proxy it resides behind) temporarily responds with other error codes, e.g., 502 Bad Gateway, the client terminates itself, too. While I've not experienced this particular error code myself, it's been reported here. Who is Affected / Why to Fix This All players and servers: If the master server goes down and forgets all session IDs, all clients and servers will be forcibly terminated, too. This has happened on multiple occasions. Either scheduled or repeatedly unscheduled (1, 2, 3, 4). This issue frustrates customers. With the master server being a single point of failure, this presents a possible attack surface. I'll refrain from elaborating on this further to not give random script kiddies any bad ideas. Players with a spotty internet connection (to the master server): Spotty internet connections are hard to debug and even harder to fix. Even if everything else works (e.g., playing DCS in multiplayer, streaming, downloads, etc.), an ISP's route to the single DCS master server may be sufficiently congested to affect the periodic session checks temporarily. Whereas DCS updates/downloads are handled via a globally distributed CDN, there's a only one master server that is located in Europe (ping/traceroute api.digitalcombatsimulator.com and cdn.digitalcombatsimulator.com). Players complaining about this in the forum are typically referred to customer service. A proper fix may pay for itself by less customer service tickets. I'd also expect far more players to be affected than there are reports on the forum (1, 2, 3, 4). Casual single players or mission editors who want to suspend their computer mid-mission to resume another day: Suspending your computer for more than 30 minutes will also result in forced termination. With the DCS save feature not yet capable of resuming complex missions, this is a valid use case for casual DCS players. Workaround (@Affected Players) As the DCS client only terminates after reconnecting to the master server, the termination can be inhibited by preventing the reconnect. Do this at your own risk: Start DCS. Once in the main menu, the mission editor, or on a multiplayer server, inhibit further communication with the master server (api.digitalcombatsimulator.com), e.g., via firewall rules or by adding an invalid IP route with an administrator command prompt: route add 185.195.197.20/32 0.0.0.0 Go about your day, suspend/resume your computer, or connect to multiplayer servers via IP address. The multiplayer server browser will no longer work. After closing DCS, remove the firewall rule or the invalid IP route: route delete 185.195.197.20/32 0.0.0.0 How to Fix This (@ED) This issue could (and should) be addressed both at the client and the master server: The master server session ID cache should not expire prematurely. Using the 72 hours saved authentication grace period for expiring sessions seems reasonable. This fix should be relatively straightforward to implement as a stopgap measure. The client (and dedicated server) should always attempt to reauthenticate with the master server instead of just quitting immediately after a failed session check. Silently start the 72 hour saved authentication grace period once the connection to the master server is lost (or the master server experiences server-side errors, i.e., 500+) and only terminate the client if the master server hasn't been reached within that duration. Reset the grace period once the connection to the master server has been re-established. That should balance between user-experience (which ultimately pays ED salaries) and software piracy concerns. How to Reproduce Start DCS (in Online Mode), open the Mission Editor. Wait a minute. Disconnect DCS from the master server api.digitalcombatsimulator.com (185.195.197.20). Either by disconnecting from the Internet, by using a firewall rule for the aforementioned IP, or by setting a non-existing network route via a command prompt with administrator privileges (route add 185.195.197.20/32 0.0.0.0). Alternatively, you can also just suspend your computer. Keep DCS disconnect from the master server for 30+ minutes (less may suffice, too, but AFAICT it needs to miss more than just one session check). Re-enable the connection to the master server. If you used the route method, delete the invalid route: route delete 185.195.197.20/32 0.0.0.0 Wait for DCS to quit within the next minute or so. Edit: Updated post, added workaround. Original post in below spoiler.

When starting DCS while the master server is unreachable it will fall back to offline mode with the saved authorization from a recent login. However, attempting to switch to online mode from the main menu will toggle the icon and shortly after close the game. According to dcs.log, leaving offline mode succeeded (even with an unplugged Ethernet cable ...) but then the game closes without logging an actual error (excerpt, full log attached): 2025-02-25 07:39:07.480 INFO ASYNCNET (Main): Successfully left the offline mode. 2025-02-25 07:39:07.491 INFO EDCORE (Main): (dDispatcher)enterToState_:5 2025-02-25 07:39:07.524 INFO APP (Main): application shutdown Steps to reproduce: Disconnect your Internet Launch DCS Acknowledge the popups Press Online Mode in main menu dcs.log

Glad to hear that. Just make sure to undo the workaround after a fix is out! Otherwise, it will come back to bite you, when you least expect it. This would be an absolute nightmare to debug, when you don't know anymore where to look.

@N0XID: Looks like you're running your servers via Wine, presumably aterfax' Docker. If so, the following shell snippet should configure a workaround for you (subject to the side-effects I pointed out before): echo "185.195.197.4 api.digitalcombatsimulator.com" >>~/.wine/drive_c/windows/system32/drivers/etc/hosts

Works as of 2.9.13.6818 on Windows 10. Note that "silent" implies automatically uploading the crash report: @BIGNEWY: Is there an option to disable the automatic upload? Tried "disable", "disabled", "no", "none", and "off" to no avail. Anything but "silent" will open the DCS Crash dialog.

The dedicated server is also affected (same lua.dll, presumably). The code does not cause a segfault with server version 2.9.12.5336. Server crash trace: dcs.20250224-092739.crash

This is an awesome, albeit belated, feature addition! Any documentation available on this? What's the function signature? I just toyed around with it and managed to crash DCS (segfault).

Clean (no mods, no scripts), freshly repaired (full verification) DCS 2.9.13.6818 install. Running the following Lua code will cause a segmentation fault (ACCESS_VIOLATION): local res = {net.dostring_in("mission", [[ return {a_do_script("return {1, 2, 3, 4}", 1, 2, 3, 4)} ]])} Steps to reproduce: Save segfault_a_do_script.lua in %USERPROFILE%\Saved Games\DCS.openbeta\Scripts\Hooks\ Run an arbitrary mission from the mission editor. Game should crash with a "DCS Crash" popup once loading completes. Crash trace for comparison: dcs.20250224-084219.crash How did I stumble upon this? I got curious what the updated a_do_script() can do and started messing around with it. Quote from the changelog:

Your symptoms sound as if your router may be the culprit. AFAIK, DCS can set up port forwarding in your router automatically via UPnP. If, however, your router has a timeout for UPnP-based forwardings and DCS does not renew these periodically, the port forwardings will expire after a timeout. As the forwardings only affect external connections, LAN connections will still work.

I feel you. Fortunately, almost everything works via CLI/SSH. The only point you need the GUI stuff is to mess with the DCS updater/server and the SRS server, which, unfortunately, both refuse to work without a GUI. Good hunting!

@N0XID Have you tried editing etc/hosts as per my suggested workaround #2? OP used the same approach, which fixed the issue for him.