Pacotes de suporte
Um pacote de suporte é um único ZIP que empacota o estado da ponte no momento em que algo deu errado. É o único artefato que solicitaremos ao fazer a triagem de um chamado. Esta página descreve exatamente o que há em um, para que você saiba o que está enviando.
Como exportar um
- Abra o FFB-Bridge e navegue até o Suporte página (barra lateral) e, em seguida, o Diagnóstico guia .
- Clique Pacote de suporte (canto superior direito do cartão de diagnóstico).
- Após um breve atraso, um banner mostra o nome e o tamanho do arquivo, com um link para o formulário de feedback e, quando disponível, Revelar arquivo.
- Abra o formulário de feedback e anexe o ZIP se desejar enviá-lo.


O que há no pacote
Um pacote é um ZIP simples. Os nomes de arquivos abaixo são a lista completa de permissões - o pacote será nunca contém qualquer coisa fora deste conjunto.
sysinfo.txt
Metadados do sistema. Texto simples, linhas chave:valor. Campos:
os-name— “Windows”, “Linux” ou “macOS”.os-version— versão do kernel, string de build do Windows ou versão do macOS.distro— no Linux, /etc/os-releasePRETTY_NAME.cpu-model,cpu-cores- de/proc/cpuinfoouWin32_Processor.ram-total-mb- de/proc/meminfoouWin32_ComputerSystem.dotnet-version— versão de tempo de execução do pacote .NET.platform— chave explícita para a ramificação Linux vs Windows.locale— localidade do usuário atual.bridge-version,build-hash— versão bridge e git SHA em tempo de construção.
session.log
Log de eventos completo da sessão atual. O mesmo conteúdo da faixa de log da guia Diagnóstico, mas incluindo tudo desde a inicialização, não apenas o que está visível. UTF-8.
last-crash.log
Se a inicialização anterior falhou, o log de falha vai parar aqui. Rastreamento de pilha, dumps de thread, as últimas linhas de log antes da falha. Ausente se a sessão não falhou.
previous-session.log
O log rotacionado da execução anterior à atual, quando presente. Depois de um relatório de falha e reinício, geralmente é o arquivo que mostra o que aconteceu antes do reinício.
doctor.json
A verificação de integridade mais recente realizada na página de suporte, em formato legível por máquina. Cada linha carrega o nome da verificação, o status (aprovado / info / aviso / reprovado / pronto / verificando / n/a) e a string de detalhe bruta. Isso nos permite ver o estado das suas verificações de integridade sem que você precise colar capturas de tela. O arquivo é nomeado
doctor.json por razões históricas – a página de suporte costumava ser chamada de Doctor.
tunables.json
Os valores do perfil de ajuste ativo no momento da exportação. Mesmo esquema de um perfil salvo. Usado para reproduzir a configuração exata de forças que você estava voando.
hardware-settings.json
Configurações de compatibilidade de hardware no momento da exportação: mesclagem por software, Smooth steady forces, polaridade dos eixos, troca pitch/roll, preferência raw-HID, opt-in para dispositivo não listado e se os toggles ao vivo divergiram das configurações salvas.
simconnect.txt
MSFS SimConnect.xml se o bridge conseguiu ler um, com endereços IP que não são localhost redigidos. Se nenhum foi encontrado, este arquivo informa isso em vez de adivinhar.
Platform extras
Windows bundles include hid-devices.txt para registros de dispositivos Plug and Play correspondentes. Os pacotes Linux incluem
usb.txt, evdev.txt, udev.txte dmesg.txt para contexto da pilha USB/input. Todo pacote também inclui README.txt com um resumo do conteúdo e uma nota de privacidade.
O que NÃO está no pacote
O construtor do pacote de suporte usa uma lista restrita de nomes de arquivos. Não incluirá nada fora dessa lista, mesmo que algo correspondente esteja presente no mesmo diretório. Em particular:
- Nenhuma senha ou credencial salva. A ponte não armazena nenhuma.
- Nenhum arquivo de perfil além de o ativo.
- Nenhum log do sistema, journal de sistema, nem nada fora dos diretórios de dados da própria ponte.
- Nenhuma captura de pacotes de rede.
- Sem tokens de nuvem (a ponte não usa nenhum).
Processamento do lado do servidor
Quando você anexa um pacote a um relatório de feedback, o responsável pelo registro do site o analisa para extrair dados indexáveis úteis em nosso banco de dados:
- Informações do sistema em uma linha de resumo para agrupamento (“quantos relatórios desta distribuição?”).
- Linhas de aviso e erro do log, com assinaturas de erro estáveis, para que possamos ver rapidamente quantas pessoas encontraram o mesmo bug.
- Resultados da verificação de integridade para detalhar o que está falhando na base de usuários.
- O texto literal do arquivo de cada entrada na lista de permissões, armazenado para que possamos reler o contexto durante a triagem.
O pacote bruto em si é retido por um curto período (30 dias por padrão) para que possamos analisá-lo novamente se nossa lógica de extração melhorar. Depois disso, os dados analisados são mantidos; o blob bruto é descartado.
Limites
| Limite | Valor |
|---|---|
| Tamanho total do pacote | 50 MB compactados |
| Tamanho não compactado por entrada | 5 MB |
| Máximo de entradas | 30 |
| Total descompactado | 20MB |
| Codificação | Somente arquivos de texto UTF-8 (mais o XML) |
Na prática, um pacote normal tem menos de um megabyte. Esses limites existem para descartar uploads hostis, não para descartar relatórios reais.
Enviando sem o formulário de feedback
Se você preferir enviar o pacote por e-mail diretamente, escreva para
feedback·ffb-bridge.com (substitua · por @) e anexe o ZIP. O analisador do lado do servidor não é executado para e-mail, portanto a triagem é mais lenta, mas o pacote é igualmente utilizável.