MartinCo

Sorry! You're absolutely right for the miz embedded ME placed FARP However adding hiddenOnMFD to the addStaticObject call to create the FARP does not work and it still shows up on the TSD in the apache that spawns after. local farp = coalition.addStaticObject(country.id.RUSSIA, { ["category"] = "Heliports", ["shape_name"] = "FARP", ["type"] = "FARP", ["x"] = -83000, ["y"] = 852000, ["name"] = "Spawned FARP", ["heading"] = 0, ["dynamicSpawn"] = true, ["hiddenOnMFD"] = true, }) farp:getWarehouse():setItem("UH-1H", 10) trigger.action.outText("FARP Spawned", 10) This is different to both my previous reports that have both either been acked, or fixed in the case of the ch47: - NS430 - reported - CH47 - reported + fixed Note if you jump into the CH47 - neither the ME, nor spawned hostile farp is shown in the nearest airports etc (only friendly ones if present) null So there is certainly some inconsistency here and maintain there is an issue to address

Using attached miz: ah64-enemy-farp.miz Map options enforced allies only Occurs both in single player and multiplayer Reproduction: * Spawn in AH-64 * Navigate to TSD and observer a control measure slightly to the west * Use the F10 menu to spawn a new farp (approx 1nm to the east) * Note that this is not shown on the TSD * Change Slot / Reslot on the AH64 * Note that we now have both hostile farps shown as control measures on the TSD This causes a real issue on multiplayer servers that wish to have players stealthy offensive farps DCS Version: 2.9.21.16362 Track file: ah64-hostile-farp.trk

Thank you so much for fixing the dynamic farps - they're working really well so far and a massive quality of life improvement along with the onPlayerTryChooseCoalition hook, it's very much appreciated! However, we have noticed that when you spawn on a dynamically spawned farp in MP, you are unable to open the briefing with the following shown in the client logs 2025-10-24 19:45:39.789 ALERT LUACOMMON (Main): Error: GUI Error: [string "./Scripts/UI/autobriefingutils.lua"]:241: Invalid arguments! Cannot read the position. GUI debug.traceback: stack traceback: [C]: ? [C]: in function 'getTemperatureAndPressureAtPoint' [string "./Scripts/UI/autobriefingutils.lua"]:241: in function 'createSectionGrid_' [string "./Scripts/UI/autobriefingutils.lua"]:321: in function 'updateScrollPane' [string "./Scripts/UI/BriefingDialog.lua"]:378: in function 'updateBriefing' [string "./Scripts/UI/BriefingDialog.lua"]:222: in function 'update' [string "./Scripts/UI/BriefingDialog.lua"]:196: in function 'show' [string "./Scripts/UI/GameMenu.lua"]:377: in function 'onChange' [string "./dxgui/bind/Button.lua"]:22: in function 'callback' [string "./dxgui/bind/Widget.lua"]:375: in function <[string "./dxgui/bind/Widget.lua"]:370> Reproduction: * Load attached mission on dedicated server (this does not happen if you run the server from within the ME) * Enter the truck, use the F10 menu to spawn farp * Use the Dynamic spawn menu to spawn at the farp * Try to open briefing, it does not open * View logs Setup: DCS 2.9.21.16362 - clean, no mods/scripts/hooks Miz file: dynamic-farp-briefing.miz Client Track: dynamic-farp-briefing-20251024-204428.trk Client Log: dcs.log Server Track: server-20251024-204425.trk

Thank you @CaptHawk for keeping on top of testing this for us all! I check in each patch and you are on fire at updating this thread. @BIGNEWY would you be able to let us know if this is reported for the team (I'm wondering if the reported was for the original issue and something that is believed to be sorted since the DCS 2.9.17.11733 patch) Really appreciate all the work Thank you, Martin

Hi All, I know this has been a problem for years and I'm sure there is an existing topic for it but I cannot for the life of me find it - with the recent introduction of the NS430 with the MiG-29 there has been renewed interest in it's availability on servers. Reproduction: * Map Option Allies only * Place 1 friendly and 1 hostile farp * Open NS430 * Navigate to Nearest Airport * Observe list of both friendly and hostile farps. This is a problem on servers like mine where we make use of player deployed dynamic farps for offensive operations and wish for them to be hidden. Please find attached track: NS430-Hostile-Farp.trk Thanks, Martin

Yea, I deffo didn't do it manually! that's what I meant with python mss (screenshots) and LoSetCameraPosition and just work your way around the whole map, so used a socket connection to have python send the next coordinates and DCS updated there Since roads are nearly all the same colour you can just do it from the map - you can see them in pink in the image above Sorry little nose for the slight hijack here!

I just hit it off overnight and can't remember - I last did the process last year or so on Kola after an update since it's a once it's done it's done sorta thing - also used the f10 to bring it into combat flite via QGIS / transform files Since the F10 is rendered on demand, you have to sleep for a bit between setting the camera position and taking the screenshot to pre render - the screenshot collection is of course the main time sink but is a one time thing

Ah you should have just asked We do exactly that I took 14 thousand or so F10 screenshots (with a bit of overlap for the top bar and map/topology options top right ) using python mss and a socket to lua export to use LoSetCameraPosition to move out position to get consistency Then stitched them all together into 5k grids (since the full image is 292,400 by 167,810 pixels and deffo don't have ram for that Then another python script to quantize that into 20m or so sectors and just did rgb comparison if tree + forest background Multi threaded that into a byte array for parallelization After that did multiple fill/infill passes to capture where a sector was surrounded by forest on day 2 or 3 blocks around it took was upgraded to forest and similar for deselecting Then another pass for edge detection on all the areas so we could distinguish between forest, deep forest and road or so Since the data I care about fits in 2 bits (nothing, forest, deep forest), I packed the results into a simple byteareay with 4 sectors per byte to save a ton of space After that it's just a conversion DCS xz to array offset and read the required bits That allows us to also visualize the output for validation A very low resolution version for visualisation https://strategic-dcs.com/storage/caucasus_overlay.jpg

Hi ED, I did a search and didn't find a topic for this outside of a comment in the main thread and as it has been quite a while - I felt it was worth creating it's own thread to confirm if it has been reported / and so others might find it - hopefully it's not a duplicate Many servers disable skin selection and set the skin on the modules, when using dynamic spawns, this is not carried through to the unit and selects the default skin - in the case of the F15, this uses an Isreali skin that causes some political discomfort across members of servers leaving the admins with a choice between enabling the skin selection, or not using dynamic spawns. Mission file: dyn-template-skin.miz * Open up in ME * Launch Multiplayer Server * Select template slot and spawn, note 64th agressors skin * Release Slot, Select Dynamic slots and load in at Kobuleti * Do not have skin from template Thanks, Martin

Right - but this is pin point accurate after turning them off immediately after launch from more than 30nm without much time to evaluate and refine the target and reduce the CEP I just downgraded to the previous patch (DCS 2.9.17.12034) and they all missed, both in HAS, POS/EOM etc. which is very different to the current patch

It was the AGM-88D that got upgraded to have GPS and ability to engage targets after turning off their radar - not our AGM-88C (which to my knowledge only used radar homing) Just tested in POS/EOM just toggle launch too - ripple them all within a few seconds and then turn off the emitters - still precise hits from 35+nm This does make all IADS systems / Skynet etc. a bit pointless (since if the harm will hit anyhow, no point going silent) - and didn't used to be the case (else these projects wouldn't have existed!)

Thank you for the fix in DCS 2.9.18.12722!

Hi ED, Since the introduction of Dynamic slots and the "All spawn/parking slots are occupied" pop up message, it would be really great if we could return a tuple on onPlayerTryChooseSlot like onPlayerTryConnect so that we can customize the message to avoid confusion. At present, we must send the player a chat message, and hope they have the window open to explain why the slot block is in effect. Reproduction Ideally, we could use a hook as follows (which allows for backwards compatibility) in Server\Scripts\Hooks to return the tuple: DCL_HOOKS = {} DCL_HOOKS.cb = {} DCL_HOOKS.cb.onPlayerTryChangeSlot = function(playerID, side, slotID) -- If we try spawn a huey at FARP1, fail else we bubble local slot_name = DCS.getUnitProperty(slotID, DCS.UNIT_NAME) if string.sub(slot_name, 1, 11) == "FARP1_UH-1H" then net.send_chat_to("Blocked access to UH-1H at FARP1", playerID) return false, "Blocked access to UH-1H at FARP1" end return nil, nil end DCS.setUserCallbacks(DCL_HOOKS.cb) Launch Mission on Server: SlotBlock-Blocked.miz Try slotting in UH-1H at FARP1 Thanks, Martin

Hi ED, With the most recent patch HARMs are pin point accurate even when the radars are set to enableEmission false, setOnOff false, or the alarm state green after a launch. I have rolled back to DCS 2.9.17.12034 and this behavior was not present. I believe this is true in the 18 as well (based on earlier thread) and a general HARM issue. DCS Version: DCS 2.9.18.12722 Reproduction: * Set up HAS for BB, SD, P, HK * Launch one harm at each target at > 30nm * setEmission Off via F10 menu * Note that RWR indications are removed as they are off * HARMs continue and precisely hit all 4 targets It seems the HARMs have the precise coordinates immediately and INS rather than radar homing Video: Please find mission/track: Mission: harms.miz Track File: harm-emission-off-tracking.trk Thanks, MartinCo

Tested again with DCS 2.9.18.12722 and the issue remains