Actium

It has, albeit at a low level. See the monthly steam user survey. With most Windows users being thoroughly vendor-locked and also not giving a damn about privacy (most people use Edge or Chrome, signed into personal accounts), I doubt this will change in the foreseeable, but it shouldn't shy the enthusiasts away from breaking it off with Windows.

Thank you! No, not yet. I'm still in the process of stabilizing the foundation. There's still a few issues I'd like to have ironed out before adding on features (e.g., automatic DCS updates, adding/configuring more server instances, installing/removing terrains, extended README.md). The ecosystem of DCS mods, bots, various tools (e.g., Olympus) and mission frameworks (e.g., Retribution, Liberation) is also so comprehensive that it's beyond the scope of this project to support them all. I will have to prioritize everything that enjoys widespread and universal use, e.g., Tacview. In terms of a roadmap, server performance is my next big objective. I'm in the process of experimenting with a recent improvement in both the Linux kernel and Wine (called ntsync) that will hopefully bring a significant performance improvement.

Dedicated server? I've tried to write a clear and concise README.md for my non-Docker installation method. Let me know in this thread if anything is unclear or missing. @aterfax created a video for the Docker install. I haven't tried installing the DCS client on Linux, but if you need some info, you may find it in this TDCS thread. There's also a bunch of videos on Youtube, but for lack of having tried it myself, I cannot endorse any. UPDATE: Just recalled the DCS_Standalone_on_Linux git repo that also appears current and quite detailed.

The dedicated server actually runs nicely on Linux (via Wine). Only recent hickup was ED's DNS resolution experiment that backfired (and has been waiting to get fixed for 4 weeks). I'd even go as far as claiming that installation and setup is actually easier on Linux than on Windows: On Linux, it works (fully) automatically either using Docker or natively. Performance on Wine is not quite on par with Windows, but I'm hopeful that ntsync will improve that in the foreseeable future. I'll post some benchmarks once I've found the time to build Wine 10.0 stable with the ntsync MR applied. As the dedicated server runs fine as-is on Wine, I'd rather ED use their time to fix the many bugs and inadequacies of the server before attempting to port it to Linux. The dedicated server is just a stripped-down client with all the baggage that comes along with it: It is made for interactive use and thus unreliable when used non-interactively. In fact, it bricks itself when anything goes awry. The ED master server is unreliable and a single point of failure. Servers randomly go missing from the server list. I'm sure the list of problems goes on. Of course, reports of these issues go unacknowledged.

@Clawhammer Thanks for testing and reporting your results.

Implemented password protection (HTTP Basic authentication) to improve security on multi-user systems. Configure a strong password in autoexec.cfg to prevent other users on the same computer from exploiting WebConsole.lua to execute arbitrary code from your user account. HTTP Basic authentication is unencrypted and only provides security for sockets bound to localhost. Do not use it to access the console remotely over network! First post updated accordingly.

@Toumal Just pushed a watchdog that'll query the WebGUI port and force a server restart if it fails to response. Also figured out that the server will keep responding normally even with a frozen simulation (infinite loop in onSimulationFrame()), unless queried with a valid encrypted request.

@Toumal Possibly of interest to you: Systemd user unit file to run and automatically restart a DCS server. More details on the whole work-in-progress thing in this forum thread (same link as above). Let me know if you have any comments on it. Thanks! Love the idea! Guess I'll write another systemd service that'll supervise the server that way. Before, I have done it the crude, hard, and brittle way by querying the game port instead of the webgui port : #!/usr/bin/python3 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.sendto(b"\000\222\274\330S\n\241\016u\233,\3325\256o\371;\304\261;Sa\213\205{\000'\252\334d\355", ("127.0.0.1", 10308)) print(sock.recvfrom(65536))

Same recommendation as for your other issue: Enable debug logging, check the contents of dcs.log, compare logs with a local dedicated server install using the same config and steps.

Does Fox3 provide access to dcs.log? Preferably, with full debug logging enabled. If so, please restart the server (so you start with an empty dcs.log), document each step you take to reproduce the issue (with as few steps as possible), and post the dcs.log along with the exact steps that produced that log. The (debug) log should be considerably more informative than screenshots. Absolutely. But that goes both ways. Therefore, I'd recommend you to install a dedicated server on your local computer*, apply the exact same configuration you use on the Fox3 server, try to reproduce the issue you have with your Fox3 server on the local dedicated server install, using the exact same steps. Finally, compare the logs to narrow down the cause of your issue. Best of luck and please report your findings here!

@ToumalCould you elaborate a bit on what exactly you do for these checks, please? I was wondering how to detect a bricked DCS_server.exe for the purpose of terminating and restarting it. I've though of a simple Python script that periodically polls the server status via its UDP query protocol and shoots it down if it fails to respond for a couple of times (got a working proof-of-concept). As I host my dedicated server on Linux, I also considered using some dark magic (swaymsg -t get_tree) to periodically check if DCS_server.exe opened any popups that would qualify it for immediate termination.

Absolutely. The DCS updater allows downloading all files without login anyway, so I see no reasonable justification to intentionally restrict the dedicated server to not start without login. It does not prevent software piracy at all. Of course, I'd be happy to learn about any logical reason to keep the login restriction (and the annoying issues it causes) in place. However, I have a practical explanation: The dedicated server code base likely borrows largely – if not entirely – from the client. You can deduce that from the dedicated server's log messages: 2025-03-03 22:25:33.969 ERROR EDCORE (Main): No suitable driver found to mount bazar/textures/f-15 It attempts but fails to load a bunch of textures, although a dedicated server would never need any textures for lack of rendering. Deriving the dedicated server from the client makes sense from the narrow perspective of code maintainability: It limits the overall amount of code. The unidiomatic login necessity, login error popups, and the mission scripting error popup are presumably just leftovers from the client. Obviously, the slightly simplified code maintenance comes at the cost of added support effort, with the latter probably outweighing the former. It shouldn't be too troublesome to #ifdef the entire login code to only be included in the client and not in the dedicated server. But that would be sth. for the DCS Code Wish List. I see no reason to invest time advocating for that change as long as the described dedicated server usability bug goes unacknowledged and the far more serious Login Failure remains unfixed for 2 weeks as of now.

@Maverick87Shaka I took the liberty to file a bug report related to this. Not regarding the sometimes unreliable master server itself, but instead about DCS_server.exe bricking itself when it happens:

The dedicated server (DCS_server.exe) cannot be used reliably as a non-interactive background service. For example, failure to login with the sometimes unreliable master server will raise this Login failed popup (if a saved authentication is available): The popup must be closed manually. Afterwards, the server process initializes and the splash screen window opens, but the server refuses to start any mission via the WebGUI and appears to be bricked indefinitely with the following dcs.log error message: 2025-03-03 21:20:24.025 ERROR ASYNCNET (Main): server_start failed: login is required If no saved authentication is available, another popup is opened that must also be acknowledged manually, before the server process terminates (at least the process isn't bricked, this time): UPDATE: An already running dedicated server will terminate with the following Login session has expired popup if the master server is unreachable for more than 20 minutes. The error occurs only when connection to the master server is re-established (more details here). The dedicated server process terminates after acknowledging the popup: Last but not least, a mission scripting error will raise another popup that freezes an already started dedicated server mid-mission until the popup is manually acknowledged (workaround available) : When using DCS_server.exe interactively, i.e., starting a single server instance on your local Desktop only if and when you need it, these popup messages may provide useful debugging information. However, many DCS_server.exe instances run non-interactively on dedicated servers in data centers without constant supervision of the server GUI. If such a popup message opens, e.g., after an automatic restart that leads to a temporary login failure or when a mission scripting error occurs, the server instance is bricked until manual admin intervention. This is highly impractical. DCS_server.exe should support non-interactive use by exiting with a non-zero exit status code immediately after fatal errors, e.g., the login failure*. Non-fatal errors should be logged to dcs.log, but otherwise ignored (or better yet: communicated to the clients as done in my workaround). The operating system service manager or a restart script can then decide if and when to attempt restarting DCS_server.exe after an error occurred, based on the exit status code. To not affect the aforementioned interactive desktop use of DCS_server.exe, a --quiet argument could be introduced, just like DCS_updater.exe has it already. Such an option should inhibit all popups including crash popup and therefore imply crash_report_mode = "silent", so DCS_server.exe can also be restarted automatically after it crashed. *) Regarding the login failure, a superior solution to just exiting would be to repeatedly attempt to connect to the master server in the background. Meanwhile, the server should still be allowed to start a mission, so dedicated servers can still be started and used (by connecting via IP) even if the master server is temporarily unavailable.

Cannot reproduce it either. For me, also behaves like Flappie described. Probably need to contact your managed server provider about it.

Tried with a locally hosted dedicated server (Windows 10, Ryzen 9 5900X, 64G DDR4@3600, and Samsung 990 Pro). Switching between missions on Caucasus takes 2~3 seconds. Switching between Marianas and Caucasus takes roughly 5~7 seconds. I believe, you will have to take it up with your managed server provider.

@Buzzer1977@Porkbrain If changing the DNS server doesn't fix it for you or is not an option, the alternative would be adding 185.195.197.4 api.digitalcombatsimulator.com to C:\windows\system32\drivers\etc\hosts as a selective, temporary workaround described here in more detail. Make sure to undo it though, once a hotfix is out.

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 since November '24. It's been smooth sailing from DCS 2.9.9 all the way thru 2.9.19, 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: ~250M RAM on Debian 13.0 (kernel + user-space) Built for headless (non-GUI) Linux servers: Does not require a desktop environment (e.g., Gnome, KDE, XFCE, ...) DCS window accessible via VNC (only needed for login and interactive installation/updates) Runs Caucasus and Marianas on servers with 8G RAM (more for other terrains) 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