Actium

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.