Actium

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 likely far outside of the TR antenna main lobe width. 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.

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

I appreciate the general sentiment shared in this thread. I'll attempt to phrase it diplomatically and I admit this is entirely subjective: This forum oftentimes feels biased by many DCS zealots true believers with thousands of posts whose opinion plays an outsized role in defending DCS against general criticism. As a software developer by trade, I too feel that DCS is unsustainably buggy. I've recently detailed my personal opinion on DCS' technical state. To exemplify, just take a look at the most recent bug reports on the Lua scripting system. Most if not all of these issues could have been caught by implementing proper (automated) testing. It's bad enough to default to releasing apparently untested software to unpaid testers, i.e., us users. What makes matters worse is that even straightforward, easily reproducible bug reports have started to go entirely unacknowledged, e.g., my two most recent reports on a_do_script() and net.dostring_in(). This is the possible beginning of a vicious cycle. Why should we bother to report issues, if ED doesn't invest the time and effort to fix the bugs or – at the very least – respond to the reports?!

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.

Still bugged as of 2.9.19.13478.

If your NAS supports Docker, using Docker to install and run the DCS dedicated server is probably the solution with the least overhead and thus best performance. Running the dedicated server on Windows via a VM is very likely affected by serious performance issues.

Debian 13 "Trixie" was released last weekend. It comes with Wine 10.0, which uses Wayland by default. I've updated the git repo to get rid of the now obsolete Xwayland. A pleasant surprise, presumably dating back to DCS 2.9.16, is a significant decrease in RAM usage that allows running Caucasus and Marianas with 8 GB of RAM. You can now operate a dedicated DCS server for as little as 8 €/month on, e.g., a CX32 Hetzner Cloud server, albeit with mediocre performance (my 100 unit benchmark mission will stall out the server).

Let me chime in with both. After a decade of playing (and scripting) ArmA followed by a 5 year milsim hiatus, I've jumped on the DCS train 2 years ago. Generally, I've had a pleasant experience playing the game (after upgrading to 64G of RAM to keep DCS from crashing). I didn't even know DCS is what I've always wanted, until I started playing it after getting sucked in by the Grim Reapers Youtube channel. Right now, nothing else compares to DCS, so until a superior alternative pops up – if ever, DCS will always be the benchmark for a good military aviation milsim experience. While I don't have DCS street cred, I'm a software engineer by trade and I do have 20+ years of coding experience (concurrent, multi-threaded C/C++ systems programming). Eventually, I couldn't resist DCS Lua scripting. At that point, however, my DCS experience changed drastically, as my perspective shifted from mere entertainment seeking to software engineering: The documentation – or better the lack thereof – is frankly embarrassing. Compared to ArmA – which I also cursed at times – and its comprehensive, official scripting docs, DCS is basically undocumented. That's an absolute no go for a product that depends largely on community content creation. The DCS scripting API with its plethora of different, undocumented Lua states and another separate a_do_script() environment is terribly convoluted and thus unnecessarily complicated to work with, obviously exacerbated by the lack of documentation. I implemented a browser-based Lua console as a learning project just to figure out how everything works. What makes matters worse, is the need to maintain this improper API to avoid breaking API compatibility and a lot of community content along with it, as the recent net.dostring_in() change illustrated. Such incisive, breaking API changes should not be released without prior discussion with community developers and advance warning. The scripting API is unnecessarily buggy, up to SEGFAULTS, due to an apparent lack of even basic testing [1, 2, 3, 4, 5]. Modern coding practices, even rudimentary unit tests, and the use of appropriate tools like AddressSanitizer (possibly combined with a bit of fuzzing) should prevent introducing and releasing with such bugs. Although adhering to such practices may sound like overhead, it'll pay for itself multiple times over by obviating a lot of time otherwise wasted by inefficiently debugging code weeks/months after having modified it. The scripting API lacks very basic functions, e.g. Unit.setLife(), with ED hesitant to add it [1, 2, 3]. With the presumably dire state of the scripting system, I do however understand the reluctance to change anything. There seems to be a lack of understanding for the needs of community developers. According to %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html the net.dostring_in() function is entirely obsolete: This is grossly wrong. Many missions, mods, admin scripts, Olympus, etc. would seize to work without that very function. The mission scripting engine is still vulnerable to arbitrary code execution via malicious mission files, despite a (temporary) mitigation being available. This matter deserves urgent attention. All Lua scripting appears to run in the main loop without runtime constraints, allowing a single script with an infinite loop to freeze a client/server. That's an obvious performance issue. The first ArmA already had scheduled script execution. The DCS core presumably relies on a global, locking, all-comprising, single-threaded event loop. Adding a (few) thousand units on the far side of the map (or planet), i.e., far outside of the visibility range, will slow the renderer to a crawl. Rendering is apparently not decoupled from the simulation (i.e., AI, pathfinding, logic, flight models, etc.), although it could and should be for obvious performance reasons. This is most likely owed to DCS' single-threaded legacy. I presume a lot of engineering effort will be required to fix this. The elusive brown crater texture bug and the on-again, off-again multiplayer scoreboard issue, and more importantly the time it took to fix either of them, point towards the DCS core being non-trivial to maintain. All of these issues indicate that there's a lot of technical debt within the DCS core. Eventually, dealing with the bugs and issues caused by such technical debt will crush feature development. I agree with the previous posters that argue for better prioritization of core development time. More time should be allotted to improving the DCS core, including the scripting system and its documentation. Obviously, a full feature moratorium on the DCS core would be too much, as that would interfere with its business model. If strictly required for module releases, features need to be added. However, IMHO, too much development time may have been spent on not strictly necessary features in the past, e.g., the aircraft radio integration of the voice chat system (everyone still uses SRS), the currently incomplete mission state save feature, the botched C-ares integration, and the recent net.dostring_in() mishap to name what's at the top of my head. I love DCS and I'm confident ED can turn the ship around. Take the necessary time to stabilize the DCS core (incl. documentation, pwees!) and postpone not strictly necessary feature work for the time being. I'm hopeful the community will understand. Ask the community for feedback early on before deciding on breaking changes (I feel like the scripting system will eventually need a complete, breaking overhaul). A publicly accessible bug tracker may be another improvement. Using the forum to file bug reports may be susceptible to oversight of straightforward bug reports [1].

I finally managed to stumble over your issue. Unfortunately, I've been unable to reliably reproduce it. The root cause is a partially initialized ~/.wine WINEPREFIX directory that lacks basic DLLs like .wine/drive_c/windows/system32/kernel32.dll. There's a straightforward fix. Force a reinitialization with wineboot: rm ~/.wine/.update-timestamp wineboot --init Then simply rerun the install script, which should run without the error.

Recently pushed Commit 17647ec, which adds the "scripting" Lua state to WebConsole.lua. This new Lua state appared with DCS 2.9.18.12722, but – obviously – came without any documentation. If anyone knows what its purpose might be, please let me know. I first assumed it might be a shortcut to net.dostring_in("mission", "a_do_script(" .. code .. ")"), but it appears to lead to an entirely different Lua state.

Any updates you can share with us? Please do solicit public feedback on your idea before actually implementing it.

It was indeed supposed to pass-thru multiple return values. However, that pass-thru never worked. With the changes being reverted, I'd expect that broken pass-thru to also be reverted, returning to the old behavior. Not quite. Lua's native pcall() demonstrates how to do it properly. It returns the success boolean first and then either an error message or all return values. That enables discriminating between both cases. Unfortunately, net.dostring_in() uses the objectively wrong ordering. Simply returning nil will not allow to differentiate between a net.dostring_in() error and the executed code rightfully returning nil. For lack of an error message in case of a net.dostring_in() error condition, debugging is also complicated.

SRS version 2.2 added a native Linux command line server. I've recently pushed commit 2f81056, which uses the native SRS server in place of the Windows GUI server via Wine. That removes quite a bit of complexity. When upgrading an existing installation, you will have to manually update all instance configurations DCS.* from DCS_defaults.

The net.dostring_in() function has the following function signature to run code in the Lua environment state (type hints after the colon): net.dostring_in(state: string, code: string) -> return_value: string, success: boolean Example with Valid State (for Comparison) Run the following code via the Scripts/Hooks folder, i.e., from the "gui" state: return {net.dostring_in("mission", "return 42")} Successful return value: { "42", true } Example with Invalid State Try to run the same code inside a non-existing state: return {net.dostring_in("invalid", "return 42")} Up until DCS 2.9.17.12034, using an invalid Lua state name returned a proper error message: { "Invalid state name", false } Since DCS 2.9.18.12722, net.dostring_in() now returns only nil, resulting in an empty table: {} I've said it before: A simple unit test could have prevented releasing DCS with such basic bugs.

Thank you and the team for the quick revert! Unfortunately, that leaves the DCS client and server vulnerable to arbitrary code execution via maliciously crafted mission files. I believe a temporary mitigation should be applied until a more permanent solution has been found. The net.dostring_in() wrapper I suggested above limits the availability of net.dostring_in() from within mission scripting to the "mission" Lua state. I presume that is the primary use of net.dostring_in() to access the a_*() functions from mission scripts. IIRC, there are mission scripts out there that use net.dostring_in("gui", ...) to change/restart missions via the F10 menu. These would be collateral damage of that fix. Please do chime in if anyone has any concerns regarding that mitigation approach. As the dedicated server is also vulnerable, a suitable configuration method for both client and server (no GUI) should be found. Suggestion for a Permanent Fix IMHO, restricting net.dostring_in() use would be a too radical change in terms of API breakage. Given an option to bypass these restrictions, there will always be countless videos and posts suggesting to enable the bypass. I know quite a few people who simply remove the sanitization from MissionScripting.lua without understanding the security implications of that action. Instead, this should be fixed at the root of the vulnerability, most importantly io.open(), os.execute(), and similar functions in the io, lfs, os modules. Arbitrary read/write file system access and executing arbitrary commands are trivially exploitable vulnerabilities. File system read access should be restricted to the relevant DCS directories, i.e., lfs.currentdir(), lfs.tempdir(), and lfs.writedir(). Write permissions should be restricted even further to prevent shenanigans like changing configuration files (fundamental flaw of the now revoked security option). This is similar to what @cfrag suggested in terms of a sandboxed 'writeString()' method. Mods that require deeper file system access could accomplish that thru a self-compiled Lua .dll module (and take responsibility for whatever vulnerabilites that results in). Access to os.execute() should probably be prohibited unless explicitly enabled. Not sure how to do that securely. The only way I've seen it used is by the SRS scripts to launch the SRS client when connecting to an SRS-enabled server. As above, I'd appreciate feedback on whether any mission/mod makers believe it would break their content. @BIGNEWY Are you and the team interested in concrete implementation suggestions from the community? If so, we could discuss sth. here. If not, I'll save myself the effort.