MartinCo

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

Thank you so much for the speedy reply, really appreciate it!

Hi @BIGNEWY Is there any update on this ? I see it was marked as fixed internally a few patches ago but it seems like it may not have reached release as of today's patch. Thanks for all the hard work! Kind Regards, Martin

Hi @BIGNEWY I got excited seeing the change note for DCS 2.9.17.11733 Unfortunately - it seems that this only works if you are the MP server host - and it is not synchronized to connected clients Using the attached mission file If you start MP from the Multiplayer menu, jump into the truck, use the F10 menu to spawn the farp, we can see that the FARP is created, and the dynamic spawn menu is activated and populated with our new farp. If we run the same mission on a dedicated server - once the FARP is created - it is shown on the map, we can have the server query the warehouse content but the dynamic spawn menu remains unavailable If we add debugging to `Scripts\UI\MultiplayerSelectRoleMap\MultiplayerSelectDynamicDialog.lua` we can see that neither the FARP name, nor DCS.getDynamicSpawnSettings response is synchronized to the client showing the farp has no name, and the settings do not allow dynamicSpawn / hotspawn LuaGUI (Main): --dbg-- farps:90210 LuaGUI (Main): --dbg-- farps:90210 => y => 501000 LuaGUI (Main): --dbg-- farps:90210 => x => -499000 LuaGUI (Main): --dbg-- farps:90210 => name => LuaGUI (Main): --dbg-- farps:90210 => coalition => blue LuaGUI (Main): --dbg-- farps:90210 => type => FARP LuaGUI (Main): --dbg-- addFunc - dynamicSpawnAvailable => false LuaGUI (Main): --dbg-- addFunc - allowHotSpawn => false Here is a video showing both of the above routes This patch has also impacted the previous workaround of pre-creating warehouse entries in the "warehouses" file within the mission - and this workaround no longer works Track file as client running the server: server-20250622-145021.trk Track file from client of server: farp-sync-bug-20250622-145058.trk Example Mission FIle: farp-sync-bug.miz Thanks, Martin