Changelog

0.9.18 — 30 October 2026

Matches DCS 2.9.31. dcs-mcp’s DCS data now comes from DCS 2.9.31.29434. The eight vehicles the Currenthill asset pack adds in 2.9.31 — ZTQ-15, PGZ-09, BMD-2, Ural Typhoon, AMN-2 Atlet, Ural-4320 with ZU-23-2, ZIL-131 and ZIL-131 Kung — can be placed under the countries the Mission Editor fields them for; before, they were refused as unknown. Iraq fields the MiG-25RBT, IL-76MD and MiG-23MLD. A new CH-47F carries the editor’s new IRSS setting, off, as the editor writes it. set_warehouse_inventory lists DCS 2.9.31’s weapons, with the two MG 42/59 it adds and the Kh-22 under its new name. The La-7’s radio is 2.9.31’s HF set: a frequency is checked against 3.7-6.06 MHz, and no presets are written for the radio it no longer has.

A livery this DCS install does not have is warned on. modify_unit and set_livery still write any livery id given — a player may have a livery your machine lacks — but now warn, livery_not_installed, when the id is not one list_liveries gives for the aircraft, so a mistyped id no longer goes unnoticed.

set_livery and modify_unit now set a static object’s livery, as the Mission Editor’s static panel does. set_livery said a static did not exist, and modify_unit refused its livery. A static aircraft’s livery that this DCS install does not have gets the same livery_not_installed warning as a flying aircraft’s.

A flight’s frequency goes where the Mission Editor puts it. set_intra_flight_frequency writes the frequency into the radio channels the aircraft’s radio panel connects to it, on each radio that can take it — an F-16 at 124 MHz on its VHF radio, not its UHF — and sets the flight’s modulation as the editor does (an F-16 at 40 MHz is FM). It had written channel 1 of the first radio whatever the frequency. The reply lists each channel written. radio_id still picks a radio, as an override. modify_group sets a flight’s frequency the same way.

A flight’s frequency is checked as the Mission Editor checks it. set_intra_flight_frequency and modify_group warned of a group frequency by the band of the aircraft’s first radio, which is often not the radio the editor checks: a Ka-50 was warned of every usual frequency, and an FW-190 was let through on frequencies the editor marks invalid. They now check it against the bands the editor’s own frequency box allows, for every aircraft whose box can be edited — including some 60 that were not checked at all. On a Client or Player flight, a frequency the editor marks invalid is now refused: the editor will not save a mission that has one.

Trigger zones: one zone to a name, a quad with an area, the radius the file holds. add_zone, add_polygon_zone and a modify_zone rename refuse a name another zone already has: the Mission Editor renames the second zone of a name when it opens the file, so whatever finds the zone by that name finds the other one. validate names zones that share a name in a mission made elsewhere. add_polygon_zone and modify_zone refuse four points on one spot or along one line, a zone no unit could ever be inside. A refused modify_zone now changes nothing; before, a refused set of vertices or colour left the rest of the same call applied. list_zones, modify_zone and delete_zone give a polygon zone’s radius as the file holds it — 3000 for a new one, as the editor writes — where they said 0.

A drawing’s icon and font are the Mission Editor’s. add_drawing_icon takes one of the 53 icons the editor’s drawing panel offers, and its description now lists them with the editor’s name for each; a file name the editor does not offer is refused, where it was written as given. add_drawing_text_box takes only the editor’s font, DejaVuLGCSansCondensed.ttf, which was already the default.

An icon by the Mission Editor’s name. add_drawing_icon takes the editor’s own name for each icon — “Armor”, “IFV”, “Air Defence SAM” — in any case. “Mechanized” is now refused: it gave the editor’s Armor symbol, while the editor’s Mechanized is a different icon, so the reply names both and you choose. Use “Armor” for the symbol it gave before.

viewshed no longer sees a target through the ground. A point where the target is below the ground is now reported masked. Before, the ground at the point itself was never counted, so a target below it was reported visible at the first point of every radial, and inside any rise that nearer terrain did not hide — dozens of points a sweep from a raised emitter, such as a hilltop radar. viewshed and check_los, which refuses a target below the ground, now agree.

set_raw_lua says what it wrote. A key inside an object value that the mission section does not keep — "bogus" in an object written to weather.clouds — is now refused by name, and nothing is written. Before, the rest of the object was written, the key dropped, and the reply said the write had not taken effect and suggested clearing the cloud preset. A value refused when the section is reloaded now says it was not written, where it said “wrote”. The description now says that text is read as JSON (“5” is written 5) and that null writes the key as nil, which Lua reads as no key at all.

set_raw_lua’s null removes a key, as its description says. Removing a cloud preset, or a forced option such as birds, was refused though it had worked; it is now taken, and the other cloud values stay. On weather.halo.preset null was saved as the text “None”, and on forcedOptions.labels it failed with a traceback: both are now refused plainly, and nothing is written.

set_raw_lua refuses NaN and infinity. set_raw_lua refuses NaN and infinity given as text (“NaN”, “Infinity”), on their own or inside an object, and writes nothing. They were written, and every save after refused until the value was replaced.

set_raw_lua names what blocks a write under goals. set_raw_lua’s refusal of a write under goals, on a file holding a trigger or goal the Mission Editor does not define, now names that entry in validate’s words and says nothing was changed.

A warehouse’s aircraft are checked as its weapons are. set_warehouse_inventory checks each aircraft entry as it checks a weapon’s: initialAmount and linkDynTempl must be whole numbers of 0 or more, unlimited true or false, and a wsType you give must be the aircraft’s own. Such values were saved as given, and text or nothing for initialAmount stopped on an error inside the server.

A weapon’s old name is answered with its new one. set_warehouse_inventory now answers a weapon’s name from an earlier DCS with the name it has now: “Kh-22 (AS-4 Kitchen)”, the Kh-22’s name until DCS 2.9.31, was refused with four other missiles suggested.

0.9.17 — 19 October 2026

Set an aircraft’s board number. modify_unit takes onboard_num, the number painted on an aircraft, written exactly as you give it — “060” stays “060” — as the Mission Editor writes what is typed. Two aircraft may share one, as in the editor.

A new flight says how much fuel it has. Every flight-building tool now reports the fuel it gave each aircraft. It is the Mission Editor’s starting fuel for the type: a full tank for most aircraft, and a share for a few — the Su-33 and C-130 start half full, the Su-27 at 59%. modify_unit’s description said every aircraft starts full; it now gives the right figures.

set_raw_lua says where to go instead. Refusing an edit under the mission’s groups, it now names the tool for each kind of field, and says plainly when no tool writes one yet.

One trigger clears the trees for every site. Each SAM site, EWR, FARP or air-defence group that clears the trees around it used to add a trigger of its own. Now the mission has one, “Tree clearing”, with an action for each site’s zone. Deleting a site — or its tree-clear zone, to keep its trees — takes its action out of that trigger, and the trigger goes with the last one. A mission that already has a trigger per site keeps them as they are.

A position can be given as the replies give it. Every tool that takes a position in a mission also takes the flat form the replies use — {"lat": …, "lon": …} or {"x": …, "y": …} — as well as lat_lon and xy. The eleven terrain tools that take no mission take latitude and longitude only, as lat_lon or flat: with no mission there is no map to convert x and y against, and x/y is refused at once, saying so. A position with a key it does not know, or in two forms at once, is refused, and the refusal shows the forms; before, the unknown key was dropped without a word and the position refused as missing. A waypoint refuses a key it does not know the same way.

Opening and saving a mission keeps what the Mission Editor keeps. A mission opened and saved again no longer loses an aircraft’s livery setting of 0 (without it, the editor gives the aircraft the country’s first livery), a group’s late activation, probability or frequency, its drawings, its fog as the file had it, or the ground-control role names.

The install report no longer says “nothing degraded” without an install. dcs_install_report’s degraded is null when no DCS install is in use, and with two installs found, a capability either holds no longer reads as missing.

modify_task refuses with the real reason, and every switch turns off. A bad value is refused by name, not as a missing target; a null inside a ControlledTask no longer changes it; maxDistEnabled and the switches inside a ControlledTask turn off; Escort’s last-waypoint flag clears as the editor’s does. Bombing, Strafing and BombingRunway are written as the editor writes them. attack_qty must be 1 or more; Land takes a direction; Engage Targets takes a priority.

Triggers take only what the Mission Editor would keep. A yes/no field takes only true or false (the text “false” was written as true). A task, cargo, template, airfield, helipad or country that isn’t there is refused, as the editor would delete the action. A refused trigger leaves no text behind. Coalition conditions take the sides the editor offers, and the unit types it offers — AIRPLANE, HELICOPTER, GROUND, NAVAL or ALL, in any case; “Air” is refused.

Deleting a group clears what pointed at it, as the Mission Editor does. A flight on a deleted ship or FARP becomes a turning point; transports, trailers and tankers stop naming it; triggers and goals naming it lose those rules. An escort or attack aimed at it is left, as the editor leaves it, and listed. validate warns about anything naming what isn’t in the mission. Saving a mission cleans its triggers and goals as the editor’s save does, and says what went; opening one keeps them as the file has them, as the editor’s load does, and validate names what the save will remove.

Static objects as the Mission Editor places them. Carrier deck crew, animals, the barrage balloon, smoke and every heliport are written with the editor’s category, rate and shape; a heliport placed by its DCS name gets its radio and warehouse; a warehouse static gets its warehouse. list_unit_types lists them all.

add_task offers only what the Mission Editor offers. FAC tasks are refused for a country the editor doesn’t allow, Start at a waypoint, and Switch Action anywhere. A Script whose Lua doesn’t compile is refused with Lua’s own message, checked with DCS’s own Lua and never run.

Waypoints as the Mission Editor writes them. An unnamed waypoint has no name, and an opened mission’s waypoints keep theirs. A vehicle’s or ship’s waypoint sits at the ground height; an altitude given for one is reported unused.

Option value names work under every spelling. ED’s value names (RANDOM_RANGE and the rest) work whichever name the option is given, and an opened mission no longer calls options the editor defines “unknown”.

Saving an opened mission adds nothing the Mission Editor wouldn’t. Keys the file didn’t have, such as hidden flags, cargo flags, rope lengths, empty countries and drawings, are no longer added, and a missing halo is written “off” instead of an invalid value.

An untouched route keeps its arrival times. Saving an opened mission recomputed every route’s times, edited or not, to values the editor wouldn’t give; now only a route you changed is recomputed.

Saving does what the Mission Editor’s save does. Like the editor, dcs-mcp now fills in a client’s radios, an aircraft’s datalink and property defaults, a store’s default settings (on a mission you build, too) and the weather’s flags; drops empty countries and outdated keys; and recompiles every trigger.

Positions, counts, speeds and colours are checked, as the Mission Editor’s boxes check them. Every tool’s numbers are held to the Mission Editor’s range where its panel has one — headings 0-360, a flight of 1 to 4, 1 to 99 vehicles or ships, altitudes 0 to 40,000 m, colours, sizes, weather — and to the physical range elsewhere: latitude -90 to 90, longitude -180 to 180, distances and speeds 0 or more. A value outside is refused, naming the range. Before, a latitude of 95 was taken and the mission could no longer be saved; a ship group of 0 units could not be reopened.

A number is a number, and yes is true. A number given as text (“2”), true given for a number, a fraction for a whole number, or “false” for a yes/no setting is refused, naming the parameter — in every tool, every task, trigger and goal. Before, “false” was taken as true, “2” was written as text, and a radio frequency given as “251” was written as that text a million times over.

Every task, trigger and goal field takes what the Mission Editor’s panel takes. Each field is checked against the editor’s own range and list: priorities, attack quantities, beacon channels, Link 4 frequencies (written in tenths, as the editor writes them), flag values, mission scores (-100 to 100), and the rest. A field whose range the editor’s code does not settle takes a whole number.

Editing a task keeps what you did not change. modify_task keeps every field you do not name exactly as the file holds it — whatever it holds — and names anything else that changes. Before, an edit could reset a weapon, a priority, a datalink or a frequency to its default, or refuse the edit for a field it was not given.

Refusals say what to fix, in plain words. A refusal names the parameter and what it takes; a group, unit or mission that is not there is named; a file that cannot be saved says why. An error inside the server says so, as a defect to report.

Triggers and goals as the Mission Editor keeps them. Opening a mission keeps its triggers and goals as the file has them, as the editor’s load does; saving cleans them as the editor’s save does, and says what it removed and what its removals left (a trigger ending in OR, or with no conditions, which then fires unconditionally). validate names everything the save will remove, and counts goals per side, as the goal tools do. A goal cannot hold OR — the editor’s goals panel offers none — and an opened one that does keeps its own compiled text.

delete_group clears what pointed at the group, and says what is left. When taking out the deleted group’s rules leaves a trigger with no conditions, or a trigger or goal ending in OR, the reply warns of it.

Tasks as the Mission Editor writes them. Defaults are the editor’s: FAC frequencies (133 MHz AM; 131 for an attacking FAC, as ED’s missions hold), SetFrequency 131 MHz, Orbit and tanker speed and altitude from the aircraft and the waypoint, a Barcap’s pattern, SwitchWaypoint’s next waypoint, a GoToWaypoint’s own waypoint. A target the editor lets you leave out can be left out. The keyed CAS, SEAD, CAP, Anti-Ship and Fighter Sweep tasks keep their target types. SwitchAction, which the editor offers to no group, is gone from the catalogue.

Hold takes a template, and the save carries the templates a mission uses.

A stored install path wins. With two DCS installs found, set_dcs_install_path now settles which one is used; before, it could not.

Lat/lon-only terrain tools say so. The eleven terrain tools that take no mission take latitude and longitude only, and say so in their schema.

Statics, payloads and warehouses. A cloned warehouse static gets a warehouse of its own, as in the editor; a cloned FARP keeps its source’s radio and says so; get_unit, get_group and the payload tools show the settings the file gets; fuel, flares and chaff are held to the airframe’s own maximum where ED’s data gives it.

Radio bands. modify_group now warns, as set_intra_flight_frequency does, when a frequency is outside every band of the aircraft’s radio.

Lua is checked before it is written. A RunScript or RunScriptFile whose Lua does not compile is refused with Lua’s own message, checked with DCS’s own Lua and never run — wherever the mission holds the file.

Speeds without a known maximum are said. A vehicle’s, ship’s or aircraft’s speed with no maximum this server holds is written as asked, and the reply says it was not checked.

0.9.16 — 15 October 2026

Trains. add_vehicle_group places a train: vehicle_type="Train" with wagons, its cars in order from the front. list_unit_types with category train lists the locomotives and the wagons. A train’s waypoints are all “On Railroads”. DCS puts a train on the railway nearest each waypoint when the mission runs, however far that is; dcs-mcp has no railway data, so it cannot tell you where the rails are or whether two waypoints are joined by rail. Afghanistan and the two Mariana Islands maps have no railway, and a train is refused there.

Place any Mission Editor template. add_template_group places a group template by name — one of DCS’s own, or one you saved in the Mission Editor — as the editor places one: the template’s origin on your point — its first unit, in every template DCS ships — the rest where the template puts them, turned by heading. Vehicle and ship templates are placed; an aircraft template is refused, because an aircraft group needs an airfield or an air start, an altitude and a task that a template does not hold. The group goes under the country the template was saved for unless you name another. list_templates lists them all, with their kind, country and units. The ten SAM site builders’ template now refuses a template that is not of ground vehicles, saying so.

Mission Options can be set and read. Two new tools, get_mission_options and set_mission_options, cover the Mission Editor’s Mission Options panel: all 26 options by the panel’s own names, each enforced at a value or left to the player, with every value checked against what the editor offers. Four could not be set at all before: Spotting Dots, G Warm-Up In The Air, and the Supercarrier module’s deck crew and 1MC. The Extended F10 view can be chosen as well, and each of its six roles given its own view and the unit layers it sees.

A weapon’s settings are listed and checked. A new tool, list_weapon_settings, lists what a store takes — its fuzes, arm and function delays, laser code — with each setting’s key, the values it allows and its default. set_payload and replace_payload now check the settings you give against that list: a key the store does not have, or a value its setting does not allow, is refused, and the message names the store’s own settings. Before, it was written and DCS ignored it. force=true still writes it. The settings a mission already carries are left as they are.

A SAM site uses the country’s own layout. DCS ships most SAM systems in a version for each country that fields them. A site built for a country that has exactly one now uses it: an Iranian SA-2 is DCS’s Iranian battery, a German Patriot is Germany’s. Before, every country got Russia’s or the USA’s. Countries with none, or with more than one, are built as before, and template still names any of them. The reply’s composition says how the template was chosen.

find_road_near finds a road near a point in the terrain data: the nearest 100 m cell DCS classed as road. The data holds a road only where its sample point fell on one, so a nearer road can be missing.

Nav points and road paths survive a save. A mission opened and saved with dcs-mcp keeps each coalition’s navigation points, and each vehicle group’s road path as the Mission Editor drew it. Both were dropped before, and the save’s reply said so. A road path is kept while the group’s route is unchanged; once you add, remove or move a waypoint, or switch one between On Road and Off Road, the old path is left out and DCS finds the road again when the mission runs.

A saved mission keeps what the Mission Editor put in it. Opening a mission and saving it used to lose five things the Mission Editor had written. All are now kept: the data cartridge (DTC) presets of a flight with a Client or Player seat; which ship a static on a deck belongs to; the radio frequency and callsign of a single-pad FARP, an Invisible FARP, an oil rig or a gas platform; the names given to tasks; and a map drawing’s “hidden on planner” setting. get_route now shows a task’s name.

A mission with the F10 view set to Extended opens. A mission whose Mission Options set F10 View Options to Extended could not be opened at all. It opens now and is saved with its Extended settings as they were.

dcs-mcp says when a terrain pack is out of date. The Terrain Manager now records which pack it installed, marks one that has a newer version published, and says how to replace it. dcs_install_report lists each pack as current, older or unknown. Packs installed before 0.9.16 are checked once, the next time you open the Terrain Manager; with every map installed that can take a minute or two.

A community mod’s ship can be placed, unless it has a flight deck.

validate no longer reports a FARP service lost while one of its providers is in reach. Most FARP services have two providers, a vehicle and a FARP static, and either one within 150 m of the pad is enough — flown for fuel, where the Fuel Depot alone and the tanker alone each refuelled. validate asked for both, and so reported fuel lost at a FARP whose tanker stood off while its Fuel Depot was at the pad. It now reports a service only when none of its providers is within 150 m and one stands beyond.

A flight is a person’s when its lead is. A person’s waypoints go on the ground so they can be used to designate; an AI flight’s stay at flying altitudes. For a flight with both, dcs-mcp went by any Client or Player seat when writing waypoints and by every seat in the mission report. Both now go by the flight’s lead, its first aircraft: an AI lead flies the route’s altitudes, whoever is on its wing. The mission report’s two checks for a flight with no tasking go by the lead as well.

A flight that starts in the air starts in the air. set_route gave a flight led by a person a start at ground level when its first waypoint had no altitude. It now gets the Mission Editor’s: 2,000 m for a plane, 500 m for a helicopter, or the ground’s height where that is higher.

A static vehicle, aircraft or ship carries its rate. A static of a vehicle, plane, helicopter or ship type is now written with its rate, as the Mission Editor writes it from DCS’s unit database. Three WWII railway wagons carry 10, where dcs-mcp wrote 4.

A blue FARP’s support vehicle is labelled “ATC/comms”. It no longer claims night lighting, which was never checked for that vehicle.

A radio-usage option takes its types under any of their names. add_task and modify_task take them as value, target_types or targetTypes; two that differ are refused. A refused edit now says the task was not changed, where it said “not added”.

A ground or ship waypoint is written as the editor writes one. A waypoint added to a vehicle or ship group no longer carries an aircraft’s navigation settings (properties), which the Mission Editor never writes for one and drops when it saves.

dcs_install_report says where the list of countries comes from: your DCS install, or the list dcs-mcp ships with, and why when it is the shipped one.

Every changed description checked against what its tool does. Each tool whose description changed in this release was audited — every sentence done and the result looked at — and what that found is fixed. set_payload and replace_payload no longer refuse a weapon setting the Mission Editor itself writes, and now refuse a number between the editor’s steps or a change to a setting the editor holds fixed. set_route gives a train’s later waypoints the speed of the one before. find_road_near says plainly that its data holds a road only where a sample fell on it, so a nearer road can be missing. And a dozen descriptions now say exactly what their tool does.

Small fixes. A point exactly on the edge of a map’s terrain data is now inside it. list_airfields says an airfield’s TACAN is unknown, not absent, when DCS’s own beacon file can’t be read as expected, and no longer says “terrain module” where it means the map in DCS. Air starts are quicker: the DCS install is read for cruise speeds once, not for every flight.

0.9.15 — 11 October 2026

The three WWII maps are supported: Normandy 2.0, The Channel and Marianas WWII. Missions on them can be built, opened and saved, with each map’s own airfields, parking stands and terrain data (a separate download in the Terrain Manager, as for every map). ED’s own missions for the three maps all open and save, and Normandy missions open on Normandy 2.0 — all twelve of ED’s do.

Every map is built from DCS’s own data. dcs-mcp took nine of the eleven maps’ coordinates and boundaries from the pydcs library. Now every map comes from DCS’s own data for it, as Iraq and Afghanistan already did. Positions come out the same — DCS’s coordinates and ours were measured identical on every map.

Syria’s terrain data is up to date, and the Mariana Islands’ covers the whole map. Syria’s was made before DCS reworked the map: in places its heights were off by up to 524 m, and some water read as land, which affected the elevation, water and line-of-sight checks there. The Mariana Islands’ stopped 283 m short of the map’s north edge. Both are made again from DCS.

A mission with WWII armour says it needs the WWII Assets Pack. The Mission Editor writes into a mission which of ED’s asset packs its units need, and shows it when the mission is opened. dcs-mcp wrote only community mods there; it now writes ED’s packs too, as the editor does.

Editing a CAP’s automatic Engage Targets changes only what you change. Naming only its target types added a range setting the task didn’t have, and the reply reported it as a change nobody asked for. Nothing flew differently.

Tool descriptions no longer point at pydcs. Some named the pydcs library, and the model sometimes went off to install it and read its code before building. They now say what each value is. Two were also wrong and are corrected: a cloud density set while a cloud preset is in use is kept, and Game Master Only can’t be set with dcs-mcp.

Checked against DCS 2.9.30.28738. dcs-mcp’s tables of DCS data were checked against the latest DCS update; DCS’s data in them is unchanged.

Saved missions name their map as the editor’s do. The Mission Editor puts a small file naming the map into every mission it saves, which DCS’s mission lists read; dcs-mcp’s saves now include it too.

Every map’s terrain data now covers the whole map. On four maps it stopped short of some of the map’s airfields — Syria’s 24 (among them Ben Gurion, Hatzerim and Marka), the Persian Gulf’s 5 (Kerman, Shiraz, Jiroft, Liwa and one other), Nevada’s Laughlin and Mina, and Iraq’s Kharg — and on eight maps it stopped short of land the Mission Editor shows. There, the elevation, water, slope, line-of-sight and building checks answered “outside the terrain data”. Every map’s data now covers all the land the editor shows. Every map’s was also made again from DCS 2.9.30.28738 and checked against DCS point for point; Kola’s had changed in a few places since it was made.

Ground units placed in, against or on a building are named. Placing ground units, statics, SAM sites or FARPs — or adding, moving or cloning units — now checks each unit against the map’s buildings and structures, using each structure’s size as DCS measures it, and names any unit that stands in, against or on one, with how far it is and how big the structure is. Before, only the middle of a group was checked, and a building beside a unit could not be told from one under it. ED’s own missions often put units inside shelters and revetments on purpose, so it is reported for you to decide. find_clear_spot now finds a spot that passes the same check.

Install every map’s terrain pack again. Every map’s pack is new in this release, and dcs-mcp does not yet notice an older one: reinstall each map you use in the Terrain Manager. With an older pack the building check is the old, coarser one, and its warning says so.

list_theaters’ map names no longer run together. It returned bare names, which Claude Desktop passed to the model joined into one string (“...MarianaIslandsMarianaIslandsWWIINevada...”). It now returns an entry per map: its name, and whether the map’s terrain pack is installed.

An edited CAP task says why it is no longer listed as CAP. In the Mission Editor “CAP” is its own action with fixed targets; choosing targets for it makes it a plain Engage Targets action, and dcs-mcp’s saved file matches that. The reply now says so — before, the task’s CAP marker went without a word.

0.9.14 — 6 October 2026

Any aircraft can be a Client slot, as in the Mission Editor — the F-14B(U) included. dcs-mcp refused a Client slot on an aircraft it didn’t know a player could fly, and it wrongly counted the F-14B(U) among them. The Mission Editor offers Client on every aircraft, so dcs-mcp now writes it on any, and warns when the type is one no player can fly in DCS — taking that slot puts a player in spectator mode.

Making an aircraft a Client gives it a player’s settings. modify_unit to Client now adds the settings the Mission Editor gives a Client — the F-14B(U)’s eight among them — and lists them in properties_added; they were missing. A flight started on a FARP pad or a deck reports start_mode “ground” (it said “air”). list_unit_types now gives each aircraft’s default task and whether a player can fly it (human_cockpit).

Every aircraft is built from DCS’s own data. dcs-mcp took most aircraft’s details from the pydcs library, and only the newest from DCS itself. Now every aircraft comes from DCS’s own data, so a new module or a DCS update is picked up from DCS, not when pydcs catches up. Missions come out the same, except where DCS’s data is newer than pydcs’s — the JF-17 now carries its four EW database settings. list_unit_types names every aircraft by its type id.

A new aircraft starts with the fuel the Mission Editor gives it. Every flight dcs-mcp started in the air carried 90% of its fuel, and a few aircraft started fuller than the editor fills them. The editor gives most aircraft a full tank and a few a share of it — the P-51D 68%, the Su-27 59%, the C-130 50%, among others. dcs-mcp now gives each what the editor does.

A new aircraft’s tail number and gun belt are the Mission Editor’s. Tail numbers now run from 010 for each country, and on through a flight, as the editor numbers them — they were random. An aircraft with a choice of gun belts now carries the one the editor gives it (the F-16C’s is the fifth); it carried none.

Some aircraft settings are written under the names DCS reads. On the Ka-50 III, the MiG-29 Fulcrum, the OH-58D and the MB-339A, dcs-mcp wrote some of an aircraft’s settings — the Ka-50’s helmet sight and INS, the Kiowa’s doors and mast sight — under names DCS does not recognise, so DCS ignored them, and an AI aircraft also carried settings only a player can use. They are now written as the Mission Editor writes them.

A new mission starts as the Mission Editor starts one for its map. It began on 1 June 2011 at 12:00, with a clear sky and both bullseyes at the map’s origin. Now it takes the map’s own date, start time, bullseyes and opening view (Caucasus 21 June 2016, 08:00), and the editor’s default weather.

A new mission flies and opens as it was written, fog included. dcs-mcp wrote a new mission in an older file version, which DCS updates when it loads it — to fly it as well as in the Mission Editor. That update changed a flight’s radio usage options: “Planes” became Planes and UAVs, and “Air” left UAVs out. A new mission is now written in DCS’s current version, with its fog where that version keeps it. And set_weather’s fog now takes effect on a mission saved by a recent Mission Editor — there it changed nothing DCS reads.

A new waypoint’s altitude, speed and properties are the Mission Editor’s. An AI flight’s waypoint given no altitude was written at 0 m; it now goes at 2,000 m after a take-off, else at the previous waypoint’s height and altitude type. Vehicles and ships given no speed keep the previous waypoint’s (they stopped), and a ship’s first waypoint is stopped, not 10 kn. A take-off or landing turned into a turning point loses its airfield and climbs to the editor’s height; a change between BARO and RADIO converts the altitude rather than keeping the number. New aircraft waypoints carry the editor’s settings for their type, and opening and saving a mission keeps its waypoints’ own settings — custom ones were lost.

set_route takes what add_waypoint takes. It refused a RADIO altitude on any aircraft and failed on a landing on a FARP or deck. Both work now.

Flights are placed as the Mission Editor places them. A flight is one aircraft unless you ask for more (it was two). Wingmen park on the free stands nearest their lead, and an air start spaces them as the editor does. A unit added to a flight gets the next callsign number (some air forces’ repeated the lead’s), a player’s skill is copied as AI, and a FARP or deck flight can grow onto the next free pad (it was refused).

Weather uses DCS’s own presets. set_weather takes DCS’s 15 weather presets by the Mission Editor’s names; our old names (“rain”, “clear” and the rest) are now refused with the list — “rain” set no rain, and DCS has no fog preset. Setting a visibility keeps the mission’s clouds (it removed them); fog switched on starts as the editor’s manual fog; dust starts at the editor’s lowest setting and, as in the editor, is refused while there is fog. The temperature is held to the map’s range for the date, and changing the month of a new mission moves its start time as the editor does.

Triggers, zones and drawings take the Mission Editor’s defaults. Set Flag sets 1 (true), Random is 10%, Increase and Decrease step 10, a zone is 3,000 m and marks are editable. An arrow is drawn to the length and angle given (its angle was written in radians, its shape fixed). A mark or message to a coalition now needs its coalition named — it was sent to blue — radio menu items default to all, and the neutral side is written as DCS reads it.

Ships, sites and airfield stock are set up as the Mission Editor sets them. Ships in a group stand 800 m apart, south and east, as the editor places them (their hulls overlapped), and a ship’s waypoint on land is warned. SAM sites, early-warning radars and FARP vehicles get the editor’s start actions — a radar had no early-warning task — radars default to Average skill, and a SAM site stands on its origin, as the editor places it. Turning off an airfield’s unlimited stock now stocks 100 of everything, as the editor does; it emptied it. Cargo statics weigh what DCS gives them, and vehicles carry their default ammunition.

Radio usage options take the Mission Editor’s names, one or several. “Radio usage when contact” (and on engage, on kill) took one target type, from a shorter list than the editor’s — UAVs and the missile types could not be named — and refused a list. It now takes one name or several, any the editor’s panel offers, or “none”.

A mod’s liveries come with it, without a restart. A mod installed while Claude Desktop was open had its aircraft but none of its liveries until Claude Desktop was restarted. When the mod export is made again, dcs-mcp now reads the liveries again too.

An AI-only mission is no longer a warning. mission_report warned when no aircraft was a player slot. The Mission Editor doesn’t, and DCS runs an AI-only mission, so it’s now a note that says so.

0.9.13 — 3 October 2026

Community mods. dcs-mcp can now build missions with your community mods — aircraft, vehicles and statics under Saved Games\DCS\Mods. Mods are programs only DCS can read, so dcs-mcp learns them from DCS itself: install_mod_export puts a small one-time script where DCS runs it; start DCS once, and at the main menu it writes what DCS knows about your mods and deletes itself. Nothing runs after that, and nothing in DCS or its install is changed. Mod aircraft then build, arm with their own stores and loadout library, air-start at their own cruise speed, and are offered their own tasks and radios; mod vehicles and statics place, and a mod’s air defence clears its trees; missions name the mods they need, as the Mission Editor does. list_unit_types marks a mod’s types, and dcs_install_report shows your mods and whether the export still matches them. Mod ships and mod weapons in warehouses aren’t supported yet. Tested with the UH-60L and OH-6A mods.

Up to date with DCS 2.9.30. The data dcs-mcp takes from DCS is rebuilt from DCS 2.9.30.28536. One value changed with it: the PLZ05 is now one of the units with datalink, as DCS 2.9.30 has them. The weapons set_warehouse_inventory names are the ones DCS 2.9.30 lists.

dcs-mcp says when your DCS and its data differ. dcs_install_report and get_server_version now give the version of your DCS install beside the DCS version dcs-mcp’s data was taken from, and say plainly what it means when they differ — for instance after a DCS update, until a dcs-mcp release catches up with it. A DCS update also marks your mods’ export as out of date, and the report labels the export’s DCS version as the export’s.

A flight’s aircraft carry its first waypoint, as in the Mission Editor. When a mission is saved, every aircraft now carries its flight’s first waypoint’s altitude and speed, as the Mission Editor writes them — missions opened from a file included; one saved by the Mission Editor is unchanged. An aircraft starting on the ground used to carry 0 and 0. A flight starting on a FARP pad or a ship’s deck now gets the Mission Editor’s first waypoint too: the ground’s height there, and 150 km/h for a helicopter or 500 km/h for a plane. So does a flight moved to another airfield, pad or deck, changed to a take-off, or given a new route that starts with one; an altitude or speed given in the same call is kept. A parked flight’s first waypoint is no longer reported as faster than the aircraft can fly.

The ground’s height is written as the Mission Editor writes it, to the nearest metre. Wherever a mission holds the height of the ground — a landing at an airfield or on a FARP pad, a ground group’s waypoints, a flight starting in the air over high ground, a human flight’s waypoint at ground level, and a waypoint raised out of the ground — it is now the whole metre the Mission Editor writes, not the terrain’s exact height.

A cloned flight’s take-off is placed as the Mission Editor’s paste places it. clone_group now gives a flight that starts at an airfield, on a FARP pad or on a ship’s deck the Mission Editor’s first waypoint: the ground’s height there, and 150 km/h for a helicopter or 500 km/h for a plane. It used to copy a changed altitude or speed from the original. Landing waypoints keep theirs.

An F4U-1D_CW’s aircraft number is drawn as DCS draws it. DCS picks the F4U-1D_CW’s three number digits at random each time it starts, and every F4U placed in that session carries them. dcs-mcp now does the same once per run; every F4U it built used to carry 3, 8, 5.

A landing goes where the Mission Editor puts it. add_waypoint, set_route and modify_waypoint put a landing on its airfield’s reference point at the ground height. A landing kept the position it was given, so a flight could be written landing at Kobuleti from 58 km out to sea. DCS landed it at Kobuleti anyway, but the file and the last leg’s timing differed from the editor’s. A landing at a neutral airfield now makes it the flight’s side, as in the editor.

A landing can be moved onto a carrier or FARP. modify_waypoint takes pad_group_id on a landing and moves it onto the ship or FARP in one call, keeping its tasks. It used to take remove_waypoint then add_waypoint, which lost them. A landing on a ship or FARP couldn’t be edited at all, not even renamed, and now can.

A flight can be based at the other side’s airfield. The flight builders and modify_waypoint’s move to another airfield refused an airfield held by the other side. The Mission Editor allows it, and DCS flies such a flight: a check mission’s blue flights started, took off and flew their route from a red airfield. The airfield stays as it is, as in the editor; a neutral airfield still becomes the flight’s side.

apply_loadout_from_library applies every loadout in DCS’s library. It refused a loadout carrying a store that DCS’s own pylon lists don’t offer, and some of DCS’s own library loadouts carry one (among them the A-10C II’s “SUU-25*9,AIM-9*2,ECM” and the B-1B’s “GBU-38*84”). It now writes the loadout as saved, as the Mission Editor copies one, and names those stores under not_offered.

Every builder refuses a group name that’s already taken. DCS needs every group name in a mission to be unique, and the Mission Editor never writes two alike. The site builders, create_farp and clone_group already refused one; add_vehicle_group, add_ship_group, the flight builders, add_static and modify_group’s rename wrote the duplicate. They now refuse it and change nothing. add_static’s default name takes the first free number instead.

A unit name is unique, as in the Mission Editor. modify_unit and add_unit_to_group refuse a unit name another unit in the mission already has — static objects included — and change nothing. They used to write the duplicate, and DCS finds units by name.

Statics are stored as the Mission Editor stores them. A static’s heading was written on the object and 0 on its group; the editor keeps the two equal, as DCS’s own missions do, and now both carry it (add_static, create_farp and the site builders, and move_group’s turn). A vehicle placed with add_static got the category “Vehicles”, which DCS’s own missions never use, instead of its own (Armor, Unarmed, Fortifications and so on), and every vehicle, aircraft or ship placed that way carried a cargo flag they leave out. A railway car placed with add_static is now written exactly as the editor writes one, and the refusal that stops a railway car being added as a vehicle now names add_static.

modify_unit edits a static object. On a static object’s unit it failed with a Python error, and so did an id that is no unit at all. It now sets a static’s name and heading, as the Mission Editor’s static panel does, refuses the fields a static doesn’t have, and says plainly when there is no such unit.

A deleted FARP’s warehouse goes with it. delete_group now removes what the Mission Editor removes with a group: a FARP’s or ship’s own warehouse, its place as a supplier of other warehouses and airfields, and any aircraft’s link to it as a dynamic-spawn template. Before, a deleted FARP’s warehouse stayed in the file, and a FARP rebuilt under the same name added a second.

Deleting a FARP removes everything built with it. delete_group on a FARP made by create_farp now also removes the support vehicles and the statics create_farp placed with it, and lists them, so the FARP can be built again under the same name. A FARP opened from a mission file still loses only its pad, as in the Mission Editor.

Radio calls come on when you ask for them. The three “Radio usage” options (when contact, when engaging, on a kill) made the AI go silent — every radio call off, even the ones it makes with no option set — when they were meant to turn calls on. They’re now written as the Mission Editor writes them, and do what they say. Search Then Engage, Search Then Engage In Zone and Escort are written the editor’s way too; which targets they pick is unchanged.

Escorts and follows break off where the editor’s do. An escort or a follow given no last waypoint now stops at its lead’s last waypoint when the lead has more than one, as the Mission Editor sets it; before, it went on for the whole mission. create_escort_flight_v2 says where its escort breaks off, and modify_task’s last_waypoint moves it.

A scattered vehicle group always gets built. add_vehicle_group with formation “scattered” could occasionally never return for a group of nine or more vehicles — about one call in fifty at twelve. When the spread it picks is too tight to fit the group, it now widens it a little and carries on.

0.9.12 — 29 September 2026

Opening a mission with community-mod aircraft or ships no longer changes what the server says it knows. Once such a mission had been opened, asking for that aircraft by name failed with “‘str’ object has no attribute ‘name’” instead of saying the type isn’t known. list_unit_types listed it, and add_ship_group would build a mod ship the server knows nothing about. Now every request answers as it did before the mission was opened. The mod units in the opened mission can still be edited, and open_miz reports them every time the mission is opened, not only the first time.

Flights no longer park on top of statics. A static placed on a parking spot left the spot looking free, so a new flight, a cloned group, or a group whose first waypoint became a parking start could be put on top of it. They now skip that spot, as add_unit_to_group and list_parking_spots already did.

Every vehicle in a new ground group is checked for slope. add_vehicle_group checked the ground around the lead vehicle only, while a column runs 40 m per vehicle behind it, so a long column could be placed with its tail on ground steeper than the slope limit. Each vehicle is now checked where it stands, and the group is refused, naming the vehicle, if one is over the limit. terrain_check=false and slope_threshold_deg work as before.

Liveries are found wherever the server finds DCS. The livery list, and the livery a new aircraft is given, came from a separate search for DCS that ignored the install you set with set_dcs_install_path. Where that search found nothing, list_liveries returned an empty list and new aircraft got no livery, without a warning. Liveries now come from the same install and Saved Games folder the server uses for everything else.

set_group_callsign writes the callsign the Mission Editor would. It gave every aircraft’s own callsign names the number 1: an F-16 named Viper was written with Enfield’s number, and DCS goes by the number. It also refused tanker names the editor offers, such as the S-3B’s Mauler, and wrote named callsigns on flights of countries that use numbered ones. The name now has to be one the editor offers that country for that aircraft, and it takes the editor’s number; any other name is refused, with the list. Flights of countries with numbered callsigns are refused.

Library loadouts take pylons off where DCS’s own loadout does. DCS marks some pylons in its loadouts <CLEAN>, which removes the pylon itself, not just what hangs on it. apply_loadout_from_library treated that as an empty pylon, so the pylon stayed on, with its weight and drag. It is now applied as DCS writes it, and list_role_loadouts shows <CLEAN> where DCS has it.

set_payload follows DCS’s loading rules, as the Mission Editor does. Some stores need another store on a second station, and some cannot be carried together, such as two targeting pods on the F/A-18C. set_payload wrote whatever it was given. It now places stores in the order given, adds or removes stores on other stations the way the editor does when you pick a store for a pylon, and lists every such change under editor_rules. Setting a whole payload with replace_payload or apply_loadout_from_library is unchanged, as picking a loadout row in the editor is.

The loadout refusal names every folder it searched. When no loadout file exists for an aircraft, the message named two folders, though the Mission Editor’s own folder and every module’s folder were searched too.

Your own loadouts come from the DCS profile the server uses. With DCS_SAVED_GAMES set, loadouts could still be read from another profile’s folder. Where more than one profile exists, the choice was made without a word; the same folder is still used, and list_role_loadouts and apply_loadout_from_library now say which.

A refusal says when the Mission Editor has no such setting either. When add_task or modify_task refused a parameter, it listed what this server accepts, and a model could take the gap to mean the setting existed elsewhere: one told a user to tick a group-attack box on Carpet Bombing, where the editor has none. When the editor has no such setting on that action, the refusal now says so and names the settings it does have.

set_payload gives the fuze values the editor writes. Its description named the fuze setting keys but not their values, so a model asked for an instantaneous fuze loaded the bomb’s defaults and asked for an example. It now gives the values the editor wrote for the BDU-50HD, whose defaults are already instantaneous.

modify_task accepts the names get_route shows. get_route shows a task as the file stores it (attackQty, groupAttack), and modify_task took only its own names (attack_qty, group_attack). Both are accepted now. A switch such as attackQtyLimit, which follows its value, is accepted when it agrees with the edit and refused when it contradicts it.

The On Road descriptions say what DCS does with a road move. add_vehicle_group and add_waypoint said a group should be on or near a road for DCS to have anything to follow. DCS moves an On Road group onto its roads when the mission runs, and the Mission Editor does so when it saves the mission; the descriptions now say that, and that placing the group near the road you want helps.

Asking for a train says why there isn’t one. add_vehicle_group answered “Unknown vehicle type ‘Train’”, as if DCS had no trains. It has; this server has no railway data to place one on the rails, and the refusal now says so.

Locomotives and wagons are no longer placed as vehicles. add_vehicle_group built them as an ordinary ground group, which DCS’s own missions never do: there a moving train is always one ‘Train’ unit on the rails, and a railway car on its own stands as a static object. They are now refused with the same explanation, and list_unit_types no longer lists them as vehicles.

Moving a country to neutral no longer leaves a mission that can’t be reopened. The neutrals side was written without a bullseye, which crashed Tacview and made open_miz fail on the file. A side we create now gets a bullseye, as the Mission Editor gives one, and a new mission carries a neutrals side as the editor’s do. A mission already saved without one opens again: it is given the editor’s bullseye, open_miz says so under repaired, and the bullseye is written when the mission is saved.

Site and FARP builders no longer refuse when CJTF is on the neutral side. When a country doesn’t field every unit a site or a FARP’s support group needs, those units go under CJTF of that side. Many missions made in the Mission Editor list CJTF Blue and CJTF Red on the neutral side, and the builders refused them. They now move CJTF onto its side, where the editor puts it in a new mission, and say so in the result. CJTF on the opposing side is still refused, as is a neutral CJTF that owns units.

A new mission starts with the countries the Mission Editor gives one. new_miz used a roster of its own that differed from the editor’s: Ukraine was on red, and Sweden, CJTF Blue and CJTF Red were on no side. It now reads DCS’s default roster, and your own if you’ve saved defaults in the editor. So Ukraine, Sweden and CJTF Blue are on blue, CJTF Red is on red, and every other country is on neutral. If you place Ukrainian units on red in a new mission, move Ukraine to red first with set_country_coalition; the refusal says so.

A FARP that create_farp refuses no longer leaves its pad behind. The pad and its warehouse were placed before the check that can refuse, so a refused FARP stayed in the mission, and a retry failed because its name was taken. The check now comes first, and a refused FARP builds nothing.

Aircraft stocked with set_warehouse_inventory now load in DCS. Each aircraft was written with its amount alone, and DCS doesn’t load an entry without a wsType: the amount was ignored, some types went missing, and a FARP’s warehouse came up empty, which left dynamic slots wrong too. Each entry is now written as the Mission Editor writes it, and an aircraft the warehouse already lists keeps its own fields when you edit it. An aircraft type DCS doesn’t ship, or one under the wrong category, is refused. A mission already saved this way is repaired when it’s opened, as the editor repairs it: open_miz lists the aircraft under repaired, the fix is written when the mission is saved, and validate names any it can’t repair.

The site builders, create_farp, and the tools that place air defence check everything that can refuse before they build anything. A FARP whose support group or statics had a name already in use was refused with its pad left in the mission — which is what happened when a FARP was rebuilt after deleting only its pad. On a machine where the server can’t read DCS’s trigger files, a FARP or SAM site was built whole and then refused. And a site refused for its name had already moved CJTF onto its side. Each now refuses first, with the mission as it was. The descriptions now say a FARP is several groups, and that all of them are deleted before rebuilding it under the same name.

add_unit_to_group adds all the aircraft asked for, or none. It took a parking stand for each aircraft in turn, and when the stands ran out partway it refused with the ones already added left in the flight. It now counts the free stands first.

On the 4-pad FARP, the support trucks no longer sink into the mat. DCS lays the mat level near the higher ground, and a mission’s vehicles stand on the terrain, so trucks placed on the mat sank wherever the ground was lower. They now stand in a line just off the mat’s edge, inside the 150 m service radius, and the statics stand on the mat; refuel, rearm, ground power and ATC were all checked in DCS. The trees are cleared over the whole mat, and create_farp reports how much the ground under the mat varies, with a warning above 3 m.

Helicopters placed on a FARP each get a pad of their own, and a FARP can’t be overfilled. Our tools parked them with no pad number and never counted a FARP’s pads, so eight helicopters could be put on a 4-pad FARP — in DCS the AI took the pads and every Client slot was left unflyable. Each aircraft is now given a free pad, numbered as the Mission Editor numbers them. A flight or a clone the free pads can’t hold is refused, and validate names a FARP that already holds too many.

modify_task can turn a setting off. A task’s attack altitude, attack direction, attack quantity and similar settings each have a switch, and modify_task had no way to turn altitude or direction off — its refusal pointed at naming a value instead, so an attempt with 0 wrote an attack from 0 m or from due north. Naming the switch false (altitudeEnabled=false) now turns the setting off and keeps its value, as unticking it in the Mission Editor does.

A parameter sent as null is treated as not given. In add_task, modify_task, add_triggered_action and the trigger and goal tools, a null was handled several ways — refused for the wrong reason, a Python error, a setting silently turned off, an Orbit saved with no altitude, a trigger whose two halves disagreed. Now a null leaves the value as it is when editing, or the default when adding, and the response lists it under null_params_ignored.

New missions, FARPs and ships have dynamic cargo switched on, as the Mission Editor does. Every airfield of a mission made with new_miz, and the warehouse of every FARP and carrier we built, had DCS’s dynamic cargo off, where the editor turns it on. It’s now on. A mission you open keeps its own setting, and set_warehouse_properties(dynamic_cargo=false) still turns it off.

Limiting a warehouse’s aircraft no longer removes every type you didn’t name. DCS stocks only what a limited warehouse lists, so naming one aircraft type left the airfield with no other. Now, as in the Mission Editor, every type you don’t name is listed too: one the warehouse already lists keeps its amount, and the rest get the editor’s 100. To stock only the aircraft you name, pass others_amount=0; any other amount is given to every type you don’t name. The response says what was listed.

A misspelled field is refused. An entry like {"amount": 12} was written beside an amount of 0, so the aircraft wasn’t stocked and nothing said so. A field a warehouse entry doesn’t have is now refused, by name.

Limiting a warehouse’s munitions no longer removes every weapon you didn’t name. As with aircraft, every weapon you don’t name is now listed as the Mission Editor lists it: at 100, or at 0 in a warehouse that already listed weapons, as the editor does. others_amount=0 stocks only the weapons you name.

Weapons can be given by name. A warehouse weapon is known only by its number, and a wrong or missing number stocked nothing without a word. Give a weapon by the name the editor’s warehouse dialog uses — a near miss gets suggestions — or by its number as "a.b.c.d". An entry without a proper number is refused. A community mod’s weapon is given by its number.

The weapons list is saved as the editor saves it. It was saved with text keys, which the Mission Editor doesn’t count, so opening the mission in the editor would have reset the warehouse to its defaults. It’s now a numbered list, in the editor’s order.

remove_waypoint removes one waypoint, as the Mission Editor’s DEL does. There was no way to remove a waypoint without rebuilding the whole route and losing every task on it. Its tasks go with it, and every loop and “stop at waypoint” that names a later waypoint is renumbered so it still names the same one. Waypoint 0 can’t be removed, as in the editor.

Inserting a waypoint renumbers the same way. A waypoint added in the middle of a route left SwitchWaypoint loops and “stop at waypoint” conditions pointing at the old numbers, so a loop could return to the new waypoint instead. They now follow, as the editor has them.

A task’s script file or message sound goes with it. remove_task and remove_waypoint remove the file too, as the editor does, unless something else still uses it.

move_group no longer drags the group’s route along. Only the group and its first waypoint move; its other waypoints stay, so a convoy keeps its objective and a carrier keeps its track. The response says how many stayed. Flights on a moved carrier or FARP go with it — where they start and where they land — while their racetracks and targets stay put. A FARP’s parked helicopters used to be left behind.

A flight at an airfield, or on a ship or pad, moves by naming the new place. move_group used to put such a flight on open ground, still set to take off from parking. It now refuses, and modify_waypoint on waypoint 0 with an airfield, ship or FARP moves it there, onto free stands or pads as a new flight would get. Like a new flight, it claims a neutral airfield for its side, and it is refused at the other side’s airfield. Changing waypoint 0’s airfield used to leave the aircraft on the old airfield’s stands.

A flight can no longer start from, or land on, the other side’s carrier or FARP. The flight tools, modify_waypoint and add_waypoint took any ship or FARP, whichever side it was on. The Mission Editor offers a flight only its own side’s, and now so do they.

set_country_coalition now warns when the country it moves owns another country’s FARP’s support vehicles. When a FARP’s country does not field every support vehicle, create_farp puts them under CJTF of its side. Moving CJTF to the other side then left the FARP without services, and nothing said so. The warning for moving the FARP’s own country no longer says its vehicles moved with it when they belong to another country.

0.9.11 — 25 September 2026

add_task writes every action the Mission Editor offers. It reached 71 of DCS’s 115 waypoint actions and refused the rest as unknown — including Refueling, which is how an AI flight is told to use a tanker. The list is now generated from DCS’s own table rather than hand-maintained, so it follows a DCS update instead of lagging it. All 115 can now be written, apart from the editor’s own “nothing selected” placeholder, which has nothing to write.

DisembarkFromTransport is no longer accepted. It was never a Mission Editor action: no occurrence in any readable DCS file, none in DCS’s own 789 shipped missions, and a working troop lift doesn’t use it. The ground group gets EmbarkToTransport; the transport gets Embarking to load and Disembarking to unload. Asking for it now returns that instruction rather than building a task that does nothing.

add_task refuses what the Mission Editor would not offer. It used to write the task and warn you — and the warning said, in its own words, that DCS would ignore it: no error, and an empty Advanced Waypoint Actions panel. A mission that looks right and isn’t. Both of DCS’s own checks now apply: whether the action is offered for that group’s task, and whether that specific aircraft or vehicle can do it. Editing a task already in a file is unaffected, so an older mission stays as editable as the editor makes it.

The mission report’s refuelling advice knew fifteen aircraft; DCS classifies sixty-one. It compared your tankers against a hand-written list — ten boom receivers, five basket ones — so a mission of Mirages, Tomcats, Su-33s, Tornados or Apaches with the wrong tanker drew no comment at all. It now reads which system each aircraft uses from DCS itself, so it follows a DCS update instead of lagging it. One aircraft, the C-130J-30, is marked refuelable without DCS saying which system it uses: the report names it and says it did not check, rather than guessing.

Waypoint options now default the way the Mission Editor sets them. Twenty-four options were built with defaults of their own, and twelve differed from DCS’s. An aircraft’s rules of engagement defaulted to Weapon Free where the editor uses Open Fire. The seven restriction options (no afterburner, no air-to-air, radio silence and so on) came on when added, where the editor adds them off. Disperse Under Fire wrote a yes/no where DCS takes a time in seconds. Values are now checked against what DCS offers each kind of group (ground units and ships get three rules of engagement, not five), and DCS’s own value names, such as WEAPON_HOLD, are accepted. Reaction to Threat no longer fails when given a value.

Attack actions carry the editor’s weapon, altitude and flight setting. Every attack wrote the same all-weapons code, whatever the attacker or target. The editor picks from a list for each: an L118 firing at a point, a Hornet bombing a runway and a Hornet attacking a tank get three different values. The weapon now comes from DCS’s own tables, checked field for field against missions built in the editor. So does the attack altitude (the waypoint’s, where the editor uses it), and so does Bombing Runway’s whole-flight attack, which DCS sets on and we had off. A weapon you name still stands, and every attack action now accepts any weapon the editor offers, where only the underlying library’s own values were accepted before.

An attack or follow action without a target is refused. Attack Group, Engage Group, Follow, Escort and their relatives wrote a target of 0, the editor’s “nothing”, when none was given, and DCS loads such an action and does nothing. They now ask for the target, and a target that isn’t in the mission is refused too. Go To Waypoint needs its waypoint for the same reason.

Tractors, trailers and the GCI station. DCS’s trailers and its GCI station (KRU) couldn’t be placed at all. They can now, along with the other vehicles DCS ships that the underlying library doesn’t know. Attach Trailer and Detach Trailer are written as the editor writes them: a trailer must be named, and must be one the tractor can tow. Embarking and Disembarking now go on ground troop carriers such as the M-113, as the editor allows.

Ships carry their own beacons from the start. A naval group’s first waypoint now gives each capable ship its own TACAN, ICLS and Link 4 on channels no other ship uses, as the editor does. A beacon added to a carrier is written in the mode DCS expects for ships. RSBN and GCI stations take the next free channel instead of all sharing channel 1.

modify_task can edit waypoint options, including the ones DCS places on the first waypoint by itself. It used to refuse every option.

modify_task edits any action, and changes only what you name. Editing an attack, a landing, a troop lift, a radio message, a script, a formation or a controlled task was refused unless the whole action was restated. Some edits also reset fields that weren’t named, such as Fire at Point’s spread radius or a FAC’s radio modulation. Every action now keeps what an edit doesn’t name. As in the editor, an attack moved to a new target keeps its weapon while that target’s list offers it.

Attack courses are written in radians. Bombing, Attack Unit, Strafing and Bombing Runway take direction in degrees, as documented, but wrote the number unchanged where DCS expects radians. An attack course of 90 came in on the wrong heading.

Radio messages are stored as the editor stores them. A Transmit Message’s subtitle now goes into the mission’s text dictionary, and its sound file gets the action’s own resource entry, as the editor writes both.

Carpet Bombing aims at its waypoint, or at a point you name. It used to write one fixed point, the same in every mission and nowhere near the run. It now aims at the waypoint it sits on, takes an optional position like the other attack actions, and keeps that point when an edit doesn’t name a new one.

Setting the DCS install path takes effect at once. After set_dcs_install_path or forget_dcs_install_path, the server kept what it had read from the old location, including a failed read, until it restarted. Because tasks are refused when DCS’s action table can’t be read, fixing the path didn’t help until then. It now takes effect immediately.

dcs_install_report says add_task refuses without DCS’s action table. It said the check would be skipped, but add_task refuses instead. The report now says so, and the refusal names how to point the server at DCS.

dcs-mcp works in Cowork and in Claude’s new layout. Anthropic is combining Chat and Cowork into one layout, account by account. There, every tool that edits a mission failed with “session_id: Field required”: the connection between the conversation and your computer drops an argument with that name. The tools now take and return mission_id instead. session_id is still accepted wherever it gets through.

0.9.10 — 18 September 2026

DCS World is now required.

Missions keep what the Mission Editor put in them.

Groups are created the way the Mission Editor creates them.

Routes can carry a time on target, and waypoints are checked against the terrain.

More mistakes are caught before you fly.

Airfields, parking and terrain come from DCS’s own data on all eleven supported maps, so parking spots, runways and ATC match what the editor shows.

Air-defence sites and FARPs clear the trees around them, so their radars and launchers are not blocked; other groups clear only when asked.

Also: four new tools (modify_task, remove_task, replace_payload, clear_payload), your own saved templates in the site builders, three cockpit trigger actions, and weapon settings applied with a loadout.

Tools were retired. If you have scripts that call them, they will fail.

0.9.9 — 14 August 2026

Strike flights had no attack task. If you built one on 0.9.3 through 0.9.8, rebuild it.

Strike and SEAD flights could be sent below ground.

DCS is now found wherever it is installed.

Fixes to placement, escorts, radios and liveries.

Response-shape changes.

Also new.

0.9.8 — 7 August 2026

Three changes that can break existing work. Please read these first.

Audio in triggers never played. It does now.

Carriers.

FARPs.

Groups, airbases and file paths.

Diagnostics and setup.

0.9.7 — 6 August 2026

Iraq and Afghanistan.

Parking.

Diagnostics and setup.

Countries.

Theatre list.

0.9.6 — 4 August 2026

SAM sites work now.

Terrain.

Smaller changes.

Upgrading. Run the installer over your existing installation. Your license key and installed terrain packs are preserved — leave the key field blank.

0.9.5 — 3 August 2026

Trigger actions.

Terrain.

Known issue, disclosed with this release. SAM site tools build each unit as its own group rather than one group for the whole site, which stops multi-component sites from functioning. This predates the beta and is the next release's priority. Details and a workaround on the known issues page.

Upgrading. Run the installer over your existing installation. Your license key and installed terrain packs are preserved — you can leave the key field blank.

0.9.4 — 2 August 2026

Coalitions. This release fixes how sides are assigned, which was wrong in several related ways.

One deliberate quirk worth knowing: dcs-mcp won't create units for a country on the neutral side, matching the Mission Editor, which doesn't offer that either. It will let you move a country to neutral while it still holds units, because DCS accepts that state.

Other fixes.

Upgrading. Run the installer over your existing installation. Your license key and installed terrain packs are preserved — you can leave the key field blank.

0.9.3 — 1 August 2026

Bug fixes.

Upgrading. Download and run the installer over your existing installation. Your licence key and any terrain packs you have installed are preserved — you can leave the key field blank during the upgrade.

Terrain catalog update — 1 August 2026

Server-side changes to the Terrain Manager catalog. No new download needed; dcs-mcp itself is unchanged at 0.9.2.

0.9.2 — 24 July 2026

The signed launch build.

0.9.1 — 21 July 2026

Beta-hardening fix from installer testing.

0.9.0 — 21 July 2026

Initial open-beta release.

Known limitations (beta)