Actium

I've reported almost a dozen bugs within the last 6 months, some even with workarounds or fixes*. Unfortunately, zero have received any attention and tagging @BIGNEWY multiple times hasn't helped. While some of my reports are clearly nice-to-have fixes, others relate to core bugs that -- at the very least -- should end up on your internal bug tracker for triage in a timely manner. For the lack of that, reporting bugs feels like a total waste of my time. *) Being tired of repeatedly applying my workarounds and fixes after every update, I've now resorted to automating that.

Try my FPSmon.lua. Most likely, the server is stalled out at way below 1 simulation frame per second. Was that with a recent experience with the multi-threaded DCS_server.exe? Just doing educated guesswork here, so take it with a grain of salt, but I believe the multi-threading implementation may have thrown a wrench into the gears of KVM. When using Wine to run the dedicated server on bare metal, whether NTSYNC is used or not makes an insane two order of magnitude difference in the 10% percentile. NTSYNC vastly improves the performance of multi-threaded synchronization. I've had a closer look and DCS_server.exe main thread alone racks up about 50k synchronization primitive syscalls per second, accumulating to 1.19 seconds within a 10 second observation time while running my benchmark framework with the Benchmark_200_*.miz mission: I'd assume that the overhead of thread synchronization primitives is vastly higher on VMs, assuming the kernel suspends the VM thread while waiting. Wouldn't be surprised by an order of magnitude deterioration compared to bare metal execution. That alone would be a reasonable explanation for a stalled dedicated server, as the accumulated 1.19 second synchronization wait time just multiplied into 11.9 seconds.

Quick update on my ntsync endeavors, to avoid the occasional bleeding edge performance nut among you some pain: While the dedicated server runs flawlessly with the development version of Wine, the updater refuses service, alleging that a debugger is running, which is definitely a false positive: I'm also working on some overdue architectural improvements: An HTTP server that hosts noVNC and the WebGUI via suitably configured reverse proxies to simplify access. While I was at it, I also tried to get Olympus up an running. Although setting it up is deceiving simple and the Olympus frontend runs with Debian Trixie's nodejs out of the box, unfortunately, the Olympus backend depends on the HttpShutdownRequestQueue() function that is not implemented by Wine: wine: Unimplemented function httpapi.dll.HttpShutdownRequestQueue called at address 00006FFFFF3BD887 (thread 02c4), starting debugger... No easy fix/workaround for that. Either implement the missing function(s) in Wine or modify the Olympus backend to use a different server framework. Any volunteers?

Sorry, no immediate idea about that. I don't have extensive experience wrt. spawning units with tasks and everything.

The Lua io module is not available in the mission scripting environment, unless you remove the sanitization in %DCS_INSTALL_DIR%/Scripts/MissionScripting.lua (not recommended). The io module is however usable from the server Lua environment, which also has access to the mission data in _G.env.mission. I did some digging in my unit spawn code to find what you might have been looking for: -- minimal table deepcopy (copies only tables, skips metatables) -- NOTE: use to copy the group table before modifying it to spawn a new group function deepcopy(tbl) local _copy = {} for _key, _value in pairs(tbl) do if type(_value) == "table" then _copy[_key] = deepcopy(_value) else _copy[_key] = _value end end return _copy end -- find aircraft group by name in _G.env.mission function find_group_by_name(grp_name) -- find aircraft group by name in _G.env.mission for _, _coalition in pairs(env.mission.coalition) do for _, _country in pairs(_coalition.country) do -- TODO: support different categories (not just Group.Category.AIRPLANE) if _country.plane ~= nil then for _, _group in pairs(_country.plane.group) do if _group.name == grp_name then return _group end end end end end -- name not found return nil end return find_group_by_name("Aerial-1") Run that in *a_do_script, scripting, or mission environment with my WebConsole to get the group definition. My console does not support Lua serialization, so it will be returned as JSON.

Presumably with the recent F-14 update, two .gitkeep files made it into both client and server deployments. I highly doubt these files were put there intentionally, merely for lack of any logical reasons to do so. Both client and dedicated server attempt and fail to load these files as livery ZIP archives: 2025-10-24 18:26:03.326 ERROR EDCORE (5320): Drivers errors while mounting coremods/aircraft/f14/liveries/f-14a-135-gr-early/.gitkeep: 2025-10-24 18:26:03.326 ERROR EDCORE (5320): ZipDriver: Failed to open zip archive coremods/aircraft/f14/liveries/f-14a-135-gr-early/.gitkeep. 2025-10-24 18:26:03.347 ERROR EDCORE (5320): Drivers errors while mounting coremods/aircraft/f14/liveries/f-14a-95-gr/.gitkeep: 2025-10-24 18:26:03.347 ERROR EDCORE (5320): ZipDriver: Failed to open zip archive coremods/aircraft/f14/liveries/f-14a-95-gr/.gitkeep. P.S.: Just me rambling about (unit) testing again. This could have been easily caught by checking the dcs.log for error messages (PowerShell: Select-String -Pattern ERROR dcs.log). Starting a vanilla DCS install shouldn't result in any error messages at all.

I recently ran my DCS server benchmark with the Benchmark_200_v2024.11.23.miz, which includes a bunch of TU-22M Backfires being shot out of the sky. The resulting log file contains repeated error messages about the GRAPHICSVISTA module being unable to load a Backfire wing model. However, the dedicated server has no renderer and thus should not call the graphics code path at all. Log excerpt: 2025-10-26 09:07:26.780 INFO Scripting (Main): event:weapon_type=6038116,initiatorPilotName=Patriot str,target_coalition=1,linked_event_id=959,targetMissionID=272,target_ws_type1=1,initiator_object_id=16816385,target=Tu-22M3,target_object_id=16786689,targetPilotName=Tu-22M3,type=hit,target_unit_type=Tu-22M3,t=149.912,initiator_unit_type=Patriot str,event_id=1014,weapon=MIM-104 Patriot,initiator_ws_type1=2,initiatorMissionID=1,initiator_coalition=2, 2025-10-26 09:07:26.780 INFO Scripting (Main): event:weapon_type=6038116,initiatorPilotName=Patriot str,target_coalition=1,linked_event_id=0,targetMissionID=272,target_ws_type1=1,initiator_object_id=16816385,target=Tu-22M3,target_object_id=16786689,targetPilotName=Tu-22M3,type=bda,target_unit_type=Tu-22M3,t=149.912,initiator_unit_type=Patriot str,event_id=1015,weapon=MIM-104 Patriot,initiator_ws_type1=2,initiatorMissionID=1,initiator_coalition=2, 2025-10-26 09:07:26.780 ERROR GRAPHICSVISTA (Main): Can't open model TU-22-OBLOMOK-WING-R. 2025-10-26 09:07:26.780 WARNING LOG (12112): 1 duplicate message(s) skipped. 2025-10-26 09:07:26.780 ERROR GRAPHICSVISTA (Main): Can't open model TU-22-OBLOMOK-WING-L. 2025-10-26 09:07:26.780 INFO Scripting (Main): event:type=ai abort mission,initiatorPilotName=Tu-22M3,t=149.912,initiator_unit_type=Tu-22M3,initiator_object_id=16786689,linked_event_id=0,event_id=1016,initiator_coalition=1,initiator_ws_type1=1,initiatorMissionID=272, 2025-10-26 09:07:26.782 ERROR GRAPHICSVISTA (Main): Can't open model TU-22-OBLOMOK-WING-L. Full log: Benchmark-20251026-2.9.21.16362.dcs.log.zip I'm reporting this, because the non-rendering dedicated server may perform significant worse than the rendering client. If the dedicated server needlessly calls the rendering code path, this could be a piece of the puzzle.

@BIGNEWY Still bugged as of DCS 2.9.21.16552.

That happens when the server simulation frame rate drops far below 1 FPS. Unfortunately, the DCS client does not warn about that condition. Because of that, I've written the FPSmon.lua script that warns about such situations in global chat to simplify performance debugging. So this happens with the dedicated server (DCS_server.exe), but not when using the regular client with GUI and 3D-renderer (DCS.exe) to host a mission?

It would be pretty straightforward for the master server to check whether the reconnecting client is the most recent client it authenticated. The master server already assigns clients a presumably random session ID upon login. If the most recent session ID reconnects, re-authenticate it, but terminate all other clients with (older) session IDs. That would result in legitimate termination of multiple simultaneous client sessions, while leaving legitimate, single client instances with connection outages alive. Unfortunately, ED do not seem to care too much about this issue.

You're welcome. Most likely explanation would be infinite recursion.

Both functions take Lua code as a string argument. net.dostring_in() can only return a string, but a_do_script() can return tables, too. However, its return value pass-thru is currently somewhat broken. If all you want is getting a group template, just unzip the .miz file, open the extracted file named "mission" with a text editor and get the group data from there. No need to deal with traversing and converting the table programatically. Just copy & paste.

@BIGNEWY Did the team have a look? This is still bugged as of 2.9.21.16362.

Unfortunately, I don't run the client on Linux, just the dedicated server. There's a Linux support group on the Tactical DCS Discord, which may be of help to you: https://discord.com/channels/679370848439894046/1261038965612613634 (you probably need to join the Discord server before that link works). Otherwise I previously stumbled over Hoggit Wiki Page and this Github repo. That's it. Sorry.

The Wine development version 10.16 with ntsync support was released 3 weeks ago. Finally got around to do some benchmarks and my naive dreams expectations were met: Performance parity with Windows Results when comparing the frame times of DCS_server.exe v2.9.21.16362 with Benchmark_200_v2024.11.23.miz on Windows 10, Wine 10.17 without ntsync, and Wine 10.17 with ntsync: While Windows still has a minimal but measurable performance advantage, the results are so close that no difference can be perceived. As always, benchmark code and mission as well as my raw measurement data are available: Benchmark-20251026-2.9.21.16362-Wine-10.17.log.gz Benchmark-20251026-2.9.21.16362-Wine-10.17+ntsync.log.gz Benchmark-20251026-2.9.21.16362-Windows-10.log.gz Planning to do some further tests before rolling this out, likely along with the Wine 11 stable release due in about 3 months.