Hardcard

You mean this? Your Caucasus map should be included in the game, imho. You did awesome work (Any chances of you doing PG / Syria in the future?) Looks like this has been around for years, I've found a reference to it from 2015: I don't think this is related to the problem, but I might be wrong, ofc.

@Flappie Oh ok, thanks. Here's a fresh dcs.log, it was recording during the last session, I experienced the issue a few minutes into the game. dcs.log

I don't know what that is, never used it. Sure, I'll post it next time this happens, thanks.

Thanks @Flappie for looking into the issue. I don't think the issue is limited to MP, though, since people are experiencing it in Mission Editor and main menu as well (myself included): If this were a BF server issue, the effects wouldn't extend to all icons and buttons in DCS, would they? Something is breaking the UI of the entire game. As for BF PG, I'm experiencing this issue a lot, but it doesn't seem to be time related, I'm not sure of what triggers it. Sometimes I lose the icons after just 2 minutes in JTAC slot, sometimes it holds for 10 minutes or longer... but it always ends up happening, it's really annoying. I've performed a clean install of all my modules (including CA), graphics drivers, tried with and without firewall, removed my DCS saved games folder, ran several DCS repairs, etc. No idea of what's causing it, but if you're going to test BF PG, I'd stay in JTAC slot for at least 1 hour (placing marks, selecting units on the map, using the ruler tool, etc.).

Can someone at ED acknowledge the issue, please?

Can somebody at ED acknowledge the issue, please?

Problem persists in latest OB 2.7.0.5118

Problem persists in latest OB 2.7.0.5118

Apparently this issue isn't unique to MP, it also happens in Mission Editor:

Same here, this requires an urgent fix

@Poulet67 Tbh, when I saw the new "start from ground" feature in the 2.7 changelog, my first thought was... I haven't tested it yet, since I'm experiencing unrelated problems with 2.7, I hope that what @reece146 said is true in most cases.

Same here, I can't do GCI in BlueFlag PG because of this issue. Buttons are still there, but they're invisible. Btw, it's not just the F10 map UI buttons that disappear, it's all window buttons in DCS (can only be fixed with a game restart) I never encountered this issue before 2.7, so I'm guessing it's a new bug introduced by 2.7.

@Vakarian I took no offense, it's just that the claim "scripts break stuff" is flawed and misleading. Also, you insist on calling it a mod, but it's a script that uses DCS scripting functions, just like Mission Editor does. It doesn't add or change anything in DCS, simply runs a routine that automatically spawns and removes replacements for the clients that you choose, using the same scripting functions that the game uses. Finally, you say you're used to empty bases and that you have no lack of patience, but you're bumping a wish list thread for a feature that ED is unlikely to implement (threads like this one are usually ignored, let's be honest, specially when there's only a handful of people requesting the feature). I don't know, it looks kind of hail Mary-ish to me, that's why I recommend SWAPR, but if you are set in your ways, I won't insist. I'm the same way regarding other people's scripts, btw.

@Vakarian You do realize that the same applies to your Mission Editor triggers, right? Mission Editor is basically an interface that outputs a bunch of scripts. If you fail to specify valid conditions for your ME triggers, you'll encounter the same problems, because it's all based on scripts. Now, as I see it, you have only a few options here: - Wait for ED to implement client replacements (I wouldn't hold my breath if I were you) - Waste hours of your time adding replacements and setting up triggers, just so you have to do it all over again every time you change something or create a new mission - Use SWAPR (which I wrote specifically to make life easier for users like you, making the process highly automatic) - Get used to empty bases

Paste the EXACT script you're using.

You need to run this code in the server environment (server hook). Server hooks need to be placed in C:\Users\YourUserName\Saved Games\DCS.openbeta\Scripts\Hooks If you try to run net commands from the mission environment, as you would a regular script, you'll get that kind of error. Other stuff that could be problematic with your snippet... I don't think you can dump tables using print , also, why the extra ()? print(Players()) --check output This line is missing a final ", syntax is invalid as is. Also, Players will return a table, are you sure you can dump it using net.log ? net.log("RGT - Player Killed - player: "..Players..") In any case, you definitely need to dump the net.get_player_list() table somewhere, so you can check its structure and build the for loop accordingly, otherwise this won't work. I normally use MOOSE's BASE:I to dump tables, but MOOSE doesn't work in the server environment, so you'll need to find a serializer that works in the server environment, somewhere. I guess you could try this (requires io desanitization in MissionScripting.lua) : https://github.com/gideros/table.save/blob/master/table.save-0.94.lua

Try getting a table of all playerIDs with this net.get_player_list() then iterate through the table using a for loop, running this command for every playerID net.kick(playerID, message) See if you can run this using a simple scheduled function (with a delay of almost 4 hours)

Give @609_Relentov a medal, please

SWAPR will automatically clone any number of clients in your missions (with the same liveries, loadouts, etc.), just place the clients as you normally would and give them a common prefix/suffix, the script will take care of spawning and removing replacements as you hop between clients. Here's a demo (it's an old version of SWAPR, ship-based clients no longer get replacements in newer versions , but the rest should work)

What Pikey said.

Join the MOOSE Discord channel and ask there.

Like others have said, you'll never hit anything at 60+nm (even 30nm is already pushing it). I also recommend that you wait until the enemy SAM site fires at you, for three reasons: 1- To ensure you're in range (will work for most SAMs, except for SA-10, Patriot, Perry, Ticonderoga and Moskva, which will fire at ~40nm, unless you're using ECM) 2- To ensure your HARM will have a radar signal to lock on to. 3- To use the HARM as countermeasure. (Depending on the mission, SAM radars might turn off upon detecting a HARM launch, forcing SAM missiles to lose lock and self-destruct)

Both the manual and Wags say it's 20nm. Now, I don't know if that applies to HMCS boresight as well, but I don't see why it shouldn't.

Unless you're in a MP server, facing people who know how to defend missiles... in that case, 7nm is the sweetspot (below 20k, provided the bandit isn't cold). Boresight mode has a range of 20nm, HMCS in bore mode + amraams is a perfectly valid option, specially when the radar refuses to get a lock in CRM mode (which usually happens when the bandit is just outside WVR).

Why would I be talking about real JDAMs? Ideally you should be using HARMs for that, but if they get intercepted, use walleyes instead. I repeat, JDAMs in DCS are very unreliable, they're a waste of pylon space in most cases (specially GBU-38s), they'll miss the target half of the time (if you're lucky).