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

1. Abra o FFB-Bridge e navegue até o Suporte página (barra lateral) e, em seguida, o Diagnóstico guia .
2. Clique Pacote de suporte (canto superior direito do cartão de diagnóstico).
3. 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.
4. 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-release PRETTY_NAME.
• cpu-model, cpu-cores - de /proc/cpuinfo ou Win32_Processor.
• ram-total-mb - de /proc/meminfo ou Win32_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. Ele contém o mesmo tipo de evento que a faixa de log de Diagnóstico e inclui todas as entradas desde a inicialização, incluindo entradas fora da janela 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

— seleção do dispositivo físico e renderizador, limite de segurança, calibração e polaridade da força, atribuições explícitas de controle e configurações de compatibilidade no momento da exportação.

aircraft-profiles.json

O arquivo de vinculações entre aeronave e perfil, incluído na íntegra quando existe. Ele registra qual perfil salvo cada aeronave aplica automaticamente, para que o suporte veja por que um perfil foi selecionado.

profiles-index.txt

Um índice dos perfis salvos no momento da exportação: nome do arquivo, tamanho, data de modificação e o título, o id e a revisão de cada perfil. O conteúdo dos perfis permanece no seu computador.

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

Na prática, um pacote normal tem menos de um megabyte. Esses limites bloqueiam uploads hostis, deixando amplo espaço para denúncias genuínas.

Enviando sem o formulário de feedback

Se você preferir enviar o pacote por e-mail diretamente, escreva para feedback·ffb-bridge.com (replace the · with an @) and attach the ZIP. The server-side parser doesn't run for email, so the triage is slower — but the bundle is just as usable.