Actium

I'm looking for a way to immersively take an (aerial) unit off the board via mission scripting. By immersive I mean killing the crew/pilot, ejecting the crew/pilot, crashing the unit into the ground, stopping its engines (e.g., by removing all fuel), or -- as a last resort -- exploding it mid-air. My application is the removal of units that aborted their mission to keep them from returning home. Example code run via a MISSION START trigger DO SCRIPT action (NOTE: only use a single removal method at a time): local eh = {} function eh:onEvent(event) if event.id == world.event.S_EVENT_AI_ABORT_MISSION then -- FIXME: unit vanishes into thin air -> lame event.initiator:destroy() -- FIXME: brute force approach. will it work reliably in multiplayer with desync/lag? trigger.action.explosion(event.initiator:getPoint(), 10) -- FIXME: not available from the mission scripting environment (i.e., a_do_script()) a_unit_set_life_percentage(event.initiator:getID(), 0) a_explosion_unit(event.initiator:getID(), 10) end end world.addEventHandler(eh) I do not want to vanish the unit via :destroy() and trigger.action.explosion() feels very brutal and prone to fail in multiplayer. DCS actually comes with ways to kill the unit by setting its life to 0% (forces crew ejection) and selectively exploding it via trigger actions: However, neither is available from the mission scripting environment via trigger.action.*(). Digging inside the mission_file.miz/mission lua code reveals the two functions a_unit_set_life_percentage(2, 0) and a_explosion_unit(2, 10). Unfortunately, neither is available from the mission scripting environment (i.e., a_do_script()), with above code resulting in: 2025-02-01 04:56:11.955 ERROR SCRIPTING (Main): Mission script error: ... attempt to call global 'a_unit_set_life_percentage' (a nil value) Is anyone aware of a way to access the UNIT AI SET LIFE and/or EXPLODE UNIT trigger actions via mission scripting, e.g., above event handler?

While not exactly what you ask for, you can mute log messages with levels below warning, only for the missions scripting environment (instead of all info messages as above example from Gater): log.set_output("dcs", "SCRIPTING", log.WARNING, log.FULL)

This bug/feature is fixed as of DCS 2.9.12.5336:

The hooks are not accessible from the mission scripting environment. You have to create a DCS Control API hook script, e.g. %USERPROFILE%\Saved Games\DCS.dcs_serverrelease\Scripts\Hooks\ProhibitNamePlayer.lua with the following content (untested code, but shouldTM be working) : -- SPDX-License-Identifier: MIT -- callback object, see DCS API documentation for details: -- * file:///C:/DCS_INSTALL_PATH/API/DCS_ControlAPI.html -- * https://wiki.hoggitworld.com/view/Hoggit_DCS_World_Wiki local myhook = {} function myhook.onPlayerTryConnect(addr, name, ucid, id) if name == "Player" then return false, "Name 'Player' not permitted. Please change your name!" end end -- register callback if this is a server instance if DCS.isServer() then DCS.setUserCallbacks(myhook) end

Should be possible via the onPlayerTryConnect hook: function myCall.onPlayerTryConnect(addr, name, ucid, id) if name == "Player" then return false, "Name 'Player' not permitted. Please change your name!" end end

This makes perfect sense. Thank you for the explanation!

The ILS of Tbilisi-Lochini runway 31L appears to be broken. Tuning to its frequency (108.90 MHz) on an F16 ILS/PLS results in receiving in static/noise* instead of morse code. The DED T-ILS page also does not indicate an ILS lock. Tuning to the ILS frequency of the opposite runway (110.30 MHz) results in receiving morse and an immediate ILS lock, albeit nonsensical. Screenshots and example mission attached. *) Curiously, tuning to other valid frequencies (e.g., 108.70 MHz) does not result in static, but silence and an unlocked ILS. Update: This is with the most recent DCS version (2.9.11.4686). Tbilisi_No_ILS_Rwy_31L.miz

Likely, that's a bug in DCS' handling of the default value for the so-called writedir, which is set through the DCS_server.exe -w INSERT_NAME_HERE command line parameter. When not set, I presume, it defaults to both DCS.release_server and DCS.dcs_serverrelease. The latter, you can see in the dedicated server window title, so I'd assume that to be the main directory. While I'd expect QA to detect such basic issues, this has been around since at least DCS 2.9.9, which was when I first stumbled over it. To mitigate this bug, start the dedicated server with a valid -w parameter, e.g., by creating a shortcut (via right click > new > shortcut), editing it (right click > properties), and adding -w DCS.server1 to the very end of the target field (after the final quote).

TL;DR: FPSmon.lua sends warnings messages to global chat if the server simulation frame rate or peak frame time falls below or exceeds configurable thresholds to help identify situations where low server performance may cause excessive lag. The simulation frame rate of the DCS server may deteriorate rapidly when the server is overloaded. Particularly missions with many actively engaged units exchanging shots may cause extreme frame times (far) in excess of 1 second. Low server simulation frame rates will limit the update rate of units other than the own on every client. While DCS clients extrapolate server frames for smooth movement of other units, extrapolation has its limits. When the DCS extrapolator is pushed beyond its limits, units move smoothly (on a continuously differentiable line), then jump suddenly, only to move smoothly again afterwards. Reasons include network issues (high ping or packet loss) or excessive server simulation frame times. Whereas ping is shown in the player list, DCS includes no metric or mechanism to warn about server performance issues (low frame rate or high frame times). The WebGUI does not issue direct warnings either. However, it does serve as a canary by updating/responding sluggishly if the server is extremely overloaded. This script periodically checks the average server simulation frame rate and peak frame time within a configurable interval (defaults to 30 seconds). If the frame rate falls below or the frame time exceeds their respective, configurable threshold, a warning message including both values is sent to global chat and also logged to the default DCS log file (Logs/dcs.log). The chat messages are also visible in the WebGUI. The following example screenshot illustrates chat output of three frame time outliers despite good average frame rate. The final warning message indicates a low average frame rate and therefore an overloaded server. Optionally, every periodic measurement can be logged by setting fpsmon_verbose = true in autoexec.cfg (see below). When enabled, this results in the following dcs.log content (when disabled, no INFO messages will be logged): 2024-12-19 16:10:46.310 INFO FPSmon.lua (Main): avg_fps=111.10 peak_frame_time=0.013 2024-12-19 16:11:16.315 INFO FPSmon.lua (Main): avg_fps=111.08 peak_frame_time=0.011 2024-12-19 16:11:46.316 INFO FPSmon.lua (Main): avg_fps=111.09 peak_frame_time=0.014 2024-12-19 16:12:16.325 INFO FPSmon.lua (Main): avg_fps=111.10 peak_frame_time=0.010 2024-12-19 16:12:46.329 INFO FPSmon.lua (Main): avg_fps=111.09 peak_frame_time=0.010 2024-12-19 16:13:16.332 INFO FPSmon.lua (Main): avg_fps=110.82 peak_frame_time=0.077 2024-12-19 16:13:46.337 WARNING FPSmon.lua (Main): avg_fps=108.35 peak_frame_time=0.756 2024-12-19 16:14:16.341 WARNING FPSmon.lua (Main): avg_fps=103.02 peak_frame_time=0.757 2024-12-19 16:14:46.348 INFO FPSmon.lua (Main): avg_fps=111.07 peak_frame_time=0.013 2024-12-19 16:15:16.352 INFO FPSmon.lua (Main): avg_fps=111.12 peak_frame_time=0.010 The intention behind this script is to help both mission development and deployment. During development, mission designers and server administrators can identify performance bottlenecks early on. If frame times grow too high, the mission should be simplified or the server hardware upgraded. In deployment, the script transparently informs and warns players of server performance issues, to faciliate pinpointing the cause of laggy units. Install by downloading FPSmon.lua into the DCS Scripts/Hooks folder, e.g.: %USERPROFILE%\Saved Games\DCS.dcs_serverrelease\Scripts\Hooks Optionally, the script can be configured via your autoexec.cfg. Without configuration, the script will use default values. If desired, add the following to %USERPROFILE%\Saved Games\DCS.*\Config\autoexec.cfg and modify the values to suit your needs: -- configure Scripts/Hooks/FPSmon.lua: -- interval of FPS log and chat messages (seconds), use zero (0) to disable (number) fpsmon_interval = 30 -- always log frame rate and peak frame time at every interval even if tresholds are not exceeded (boolean: true|false) fpsmon_verbose = false -- FPS (Hz) and frame time (seconds) thresholds to send warning messages to global chat (number: >0) fpsmon_warn_fps = 5 fpsmon_warn_time = 0.5

Myself annoyed by the error popups (which will also happily freeze a dedicated server), I've written a hook script that will automatically disable the popups. However, to aid in debugging, it will send the logged error message to global chat, so errors are less likely to go unnoticed.

TL;DR: NoErrPopup.lua disables the mission scripting error message popups on servers to prevent a potentially irrecoverable server-only freeze. By default, it will send error messages to global chat. DCS World defaults to open error message popups if an error occurs in the mission scripting environment. These popups freeze the simulation until each popup is closed manually. The dedicated server DCS_server.exe is also affected. A mission scripting error triggers a popup on the server, which stalls the server. From a client perspective, this freezes all units except for the local client. As no client-side error messages are displayed, the frozen/stalled server condition cannot be detected by clients. The WebGUI will also be unresponsive. Without direct or remote (RDP/VNC) access to the server, which is not available for most if not all managed servers, this issue is irrecoverable without support intervention or a server restart. The error popups can be disabled via env.setErrorMessageBoxEnabled(false) in the mission editor. However, this must be done in each mission with an appropriate MISSION START trigger. As this approach hampers debugging, it would necessitate separate mission files for production and debugging. NoErrPopup.lua runs env.setErrorMessageBoxEnabled(false) inside the mission scripting environment after a mission has been loaded via a server-side hook script, obviating the need to explicitly disable the popups in each mission. By default, mission scripting error messages will be sent to global chat to facilitate debugging and/or to notify clients that a server-side scripting error has occurred, as it may or may not affect the playability of the current mission. When disabling this feature, mission scripting errors will only be logged to Logs/dcs.log (default DCS behavior). If enabled, error error chat messages will be visible to clients and inside the WebGUI as follows: Install NoErrPopup.lua by downloading it into the DCS Scripts/Hooks folder, e.g.: %USERPROFILE%\Saved Games\DCS.dcs_serverrelease\Scripts\Hooks Optionally, the script can be configured via your autoexec.cfg. Without configuration, the script will use default values. If desired, add the following to %USERPROFILE%\Saved Games\DCS.*\Config\autoexec.cfg and modify the values to suit your needs: -- configure Scripts/Hooks/NoErrPopup.lua: -- do not send error messages to global chat (boolean: true|false) noerrpopup_mute = false