DCS Mission
Control

Il motore della campagna: una guerra di terra dentro la missione (dalla v1.62 alla v1.150). Mission Control non scrive più solo la missione dopo: un motore gira dentro la missione DCS e fa combattere le due parti, settore per settore. Ogni parte ha un direttore automatico che manda le forze, corazzate all'assalto, motorizzate al controllo dei settori neutrali, difesa nel contrattacco; chi tiene una fazione può prendere i suoi posti e spendere i crediti della parte, decidendo dove ma non quante forze, così le due parti hanno sempre lo stesso numero di forze in campo, con una persona o senza. Le forze si comportano come quelle dei suoi script: un carro che vede la torretta nemica già girata verso di lui lo insegue, un IFV prova ad aggirarlo, la contraerea si nasconde dietro le case e si scopre per tirare. Quando un campo di battaglia è vinto il fronte avanza, la storia del fronte lo tiene, e i risultati arrivano su Discord. Dietro le linee volano AWACS e cisterne gratis, coi nominativi, le frequenze e i TACAN delle serate JATF, e l'IA mette la sua CAP coi crediti, coi caccia e i carichi del periodo. Lo scenario si prepara nel Campaign Manager e ogni parte si comanda dal Faction Command.

Una campagna da zero (v1.77). Accanto a quella che parte da un .miz fatto a mano, c'è la campagna che il .miz se lo fa scrivere da SECTOR: si sceglie il teatro fra gli undici di cui SECTOR conosce la mappa, il giorno, l'ora e il meteo con le voci del Mission Editor. Se SECTOR gira sulla stessa macchina di DCS, un tasto mette il file nella cartella delle missioni e dice al server di caricarlo fra trenta secondi, con un messaggio in gioco per chi è in volo. La serata di prova, con ventidue missioni scritte da SECTOR, è ancora da fare.

La campagna dinamica, fase 1: la missione dopo la scrive Mission Control (v1.55). Il riferimento è DCS Retribution, ma con una scelta presa insieme all'inizio: non si parte da zero, si parte dalla missione fatta a mano nel Mission Editor, riscritta a ogni turno. Slot, frequenze, script, trigger, magazzini e immagini restano come nel file. La gestione preme Genera la missione, sceglie quanti giorni passano, l'ora di partenza e se lasciare i relitti, guarda l'anteprima e genera. Lo stato dei bersagli decide il resto: un gruppo distrutto sparisce e lascia i relitti al suo posto, di un gruppo danneggiato spariscono solo i mezzi che il Tacview ha visto cadere, e un gruppo ad attivazione ritardata non si tocca, perché di solito è il modello di uno script.

Il piano, il briefing rilasciato, gli avvisi su Discord e le iscrizioni (v1.49 e v1.50). Sopra la mappa c'è il piano della missione, una tabella coi pacchetti da guardare insieme prima di volare. Il controller rilascia il briefing, che nasce nel Briefing Builder per la sua parte dall'estratto del .miz e dai pacchetti del piano, e se lo rilascia di nuovo tiene quello che è stato corretto a mano. Gli avvisi vanno su Discord con un webhook per parte, che non torna mai al browser. Sotto ogni pacchetto un pilota preme Mi iscrivo, uno per missione, e la fazione la mette Discord dal ruolo, perché fazione e funzione sono cose separate: il ruolo dice cosa fai, la fazione da che parte stai, e la fazione segue la missione. Nei rapporti si allegano anche i video MP4.

Lo stato dei bersagli dal Tacview, in automatico (v1.46.0). Oltre ai rapporti scritti a mano, il controller carica la registrazione della missione, la stessa che si apre nell'Analyzer, e il server la legge con lo stesso parser: trova i mezzi a terra e le navi distrutti (in un .acmi un mezzo distrutto sparisce prima della fine), li aggancia ai bersagli dal nome del gruppo del Mission Editor e aggiorna lo stato senza bisogno di conferme. Sul bersaglio resta un rapporto con la prova: quanti mezzi su quanti, e per ognuno quando, chi lo ha colpito e con che arma. Dove la registrazione ha qualcosa da dire decide lei, e la segnalazione di un pilota in attesa si chiude con quello che dice il file; uno stato già più grave non torna indietro. Una registrazione spezzata in due file si carica un pezzo per volta e i mezzi si sommano, lo stesso file ricaricato non cambia niente, e il file non resta sul server.

Pacchetti, rapporti con le foto, fasi della missione e fronte (v1.45.0). Il controller crea i pacchetti con il loro compito (SEAD, attacco, CAS, antinave, scorta, CAP, ricognizione, supporto) e un pilota ne prende il comando, sceglie i bersagli cliccandoli sulla mappa e scrive velivoli, orario sul bersaglio e nota. Le missioni hanno tre fasi dichiarate in testata, in costruzione, attiva e conclusa, e al più una in costruzione e una attiva insieme: quando una missione diventa attiva il piano si ferma per i leader, mentre il controller può ancora correggere. Sulla scheda di un bersaglio ogni pilota scrive due righe, dice se è danneggiato o distrutto e allega fino a quattro foto, riconosciute dai byte e non dall'estensione; quello che dice un pilota resta da confermare finché il controller non conferma o respinge, quello che scrive il controller vale subito. La gestione disegna la linea del fronte con gli avanzamenti possibili, e le linee delle missioni precedenti restano tratteggiate: è lo storico.

Prima versione di /mission, il tabellone dei bersagli (v1.44.0). Il controller di fazione carica il .miz e ne escono, per la sua parte, i gruppi dell'altra coalizione che possono essere bersagli, ognuno col tipo deciso da cosa ha dentro, la classe, la portata se è difesa aerea, la composizione coi nomi del Mission Editor e la posizione. Con A, M e B gli dà la priorità, e da quel momento i piloti lo vedono: quello che resta fuori elenco per loro non esiste. Alla missione dopo si carica il file nuovo e priorità, stato e note restano, perché i gruppi si riconoscono dal nome. Corretta anche la conversione dalle posizioni di DCS, che sbagliava di 16 metri al bordo del Caucaso e di 200 su Kola: le costanti dei teatri sono state confrontate con quelle di pydcs, due erano sbagliate e quattro mancavano.