Actium

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.

@MarkP Another heads up: ED messed up the master server login in version 2.9.13. At least for me with Wine 8.0, attempting to start the server fails 10 out of 10 times. Workaround: echo "185.195.197.4 api.digitalcombatsimulator.com" >>~/.wine/drive_c/windows/system32/drivers/etc/hosts

That is exactly what to expect from a CDN. The first layer of load balancing is implemented through DNS by directing different clients to different IP addresses, i.e., physical servers or load balancers, for their respective requests, instead of directing all clients to hammer on the same few servers. Also, the login issue is not caused by resolving cdn.digitalcombatsimulator.com, but by resolving api.digitalcombatsimulator.com. AFAICT, the CDN is only relevant for the updater.

While I do not have the issue on Windows 10, I can reproduce it 10 out of 10 times when running the dedicated server on Linux via Wine 8.0. Two possible solutions that both work for me (again, on Linux): Downgrade to version 2.9.12 until a hotfix is out. This will exclude you from all server already running 2.9.13. To perform a downgrade, open the windows terminal or command prompt and enter: "C:\Games\DCS World OpenBeta\bin\DCS_updater.exe" update 2.9.12.5336.1 (adjust to your DCS installation path) Add the api.digitalcombatsimulator.com domain to Windows' etc/hosts file as suggested by the OP. This is a temporary workaround! Undo it immediately once a hotfix is out! Otherwise, it will come back to haunt you (possibly years in the future), if the ED master server IP address ever changes. You have been warned. Apply the workaround as follows: a) Open the start menu, search for notepad, rightclick, run as administrator. b) Menu: File > Open. Paste C:\Windows\System32\drivers\etc\hosts into the filename field and press open. c) Add the following line: 185.195.197.4 api.digitalcombatsimulator.com d) Save and close notepad. e) Open a command prompt and run: ipconfig /flushdns If anyone on Windows, e.g., @trindade, opts for #2, please report back whether it works, as I've only been able to verify it on Linux, i.e., Wine.

@MarkP Just invited you to the repo. Added a small README with the instructions required to get it up and running. Let me know if you have any problems.

@MarkP If you have the prerequisites (Debian 12 "Bookworm" or comparable, e.g. Ubuntu), running it via Wine is fairly straightforward. Mileage may vary with other distros, but systemd is a hard requirement. You would have to install a few packages (fonts-liberation, wine, wine32, wine64, sway, wayvnc, xwayland). DCS and SRS installation and everything else should work automagically. If all works out, it'll be less work than setting it up on Windows. Do you happen to have a Github account I can share the repo with?

There you go: -- a random function function random_function() return 42 end -- name of random function as a string variable local function_name = "random_function" -- recover the original function local recovered_function = loadstring("return " .. function_name)() -- CAN BE REMOVED: just to prove both functions are identical assert(recovered_function == random_function) -- call the recovered random function return recovered_function()

Just to avoid any possible misunderstanding and on account of the plentiful and – for the sake of backwards compatibility – unfortunately irreversible crutches* in DCS' Lua API, please indulge me for pointing out the following: Adding an error message to the log is the worst possible "fix" for this particular issue, as it cannot be caught programmatically**. Always enable use of Lua's integrated error handling mechanism pcall(), when possible. For net.lua2json(), I would suggest the solutions 1 thru 3 in my order of personal preference: Serialize Lua values that cannot be represented in JSON, e.g., cyclic references, functions, userdata, etc., as null. Neither pairs() nor ipairs() will ever return a nil-valued key or value. When deserializing from JSON back to Lua, these null-values will simply disappear. No harm done, but valuable, human-readable debugging insight added. Simply skip all values that cannot the be serialized to JSON. Same outcome as above when deserializing, but less debugging friendly. Inconvenient: Use Lua's error() or lua_error() functions, respectively, to throw an exception that can be handled somewhere up the chain. Would make net.lua2json() useless for some types of data, but we can implement suitable alternatives. DO NOT: Return a string with an error message* instead of a string containing the serialized data. A huge footgun and inconsistent API design as it facilitates passing along an error message instead of valid JSON without noticing. Feel free to DM me, if you or your Devs have any questions. *) I'm pointing this out explicitly, because net.dostring_in() does exactly that, and, as a cherry on top, it has a second boolean return value that indicates success/failure and thus whether the first return value is the actual string return value or a string error message. Of course, the second return value is undocumented. Appears inspired by pcall(), although the order of return values got messed up. Regardless, only pcall() needs to return success/failure as a separate boolean return value. All other functions can simply defer their error handling to the proper use of pcall(). UPDATE: And as another undocumented "feature" and unreasonable behavior, net.dostring_in() will simply return nil when called from a client connected to a server **) For the sake of proving that I did my homework, it could be done with DCS.getLogHistory(), but that would be a truly ridonculous crutch.

Hahaha, made my day Thank you for sharing! Depends on what kind of missions you plan on running on the server. The CPU in questions weighs in at about 40% of the single thread performance of the current top notch CPUs. Multi-thread performance doesn't really matter, as the dedicated server is bottlenecked by its main thread. I run Caucasus on a Linux VM with 16 GB RAM and a couple of 2,4 GHz AMD EPYC cores (somewhat comparable to your i5-8500T). Large missions with >100 AI units fighting will quickly bring the server to its knees, but it works well for smaller missions. Your i5-8500T may work out with modestly sized mission, particularly when running the DCS dedicated server unvirtualized. Depending on the map, even 16 GB may be enough, e.g., on Caucasus.

@Flappie: Thank your for the update and prompt action from the devs! Please forgive me for the following jibe: For an API usage to be "wrong", there'd need to be documentation that specifies what is right. However, DCS_ControlAPI.html is quite terse on net.lua2json(): "net.lua2json(value) -> string: Convert a Lua value to JSON string" Obviously, cyclic data cannot be expressed in JSON. Regardless, using an API incorrectly should always result in a recoverable error (message) and never in a segmentation fault. Here's an MIT-licensed implementation for serializing arbitrary Lua values (including those with cycles) to valid JSON without crashing in as little as ~100 lines of code: https://gist.github.com/ActiumDev/4c2a4b9ea1a638d131f1ab38ec61f16f#file-webconsole-lua-L408 (part of my standalone web console) Feel free to use it according to the terms of the MIT license. Just FYI: I'm available for renumerated consulting.

Mission file for easy reproduction. Launch the mission, watch the countdown, see the game window close. Crash_net.lua2json.miz

@Flappie: Gotcha. While you're at it, there's another net.lua2json() bug the devs can fix:

Running the the following Lua code will instantly crash DCS (client and dedicated server alike): local t = {} t[1] = t return net.lua2json(t) On the dedicated server I got the following log messages, indicating a segmentation fault (access violating): 2025-02-16 21:21:06.058 INFO EDCORE (Main): try to write dump information 2025-02-16 21:21:08.560 INFO EDCORE (Main): # -------------- 20250216-212108 -------------- 2025-02-16 21:21:08.560 INFO EDCORE (Main): DCS/2.9.12.5336 (x86_64; MT; Windows NT 10.0.18362) 2025-02-16 21:21:08.560 INFO EDCORE (Main): 2025-02-16 21:21:08.560 INFO EDCORE (Main): # C0000005 ACCESS_VIOLATION at 0000000380025f70 00:00000000 2025-02-16 21:21:08.560 INFO EDCORE (Main): SymInit: Symbol-SearchPath: 'C:\DCS_server\bin;', symOptions: 532, UserName: 'dcs' 2025-02-16 21:21:08.560 INFO EDCORE (Main): OS-Version: 10.0.18362 () 0x0-0x1 2025-02-16 21:21:13.483 INFO EDCORE (Main): Minidump created. Presumably, net.lua2json() does not check for cyclic references, recursing infinitely, and finally smashing past the end of the stack, which causes the segfault.

The dedicated server has been multi-threaded since (at least) version 2.9.9. However, while it does use multiple threads, like the DCS client it still relies heavily on the main thread and does not scale well with CPU cores. Therefore, CPU single thread performance is key. Overall performance deteriorates rapidly once the main thread hits its performance ceiling. Presumably, due to a lack of sufficiently concurrent, lock-free data structures and therefore excessive locking that prevents threads from running simultaneously.

I've stumbled over this on a few occasions, too. Unable to reliably reproduce. Server hosted in a proper data center (and the VNC session showing that amazing popup message worked flawlessly), so I'd pinpoint the issue on the ED side of things and not with our respective network connections. The login* failure is exacerbated by the need to acknowledge it manually. This defeats the purpose of a dedicated server, which is to operate autonomously, without the need for admin intervention. Better to either automatically retry until the login succeeds* or fail with a non-zero, documented** exit code (i.e., not a popup message) and let the OS decide about restarting the service. *) Why would a dedicated server need to login before serving a mission anyway? Just start the mission immediately and register with the master server in the background (retrying until it succeeds). What's the potential (financial) harm of letting a free dedicated server start without blessing from the ED master server? **) Sorry. Couldn't help myself.

@Flappie So ED is outsourcing bug triage to unpaid volunteers like yourself?

Personally, I'm not using docker for DCS and SRS installation. I wrote a bunch of shell scripts that install DCS and SRS from scratch as well as systemd unit files for service orchestration. I wanted to release these files on Github, eventually (in a couple of weeks/months), but if you're interested, I'll try to expedite the release. Will save you the hassle of going through the docker stuff. Also, AFAIK, there's currently no docker image for running SRS.

TL;DR: WebConsole.lua is an experimental, interactive, browser-based Lua console with syntax highlighting for scripting in all of DCS' scripting environments. It explicitly supports mission scripting to accelerate otherwise slow mission development cycles (edit DO SCRIPT code, start mission, test, stop mission, repeat). Install by downloading WebConsole.lua into your %USERPROFILE%\Saved Games\DCS.*\Scripts\Hooks\ folder, start a DCS mission, and open the console in your web browser. Script return values are automatically serialized as human- and machine-readable JSON. Also supports non-interactive use through an HTTP API to issue DCS scripting commands from any programming language. Read below security advisory before installing! I'm publishing it in its current state, because I already use it productively for mission scripting and I'm looking for feedback from the community. As it is experimental, there are no support or compatibility guarantees. Use at your own risk, feel free to break it, and don't hesitate to report any issues in this thread! Features Easily run arbitrary code in all of DCS' scripting environments (called Lua states, accessed via net.dostring_in()). Currently, these include config, export, gui, mission, and server. Let me know if anything is missing. Access to the separate mission scripting environment (dubbed *a_do_script), where all DO SCRIPT code from the mission editor runs, is supported out of the box since DCS 2.9.13 (no modification of MissionScripting.lua required). UPDATE: Broken since 2.9.15.9408, but workaround available. Supports both clients and (dedicated) servers. Clients not also serving missions, e.g., from the mission editor, are restricted to the gui environment. Lua syntax highlighting and checking via an embedded code editor (ACE). Secure integration into mission scripting: Unlike other consoles, WebConsole.lua does not require disabling the sanitization in MissionScripting.lua. Serialization of complex return values into human- and machine-readable JSON. Interactive inspection of returned JSON objects (see screenshot). The serialization format is a work-in-progress, i.e., not stable. Beware of arrays starting with null. Alternatively serializing to Lua is feasible, but currently missing. Feel free to implement and contribute it. HTTP API for non-interactive use from a programming language of your choice. Includes error handling and translation into appropriate HTTP status codes (Success -> 200 OK; Error -> 500 Internal Server Error). Note that the API is not stable and may change without notice. Security Advisory All DCS Lua consoles, e.g., dcs-witchcraft, DCS-BIOS, DCS Fiddle, DCS Lua Runner, DCS Code Injector, and my WebConsole.lua, use a socket bound to localhost (127.0.0.1) to issue scripting commands to DCS. This socket is not accessible remotely, neither from the internet, nor from your local area network. However, the socket is open to any user or program on your local computer. Without authentication or a firewall in place, other users (and whatever software they run) can use the socket and Lua's os.execute() to escape the DCS Lua scripting environment, enabling arbitrary code execution with user permissions. This is a potential security vulnerability that could be exploited to access/steal your files, install malware, etc. Single-user computers are generally safe. However, multi-user systems are vulnerable, unless properly authenticated (password protected), firewalled, or all co-users are absolutely trustworthy. Do **NOT EVER** modify any Lua console to bind its socket to 0.0.0.0 to enable remote scripting access, as this would enable remote code execution for anyone. Password protection via HTTP Basic authentication is unencrypted and generally insecure. If you want to use any Lua console remotely you could, e.g.: Set up a reverse HTTP(S) proxy that authenticates and encrypts all web console requests. Use encrypted and authenticated port forwarding, e.g., via Secure Shell: ssh -L 8089:127.0.0.1:8089 user@server (also possible on Windows) Set up a VPN and bind the socket to the VPN interface IP address. Note that everyone on the VPN will be allowed access, unless firewall rules are in place. Installation Download WebConsole.lua and copy it into your Scripts/Hooks folder, e.g., %USERPROFILE%\Saved Games\DCS.*\Scripts\Hooks\WebConsole.lua. Optionally, configure port and password in your %USERPROFILE%\Saved Games\DCS.*\Config\autoexec.cfg as follows. If left unconfigured, port defaults to 8089 and authentication is disabled. -- configure Scripts/Hooks/WebConsole.lua: -- WARNING: the web console is not remote-accessible via network. however, it -- enables arbitrary code execution with user privileges to anyone -- with access to its socket. -- this is a potential security vulnerability on multi-user systems, -- enabling other local users to run arbitary code from your user -- account, access your files, install malware, etc. -- enable HTTP authentication with a strong password below or use an -- appropriately configured firewall on multi-user systems! -- web console HTTP port (number: -1 to disable | >1023 to enable | nil: 8089) webconsole_port = 8089 -- base64-encoded "username:password" string for optional HTTP Basic -- authentication or nil to disable authentication. on Windows PowerShell use -- `[Convert]::ToBase64String([char[]] "username:password")` and on Linux use -- `echo -n "username:password" | base64` for base64-encoding. example value -- for "username:password": webconsole_auth = "dXNlcm5hbWU6cGFzc3dvcmQ=" webconsole_auth = nil Interactive Use After installing as instructed below, start a mission (e.g., from the mission editor or on a server). Open http://127.0.0.1:8089/ (if using the default port) in your browser while the mission is running. Type code, press Execute, and check its return value. Rinse, repeat. The console does not work while the mission/server is paused. Non-Interactive Use Exemplary curl command line to fetch server logs: curl "http://127.0.0.1:8089/execute" -X POST \ -H "Accept: application/json" -H "Content-Type: application/lua" -H "X-Lua-State: gui" \ --data-raw "return {DCS.getLogHistory()}" Exemplary Windows PowerShell code to fetch list of currently connected players from a server: (Invoke-WebRequest ` -Uri http://127.0.0.1:8089/execute -Method POST ` -Headers @{"Accept" = "application/json"; "X-Lua-State" = "gui"} ` -ContentType "application/lua" ` -Body "local players = {} for _, id in ipairs(net.get_player_list()) do players[#players + 1] = net.get_player_info(id) end return players").Content Screenshots Web console used to retrieve and display the contents of the global variable world in the mission scripting environment: The web console can also be used to recursively dump all global variables via return _G. Note that doing so will freeze the server until serialization and HTTP transfer have completed. To avoid browser performance issues, the result display is truncated. The entire result can be saved to a local file via the Save button. Serializing to JSON has the benefit of being able to use web development tools, like the interactive JSON inspectors included in, e.g., Firefox and Chrome. Click the Open button to open the result in a new window:

AFAICT, the DCS server loads all required assets while loading the mission, incurring significantly longer load times from an HDD. However, short of a developer confirming that no load will ever occur while a mission runs, no one knows for sure. If you run into performance issues later on, you'll always wonder whether these are caused by the HDD. Writing Tacview logs onto an HDD may very well affect the server performance. So, personally, I'd invest into an NVMe SSD. Half a TB costs around 50 bucks these days. IMHO, well worth the peace of mind.

With "only" 32 GB RAM on the Proxmox host, you may run out of RAM with a Windows VM in addition to – presumably – a few more Linux VMs (or containers?) running the other services you mentioned. A single DCS_server.exe process with an empty Caucasus map loaded allocates around 10 GB. Add a Windows VM with 20~24 GB of RAM on top and you're already almost out of RAM. Of course, your mileage may vary. As you're using Proxmox, you may be comfortable with using Wine to run your DCS server on Linux, obviating the RAM overhead of a Windows (Server) VM. Here's a forum post on how to run the DCS server via Docker. I run a DCS server on Debian stable with Wine 8.0 without problems, using self-written systemd user services to administer multiple server instances. If you do opt for Wine: A Proxmox container will likely yield better performance (and less RAM usage) than a VM. I have no hard data on this, but I have read post on the forum that state this, corroborated by my own gut feeling. If you want to dive even deeper, using a recent Linux Kernel with NTSYNC support as well as a Wine version with the NTSYNC patch might deliver performance on par with Windows. I haven't had the time to try it, so take this with a huge grain of salt! However, judging from the server's mediocre multi-threading performance, I would not be surprised if NTSYNC actually delivers noteworthy performance improvements.

Thanks @cfrag and @DD_Friar! I had a gut feeling I had exhausted DCS' limited scripting options and wanted to confirm that. The one trigger per unit kludge is not a viable option for me, because >100 units are involved. I guess I'll opt for just 'sploding the deserting units. I tend to agree . I've read dozens of his forum posts, typically including justified yet entertaining criticism of DCS' desolate mission scripting state. Today's post did not disappoint I come from the very first ArmA, which was also painful to script with, but DCS appears to play in a wholly different league.