Ondersteuningsbundels

Een ondersteuningsbundel is een enkele ZIP die de staat van de bridge weergeeft op het moment dat er iets misging. Het is het enige artefact waar we naar zullen vragen bij het beoordelen van een ticket. Op deze pagina wordt beschreven wat er precies in zit, zodat u weet wat u verzendt.

Hoe exporteer je er een?

1. Open FFB-Bridge en navigeer naar de Ondersteuning pagina (zijbalk) en vervolgens de Diagnostiek Tabblad .
2. Klik Supportbundel (rechtsboven op de diagnosekaart).
3. Na een korte vertraging toont een banner de bestandsnaam en -grootte, met een link naar het feedbackformulier en, indien beschikbaar, Bestand onthullen.
4. Open het feedbackformulier en voeg de ZIP toe als u deze wilt verzenden.

Wat zit er in de bundel

Een bundel is een gewone ZIP. De onderstaande bestandsnamen vormen de volledige toelatingslijst; de bundel ook nooit iets buiten deze set bevatten.

sysinfo.txt

Systeemmetadata. Platte tekst, sleutel:waarderegels. Velden:

• os-name — “Windows”, “Linux” of “macOS”.
• os-version — kernelversie, Windows-buildstring of macOS-versie.
• distro — op Linux, /etc/os-release PRETTY_NAME.
• cpu-model, cpu-cores – van /proc/cpuinfo of Win32_Processor.
• ram-total-mb – van /proc/meminfo of Win32_ComputerSystem.
• dotnet-version — runtime-versie van het gebundelde .NET.
• platform — expliciete sleutel voor de Linux-vs-Windows-tak.
• locale — huidige gebruikerslandinstelling.
• bridge-version, build-hash — bridge-versie en git SHA tijdens het bouwen.

sessie.log

Volledig gebeurtenislogboek voor de huidige sessie. Dezelfde inhoud als de logstrook van het tabblad Diagnostiek, maar inclusief alles vanaf de lancering, niet alleen wat zichtbaar is. UTF-8.

last-crash.log

Als de vorige start is gecrasht, komt het crashlog hier terecht. Stacktrace, threaddumps, de laatste paar logregels vóór de crash. Afwezig als de sessie niet is gecrasht.

previous-session.log

Het geroteerde log van de run vóór de huidige, indien aanwezig. Na een crash-en-herstartmelding is dit vaak het bestand dat laat zien wat er vóór de herstart gebeurde.

doctor.json

De meest recente Gezondheidscontroles-scan vanaf de ondersteuningspagina in machineleesbare vorm. Elke rij bevat de naam van de controle, de status (pass / info / warn / fail / ready / checking / n.v.t.) en de onbewerkte detailreeks. Hierdoor kunnen we de status van je gezondheidscontroles zien zonder dat je schermafbeeldingen hoeft te plakken. Het bestand heet doctor.json om historische redenen heette de ondersteuningspagina vroeger Doctor.

tunables.json

De waarden van het actieve tuning-profiel op het moment van exporteren. Hetzelfde schema als een opgeslagen profiel. Wordt gebruikt om de exacte krachtconfiguratie waarmee je vloog te reproduceren.

hardware-settings.json

Hardwarecompatibiliteitsinstellingen op het moment van export: softwareblending, Smooth steady forces, aspolariteit, pitch/roll-wissel, raw-HID-voorkeur, opt-in voor niet-vermelde apparaten en of live-schakelaars afweken van opgeslagen instellingen.

simconnect.txt

MSFS's SimConnect.xml als de bridge er een kon lezen, met niet-localhost-IP-adressen geredigeerd. Als er geen werd gevonden, zegt dit bestand dat in plaats van te raden.

Platform extras

Windows bundles include hid-devices.txt voor overeenkomende Plug and Play-apparaatrecords. Linux-bundels bevatten usb.txt, evdev.txt, udev.txt, en dmesg.txt voor context over de USB-/input-stack. Elke bundel bevat ook README.txt met een inhoudssamenvatting en privacynotitie.

Wat zit er NIET in de bundel

De supportbundelbouwer gebruikt een strikte toelatingslijst met bestandsnamen. Hij neemt niets op buiten die lijst, zelfs niet als er iets dat overeenkomt in dezelfde map aanwezig is. In het bijzonder:

• Geen opgeslagen wachtwoorden of inloggegevens. De brug slaat niets op.
• Geen profielbestanden anders dan de actieve.
• Geen systeemlogboeken, journaals of iets anders buiten de eigen gegevensmappen van de bridge.
• Geen netwerkpakketopnamen.
• Geen cloudtokens (de bridge gebruikt er geen).

Verwerking aan de serverzijde

Wanneer u een bundel aan een feedbackrapport koppelt, parseert de intakemedewerker van de site deze om nuttige indexeerbare gegevens in onze database te extraheren:

• Systeeminformatie in een samenvattende rij voor groepering (“hoeveel rapporten van deze distro?”).
• Waarschuwings- en foutregels uit het logboek, met stabiele foutsignaturen, zodat we in één oogopslag kunnen zien hoeveel mensen dezelfde bug tegenkomen.
• Resultaten van de statuscontrole voor een overzicht van wat er in de gebruikersbasis mislukt.
• De letterlijke bestandstekst van elk item op de toelatingslijst, opgeslagen zodat we de context opnieuw kunnen lezen tijdens de triage.

De onbewerkte bundel zelf wordt gedurende een korte periode (standaard 30 dagen) bewaard, zodat we deze opnieuw kunnen parseren als onze extractielogica verbetert. Daarna worden de geparseerde gegevens bewaard; de ruwe klodder wordt verwijderd.

Grenzen

In de praktijk bedraagt een normale bundel minder dan een megabyte. Deze limieten zijn er om vijandige uploads uit te sluiten, niet om echte rapporten uit te sluiten.

Verzenden zonder het feedbackformulier

Als je de bundel liever rechtstreeks wilt e-mailen, schrijf dan naar feedback·ffb-bridge.com (vervang de · door een @) en bevestig de ZIP. De server-side parser werkt niet voor e-mail, dus de triage is langzamer, maar de bundel is net zo bruikbaar.