Pacchetti di supporto

Un bundle di supporto è un singolo ZIP che racchiude lo stato del bridge nel momento in cui qualcosa è andato storto. È l'unico artefatto che chiederemo durante la valutazione di un ticket. Questa pagina descrive esattamente cosa c'è in uno, quindi sai cosa stai inviando.

Come esportarne uno

1. Apri FFB-Bridge e vai al file Supporto pagina (barra laterale), quindi il file Diagnostica scheda.
2. Fare clic Pacchetto di supporto (in alto a destra della scheda Diagnostica).
3. Dopo un breve ritardo, un banner mostra il nome e la dimensione del file, con un collegamento al modulo di feedback e, ove disponibile, Rivela il file.
4. Apri il modulo di feedback e allega il ZIP se vuoi inviarlo.

Cosa c'è nel pacchetto

Un bundle è un semplice ZIP. I nomi dei file riportati di seguito rappresentano l'elenco completo dei consentiti: il pacchetto lo farà mai contenere qualcosa al di fuori di questo insieme.

sysinfo.txt

Metadati di sistema. Testo semplice, righe chiave:valore. Campi:

• os-name — “Windows”, “Linux” o “macOS”.
• os-version : versione del kernel, stringa di build di Windows o versione di macOS.
• distro — su Linux, /etc/os-release PRETTY_NAME.
• cpu-model, cpu-cores - da /proc/cpuinfo o Win32_Processor.
• ram-total-mb - da /proc/meminfo o Win32_ComputerSystem.
• dotnet-version — versione runtime di .NET in bundle.
• platform — chiave esplicita per il ramo Linux-vs-Windows.
• locale — locale dell'utente corrente.
• bridge-version, build-hash — versione bridge e git SHA in fase di compilazione.

sessione.log

Registro eventi completo per la sessione corrente. Stesso contenuto della striscia di registro della scheda Diagnostica, ma include tutto dal lancio, non solo ciò che è visibile. UTF-8.

last-crash.log

Se il lancio precedente si è bloccato, il registro degli arresti anomali viene visualizzato qui. Analisi dello stack, dump dei thread, le ultime righe di registro prima dell'arresto anomalo. Assente se la sessione non si è bloccata.

previous-session.log

Il log ruotato dall'esecuzione precedente a quella corrente, quando presente. Dopo un report di crash e riavvio, spesso è il file che mostra cosa è accaduto prima del riavvio.

doctor.json

La scansione più recente dei Controlli di integrità dalla pagina Supporto in formato leggibile dalla macchina. Ogni riga riporta il nome del controllo, lo stato (pass / info / warn / fail / ready / checking / n/a) e la stringa dei dettagli grezzi. Questo ci consente di vedere lo stato dei controlli di integrità senza dover incollare screenshot. Il file è denominato doctor.json per ragioni storiche: la pagina di supporto si chiamava Doctor.

tunables.json

I valori del profilo di regolazione attivo al momento dell'esportazione. Stesso schema di un profilo salvato. Utilizzato per riprodurre l'esatta configurazione di forze con cui si stava volando.

hardware-settings.json

Impostazioni di compatibilità hardware al momento dell'esportazione: blending software, Smooth steady forces, polarità degli assi, scambio pitch/roll, preferenza raw-HID, opt-in per dispositivi non elencati e se i toggle live differivano dalle impostazioni salvate.

simconnect.txt

MSFS SimConnect.xml se il bridge è riuscito a leggerne uno, con gli indirizzi IP non-localhost oscurati. Se non ne è stato trovato nessuno, questo file lo dice invece di indovinare.

Platform extras

Windows bundles include hid-devices.txt per i record dei dispositivi Plug and Play corrispondenti. I bundle Linux includono usb.txt, evdev.txt, udev.txt, e dmesg.txt per il contesto dello stack USB/input. Ogni bundle include anche README.txt con un riepilogo dei contenuti e una nota sulla privacy.

Cosa NON c'è nel pacchetto

Il generatore di pacchetti di supporto utilizza un rigoroso elenco di nomi di file consentiti. Non includerà nulla al di fuori di tale elenco, anche se nella stessa directory è presente qualcosa di corrispondente. In particolare:

• Nessuna password o credenziale salvata. Il ponte non ne immagazzina.
• Nessun file di profilo altro che quello attivo.
• Nessun registro di sistema, diario o altro al di fuori delle directory dei dati del bridge.
• Nessun pacchetto di rete acquisito.
• Nessun token cloud (il bridge non ne utilizza).

Elaborazione lato server

Quando alleghi un pacchetto a un rapporto di feedback, l'operatore di assunzione del sito lo analizza per estrarre dati indicizzabili utili nel nostro database:

• Informazioni di sistema in una riga di riepilogo per il raggruppamento ("quanti rapporti da questa distribuzione?").
• Righe di avviso ed errore dal registro, con firme di errore stabili, così possiamo vedere a colpo d'occhio quante persone hanno riscontrato lo stesso bug.
• Risultati dei controlli di integrità per un'analisi dettagliata di ciò che non funziona nella base utenti.
• Il testo letterale del file di ogni voce consentita, archiviato in modo da poter rileggere il contesto durante la valutazione.

Il bundle grezzo stesso viene conservato per un breve periodo (30 giorni per impostazione predefinita) in modo da poterlo rieseguire se la nostra logica di estrazione migliora. Successivamente, i dati analizzati vengono conservati; il blob grezzo viene eliminato.

Limiti

In pratica un bundle normale è sotto il megabyte. Questi limiti esistono per escludere caricamenti ostili, non per escludere segnalazioni reali.

Invio senza modulo di feedback

Se si preferisce inviare il pacchetto direttamente via email, scrivere a feedback·ffb-bridge.com (sostituisci il · con una @) e allega il ZIP. Il parser lato server non viene eseguito per la posta elettronica, quindi la valutazione è più lenta, ma il pacchetto è altrettanto utilizzabile.