Doutor

A página do Médico é uma verificação de saúde completa. Ele executa vários testes no dispositivo, no SIM e no ambiente host e, onde há uma solução óbvia, oferece uma ação em linha para aplicá-la. Comece aqui sempre que algo não estiver funcionando - provavelmente o médico já sabe o que é.

Compatibilidade de hardware

O primeiro cartão na página do Doutor é um compatibilidade de hardware painel. Ele hospeda dois controles relacionados: um Inverter polaridade do eixo alternar e um drag-pad ao vivo teste de polaridade. Ambos existem porque diferentes execuções de produção do Sidewinder Force Feedback 2 interpretam a polaridade do force-feedback de maneira diferente - em algumas baquetas, o que a ponte pensa que é “para frente” puxa fisicamente para trás e vice-versa. A alternância é a correção no nível da instalação; o teste é como você sabe se deve invertê-lo.

Teste de polaridade ao vivo

Clique Começar e um pequeno drag-pad XY torna-se ativo. Mova o disco, o stick segue em tempo real - a ponte é armada automaticamente no modo Mock durante o teste para que a verificação de pré-requisitos passe sem uma conexão sim. Clique Pare quando terminar. Um modal de confirmação pergunta “O stick seguiu o disco?”:

• Sim — a polaridade está correta, nenhuma alteração foi feita.
• Não — a alternância muda automaticamente e todas as forças subsequentes nos eixos de inclinação e rotação são negadas na borda de saída do dispositivo.

Navegar para fora da página Doctor no meio do teste o interrompe silenciosamente e restaura sua fonte de entrada anterior (ativa ou inativa) - sem necessidade de parada explícita.

Inverter polaridade do eixo (manual)

A alternância à esquerda do cartão é a mesma configuração que o teste escreveria. Use-o diretamente se você já sabe que seu stick precisa ser virado - por exemplo, você já passou por isso em uma instalação anterior e deseja configurá-lo antes de testar. A configuração é no nível de instalação, não por perfil: ela reside nas preferências da ponte, aplica-se aos eixos de inclinação e rotação juntos e sobrevive às reinicializações.

Periódicos combinados com software

A ponte tem duas maneiras de enviar efeitos periódicos e únicos (rumble, buffets, tremores…) para o FFB2. Modo de hardware - o padrão de instalação nova - usa efeitos de hardware DirectInput, e o beta.11 mantém essa topologia deliberadamente pequena: uma constante vetorial, uma mola de dois eixos e um pool periódico preguiçoso de três slots. O firmware ainda controla as formas de onda periódicas na taxa nativa; a ponte simplesmente reutiliza esses slots físicos para a pista atual, motor, bufê e pistas únicas. Periódicos combinados com software, a alternância na mesma linha Doctor, mantém apenas o caminho de hardware de força/centralização contínua e sintetiza sugestões periódicas e únicas em C# a 200 Hz, dobrando o resultado nas saídas de força constante.

O modo de hardware é mais nítido e tem menor latência nos efeitos de frequência mais alta porque o firmware os conduz mais rápido do que a taxa de tick da ponte. A combinação de software é o substituto de compatibilidade para pilhas de drivers que ainda travam no modo de hardware, para resultados de testes com falha ou para usuários que preferem deliberadamente. Uma saída genérica e impura não força a combinação de software por si só. Ambos os modos usam os mesmos quatorze efeitos com os mesmos controles deslizantes de ajuste por efeito – a escolha é um detalhe de envio, não uma alternância de recurso. Requer reinicialização de qualquer maneira; o despachante lê o modo na inicialização.

Clique Testar efeitos de hardware para testar a topologia de hardware compacta com segurança. O Doutor inicia um processo de trabalho separado, aloca a mesma constante vetorial, mola de dois eixos e conjunto periódico que a ponte usa em voo e depois a desmonta. Se a pilha DirectInput/PID do Windows falhar, apenas o trabalhador morre e a ponte permanece aberta. Se o teste for aprovado, o Doctor e o tempo de execução mudarão para o mesmo estado de modo de hardware na próxima inicialização, de modo que o status do Doctor e o modo real do despachante coincidam.

Como os cheques são dispostos

Cada linha de verificação tem quatro partes:

• Ponto de status — verde (aprovado), âmbar (aviso), vermelho (reprovado), cinza (não aplicável nesta plataforma).
• Título - o que está sendo verificado.
• Detalhe - um resumo de uma linha do que foi encontrado. Passe o mouse (ou toque no toque) para ver todos os detalhes.
• Botão de ação – presente apenas quando há algo acionável. Exemplos: Instalar regra do udev, Usar porta: 5111, Corrigir….

Os cheques

Dispositivo

Confirma que o Sidewinder Force Feedback 2 está visível para o sistema operacional e que a ponte pode abri-lo exclusivamente. Falha se o VID/PID não estiver presente ou se outro processo estiver segurando o identificador.

Linux regra do udev

Checks whether /etc/udev/rules.d/99-ffb-bridge.rules está presente e corresponde ao conteúdo canônico. Quando ausente, a ação é Instalar regra do udev — this triggers a pkexec prompt para gravar o arquivo em um local privilegiado.

Configuração do SimConnect

Looks for MSFS's SimConnect.xml no local apropriado da plataforma, analisa-o e compara quaisquer entradas IPv4 habilitadas com a porta que a ponte está usando. Três resultados possíveis:

• Entrada correspondente encontrada. Verde – nada para fazer.
• Entrada em um porto diferente. Âmbar – oferece um Usar porta:X botão para adotar essa porta.
• Nenhuma entrada utilizável (ou arquivo não analisável). Vermelho – oferece um Corrigir… botão que abre a caixa de diálogo de instalação (veja abaixo).

Acessibilidade do SimConnect

Testa a porta TCP configurada. Envia um pacote SimConnect OPEN real e inspeciona o cabeçalho de resposta para poder distinguir MSFS está ouvindo de outra coisa está ouvindo.

Acessibilidade do X-Plane

Sends a tiny RREF probe to 127.0.0.1:49000 e espera brevemente por um dataref em resposta. Mapeia o tempo limite e o Winsock WSAECONNRESET (recebido quando uma porta ICMP inacessível foi entregue) para “não em execução”.

Tempo de execução

Verifica se o circuito de controle está funcionando em seu alvo de 50 Hz. Avisa se a média dos últimos 60 s cair abaixo de 45 Hz.

Registro de falhas

Se houver um log de falhas da última sessão, a linha ficará âmbar e oferecerá Revelar para ir até ele em seu gerenciador de arquivos e Enviar via formulário de feedback que preenche previamente um envio de feedback com o log anexado.

Caixa de diálogo de correção

Corrigir… os botões não aplicam as alterações diretamente - eles abrem uma caixa de diálogo que mostra exatamente o que está prestes a ser alterado, onde e (no Linux) o que o prompt de autenticação solicitará que você aprove.

O diálogo é sempre aditivo: as entradas existentes nunca são substituídas. Se o arquivo de destino não puder ser analisado, a caixa de diálogo explica que um backup com registro de data e hora será feito primeiro. Cancelar é sempre a escolha segura.

Comportamento do Linux pkexec

Ações que gravam em caminhos do sistema (regras do udev, qualquer coisa abaixo /etc) route through pkexec. Você verá o prompt normal do polkit da sua distribuição - o mesmo que aparece para gparted ou uma GUI do gerenciador de pacotes. Códigos de saída que o médico interpreta:

Quando o Doutor é verde em todos os lugares

O aplicativo deve funcionar. Caso contrário, o log de eventos do Diagnóstico mostrará mais detalhes do que o status de uma linha do Médico. Vá para lá a seguir ou pule para Solução de problemas para sintomas e soluções comuns.