JATF Briefing
Builder
Compilatore di briefing JATF per DCS World. Si crea il briefing, si carica il file .miz e l'applicazione precompila quello che la missione contiene davvero; si corregge, si completa, e si esce con un PDF unico per il pacchetto e un cosciale PNG per ogni volo. Ogni campo dichiara da dove viene, e quello che il .miz possiede viene validato invece che riscritto.
Cos’è
Il Briefing Builder compila i briefing nel formato JATF partendo dalla missione vera. Il flusso è breve: si crea il briefing, si carica il file .miz, l’applicazione precompila quello che la missione contiene davvero, si corregge e si completa a mano, e si esce con un PDF unico per il pacchetto e un cosciale PNG per ogni volo.
È uno degli strumenti di SECTOR, l’applicazione che ospita anche Mission Tracker, Live View, GCI Scope, ACIS, ATC, JTAC e Comms, e come la Live View sta dietro una sessione admin.
Il punto: restituire il tempo speso a ricopiare
Un briefing di pacchetto è in buona parte lo stesso dato scritto tre volte. Radio e TACAN di un volo esistono una volta sola, ma finiscono nel COMM-PLAN, nel task del pacchetto e sul cosciale, e ogni copia è un’occasione di sbagliare. Qui esiste una sorgente sola e tre rese, prodotte dalla stessa funzione: si scrive una volta e le tre viste seguono.
L’import è un acceleratore, non un presupposto
Il modello non dà per scontato che ci sia un .miz. Ogni campo si compila a mano dalla prima riga all’ultima, e il file è solo un modo per arrivarci prima.
Per rendere la cosa leggibile invece che magica, ogni campo porta scritta la sua classe di origine:
| Classe | Da dove viene |
|---|---|
| E | Estratto dal .miz |
| A | Assegnato dall’applicazione |
| M | Scritto a mano |
Un campo autopopolato che l’autore modifica passa a M, e da quel momento nessun reimport lo sovrascrive. Il blocco vale per singolo campo, e non è un vezzo: rigenerare dopo una modifica minima al .miz non deve rimescolare valori che sono già stati comunicati ai piloti.
Validare invece che riscrivere
Sui campi che vivono davvero dentro il .miz (radio, TACAN, ICLS) l’applicazione valida e segnala, non corregge: la correzione si fa nel Mission Editor, dove quel dato ha la sua unica versione vera. Questo toglie di mezzo alla radice il rischio peggiore di un briefing generato, cioè che il cosciale stampi una frequenza che nel cockpit non esiste.
L’assegnazione automatica resta dov’è utile e innocua, cioè sui campi che nel .miz non esistono affatto: laser, carburante, canali comuni del briefing.
Il carico prende la forma del velivolo
Come si descrive un carico dipende da cosa lo porta: piloni numerati per un caccia, un manifesto per un Hercules, carico e passeggeri per un elicottero da trasporto. Stampare “PILONE 7” sul cosciale di un C-130 produce una scheda che non si può compilare, quindi la forma cambia con il velivolo.
I dati vengono dal datamine di DCS e sono rigenerabili: 1900 CLSID tradotti in nome e peso dell’arma, e il numero di piloni per 144 velivoli. Un CLSID che non si risolve resta com’è e viene segnalato, mai tradotto tirando a indovinare, perché un nome d’arma sbagliato manda un pilota a pianificare con un carico che non ha.
Le uscite
Un PDF unico con indice e numerazione, e un PNG 1536x2048 per ogni volo. Il PDF non sostituisce l’export in immagine: DCS carica i cosciali come file grafici dalla cartella Kneeboard, quindi servono entrambi.
Il cosciale è uno per volo e non uno per pacchetto, perché la INTRAFLIGHT è diversa per ogni volo. Il PNG si produce passando da SVG a data URI a canvas, senza librerie esterne, perché la CSP dell’applicazione non ammette script serviti da un CDN.
Le password del server non finiscono mai nel PDF né sui cosciali.
Sicurezza della lettura dei file
Un .miz è uno zip che arriva da fuori, quindi viene trattato come tale. La lettura ha un budget (60 MB di archivio, 24 MB per singolo membro) che ferma le zip bomb prima che diventino un problema di memoria, e il Lua viene interpretato da un parser del solo sottoinsieme tabellare che serve: una loadstring sarebbe più comoda ma non permetterebbe di imporre un tetto.
Le immagini caricate seguono lo stesso principio: il tipo si decide dalla firma dei byte e non dall’estensione, il nome del file lo sceglie il server, e le dimensioni si leggono dall’intestazione senza tirare dentro una libreria di imaging.
Distanze e rotte
La proiezione cambia per teatro, ma distanza e rotta non la usano: si calcolano nello spazio metrico del .miz, dove i numeri sono già quelli giusti. È il motivo per cui restano esatte anche dove le costanti di proiezione sono ancora da verificare.
Cosa manca, dichiarato
I punti aperti sono scritti dentro l’interfaccia, non nascosti nel codice: la griglia JATF è compilata solo in parte (bande e assegnazioni comuni ancora da riempire), i canali e le costanti di proiezione sono marcati come non verificati, e manca la tabella che traduce l’identificativo numerico dell’aeroporto nel suo nome, quella che servirebbe a precompilare partenza, arrivo e alternato.