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.

session.log

Volledig gebeurtenislogboek voor de huidige sessie. Het bevat hetzelfde gebeurtenistype als de Diagnostische logstrook en bevat alle vermeldingen sinds de lancering, inclusief vermeldingen buiten het zichtbare venster. 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

— keuze van het fysieke apparaat en de renderer, veiligheidsplafond, kalibratie en krachtpolariteit, expliciete besturingstoewijzingen en compatibiliteitsinstellingen op het moment van exporteren.

aircraft-profiles.json

Het bestand met de koppelingen tussen vliegtuig en profiel, letterlijk opgenomen wanneer het bestaat. Het legt vast welk opgeslagen profiel elk vliegtuig automatisch toepast, zodat support kan zien waarom een profiel is gekozen.

profiles-index.txt

Een index van de opgeslagen profielen op het moment van exporteren: bestandsnaam, grootte, wijzigingstijd en de titel, id en revisie van elk profiel. De inhoud van de profielen zelf blijft op je computer.

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 blokkeren vijandige uploads en laten voldoende ruimte over voor echte rapporten.

Verzenden zonder het feedbackformulier

Als je de bundel liever rechtstreeks wilt e-mailen, schrijf dan naar feedback·ffb-bridge.com (replace the · with an @) and attach the ZIP. The server-side parser doesn't run for email, so the triage is slower — but the bundle is just as usable.