Actium

You have two options. For both, you have to open PowerShell. These are just educated guesses, as I don't have DCS installed via Steam, so, unfortunately, I can't check if it works. The first option is to run the two commands I've posted above. They will generate a new registry key that pretends the DCS World OpenBeta Server is installed where you installed DCS World via Steam. That should theoretically get the DCS Updater to search files there before downloading them instead. Alternatively, if it used to work from the old Steam directory on your D: drive, you could create a symlink from the D: drive to the E: drive. That way, if the DCS updater searches in the old location on D: it will be implicitly "forwarded" to the E: drive. Generate the Symlink as follows (note that the parent directories on D: must exist; create them if necessary): mklink /d D:\Steam\steamapps\common\DCSWorld E:\SteamLibrary\steamapps\common\DCSWorld

More informative error messages would certainly help. Same applies to the Error 500 issue. It shouldn't be too difficult to add human-readable error messages to the popup and the dcs.log, so users are not left absolutely clueless as to what is going on. I've even detailed a straightforward way to implement that. Should be feasible in a day's work.

The DCS_updater.exe checks for other install locations within your registry. AFAICT it checks the following registry keys to find other local DCS installations: HKCU\Software\Eagle Dynamics\DCS World OpenBeta\Path HKCU\Software\Eagle Dynamics\DCS World\Path HKCU\Software\Eagle Dynamics\DCS World OpenBeta Server\Path HKCU\Software\Eagle Dynamics\DCS World Server\Path A crude way of getting the updater to find your Steam installation would be to create one of the above registry keys, preferably one that does not yet exist on your system, and to set it to your Steam DCS directory. Haven't tried that, but should theoretically work. Obviously, try at your own risk. Update: Quickest way to do that would be through Windows PowerShell. This will not overwrite any existing registry keys, so should be relatively safe: New-Item -Path "HKCU:\Software\Eagle Dynamics\DCS World OpenBeta Server\" New-Item -Path "HKCU:\Software\Eagle Dynamics\DCS World OpenBeta Server\Path" -Value "E:\SteamLibrary\steamapps\common\DCSWorld"

@BIGNEWY Maybe merge with https://forum.dcs.world/topic/312603-login-session-expired/

I wrote a benchmark script for the dedicated server. Exemplary results.

Having a look at all occurrences of ASYNCNET on your dcs.log, it appears the session expiration occurred out of the blue by decision of the DCS master server: 2025-09-19 12:51:52.652 INFO ASYNCNET (4780): Login success. 2025-09-19 12:51:54.241 INFO ASYNCNET (4780): Got auth data. 2025-09-19 12:51:54.605 INFO ASYNCNET (Main): ProtocolVersion: 408 2025-09-19 12:51:54.605 INFO ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback" 2025-09-19 12:51:54.605 INFO ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast" 2025-09-19 14:40:01.848 ERROR ASYNCNET (4780): The session has expired (401). Exiting... Unless you started another DCS instance with the same account credentials, there's no good reason for the master server to do that. This is not a an issue with a spotty internet connection. If it were, the log would include messages indicating failed connection attempts. Thus, this lies within the hand of ED to figure out via logs from their master server. As BIGNEWY recommended above, do file a support ticket.

The F-16 Early Access Guide Page 465 defines the small circle on the DLZ as the Radar Activation Range: However, as of DCS 2.9.19.13478 that small circle is now located above the current range caret although missile activation is still 50 seconds away. Documentation and actual implementation are inconsistent. From the looks of the documentation screenshot, the docs may be in need of an update. Track file from which the screenshot was taken: F16_DLZ_Radar_Activation_Range.trk

You made my day! I appreciate your passion and support for the DCS Train Simulator Community! Maybe ED should consider to integrate train conducting into Combined Arms @cfrag Thank you for your very concise and to the point summary of the state of DCS. I do agree wholeheartedly. The tools situation is exacerbated by the lack of official documentation for almost everything, a tendency to break the scripting interface, and an utter lack of developer attention to core bug reports combined with apparent zero pre-release testing [1, 2]. What adds insult to injury is that the Simulation Control API Documentation (see %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html) claims that scripting API centerpiece net.dostring_in() is now allegedly obsoleted by a_do_script(). That conclusion is ill-conceived and makes me wonder whether ED still understands their own code base. I do have my doubts. Bug triage, i.e., presumably forwarding confirmed bugs to an internal bug tracker, and testing is outsourced to community volunteers, who recently got this new and shiny badge to bolster morale. Sadly, only a tiny fraction of General Bugs filed within the last 2+ months have received any official attention. Reporting bugs in the faint hope to get them fixed seems like a waste of time now. A general note on managers: Managers typically work on behalf of the short-term shareholder value. Not the employees, not the long-term sustainability, and certainly not the customers. Boeing is a prime example of the application of this management mantra. Just to put expectations into perspective. Despite its many flaws, I do love and enjoy DCS thanks to the squadron I fly with. They make it worthwhile. However, I am outspoken about DCS' shortcomings in order to get its issues enough attention from ED. To make DCS better for everyone, including the evangelists who repeatedly suggest us critics to walk away. I'm terribly naive, I know ... My wish: These efforts to fall on fruitful ground and be appreciated and considered. By ignoring the content creators, ED is leaving vast resources untapped and fallow.

The WebGUI screenshot function is defective. Note the broken image icon that appeared after trying to take a screenshot via the camera button: Took a closer look with the Web Developer Tools (F12). The HTTP GET request, which is supposed to retrieve the screenshot from the dedicated server, fails with Error 404 (Not Found). However, the URL http://127.0.0.1:8088/screenshots//screenshots/d7GSsJF1dg6hbrm looks wonky, judging from the double slash between the two occurrences of screenshot. Change that to http://127.0.0.1:8088/screenshots/d7GSsJF1dg6hbrm and built-in HTTP server will respond with the screenshot. Hence, this issue appears to be confined to the WebGUI implementation, which gets the URL wrong.

Being privacy minded and out of curiosity, I had a look at the WebGUI, which is used to create said screenshots. At first, the screenshot function seems defunct. Note the broken image icon that appeared after trying to take a screenshot via the camera button: Took a closer look with the Web Developer Tools (F12). The HTTP GET request, which is supposed to retrieve the screenshot from the dedicated server, fails with Error 404 (Not Found). However, the URL http://127.0.0.1:8088/screenshots//screenshots/d7GSsJF1dg6hbrm looks wonky, judging from the double slash between the two occurrences of screenshot. Won't bother to file a bug report for that, as that seems to be a waste of time. UPDATE: Copied and pasted a bug report. Change that to http://127.0.0.1:8088/screenshots/d7GSsJF1dg6hbrm and you'll get an actual screenshot, which appears to be limited to whatever is rendered by DCS itself. I disabled full-screen mode, put a bunch of windows on top of the DCS window, took a screenshot, and got this (lacks all the stacked windows):

Having a look at the uploaded dcs.log, this doesn't look like a local network issue. All occurrences of ASYNCNET in the log (PowerShell: Select-String ASYNCNET dcs.log): dcs.log:21:2025-09-06 18:29:43.859 INFO ASYNCNET (10472): Login success. dcs.log:22:2025-09-06 18:29:45.017 INFO ASYNCNET (10472): Got auth data. dcs.log:26:2025-09-06 18:29:45.100 INFO ASYNCNET (Main): ProtocolVersion: 367 dcs.log:27:2025-09-06 18:29:45.100 INFO ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback" dcs.log:28:2025-09-06 18:29:45.100 INFO ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast" dcs.log:356:2025-09-06 18:30:07.852 WARNING ASYNCNET (Main): Ignoring duplicate request to imageAFGHANISTAN_terrain while one is already in flight. dcs.log:357:2025-09-06 18:30:12.471 ERROR ASYNCNET (10472): Entering offline mode failed because server returned an invalid reply. Starting the game, authentication succeeds, but half a minute later, the server responds with an invalid reply. As per the OP, these are Error 500 (Internal Server Error) and Error 401 (Unauthorized). These HTTP error codes come from the server, after the client successfully completed an HTTP request/response transaction. Hence, no apparent network issue. That only leaves a server-side cause, so opening a ticket for ED support to get involved is IMHO the most promising approach.

I agree. It's a shame that adding an EWR to the group won't change a thing in vanilla DCS. Regardless, the higher detection range in a ~50° sector is nonsensical.

The SA-5 TR has a significantly higher range than its SR. With the TR emitting by default*, an SA-5 battery will lock and shoot a target within ±25° of the TR azimuth angle at ~130 nm range. This is far outside of the TR antenna main lobe width of less than 2°. When this happens, the TR azimuth will suddenly snap from its initial angle by 25° to the azimuth of the approaching aircraft: SA5_TR_Omniscient.trk The TR scans neither azimuth not elevation, sitting still until it magically becomes aware where to aim to lock the aircraft. When approaching 30° off the TR azimuth, it will only lock and engage an F-16 at a range of 70 nm. Presumably, getting the targeting information from its shorter range SR: SA_TR_Normal.trk *) Apart from the TR magically picking up targets outside of its antenna main lobe, I doubt it would be continuously emitting. Firstly, it would give away its location, inviting ARM attacks. Secondly, unlike an SR, the TR electronics would likely not be designed to emit continuously for hours/days, causing unnecessary wear and thus premature hardware failure. SA5_TR_Test.miz

When multiple players use dynamic spawn to spawn more or less simultaneously, they may spawn in the same parking position, resulting in multiple planes spawned inside of each other. This physically invalid state is then quickly resolved by means of pilot death, explosions, and magically levitating fireballs. This is not the first time, I've noticed this issue. Unfortunately, the associated track file is too large to upload (~80 MB). Instead, I've uploaded a fun explosion video, showing the spawn issue occurring twice in a row. First with two F-16s, then with three. Guess this is a server-side issue, with the server failing to arbitrate parking positions between simultaneously spawning players. dynamic_spawn_explosions.mp4 P.S.: Gotta praise DCS for being consistent. Rain falls downwards through ceilings, aircraft fall upwards through ceilings.

That was allegedly fixed according to the 2.9.19.13478 changelog: However, HARMs will also hit destroyed emitters with perfect accuracy. The attached .trk and Tacview files show an HTS-targeted PGM5 POS PB shot at an active P-19 followed by a second POS RUK shot. The second shot was fired shortly before the P19 was destroyed. However, it will still home on the dead P19: Tacview-20250901-193008-DCS.zip.acmiHARM_HTS_POS_hits_dead_P19.trk Same applies for an initial HTS POS shot followed by three HAS shots. All follow-up shots will home on the destroyed P19: Tacview-20250901-194932-DCS.zip.acmiHARM_HAS_hits_dead_P19.trk

@celestHawk Thank you for speaking out! I do agree with many of the points you make. Presumably, the silent majority simply accepts DCS as-is or – worse for us who stick around – simply drops DCS. Without a constant influx of new players/simmers, DCS will eventually die out for lack of funding. I'd love to see ED's statistics on retention of new users. Having started DCS two years ago, I can attest to the onboarding experience being subpar compared to other games/sims around. Without the community content, I would have been lost even more. But, as you pointed out, there's nothing like DCS, which is the only reason I stuck with it. DCS' bugs and issues puzzled me. I come from ArmA 1 thru 3 and DCS seemed like a noticeable step backwards in terms of documentation, scripting, and stability. The updater is archaic. ED promised background updates about a year ago but they never materialized. It should continue interrupted updates and also recognize insufficient disk space, though. Never had an issue with that. @Rudel_chw You are a decade-long, die-hard DCS fan. You are entitled to your opinion. However, sarcastically telling disagreeing users to just "bugger off" is against everyone's interest. DCS needs to retain and grow its user base to keep its business afloat. If a superior competitor ever comes around it may flip the switch on DCS. Having started DCS two years ago and having a software development background, I'm still unpleasantly surprised by its multitude of bugs and issues. While ED do solicit feedback and bug reports, I feel like the effort is in vain if such posts do not get acknowledged officially. In case you'd like to know more about my – certainly incomplete – technical assessment and suggestions for the DCS core, feel free to read this. No feedback from ED about it, just like several core bug reports, I've recently posted, which is frustrating. Also nothing new on the net.dostring_in() issue. An 8+ CVSS security vulnerability simply sitting around despite a mitigation being available. There's certainly room for improvement.

The DCS WebGUI app communicates with the DCS dedicated server via HTTP POST requests to /encryptedRequest. On the dedicated server, these POST requests are handled by a built-in HTTP server listening on :8088 (or whatever port configured via webgui_port in autoexec.cfg). This works well when accessing the WebGUI in a browser to communicate with a local dedicated server. Unfortunately, the URL is hard-coded into WebGUI/js/app.js as http://127.0.0.1:8088/encryptedRequest, which fails when providing access to the WebGUI via an HTTP reverse proxy. Supporting reverse proxy use would facilitate providing configurable, secure access to the WebGUI on dedicated servers without handing out the server account login credentials. This has come up in the forums a couple of times [1, 2, 3, 4]. Screenshot of the WebGUI issue with and unmodified WebGUI/js/app.js file: This issue is relatively straightforward to fix by removing the hard-coded URL from WebGUI/js/app.js and setting up the encryption key for non-local use with the following three search and replace operations: Search: dynamicUrl:"http://127.0.0.1\\:8088/encryptedRequest" Replace: dynamicUrl:"encryptedRequest" Search: "http://".concat(e.address,":").concat(e.port,"/encryptedRequest") Replace: window.location.protocol=="file:"?"http://".concat(e.address,":").concat(e.port,"/encryptedRequest"):"encryptedRequest" Search: if(e.url.includes("file:///")||e.url.includes("localhost")) Replace: if(true) Or alternatively via a single sed invocation: sed 's,dynamicUrl:"http://127.0.0.1\\\\:8088/encryptedRequest",dynamicUrl:"encryptedRequest",' app.js.orig \ | sed 's,if(e.url.includes("file:///")||e.url.includes("localhost")),if(true),' \ | sed 's;"http://".concat(e.address,":").concat(e.port,"/encryptedRequest");window.location.protocol==="file:"?"http://".concat(e.address,":").concat(e.port,"/encryptedRequest"):"encryptedRequest";' >app.js.fixed These minimal changes will enable use of the WebGUI via a reverse proxy, without affecting local WebGUI use (will work as before).

assert() is used for benign error handling. It is not a security measure against malicious code. The reverted changes attempted to address the latter.

Thanks! It does, but only with absolute paths (relative paths fail with error: 31) and string literals. That is not ideal, because the literals differ for every dedicated server instance. That requires to modify each config file instead of relying on auto-configuration. Attempting to dynamically set the writedir in options.lua via ["tacviewExportPath"] = lfs.writedir() .. "Tacview", fails for lack of the lfs module. Same with environment variables for lack of os.getenv(). Trying to set it from a hook script as follows net.dostring_in("config", [[ options.plugins.Tacview.tacviewExportPath = lfs.writedir() .. "Tacview" return options.plugins.Tacview.tacviewExportPath ]]) does set the configuration value, but Tacview fails to honor it. It uses the value set in options.lua. If you ever happen to have time on your hands, an option to save the .acmi files relative to lfs.writedir() would be greatly appreciated. Will do.

Totally worth a shot, IMHO. The Pentium only has 6% less single thread rating than my current Ryzen 9 5900X. DCS will only max out a single core and the OS scheduler should be able to manage that, unless its simultaneously transcoding some videos. Should achieve performance roughly comparable to my benchmarks with the 5900X.

Dummy response to mark as solved.

The CPU (Pentium Gold 8505) does have a fairly decent cpubenchmark.net single thread rating of 3272, which is only 36% less than a Core Ultra 9 285K. See CPU comparison. Should do fine for an average mission.

Anti-radiation missiles (ARMs) can lock on to and hit moving ships, but impacts only have limited effect on the health/hitpoints of the ship. Despite homing on radar emitters, ARM hits will not disable the radar in DCS World as of version 2.9.19.13478, because it lacks a ship damage model. This script adds the necessary event handler to permanently disable the radar of a ship that is hit by an ARM via :enableEmission(false). Works in multiplayer and on the dedicated server. Unfortunately, that will also disable all point-defense systems (CIWS) that should have independent targeting sensors, rendering ships entirely defenseless with the first ARM hit. While this is admittedly crude, IMHO, it's still a step up from DCS vanilla behavior of not modelling ARM hits on ships. Install via the mission editor: Open trigger screen (via menu item "Set rules for triggers") Triggers > New > Type: Mission Start Actions > New > Action: Do Script File > File: Open > ARMsDisableShipRadars.lua F-16 example mission (with debug messages enabled) attached: ARMs_Disable_Ship_Radars.miz Contents of attached ARMsDisableShipRadars.lua for a quick view:

Running Tacview with multiple DCS server instances on the same user account via different writedirs (DCS_server.exe -w DCS.server1..N) currently results in all Tacview files from all instances being combined into a single folder. Is there a way to have Tacview store the files within the profile/instance/writedir folder, i.e., %USERPROFILE%/Saved Games/DCS.serverN/? The only configuration option I found so far is the following registry key: [HKCU\\SOFTWARE\\Raia Software Inc.] "TacviewExportPath"="C:\\\\DCS_configs\\\\Tacview\\\\" Being part of HKCU, it results in a combined folder for all instances/writedirs as described above. What do I need this for? I maintain a project to facilitate running the DCS dedicated server on Linux via Wine. It supports multiple server instances with separate writedirs. After manual installation, Tacview runs well with it and I'd like to streamline the admin experience by separating Tacview files per server instance to provide fine-grained remote file access on a per-instance basis. Setting the directory via environment variables or alternatively a variable in the Tacview scripts or autoexec.cfg would be an option for me. Basically, any way to do this in an automated fashion would suit me. Also, to facilitate server-side Tacview deployment, I'd like to install the Tacview hook scripts and DLLs automatically. Would you be open to that? It would need a straightforward access to the relevant files, short of downloading the ~1 GB installer exe and extracting the required files from it. Feel free to DM me on this matter to discuss details.

Still bugged as of 2.9.19.13478.