Actium

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. The termination also occurs with the same error popup for a variety of other reasons. 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: 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): HTTP request dcs:checksession failed with error 28: Timeout was reached 0000-00-00 00:00:00.000 WARNING ASYNCNET (0): Session check failed: -28 0000-00-00 00:00:00.000 ERROR ASYNCNET (0): 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. Apparently, this issue also occurs entirely out of the blue without any prior connection issues (i.e., no session check errors/warnings, cf. above) in dcs.log [1, 2, 3]. According to BIGNEWY, reasons may include simultaneous logins with the same account, local internet issues, or changing IP addresses [1, 2, 3, 4, 5]. However, I've not been able to reproduce this by repeatedly changing public IP address during a DCS session. The referenced local internet issues causing failure to connect to the master server would result in session check failed messages in dcs.log. So with the noteworthy exception of simultaneous use of a single account, I see no reason why this issue should occur. This might even be a bug in the master server. 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 for comparison). 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 PowerShell: $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/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 $api_addr/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. Improve client error messages. The session expiration presumably occurs for a variety of reasons, but the client always shows the same generic error popup message. To simplify debugging, the client popup message and dcs.log should include a human-readable explanation of the specific reason for the session expiration. This would require support from the master server, which must include this reason in its response (e.g., as the response body with a text/plain Content-Type; currently the 401 responses are text/html with an empty body). 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 PowerShell with administrator privileges (alternatively, you can also just suspend your computer): $api_addr = (Resolve-DnsName api.digitalcombatsimulator.com).Address route add $api_addr/32 0.0.0.0 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 $api_addr/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.

@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.