DCS Mission
Control
The module that holds a DCS campaign together from one mission to the next: the target board extracted from the .miz, priorities set by the faction controller, packages the leaders take and plan, pilot reports with photographs, and a front line that moves. Target status can arrive on its own from the mission's Tacview.
What it is
Mission Control is the part that was missing: not a tool for a single mission, but the place where a campaign stays standing from one mission to the next. What needs hitting, who goes, what was left standing afterwards, and where the front has moved.
It lives inside SECTOR, the application that also hosts Mission Tracker, Live View, GCI Scope, ACIS, ATC, JTAC, Comms and Briefing Builder, and is reached from gcidemo. The Briefing Builder and the Analyzer stay separate tools: one compiles the flight’s briefing, the other analyses the recording, and neither needs to know what happened three missions ago.
The target board
The faction controller loads the .miz and out come, for their own side, the other coalition’s groups that can be targets: ground vehicles, ships, static objects. Each arrives with the type decided by what it contains (air defence, armour, artillery, infantry, logistics, ships, structures, aircraft on the ground), the class, the range if it is air defence, the composition with the Mission Editor’s names and the position.
Then comes the part that matters. With A, M and B the controller sets high, medium or low priority, and only from that moment do the pilots see it: whatever stays off the list, for them, does not exist. That is not an oversight, it is the point of the module: a list of three hundred groups pulled out of a file is not intelligence, it is a dump.
A bridge, a hangar or a runway is not a group in the .miz, and is placed by hand with a click on the map.
What the pilots see
The list ordered by importance, the map with the targets in the colour of their status and the range ring around air defence, and the card with the position in degrees and minutes and in MGRS.
Each side has its own board, and the filter sits on the server: whoever has a role tied to a coalition sees only theirs, and not because the browser hides the rest.
The packages
The controller creates the mission’s packages, which are born Alfa, Bravo and so on, each with its task: SEAD, strike, CAS, anti-ship, escort, CAP, reconnaissance, support. A pilot takes command of a free package, picks the targets by clicking them on the map or in the list, and writes aircraft, time on target and a note.
It is the division of labour that actually exists in a group: whoever decides what matters is not whoever decides how to get there.
The three phases
A mission is under construction (the plan is being made), active (the plan is frozen for the leaders, the controller still corrects) or concluded (it stays in the history). At most one under construction and one active at a time, so the next mission is prepared while tonight’s has already launched.
The reports, and who has the last word
On a target’s card every pilot writes two lines, says whether it is damaged or destroyed, and attaches up to four photographs or GIFs, recognised by their bytes rather than their extension, visible only to whoever sees that target.
The rule is deliberately asymmetric: what a pilot says stays pending until the controller confirms or rejects it, what the controller writes counts immediately. A pilot in a hard turn seeing a fire is testimony, not a verdict.
The status that updates itself
Since 1.46 there is a second route, and it coexists with the first. The controller presses Upload the Tacview and gives the mission’s recording, the same one that opens in the Analyzer. The server reads it with the same parser, finds the destroyed ground vehicles and ships (in an .acmi a destroyed vehicle disappears before the end), attaches them to the targets by group name and updates the status with no confirmations.
A Tacview report with the evidence stays on the target: how many vehicles out of how many, and for each one when, who hit it and with what weapon. Where the recording has something to say it decides, and a pending report is closed by what the file says; a status already more severe does not go back.
A recording split across two files is uploaded a piece at a time and the vehicles add up; the same file uploaded again changes nothing. The file does not stay on the server, with the same limits as the Analyzer.
The front
Management draws the front line on the map, with points that drag and several segments, and the possible advances as arrows in the colour of whoever advances, with the condition and the outcome. The line holds after the last concluded mission, and the earlier ones stay dashed: that is the history, with each mission’s account, the targets hit and the plan that was in place.
Who can do what
The controller is a permission on the role, not a level: the mission_ctrl checkbox, valid for that role’s coalition. There can be more than one per side, and an administrator always is one. The page refreshes itself every five seconds and writes are small operations, so two controllers working together do not overwrite each other.
Status
It is work in progress: all three phases are there and the demo carries a read-only sample campaign, but the automatic hook from the Tacview still has to be tried on a real campaign with a recording that has destroyed ground targets, because the Analyzer’s sample has none.
Access
Open at gcidemo.alessandrosimonitto.it/mission, with a read-only sample campaign on the ground vehicles of the Syria mission.