Ensembles de support

Un ensemble de support est un seul fichier ZIP qui empaquette l'état du pont au moment où quelque chose a mal tourné. C'est le seul artefact que nous demanderons lors du tri d'un ticket. Cette page décrit exactement ce qu'il contient, afin que vous sachiez ce que vous envoyez.

Comment en exporter un

1. Ouvrez FFB-Bridge et accédez au Support page (barre latérale), puis la Diagnostics onglet.
2. Cliquez Ensemble de support (en haut à droite de la carte Diagnostics).
3. Après un court délai, une bannière affiche le nom et la taille du fichier, avec un lien vers un formulaire de commentaires et, le cas échéant, Révéler le fichier.
4. Ouvrez le formulaire de commentaires et joignez le ZIP si vous souhaitez l'envoyer.

Que contient l'ensemble

Un ensemble de support est un simple ZIP. Les noms de fichiers ci-dessous constituent la liste autorisée complète : l'ensemble jamais contenir quoi que ce soit en dehors de cet ensemble.

sysinfo.txt

Métadonnées du système. Texte brut, lignes clé:valeur. Champs :

• os-name — « Windows », « Linux » ou « macOS ».
• os-version — version du noyau, chaîne de build Windows ou version macOS.
• distro — sous 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 - version d'exécution du .NET fourni.
• platform — clé explicite pour la branche Linux-vs-Windows.
• locale — paramètres régionaux de l'utilisateur actuel.
• bridge-version, build-hash - version bridge et git SHA au moment de la construction.

session.log

Journal complet des événements pour la session en cours. Même contenu que la bande de journal de l'onglet Diagnostics, mais incluant tout depuis le lancement, pas seulement ce qui est visible. UTF-8.

dernier-crash.log

Si le lancement précédent s'est écrasé, le journal des plantages atterrit ici. Trace de pile, vidages de threads, les dernières lignes de journal avant le crash. Absent si la session n'a pas planté.

previous-session.log

Le journal pivoté de l'exécution précédant l'exécution actuelle, s'il est présent. Après un rapport de crash et redémarrage, c'est souvent le fichier qui montre ce qui s'est passé avant le redémarrage.

doctor.json

Le scan des Vérifications de santé le plus récent depuis la page Support, sous forme lisible par machine. Chaque ligne porte le nom de la vérification, le statut (réussite / info / avertissement / échec / prêt / vérification en cours / s.o.) et la chaîne de détail brute. Cela nous permet de voir l'état de vos vérifications de santé sans que vous ayez à coller de captures d'écran. Le fichier est nommé doctor.json pour des raisons historiques, la page Support s'appelait autrefois Doctor.

tunables.json

Les valeurs du profil de réglage actif au moment de l'exportation. Même schéma qu'un profil enregistré. Utilisé pour reproduire la configuration exacte de la force que vous pilotiez.

hardware-settings.json

Paramètres de compatibilité matérielle au moment de l'exportation : mélange logiciel, Smooth steady forces, polarité des axes, permutation pitch/roll, préférence raw-HID, opt-in appareil non listé et indication si les bascules en direct différaient des paramètres enregistrés.

simconnect.txt

MSFS SimConnect.xml si la passerelle a pu en lire un, avec les adresses IP non-localhost masquées. Si aucun n'a été trouvé, ce fichier l'indique au lieu de deviner.

Platform extras

Windows bundles include hid-devices.txt pour les enregistrements Plug and Play correspondants. Les bundles Linux incluent usb.txt, evdev.txt, udev.txt, et dmesg.txt pour le contexte de la pile USB/entrée. Chaque bundle inclut aussi README.txt avec un résumé du contenu et une note de confidentialité.

Ce qui n'est PAS dans l'ensemble

Le générateur de bundle de support utilise une liste autorisée stricte de noms de fichiers. Il n'inclura rien en dehors de cette liste, même si quelque chose correspondant est présent dans le même répertoire. En particulier :

• Aucun mot de passe ou identifiant enregistré. Le pont n'en stocke aucun.
• Aucun fichier de profil autre que celui qui est actif.
• Aucun journal système, journal ou quoi que ce soit en dehors des répertoires de données du pont.
• Aucune capture de paquet réseau.
• Pas de jetons cloud (le pont n'en utilise pas).

Traitement côté serveur

Lorsque vous joignez un ensemble de support à un rapport de rétroaction, le service d'accueil du site l'analyse pour extraire des données indexables utiles dans notre base de données :

• Informations système dans une ligne récapitulative pour le regroupement (« combien de rapports de cette distribution ? »).
• Lignes d'avertissement et d'erreur du journal, avec des signatures d'erreur stables, afin que nous puissions voir en un coup d'œil combien de personnes ont rencontré le même bug.
• Résultats du bilan de santé pour une analyse de ce qui échoue dans la base d'utilisateurs.
• Le texte du fichier textuel de chaque entrée sur la liste verte, stocké afin que nous puissions relire le contexte lors du tri.

L'ensemble brut lui-même est conservé pendant une courte fenêtre (30 jours par défaut) afin que nous puissions le réanalyser si notre logique d'extraction s'améliore. Après cela, les données analysées sont conservées ; le blob brut est supprimé.

Limites

En pratique, un ensemble normal fait moins d'un mégaoctet. Ces limites sont là pour exclure les téléversements hostiles, et non pour exclure les rapports réels.

Envoi sans le formulaire de commentaires

Si vous préférez envoyer l'ensemble directement par courriel, écrivez à feedback·ffb-bridge.com (remplacez le · par un @) et joignez le ZIP. L'analyseur côté serveur ne fonctionne pas pour le courriel, donc le tri est plus lent, mais le bundle est tout aussi utilisable.