Notes de version FFB Probe

Une correction de l’intensité de test par défaut : seul le Brunner FFB-G Joystick démarre à 75 %, et toutes les autres bases Brunner démarrent à 35 %.

Intensité par défaut des bases Brunner

• Seul le Brunner FFB-G Joystick démarre à 75 %. FFB-Probe le reconnaît au type de base qu’il signale par le canal de configuration de Brunner, peu importe la poignée installée, et la liste de contrôle affiche « Validated base (Brunner FFB-G Joystick) — default 75% ». La version 1.1.1 avait attribué la valeur par défaut de 75 % à toutes les bases Brunner.
• Les autres bases Brunner démarrent à 35 %. La CLS-E, la CLS-P, un palonnier et toute autre base Brunner démarrent à 35 %, comme tout périphérique sur lequel les tests n’ont pas été validés. Comme sur tout périphérique, vous pouvez augmenter vous-même l’intensité jusqu’à la limite de 75 %.
• Une base dont le type ne peut pas être lu démarre à 35 %. Tant que Simux, CLS2Sim, le Brunner USB Config Tool ou FFB-Bridge occupe le canal de configuration, FFB-Probe ne peut pas lire le type de base. La liste de contrôle vous demande alors de fermer le programme et de cliquer sur « Re-scan ».

Vous pouvez désormais choisir avec quelle force les tests sollicitent votre périphérique, sans jamais dépasser une limite absolue, et vous confirmez que vous l’utiliserez de façon sécuritaire avant le début d’un test.

Intensité du test

• Un curseur d’intensité dans la liste de contrôle. Avant un test, vous pouvez régler l’intensité du test de 0 % à 75 % par paliers de 5 %. La valeur, la valeur par défaut de votre périphérique et le maximum de 75 % sont affichés à côté du curseur, et FFB-Probe mémorise la dernière intensité choisie pour chaque périphérique.
• Des valeurs par défaut selon le périphérique. Les manches sur lesquels les tests ont été validés démarrent à 75 % : le SideWinder Force Feedback 2, les adaptateurs USB pour SideWinder FFB Pro (03EB:2056, PicoWinder CAFE:4004), les Logitech G940, Force 3D Pro et WingMan Force 3D, ainsi que toutes les bases Brunner. Tous les autres périphériques, y compris les bases de vol MOZA et le matériel que FFB-Probe ne connaît pas encore, démarrent à 35 %.
• 75 % est une limite absolue. Rien de ce que joue FFB-Probe ne dépasse 75 % de la pleine échelle, sur aucun périphérique et dans aucun test, y compris avec l’option de ligne de commande --magnitude et les modes de diagnostic. Les effets joués simultanément se partagent l’intensité choisie, de sorte qu’ensemble ils ne la dépassent jamais ; le test de saturation la répartit désormais entre ses trois forces, soit 25 % chacune à 75 %.
• Les bases Brunner ne sont plus limitées à 35 %. Avec leurs gains DirectX augmentés pour le test, elles démarrent désormais à 75 %, comme le SideWinder FFB2. À 35 %, les tests étaient trop faibles pour être évalués.
• L’intensité des bases de vol MOZA peut être augmentée. Elles démarrent toujours à 35 %, le plafond de FFB-Bridge pour ce matériel, mais vous pouvez désormais augmenter l’intensité vous-même. L’ancien plafond fixe de 35 % est remplacé par la valeur par défaut et la limite de 75 %.

Confirmation de sécurité

• Un avis de sécurité avant chaque test. La liste de contrôle explique toujours que les périphériques à retour de force peuvent bouger brusquement et avec une force réelle : gardez une main posée légèrement sur la poignée, éloignez doigts, câbles et objets, et arrêtez à tout moment avec Échap ou Stop. « Arm probe » reste désactivé tant que vous n’avez pas coché « I understand and accept responsibility ».
• Un avertissement supplémentaire au-delà de la valeur par défaut. Si vous augmentez l’intensité au-delà de la valeur par défaut de votre périphérique, l’avis ajoute un avertissement : les bases puissantes à entraînement direct peuvent heurter violemment leurs butées.

Rapports

• L’intensité est enregistrée. Chaque rapport enregistre l’intensité du test et indique si vous l’avez modifiée. Le rapport HTML affiche « Test strength: 75% (default) » ou « Test strength: 50% (chosen by tester) », et les données partagées contiennent un nouvel objet run avec strength_pct et strength_source. Le format du rapport reste schema: 1.
• Le test sur deux axes n’a plus qu’un nom. Il est désormais signalé sous le nom « Two-axis diagonal — diagonal » au lieu de « Two-axis diagonal — diagonal (X=75%, Y=75%) », afin qu’une intensité réglable ne le scinde pas en entrées distinctes pour chaque intensité. Le site fusionne l’ancien nom avec le nouveau.
• Les notes restent privées. Vos notes saisies restent privées et n’apparaissent jamais sur la page publique du périphérique.

Ligne de commande

• --magnitude règle l’intensité du test. Les valeurs hors de 0..75 sont ramenées dans cette plage au lieu d’être refusées. Sans cette option, la valeur par défaut du périphérique (75 % ou 35 %) est utilisée ; les versions précédentes utilisaient 75 % sous Windows et 50 % sous Linux, ou 60 % quand elles étaient lancées par l’app. La console et le journal de débogage indiquent l’intensité utilisée et s’il s’agissait de la valeur par défaut.

Une version de consolidation : un test terminé n’est plus perdu à l’étape « Share », les résultats qui arrivent dans la base de données publique sont plus exacts, et les bases de vol Brunner et MOZA fonctionnent désormais dès le départ.

Bases Brunner

• Le mode CLS2Sim est détecté. Les bases Brunner sont livrées en mode CLS2Sim, qui n’a pas d’interface de retour de force ; les versions précédentes ne trouvaient donc aucun périphérique. Quand aucun périphérique à retour de force n’est trouvé, FFB-Probe recherche désormais une base Brunner et propose « Switch to DirectX mode » ; rien n’est basculé sans ce clic.
• Le retour au mode d’origine est automatique. « Switch back when finished » est activé par défaut : la base revient en mode CLS2Sim après le test, à la fermeture de FFB-Probe, ou au démarrage suivant après une fermeture inattendue. Seul le réglage du mode USB est écrit, et si une étape échoue, la base est remise dans son état d’origine.
• Des effets à pleine puissance. La base applique à chaque effet des gains qu’elle stocke elle-même (50 % en sortie d’usine), si bien que les effets arrivaient au moteur à environ un quart de leur force. Pour les tests en direct, FFB-Probe règle FX master et les gains d’effet à 100 %, restaure ensuite vos valeurs et indique vos gains enregistrés dans le rapport.
• Les programmes qui occupent la base sont nommés. Si Simux, CLS2Sim, le Brunner USB Config Tool ou FFB-Bridge occupe la base, FFB-Probe le nomme et vous explique comment le fermer. Sous Linux, si l’accès à l’interface de configuration de la base est refusé, FFB-Probe affiche la ligne de règle udev à ajouter.
• Les directions pivotées sont enregistrées telles que mesurées. La rotation de 90° des directions que vous pouvez ressentir en mode DirectX vient de la façon dont le mode DirectX de Brunner associe ses axes ; FFB-Probe l’enregistre telle qu’elle est mesurée.

Bases de vol MOZA

• L’état de la base est vérifié avant chaque test. FFB-Probe lit, sans rien modifier, si une MOZA AB9, AY210, AB6 ou AY90 jouera réellement les effets de retour de force. Une base en mode Telemetry de MOZA Cockpit, ou dont le retour de force est désactivé, la sortie de couple bloquée ou le gain de jeu à 0, ne bouge pas ; les versions précédentes l’enregistraient comme « n’a rien fait », et les rapports d’une telle base indiquent désormais qu’elle n’était pas prête.
• Préparation facultative de la base. « Prepare base for testing » passe la base en mode DirectInput et ouvre ses verrous de sortie de force après avoir sauvegardé vos réglages, et « Restore my MOZA settings when finished » (activé par défaut) les rétablit ensuite. Les limites de course, l’étalonnage et Force Sensing ne sont jamais modifiés.
• Un plafond de force sûr. Les bases de vol MOZA et les bases Brunner exécutent les tests d’effets à 35 % de force au maximum, le plafond de FFB-Bridge pour ce matériel, afin qu’un manche non tenu ne soit pas envoyé contre ses butées.

Autres programmes qui utilisent votre périphérique

• Les programmes en conflit sont signalés. L’écran d’accueil vous avertit quand un programme susceptible d’accaparer votre périphérique est en cours d’exécution : FFB-Bridge, MOZA Cockpit / Pit House, les outils Brunner, Logitech G HUB ou un simulateur de vol.
• Des erreurs d’accès exclusif claires. Quand un autre programme détient le périphérique en exclusivité, FFB-Probe indique lequel au lieu d’échouer avec une erreur générique ; sous Linux, les processus qui détiennent le périphérique sont nommés. Ces noms de programmes ne sont affichés qu’à vous et ne sont jamais ajoutés au rapport partagé.

Le partage n’échoue jamais pour un test valide

• Fini les tests perdus. Une note trop longue ou une puce de trop suffisait auparavant pour que le site rejette tout le rapport. Chaque champ est désormais ramené aux limites du site avant l’envoi : sélectionner toutes les puces fonctionne, les notes très longues sont raccourcies, et les noms de périphérique fictifs comme « test » deviennent Unknown force-feedback device vvvv:pppp.
• Nettoyage des chemins plus rigoureux. Les chemins de fichiers sont retirés plus complètement des messages d’erreur, y compris les chemins Windows avec des espaces dans le nom d’utilisateur.
• Code d’assistance et lien vers le périphérique après le partage. Les deux s’affichent dans l’app et sur le bouton « Share » du rapport HTML.
• Même format, même confidentialité. Le format du rapport est inchangé (schema: 1), et vos notes saisies restent privées et n’apparaissent jamais sur la page publique du périphérique.

Des résultats plus exacts

• Mesure signée du mouvement sous Windows. FFB-Probe mesure désormais sous Windows de combien et dans quel sens le manche bouge pendant chaque effet, comme il le faisait déjà sous Linux. Les mesures sont signées, par exemple X peak +25.1%, et indiquent donc la direction.
• Les effets s’arrêtent à temps. Chaque effet s’arrête dès la fin de sa fenêtre de lecture, et non quand vous répondez. Certains micrologiciels, comme celui de Brunner, prolongeaient une force de 5 secondes d’environ une seconde.
• Le centrage automatique ne gêne plus. Le ressort de centrage automatique propre au périphérique est désactivé pendant les tests en direct puis rétabli, il ne contrarie donc plus et ne masque plus l’effet testé. Sur les bases Brunner, il bloquait tous les effets.
• Davantage de réponses dans le rapport. Les réponses de rampe sont désormais incluses au lieu d’être ignorées, et les résultats de polarité, de test sur deux axes et de saturation apparaissent dans les diagnostics publics.
• La classe de périphérique est enregistrée. Les rapports indiquent si le périphérique est un joystick, un manche de vol, un volant ou une manette, afin que la base de données publique puisse distinguer le matériel de vol des volants.
• Des paramètres d’effet corrects. Les tests de centrage automatique sollicitent la propriété de centrage automatique (les versions précédentes utilisaient un mauvais identifiant de propriété), et ressort, amortisseur, inertie et friction suivent la convention de coordonnées attendue par DirectInput. Les périphériques inconnus indiquent de nouveau leur vrai nom de pilote sous Windows.

L’app

• L’affichage en direct suit le périphérique testé. Il affichait auparavant la première manette de jeu listée par Windows ; sur une installation avec plusieurs manettes, il restait donc immobile.
• Stop fonctionne partout. Stop fonctionne à tout moment d’un test, Échap arrête un test, et fermer la fenêtre pendant un test arrête d’abord les effets et libère le périphérique. Seul le périphérique sélectionné est testé, et le moteur de sonde s’arrête si l’app se ferme.
• Plus facile à utiliser. Les réponses peuvent être ignorées, la fenêtre peut être redimensionnée et le texte est plus lisible.
• Des mises à jour proposées au bon moment. Aucune mise à jour n’est proposée pendant un test, et les versions bêta ne sont pas proposées aux utilisateurs de la version stable.

Linux

• Relancer un test fonctionne. « Run test again » rejoue maintenant l’effet.
• Le centrage automatique du noyau est géré effet par effet. Il est désactivé pendant la lecture de chaque effet et rétabli entre les effets, et il n’est jamais modifié sur le Logitech G940, dont le pilote ignore ce réglage.
• Moins de fichiers par test. Les tests normaux n’écrivent que le rapport HTML et le JSON de partage ; les anciens fichiers d’assistance ne sont écrits que si FFB_PROBE_KEEP_LEGACY=1 est défini.

Noms des périphériques

• Noms ajoutés et corrigés. MOZA 346E:1002 est désormais identifié comme MOZA AB6. Ajouts : MOZA AY90 (346E:1003), Brunner FFB-G / FFB-H, l’adaptateur PicoWinder pour SideWinder FFB Pro (CAFE:4004) et Adapt-FFB-Joy (03EB:204E).

Une correction du partage de rapports pour les distributions Linux qui se décrivent par un nom convivial de distribution plutôt que par une chaîne Linux de type noyau.

Partage de rapports depuis Linux

• Un seul jeton os.family grossier. Le champ os.family de la charge utile de soumission est désormais toujours l'un de Windows, Linux, macOS ou Unknown. À partir de .NET 8, Linux indique le nom convivial de la distribution — par exemple Fedora Linux 42 (Workstation Edition) — que les versions précédentes transmettaient tel quel ; le site rejette les valeurs de plus de 32 caractères avec os_family_invalid.
• Les noms conviviaux sont résolus via la plateforme en cours d'exécution. Les noms de distribution qui ne contiennent jamais le mot Linux, comme celui d'Ubuntu, sont désormais résolus via la plateforme sur laquelle la sonde s'exécute plutôt que via la description du système d'exploitation ; ils ne fragmentent donc plus les instantanés de capacités par système d'exploitation de la base de données publique.
• Les installations existantes continuent de partager. Le site normalise également les valeurs héritées à la réception, de sorte que les rapports des versions plus anciennes sont partagés avec succès sans mise à jour préalable.

La mise à jour automatique arrive sur Windows et Linux, poursuivant les travaux de mesure de mouvement et d'identification matérielle publiés plus tôt le même jour.

Mises à jour automatiques

• Un contrôle de démarrage privé. L'interface graphique lit un petit manifeste de version stable au démarrage. Il n'envoie aucun ID d'installation, requête de version actuelle, informations sur le périphérique ou résultats de sonde ; les réponses hors ligne et mal formées restent silencieuses.
• Windows peut terminer la mise à niveau. Après consentement explicite, FFB-Probe télécharge le programme d'installation, vérifie sa longueur exacte et SHA-256, requiert une signature Windows valide de Rohsam Inc., exécute le programme d'installation par utilisateur en silence et redémarre la nouvelle version.
• Les installations AppImage peuvent se mettre à jour elles-mêmes. Un Linux AppImage en cours d'exécution peut télécharger et vérifier le nouveau AppImage, appeler son gestionnaire d'installation à l'échelle de l'utilisateur, actualiser l'entrée et les icônes du bureau et lancer la copie installée.
• Solution de repli sûre pour d’autres installations. Les versions de développement, les AppDirs extraits, les packages de distribution et les autres installations non AppImage Linux ne sont jamais écrasés. L'invite renvoie à la page de téléchargement et à ces notes de version, et chaque utilisateur peut différer ou ignorer une version.

Améliorations matérielles et Linux incluses

• Mouvement mesuré pendant les effets Linux. Les tests en direct échantillonnent désormais les axes de l'appareil pendant qu'une force joue, enregistrant le déplacement de l'objectif parallèlement à la réponse du testeur.
• MOZA AY210 conseils. Le AY210 (346E:1001) a un nom canonique et des conseils avant le vol pour les paramètres du fournisseur qui peuvent masquer les forces commandées de l'extérieur.
• Noms de matériel corrects et cohérents. MOZA 346E:1002 est identifié comme la base AB6/AB9 partagée PID, et le SideWinder Force Feedback Pro adapté à 03EB:2056 utilise un nom multiplateforme dans l'application et la base de données publique.
• Découverte Linux plus robuste. Le chemin du pilote et la résolution du descripteur HID sont plus défensifs et le centre automatique n'est écrit que lorsque le périphérique annonce cette fonctionnalité.

Remarque sur la mise à niveau

• Une mise à jour manuelle pour les utilisateurs existants. Les versions jusqu'à 1.0.6 ne contiennent pas le programme de mise à jour, elles doivent donc installer 1.0.7 manuellement une fois. Les versions postérieures à 1.0.7 peuvent ensuite être installées depuis l'application.

Une version matérielle et Linux de preuves qui a été remplacée par 1.0.7 avant que le canal de téléchargement du site Web ne progresse.

Mesure Linux

• La télémétrie des axes rejoint les réponses subjectives. Le travailleur Linux enregistre le déplacement mesuré pendant que les effets jouent, aidant ainsi à distinguer un effet de travail d'une réponse incorrecte de « rien fait ».
• Configuration de l'appareil plus sûre. Les chemins d'événements d'entrée et les descripteurs de rapport HID sont résolus de manière plus fiable, tandis que FF_AUTOCENTER n'est touché que sur le matériel qui l'expose.

Identité matérielle

• MOZA AY210 ajouté. Le AY210 (346E:1001) reçoit un nom canonique et des conditions préalables MOZA Cockpit avant le test.
• MOZA AB6/AB9 PID corrigé. L'identifiant partagé 346E:1002 n'implique plus qu'un seul des deux modèles de base compatibles.
• Nom SideWinder adapté normalisé. 03EB:2056 se regroupe désormais sous un seul nom Windows/Linux. Il s'agissait d'une correction de nom, pas d'une nouvelle revendication de support d'actionnement.

Linux emballage

• Installation AppImage à l'échelle de l'utilisateur. Le AppImage a obtenu l'intégration intégrée des bureaux --install et --uninstall pour les applications de l'utilisateur et les répertoires XDG.

Un correctif d'actionnement Windows pour le micrologiciel qui démarre dans son propre mode ressort et accepte autrement les commandes de sonde sans produire de force physique.

Corrections

• Un état propre de l'appareil avant les effets en direct. Après avoir acquis l'appareil et défini le gain global, le travailleur Windows envoie un DirectInput STOPALL de son mieux avant le début de la séquence de test en direct. Cela efface les forces par défaut appartenant au micrologiciel afin que les effets FFB Probe téléchargés puissent prendre le contrôle dès le premier test.
• Pas de réinitialisation destructrice. Le correctif évite délibérément DISFFC_RESET, en préservant le tableau des effets du périphérique et en réservant une réinitialisation complète pour la récupération après incident.

À qui profite

• Ressort par défaut et firmware DIY. Le changement cible les appareils, y compris les jougs DIY dérivés de Fino, qui signalent des appels réussis Create et Play mais restent retenus par un ressort de démarrage jusqu'à ce que STOPALL soit émis.

Une version d'interface ciblée qui maintient toutes les actions requises accessibles dans la fenêtre de l'assistant de taille fixe.

Disposition de la liste de contrôle

• La dénomination des appareils inconnus ne couvre plus les commandes. Lorsque la carte supplémentaire « Nommer cet appareil » apparaît, les cartes de liste de contrôle défilent tandis que les commandes de sonde de bras, de retour et de progression restent épinglées et visibles.

Disposition des réponses au test

• Les longues notes privées restent contenues. La zone de réponse peut défiler et la zone de notes multilignes a son propre plafond de hauteur, de sorte que Continuer et Exécuter le test restent accessibles quelle que soit la longueur de la note ou les puces sélectionnées.

Couverture de régression

• Les présentations des problèmes sont couvertes par des captures d'écran. Le faisceau de capture d'écran affiche désormais à la fois une liste de contrôle des périphériques inconnus et une longue réponse sur plusieurs lignes, protégeant les mises en page qui ont régressé.

Un correctif de métadonnées et d’identification des appareils qui maintient les lignes de matériel public propres et rend explicites les appareils inconnus avant le partage.

Métadonnées de soumission cohérentes

• Les versions FFB Probe utilisent désormais SemVer stable. Les téléchargements envoient désormais des valeurs telles que 1.0.1 sans suffixe de révision source du SDK, de sorte que la base de données publique ne divise pas une version en plusieurs chaînes de construction.

Noms des appareils

• Un catalogue VID:PID partagé de 138 entrées. Windows, Linux, l'interface graphique et le site Web ont obtenu une table de noms de retour de force beaucoup plus large, comprenant les identifiants MOZA AB9 et Logitech G940.
• Le matériel inconnu doit être nommé. L'interface graphique s'arrête sur la liste de contrôle pour un nom de fabricant/modèle, la CLI interactive exécute une invite et l'automatisation peut transmettre --device-name. Les espaces réservés génériques sont rejetés avant le téléchargement.
• Les noms de plateformes utiles restent disponibles. Les exécutions non interactives conservent un nom de système d'exploitation nettoyé significatif lorsqu'il en existe un, sinon elles utilisent un périphérique de retour de force inconnu explicite VID:PID.

Coordination du site Internet

• Les noms d'application et de base de données sont désormais match. Le site Web a reçu le même catalogue normalisé, donc les anciennes et les nouvelles soumissions sont regroupées sous des noms stables.

La première version publique stable du diagnostic autonome FFB-Probe pour Windows et Linux.

Tests matériels guidés

• Un assistant complet axé sur les testeurs. FFB-Probe détecte un dispositif de retour de force connecté, présente une liste de contrôle de sécurité, joue de courts effets en direct et enregistre ce que le testeur a ressenti après chacun d'eux.
• Large couverture d’effet. La suite de tests vérifie le comportement constant, conditionnel, périodique, du ressort, de l'amortisseur, de l'inertie et de la rampe, avec des diagrammes et une progression en fonction des sections.
• Windows et Linux dès le premier jour. Le travailleur Windows DirectInput et le travailleur Linux evdev sont livrés derrière la même interface multiplateforme Avalonia.

Rapports et partage

• Sortie lisible par l’homme et par la machine. Chaque exécution écrit un rapport HTML et la charge utile exacte de soumission JSON localement, afin que les testeurs puissent inspecter les preuves avant de décider de les partager.
• Le partage est volontaire. Rien n'est téléchargé automatiquement. L'écran de résultats et le rapport HTML enregistré exposent l'action de partage uniquement une fois que le testeur peut examiner les champs collectés.
• Faits publics, notes privées. Les capacités matérielles, les réponses aux effets et les diagnostics à vocabulaire fermé peuvent prendre en charge la base de données publique, tandis que les notes en texte libre restent privées pour le tri de la prise en charge.

Paquets de version

• Sorties autonomes. La version publique comprend un programme d'installation Windows par utilisateur et un Linux x86-64 AppImage avec le runtime .NET fourni.
• Distribution Windows signée. Les binaires stables Windows et le programme d'installation sont produits via le workflow de publication sous l'identité de l'éditeur Rohsam.