Notas de lançamento do FFB Probe

Uma correção da intensidade de teste padrão: só o Brunner FFB-G Joystick começa em 75%, e todas as outras bases Brunner começam em 35%.

Intensidade padrão das bases Brunner

• Só o Brunner FFB-G Joystick começa em 75%. O FFB-Probe o reconhece pelo tipo de base que ele informa pelo canal de configuração da Brunner, qualquer que seja a empunhadura instalada, e a lista de verificação mostra “Validated base (Brunner FFB-G Joystick) — default 75%”. A versão 1.1.1 tinha dado o padrão de 75% a todas as bases Brunner.
• As demais bases Brunner começam em 35%. A CLS-E, a CLS-P, um pedal de leme e qualquer outra base Brunner começam em 35%, como qualquer dispositivo em que os testes não foram validados. Como em todo dispositivo, você mesmo pode aumentar a intensidade até o limite de 75%.
• Uma base cujo tipo não pode ser lido começa em 35%. Enquanto o Simux, o CLS2Sim, o Brunner USB Config Tool ou o FFB-Bridge estiver ocupando o canal de configuração, o FFB-Probe não consegue ler o tipo de base. A lista de verificação então pede que você feche o programa e clique em “Re-scan”.

Agora você pode escolher a intensidade com que os testes acionam seu dispositivo, nunca acima de um limite rígido, e confirma que vai operá-lo com segurança antes de um teste começar.

Intensidade do teste

• Um controle deslizante de intensidade na lista de verificação. Antes de um teste, você pode definir a intensidade de 0% a 75% em passos de 5%. O valor, o padrão do seu dispositivo e o máximo de 75% aparecem ao lado do controle deslizante, e o FFB-Probe lembra a última intensidade que você escolheu para cada dispositivo.
• Padrões por dispositivo. Os joysticks em que os testes foram validados começam em 75%: o SideWinder Force Feedback 2, os adaptadores USB para SideWinder FFB Pro (03EB:2056, PicoWinder CAFE:4004), o Logitech G940, o Force 3D Pro e o WingMan Force 3D, além de todas as bases Brunner. Todos os outros dispositivos, incluindo as bases de voo MOZA e hardware que o FFB-Probe ainda não conhece, começam em 35%.
• 75% é um limite rígido. Nada que o FFB-Probe reproduz passa de 75% da escala total, em qualquer dispositivo e em qualquer teste, incluindo a opção de linha de comando --magnitude e os modos de diagnóstico. Efeitos reproduzidos ao mesmo tempo dividem a intensidade que você escolheu, então juntos nunca a ultrapassam; o teste de saturação agora a divide entre suas três forças, 25% cada a 75%.
• As bases Brunner não ficam mais limitadas a 35%. Com os ganhos DirectX elevados durante o teste, elas agora começam em 75%, como o SideWinder FFB2. Com 35%, os testes ficavam fracos demais para avaliar.
• As bases de voo MOZA podem ter a intensidade aumentada. Elas continuam começando em 35%, o limite do FFB-Bridge para esse hardware, mas agora você mesmo pode aumentar a intensidade. O antigo teto fixo de 35% foi substituído pelo padrão e pelo limite de 75%.

Confirmação de segurança

• Um aviso de segurança antes de cada teste. A lista de verificação sempre explica que dispositivos de force feedback podem se mover de repente e com força real: mantenha uma mão apoiada levemente na empunhadura, mantenha dedos, cabos e objetos afastados e pare com Esc ou “Stop” a qualquer momento. “Arm probe” fica desativado até você marcar “I understand and accept responsibility”.
• Um aviso extra acima do padrão. Se você aumentar a intensidade acima do padrão do seu dispositivo, o aviso acrescenta um alerta de que bases direct drive potentes podem bater com força nos batentes.

Relatórios

• A intensidade é registrada. Cada relatório registra a intensidade do teste e se você a alterou. O relatório HTML mostra “Test strength: 75% (default)” ou “Test strength: 50% (chosen by tester)”, e os dados compartilhados trazem um novo objeto run com strength_pct e strength_source. O formato do relatório continua sendo schema: 1.
• O teste de dois eixos tem um único nome. Agora ele é informado como “Two-axis diagonal — diagonal” em vez de “Two-axis diagonal — diagonal (X=75%, Y=75%)”, para que uma intensidade ajustável não o divida em uma entrada separada para cada intensidade. O site junta o nome antigo ao novo.
• As notas continuam privadas. As notas que você digita continuam privadas e nunca aparecem na página pública do dispositivo.

Linha de comando

• --magnitude define a intensidade do teste. Valores fora de 0..75 são limitados ao intervalo em vez de recusados. Sem essa opção, é usado o padrão do dispositivo (75% ou 35%); as versões anteriores usavam 75% no Windows e 50% no Linux, ou 60% quando iniciadas pelo aplicativo. O console e o log de depuração informam a intensidade usada e se ela era o padrão.

Uma versão de robustez: um teste concluído não se perde mais na etapa “Share”, os resultados que chegam ao banco de dados público estão mais precisos e as bases de voo Brunner e MOZA agora funcionam de imediato.

Bases Brunner

• O modo CLS2Sim é detectado. As bases Brunner saem de fábrica no modo CLS2Sim, que não tem interface de force feedback, por isso as versões anteriores não encontravam nenhum dispositivo. Quando nenhum dispositivo de force feedback é encontrado, o FFB-Probe agora procura uma base Brunner e oferece “Switch to DirectX mode”; nada é alterado sem esse clique.
• A volta ao modo original é automática. “Switch back when finished” vem ativado por padrão: a base volta ao modo CLS2Sim depois do teste, quando você fecha o FFB-Probe ou na próxima inicialização após um fechamento inesperado. Só a configuração de modo USB é gravada e, se alguma etapa falhar, a base volta a ficar como estava.
• Efeitos com força total. A base multiplica cada efeito por ganhos que ela mesma armazena (50% de fábrica), então os efeitos chegavam ao motor com cerca de um quarto da força. Nos testes ao vivo, o FFB-Probe ajusta FX master e os ganhos de efeito para 100%, restaura seus valores depois e registra no relatório os ganhos que estavam salvos.
• Programas que ocupam a base são identificados. Se o Simux, o CLS2Sim, o Brunner USB Config Tool ou o FFB-Bridge estiver ocupando a base, o FFB-Probe informa qual é e explica como fechá-lo. No Linux, se o acesso à interface de configuração da base for negado, o FFB-Probe mostra a linha de regra udev a ser adicionada.
• Direções rotacionadas são registradas como medidas. A rotação de 90° nas direções que você pode sentir no modo DirectX vem da forma como o modo DirectX da Brunner mapeia os eixos; o FFB-Probe a registra exatamente como foi medida.

Bases de voo MOZA

• A prontidão da base é verificada antes do teste. O FFB-Probe lê, sem alterar nada, se uma MOZA AB9, AY210, AB6 ou AY90 vai realmente reproduzir efeitos de force feedback. Uma base no modo Telemetry do MOZA Cockpit, ou com force feedback desativado, saída de torque inibida ou ganho do jogo em 0, não se move; as versões anteriores registravam isso como “não fez nada”, e agora os relatórios dessa base informam que ela não estava pronta.
• Preparação opcional da base. “Prepare base for testing” coloca a base no modo DirectInput e libera as travas de saída de força depois de salvar suas configurações, e “Restore my MOZA settings when finished” (ativado por padrão) as restaura no final. Limites de curso, calibração e Force Sensing nunca são alterados.
• Um limite de força seguro. As bases de voo MOZA e as bases Brunner executam os testes de efeitos com no máximo 35% de força, o limite do FFB-Bridge para esse hardware, para que um joystick solto não seja levado até os batentes.

Outros programas usando seu dispositivo

• Programas em conflito são sinalizados. A tela de boas-vindas avisa quando há um programa em execução que pode tomar o seu dispositivo: FFB-Bridge, MOZA Cockpit / Pit House, ferramentas da Brunner, Logitech G HUB ou um simulador de voo.
• Erros claros de acesso exclusivo. Quando outro programa mantém o dispositivo em uso exclusivo, o FFB-Probe informa qual é, em vez de falhar com um erro genérico; no Linux, os processos que ocupam o dispositivo são nomeados. Esses nomes de programas são mostrados só para você e nunca entram no relatório compartilhado.

O compartilhamento nunca falha em um teste válido

• Chega de testes perdidos. Antes, uma nota longa ou um chip a mais bastava para o site rejeitar o relatório inteiro. Agora cada campo é mantido dentro dos limites do site antes do envio: selecionar todos os chips funciona, notas muito longas são encurtadas e nomes de dispositivo provisórios como “test” passam a ser Unknown force-feedback device vvvv:pppp.
• Remoção de caminhos mais completa. Caminhos de arquivo são removidos das mensagens de erro de forma mais completa, incluindo caminhos do Windows com espaços no nome de usuário.
• Código de suporte e link do dispositivo após compartilhar. Ambos aparecem no aplicativo e no botão “Share” do relatório HTML.
• Mesmo formato, mesma privacidade. O formato do relatório não mudou (schema: 1), e as notas que você digita continuam privadas e nunca aparecem na página pública do dispositivo.

Resultados mais precisos

• Medição de movimento com sinal no Windows. O FFB-Probe agora mede no Windows quanto e em que direção o stick se move durante cada efeito, como já fazia no Linux. As leituras têm sinal, por exemplo X peak +25.1%, e assim mostram a direção.
• Os efeitos param na hora certa. Cada efeito para assim que termina sua janela de reprodução, e não quando você responde. Alguns firmwares, como o da Brunner, mantinham uma força de 5 segundos por cerca de um segundo a mais.
• A autocentralização não atrapalha mais. A mola de autocentralização do próprio dispositivo é desligada durante os testes ao vivo e restaurada depois, então ela não combate nem mascara mais o efeito testado. Nas bases Brunner, ela bloqueava todos os efeitos.
• Mais respostas chegam ao relatório. As respostas de rampa agora são incluídas em vez de descartadas, e os resultados de polaridade, dois eixos e saturação aparecem nos diagnósticos públicos.
• A classe do dispositivo é registrada. Os relatórios registram se o dispositivo é um joystick, um manche de voo, um volante ou um gamepad, para que o banco de dados público consiga separar o hardware de voo dos volantes.
• Parâmetros de efeito corretos. Os testes de autocentralização usam a propriedade de autocentralização (as versões anteriores usavam o id de propriedade errado), e mola, amortecedor, inércia e atrito seguem a convenção de coordenadas que o DirectInput espera. Dispositivos desconhecidos voltam a informar o nome real do driver no Windows.

O aplicativo

• A leitura ao vivo acompanha o dispositivo testado. Antes ela mostrava o primeiro controle de jogo listado pelo Windows, então em um setup com mais de um controle ela não se mexia.
• Stop funciona em qualquer momento. Stop funciona em qualquer ponto de um teste, Esc interrompe um teste, e fechar a janela durante um teste para os efeitos e libera o dispositivo primeiro. Só o dispositivo selecionado é testado, e o mecanismo de teste é encerrado se o aplicativo for fechado.
• Mais fácil de usar. É possível pular respostas, redimensionar a janela, e o texto ficou mais fácil de ler.
• Ofertas de atualização em hora melhor. Atualizações nunca são oferecidas durante um teste em andamento, e versões beta não são oferecidas a quem usa a versão estável.

Linux

• Repetir um teste funciona. “Run test again” agora reproduz o efeito de novo.
• A autocentralização do kernel é controlada a cada efeito. Ela é desligada enquanto cada efeito é reproduzido e restaurada entre os efeitos, e nunca é alterada no Logitech G940, cujo driver ignora essa configuração.
• Menos arquivos por teste. Testes normais gravam apenas o relatório HTML e o JSON de compartilhamento; os arquivos de suporte legados só são gravados quando FFB_PROBE_KEEP_LEGACY=1 está definido.

Nomes de dispositivos

• Nomes novos e corrigidos. MOZA 346E:1002 agora é identificado como MOZA AB6. Adicionados: MOZA AY90 (346E:1003), Brunner FFB-G / FFB-H, o adaptador PicoWinder para SideWinder FFB Pro (CAFE:4004) e Adapt-FFB-Joy (03EB:204E).

Uma correção do compartilhamento de relatórios em distribuições Linux que se descrevem com um nome amigável da distribuição em vez de uma string Linux no estilo kernel.

Compartilhamento de relatórios no Linux

• Um único token genérico de os.family. O os.family da carga de envio agora é sempre um entre Windows, Linux, macOS ou Unknown. No .NET 8 e posteriores, o Linux informa o nome amigável da distribuição — por exemplo, Fedora Linux 42 (Workstation Edition) — que as compilações anteriores repassavam literalmente, e o site rejeita valores com mais de 32 caracteres com os_family_invalid.
• Os nomes amigáveis são resolvidos pela plataforma em execução. Nomes de distribuição que nunca contêm a palavra Linux, como o do Ubuntu, agora são resolvidos pela plataforma em que a sonda está sendo executada em vez da descrição do sistema operacional, de modo que não fragmentam mais os instantâneos de capacidade por sistema operacional do banco de dados público.
• As instalações existentes continuam a compartilhar. O site também normaliza valores legados na recepção, então relatórios de compilações mais antigas são compartilhados com sucesso sem atualizar primeiro.

A atualização automática chega em Windows e Linux, dando continuidade ao trabalho de movimento medido e identificação de hardware publicado no mesmo dia.

Atualizações automáticas

• Uma verificação de inicialização privada. A GUI lê um pequeno manifesto de versão estável na inicialização. Ele não envia ID de instalação, consulta de versão atual, informações do dispositivo ou resultados de investigação; respostas off-line e malformadas permanecem em silêncio.
• Windows pode concluir a atualização. Após consentimento explícito, FFB-Probe baixa o instalador, verifica seu comprimento exato e SHA-256, requer uma assinatura Windows válida de Rohsam Inc., executa o instalador por usuário silenciosamente e reinicia a nova compilação.
• As instalações de AppImage podem se atualizar. Um Linux AppImage em execução pode baixar e verificar o novo AppImage, invocar seu manipulador de instalação com escopo de usuário, atualizar a entrada e os ícones da área de trabalho e iniciar a cópia instalada.
• Fallback seguro para outras instalações. Compilações de desenvolvimento, AppDirs extraídos, pacotes de distribuição e outras instalações não AppImage Linux nunca são sobrescritas. O prompt leva à página de download e a essas notas de versão, e cada usuário pode adiar ou pular uma versão.

Melhorias de hardware e Linux incluídas

• Movimento medido durante efeitos Linux. Os testes ao vivo agora amostram os eixos do dispositivo enquanto uma força é executada, registrando o deslocamento objetivo junto com a resposta do testador.
• MOZA AY210 orientação. O AY210 (346E:1001) possui um nome canônico e orientação pré-voo para as configurações do fornecedor que podem mascarar forças comandadas externamente.
• Nomes de hardware corretos e consistentes. MOZA 346E:1002 é identificado como a base AB6/AB9 compartilhada PID, e o SideWinder Force Feedback Pro adaptado em 03EB:2056 usa um nome de plataforma cruzada no aplicativo e no banco de dados público.
• Descoberta Linux mais robusta. A resolução do caminho do driver e do descritor HID são mais defensivas e o autocenter é gravado apenas quando o dispositivo anuncia esse recurso.

Nota de atualização

• Uma atualização manual para usuários existentes. As versões até 1.0.6 não contêm o atualizador, portanto devem instalar 1.0.7 manualmente uma vez. As versões posteriores a 1.0.7 podem ser instaladas de dentro do aplicativo.

Uma liberação de hardware e evidências Linux que foi substituída por 1.0.7 antes do avanço do canal de download do site.

Medição Linux

• A telemetria do eixo une respostas subjetivas. O trabalhador Linux registra o deslocamento medido enquanto os efeitos são reproduzidos, ajudando a distinguir um efeito de trabalho de uma resposta incorreta de 'não fez nada'.
• Configuração de dispositivo mais segura. Os caminhos de eventos de entrada e os descritores de relatório HID são resolvidos de forma mais confiável, enquanto FF_AUTOCENTER é tocado apenas no hardware que o expõe.

Identidade de hardware

• MOZA AY210 adicionado. O AY210 (346E:1001) recebe um nome canônico e pré-condições MOZA Cockpit antes do teste.
• MOZA AB6/AB9 PID corrigido. O identificador 346E:1002 compartilhado não implica mais apenas um dos dois modelos básicos compatíveis.
• Nome do SideWinder adaptado e normalizado. 03EB:2056 agora agrega sob um nome Windows/Linux. Esta foi uma correção de nomenclatura, não uma nova reivindicação de suporte de atuação.

Linux embalagem

• Instalação AppImage com escopo do usuário. O AppImage ganhou integração de desktop --install e --uninstall integrada para os aplicativos do usuário e diretórios XDG.

Uma correção de atuação Windows para firmware que inicia em seu próprio modo de mola e aceita comandos de sonda sem produzir força física.

Correções

• Um estado limpo do dispositivo antes dos efeitos ao vivo. Depois de adquirir o dispositivo e definir o ganho global, o trabalhador Windows envia um esforço de melhor esforço DirectInput STOPALL antes do início da sequência de teste ao vivo. Isso limpa as forças padrão de propriedade do firmware para que os efeitos FFB Probe carregados possam assumir o controle desde o primeiro teste.
• Nenhuma reinicialização destrutiva. A correção evita deliberadamente DISFFC_RESET, preservando a tabela de efeitos do dispositivo e reservando uma reinicialização completa para recuperação de falhas.

Quem se beneficia

• Firmware de mola padrão e DIY. A mudança visa dispositivos - incluindo Fino DIY Yokes derivados - que relatam chamadas Create e Play bem-sucedidas, mas permanecem retidos por uma mola de inicialização até que STOPALL seja emitido.

Uma versão de interface focada que mantém todas as ações necessárias acessíveis dentro da janela do assistente de tamanho fixo.

Layout da lista de verificação

• A nomenclatura de dispositivos desconhecidos não cobre mais os controles. Quando o cartão extra 'Nomeie este dispositivo' aparece, os cartões da lista de verificação rolam enquanto os controles Armar sonda, Voltar e progresso permanecem fixados e visíveis.

Layout de resposta de teste

• Longas notas privadas permanecem contidas. A área de resposta pode rolar e a caixa de notas multilinhas tem seu próprio limite de altura, portanto, Continuar e Executar teste novamente permanecem acessíveis independentemente da duração da nota ou dos chips selecionados.

Cobertura de regressão

• Os layouts de problemas são cobertos por capturas de tela. O recurso de captura de tela agora renderiza uma lista de verificação de dispositivos desconhecidos e uma longa resposta com várias linhas, protegendo os layouts que regrediram.

Um hotfix de metadados e identificação de dispositivos que mantém limpas as linhas de hardware público e torna explícitos os dispositivos desconhecidos antes do compartilhamento.

Metadados de envio consistentes

• Versões de FFB Probe usam SemVer estável. Os uploads agora enviam valores como 1.0.1 sem um sufixo de revisão de origem do SDK, para que o banco de dados público não divida uma versão em várias strings de compilação.

Nomes de dispositivos

• Um catálogo VID:PID compartilhado de 138 entradas. Windows, Linux, a GUI e o site ganharam uma tabela de nomes de force-feedback muito mais ampla, incluindo os identificadores MOZA AB9 e Logitech G940.
• O hardware desconhecido deve ser nomeado. A GUI faz uma pausa na lista de verificação para um nome de fabricante/modelo, a CLI interativa executa o prompt e a automação pode passar --device-name. Os espaços reservados genéricos são rejeitados antes do upload.
• Nomes de plataformas úteis permanecem disponíveis. As execuções não interativas retêm um nome de sistema operacional higienizado significativo quando existe, caso contrário, elas usam um dispositivo de feedback de força desconhecido explícito VID:PID fallback.

Coordenação do site

• Os nomes de aplicativos e bancos de dados agora correspondem. O O site recebeu o mesmo catálogo normalizado, portanto, os envios antigos e novos são agregados sob nomes estáveis.

A primeira versão pública estável do diagnóstico FFB-Probe independente para Windows e Linux.

Teste de hardware guiado

• Um assistente completo focado em testadores. FFB-Probe detecta um dispositivo de feedback de força conectado, apresenta uma lista de verificação de segurança, reproduz efeitos curtos ao vivo e registra o que o testador sentiu após cada um.
• Ampla cobertura de efeitos. O conjunto de testes verifica o comportamento constante, condicional, periódico, de mola, amortecedor, inércia e rampa, com diagramas e progresso com reconhecimento de seção.
• Windows e Linux desde o primeiro dia. O trabalhador Windows DirectInput e o trabalhador Linux evdev são enviados por trás da mesma interface Avalonia de plataforma cruzada.

Relatórios e compartilhamento

• Saída legível por humanos e legível por máquina. Cada execução grava um relatório HTML e a carga útil de envio JSON exata localmente, para que os testadores possam inspecionar as evidências antes de decidir se devem compartilhá-las.
• O compartilhamento é opcional. Nada é carregado automaticamente. A tela de resultados e o relatório HTML salvo expõem a ação de compartilhamento somente depois que o testador pode revisar os campos coletados.
• Fatos públicos, notas privadas. Recursos de hardware, respostas de efeitos e diagnósticos de vocabulário fechado podem dar suporte ao banco de dados público, enquanto as notas de texto livre permanecem privadas para triagem de suporte.

Pacotes de lançamento

• Versões independentes. A versão pública inclui um instalador Windows por usuário e um Linux x86-64 AppImage com o tempo de execução .NET incluído.
• Distribuição Windows assinada. Binários Windows estáveis e o instalador são produzidos por meio do fluxo de trabalho de lançamento sob a identidade do editor Rohsam.