Actium

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.

The easier way to accomplish that would be to unzip the .miz file (it is just a regular ZIP archive file). The group templates are part of the file named mission. From my experience, net.dostring_in() can return very large strings. Dozens of megabytes worked for me in the past.

I may have accidentally botched the link when removing the tracking parameters. Fixed that with proper URL-encoding and disambiguated the phrasing a bit. Hope it's clear now.

I absolutely agree that the user files need a user-experience improvement. However, I do not expect any short-term wonders to that end. A possible workaround is to use a search engine with the site:www.digitalcombatsimulator.com/en/files/ parameter to restrict the search results to DCS user files. Example with Google and "tourist". P.S: Not addressed at above posters, who I'd expect to be fully aware of that option, but rather to help the less tech savvy DCS users make better use of the user files right now.

Unfortunately, the DCS scripting API documentation – or the lack thereof – is incredibly disappointing. The scripting FAQ contains nothing on either function. The only other source I found is %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html, which is very superficial and erroneous. Expand this spoiler at your discretion to read another short rant about the state of DCS scripting engine: I implemented my WebConsole.lua with the primary intent to figure out how the DCS scripting engine works through trial and error. I've summarized the understanding I developed from that in this post. Take it with a grain of salt. Relevant quote here: The a_do_script() function provides access to the actual mission scripting environment, i.e., all LUA code run via the mission editor, e.g., thru trigger. For examples of a_do_script() use, see the links here. @BIGNEWY Please do chime in if you have any additional information and please encourage your developers to improve the documentation.

@TheHoff I have reason to believe that a KVM-hosted Windows VM running the DCS dedicated server does perform substantially worse (by orders of magnitude) than Windows running unvirtualized on the same hardware. Details including benchmarks. Running DCS_server.exe directly on the host via Wine appears to perform much better than using an intermediary Windows VM.

I've run a bunch of benchmarks that point to the dedicated server performing very poorly under KVM, which I presume winboat relies upon. Since the client and dedicated server presumably share the same code base, I'd be weary that trying to run the DCS client in a VM may affect the performance significantly. If you give it a try, make sure to benchmark it against native performance and do share you results.

@BIGNEWY Any updates on this? The arbitrary code execution vulnerability is still exploitable in both client (CVSS 8.6) and dedicated server (CVSS 8.8) as of right now. It's been exactly 10 months since I've first reported the issue confidentially along with a proof-of-concept exploit (see support ticket #176799). I understand that a proper fix that doesn't break the scripting API is a non-trivial task that will take some time. Until then, a temporary stopgap exploit mitigation should be deployed. It is reckless to leave DCS trivially exploitable. I've suggested a straightforward mitigation more than 3 months ago (ticket #190402) and also posted it in this thread, which I've updated just now to add logging. Please address security vulnerabilities with the urgency they deserve! Feel free to reach out if you need help with that. P.S.: %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html still contains the revoked security option configuration directives. Please update the documentation accordingly.

Thread wasn't moved, so I posted a new bug report in the Game Crash section: @Maverick Su-35S If you happen to have a crashdump, please post it there.

The DCS client and server quit with a "Login session has expired" popup when reconnecting to the master server after the connection had been lost for about half an hour. Said quitting now appears to trigger a delayed segmentation fault. Originally reported here. Full crash dump: dcs.log-20251003-120952.zip Annotated excerpt from dcs.log: # tabbing in and out, everything works prior to computer suspension 2025-10-03 11:15:20.855 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-10-03 11:15:22.549 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] 2025-10-03 11:16:57.822 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-10-03 11:17:02.051 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] 2025-10-03 11:21:16.576 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-10-03 11:21:17.875 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] ... # coming back up from suspension, the session check fails immediately 2025-10-03 12:06:56.534 ERROR ASYNCNET (2808): HTTP request dcs:checksession failed with error 6: Could not resolve hostname 2025-10-03 12:06:56.535 WARNING ASYNCNET (2808): Session check failed: -6 ... # a minute later, DCS decides to terminate, but lets me tab in and out anyway 2025-10-03 12:07:57.966 ERROR ASYNCNET (2808): The session has expired (401). Exiting... 2025-10-03 12:07:57.972 INFO EDCORE (Main): (dDispatcher)enterToState_:5 2025-10-03 12:08:38.747 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-10-03 12:08:42.582 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [0, 0] 2025-10-03 12:09:42.972 INFO DXGUI_WIN_ADAPTER (Main): resize main window to [2560, 1440] 2025-10-03 12:09:48.735 INFO APP (Main): application shutdown ... # two minutes later, DCS suddenly SEGFAULTs 2025-10-03 12:09:49.196 WARNING SCENE (8972): Scene was removed with 1 alive objects 2025-10-03 12:09:49.210 INFO WorldPlugIns (Main): Deinitializing plugins... 2025-10-03 12:09:50.441 INFO TERRAIN (Main): lSystem::exit() 2025-10-03 12:09:50.443 INFO TERRAIN (Main): lSystem::CleanScenes() 2025-10-03 12:09:50.443 INFO WORLDGENERAL (Main): TerrainUtility:: updated in parallel: 0, updated in the main thread: 0 2025-10-03 12:09:50.504 INFO INTER (8972): ITerrainGraphicsEntryPoint::close() 2025-10-03 12:09:50.564 INFO INTER (Main): ITerrainEntryPoint::close() 2025-10-03 12:09:51.160 INFO INTER (Main): ITerrainGraphicsEntryPoint::close() 2025-10-03 12:09:51.160 INFO INTER (Main): ITerrainEntryPoint::close() 2025-10-03 12:09:51.161 INFO EDCORE (Main): try to write dump information 2025-10-03 12:09:51.163 WARNING SCENE (8972): Scene was removed with 5 alive objects 2025-10-03 12:09:51.271 INFO EDCORE (Main): # -------------- 20251003-120952 -------------- 2025-10-03 12:09:51.273 INFO EDCORE (Main): DCS/2.9.20.15384 (x86_64; MT; Windows NT 10.0.19045) 2025-10-03 12:09:51.275 INFO EDCORE (Main): C:\Games\DCS World OpenBeta\bin\lua.dll 2025-10-03 12:09:51.277 INFO EDCORE (Main): # C0000005 ACCESS_VIOLATION at 00007ff9994817d0 00:00000000 2025-10-03 12:09:51.279 INFO EDCORE (Main): SymInit: Symbol-SearchPath: 'C:\Games\DCS World OpenBeta\bin;', symOptions: 532, UserName: 'user' 2025-10-03 12:09:51.281 INFO EDCORE (Main): OS-Version: 10.0.19045 () 0x100-0x1 2025-10-03 12:09:51.282 INFO EDCORE (Main): 0x00000000000017d0 (lua): lua_gettop + 0x0 2025-10-03 12:09:51.284 INFO EDCORE (Main): 0x00000000000761eb (edCore): Lua::Config::Config + 0x1B 2025-10-03 12:09:51.286 INFO EDCORE (Main): 0x0000000000a980de (DCS): SW + 0x47BEAE 2025-10-03 12:09:51.286 INFO DX11BACKEND (8972): DX11Renderer::shutdown() 2025-10-03 12:09:51.288 INFO EDCORE (Main): 0x0000000000a97c32 (DCS): SW + 0x47BA02 2025-10-03 12:09:51.290 INFO EDCORE (Main): 0x0000000000a9078b (DCS): SW + 0x47455B 2025-10-03 12:09:51.290 INFO EDCORE (Main): 0x0000000000a45aaf (DCS): SW + 0x42987F 2025-10-03 12:09:51.291 INFO EDCORE (Main): 0x000000000015a56a (Visualizer): smSceneManager::DestroySceneManager + 0xCA 2025-10-03 12:09:51.291 INFO EDCORE (Main): 0x0000000000a66f36 (DCS): SW + 0x44AD06 2025-10-03 12:09:51.291 INFO EDCORE (Main): 0x00000000025b8da1 (DCS): AmdPowerXpressRequestHighPerformance + 0x1097D9D 2025-10-03 12:09:51.291 INFO EDCORE (Main): 0x00000000010dac82 (DCS): SW + 0xABEA52 2025-10-03 12:09:51.291 INFO EDCORE (Main): 0x0000000000017374 (KERNEL32): BaseThreadInitThunk + 0x14 2025-10-03 12:09:51.504 INFO EDCORE (Main): Minidump created.

The dedicated server actually runs hassle-free on vanilla Wine. Unfortunately, the performance is worse than Windows on bare metal. Coincidentally, Wine 10.16 with upstreamed NTSYNC support came out last week. I'm expecting/hoping/praying for that to make a significant performance impact, but I haven't had the time to run new benchmarks.

Lolz. Exact same situation here. No need to apologize. Glad we could clear that up.

My genuine apologies for my curt inquiry if it came across as impolite! I've read the entire thread and was merely curious as to where that information originated from, as I've never read anything about it and – as you rightfully mentioned – ED could improve in terms of documentation and answering technical questions on this forum. I appreciate your efforts to step in!

S_EVENT_SHOT triggers when firing a weapon, not when it impacts. Dunno whether S_EVENT_HIT will trigger when a bomb hits the ground without damaging any units. Also unsure whether your use of addEventHandler() is correct. See here for an exemplary use of S_EVENT_HIT to detect (H)ARMs that hit a ship: