FFB Probe Versionshinweise

Eine Korrektur der Standard-Teststärke: Nur der Brunner FFB-G Joystick startet bei 75 %, alle anderen Brunner-Basen starten bei 35 %.

Brunner-Standardstärke

• Nur der Brunner FFB-G Joystick startet bei 75 %. FFB-Probe erkennt ihn am Basistyp, den er über Brunners Konfigurationskanal meldet, unabhängig vom montierten Griff, und die Checkliste zeigt „Validated base (Brunner FFB-G Joystick) — default 75%“. Version 1.1.1 hatte jeder Brunner-Basis den Standardwert von 75 % gegeben.
• Andere Brunner-Basen starten bei 35 %. Die CLS-E, die CLS-P, ein Ruder und jede andere Brunner-Basis starten bei 35 %, wie jedes Gerät, auf dem die Tests nicht validiert wurden. Wie bei jedem Gerät können Sie die Stärke selbst bis zur Grenze von 75 % erhöhen.
• Eine Basis, deren Typ sich nicht lesen lässt, startet bei 35 %. Solange Simux, CLS2Sim, das Brunner USB Config Tool oder FFB-Bridge den Konfigurationskanal belegt, kann FFB-Probe den Basistyp nicht lesen. Die Checkliste bittet Sie dann, das Programm zu schließen und auf „Re-scan“ zu klicken.

Sie können jetzt wählen, wie stark die Tests Ihr Gerät antreiben – nie über eine feste Obergrenze hinaus –, und bestätigen vor dem Start eines Laufs, dass Sie es sicher bedienen.

Teststärke

• Ein Stärkeregler in der Checkliste. Vor einem Lauf können Sie die Teststärke von 0 % bis 75 % in Schritten von 5 % einstellen. Der Wert, der Standardwert Ihres Geräts und das Maximum von 75 % werden neben dem Regler angezeigt, und FFB-Probe merkt sich für jedes Gerät die zuletzt gewählte Stärke.
• Standardwerte je Gerät. Sticks, auf denen die Tests validiert wurden, starten bei 75 %: der SideWinder Force Feedback 2, die USB-Adapter für den SideWinder FFB Pro (03EB:2056, PicoWinder CAFE:4004), der Logitech G940, Force 3D Pro und WingMan Force 3D sowie jede Brunner-Basis. Alle anderen Geräte, einschließlich MOZA-Flugbasen und Hardware, die FFB-Probe noch nicht kennt, starten bei 35 %.
• 75 % sind eine feste Obergrenze. Nichts, was FFB-Probe wiedergibt, überschreitet 75 % des Vollausschlags – auf keinem Gerät und in keinem Test, einschließlich der Befehlszeilenoption --magnitude und der Diagnosemodi. Gleichzeitig laufende Effekte teilen sich die gewählte Stärke, sodass sie zusammen nie darüber liegen; der Sättigungstest teilt sie jetzt auf seine drei Kräfte auf, bei 75 % je 25 %.
• Brunner-Basen sind nicht mehr auf 35 % begrenzt. Da ihre DirectX-Verstärkungen für den Lauf angehoben werden, starten sie jetzt wie der SideWinder FFB2 bei 75 %. Bei 35 % fühlten sich die Tests zu schwach an, um sie zu beurteilen.
• MOZA-Flugbasen lassen sich höher einstellen. Sie starten weiterhin bei 35 %, der Obergrenze von FFB-Bridge für diese Hardware, aber Sie können die Stärke jetzt selbst erhöhen. Die bisherige feste Obergrenze von 35 % wird durch den Standardwert und die Grenze von 75 % ersetzt.

Sicherheitsbestätigung

• Ein Sicherheitshinweis vor jedem Lauf. Die Checkliste erklärt immer, dass sich Force-Feedback-Geräte plötzlich und mit echter Kraft bewegen können: Lassen Sie eine Hand leicht auf dem Griff ruhen, halten Sie Finger, Kabel und Gegenstände fern und stoppen Sie jederzeit mit Esc oder „Stop“. „Arm probe“ bleibt deaktiviert, bis Sie „I understand and accept responsibility“ ankreuzen.
• Eine zusätzliche Warnung über dem Standardwert. Erhöhen Sie die Stärke über den Standardwert Ihres Geräts, ergänzt der Hinweis eine Warnung, dass starke Direct-Drive-Basen hart in ihre Endanschläge schlagen können.

Berichte

• Die Stärke wird erfasst. Jeder Bericht erfasst die Teststärke und ob Sie sie geändert haben. Der HTML-Bericht zeigt „Test strength: 75% (default)“ oder „Test strength: 50% (chosen by tester)“, und die geteilten Daten enthalten ein neues run-Objekt mit strength_pct und strength_source. Das Berichtsformat ist weiterhin schema: 1.
• Der Zwei-Achsen-Test hat einen einzigen Namen. Er wird jetzt als „Two-axis diagonal — diagonal“ statt als „Two-axis diagonal — diagonal (X=75%, Y=75%)“ gemeldet, damit eine einstellbare Stärke ihn nicht in einen eigenen Eintrag je Stärke aufteilt. Die Website führt den alten Namen mit dem neuen zusammen.
• Notizen bleiben privat. Ihre eingegebenen Notizen bleiben privat und erscheinen nie auf der öffentlichen Geräteseite.

Befehlszeile

• --magnitude legt die Teststärke fest. Werte außerhalb von 0..75 werden begrenzt statt abgelehnt. Ohne die Option wird der Standardwert des Geräts (75 % oder 35 %) verwendet; frühere Builds nutzten 75 % unter Windows und 50 % unter Linux bzw. 60 %, wenn sie von der App gestartet wurden. Konsole und Debug-Log geben die verwendete Stärke an und ob es der Standardwert war.

Ein Härtungs-Release: Ein abgeschlossener Testlauf geht beim Schritt „Share“ nicht mehr verloren, die Ergebnisse in der öffentlichen Datenbank sind genauer, und Brunner- sowie MOZA-Flugbasen funktionieren jetzt auf Anhieb.

Brunner-Basen

• Der CLS2Sim-Modus wird erkannt. Brunner-Basen werden im CLS2Sim-Modus ausgeliefert, der keine Force-Feedback-Schnittstelle bietet, weshalb frühere Builds kein Gerät fanden. Wird kein Force-Feedback-Gerät gefunden, prüft FFB-Probe jetzt, ob eine Brunner-Basis angeschlossen ist, und bietet „Switch to DirectX mode“ an; ohne diesen Klick wird nichts umgeschaltet.
• Das Zurückschalten erfolgt automatisch. „Switch back when finished“ ist standardmäßig aktiv: Die Basis kehrt nach dem Lauf, beim Schließen von FFB-Probe oder nach einem unerwarteten Beenden beim nächsten Start in den CLS2Sim-Modus zurück. Geschrieben wird nur die USB-Modus-Einstellung, und schlägt ein Schritt fehl, wird die Basis in ihren ursprünglichen Zustand zurückversetzt.
• Effekte in voller Stärke. Die Basis skaliert jeden Effekt mit selbst gespeicherten Verstärkungen (ab Werk 50 %), sodass Effekte nur mit etwa einem Viertel ihrer Stärke am Motor ankamen. Für die Live-Tests setzt FFB-Probe FX master und die Effektverstärkungen auf 100 %, stellt Ihre Werte danach wieder her und vermerkt Ihre gespeicherten Verstärkungen im Bericht.
• Programme, die die Basis belegen, werden benannt. Belegt Simux, CLS2Sim, das Brunner USB Config Tool oder FFB-Bridge die Basis, nennt FFB-Probe das Programm und erklärt, wie Sie es schließen. Wird unter Linux der Zugriff auf die Konfigurationsschnittstelle der Basis verweigert, zeigt FFB-Probe die udev-Regelzeile an, die Sie hinzufügen müssen.
• Gedrehte Richtungen werden wie gemessen erfasst. Die Drehung der Richtungen um 90°, die Sie im DirectX-Modus spüren können, entsteht dadurch, wie Brunners DirectX-Modus die Achsen zuordnet; FFB-Probe erfasst sie so, wie sie gemessen wurde.

MOZA-Flugbasen

• Die Bereitschaft wird vor einem Lauf geprüft. FFB-Probe liest, ohne etwas zu ändern, aus, ob eine MOZA AB9, AY210, AB6 oder AY90 Force-Feedback-Effekte tatsächlich wiedergibt. Eine Basis im Telemetry-Modus von MOZA Cockpit oder mit deaktiviertem Force Feedback, gesperrter Drehmomentausgabe oder einer Spielverstärkung von 0 bewegt sich nicht; frühere Builds meldeten das als „hat nichts bewirkt“, und Berichte von einer solchen Basis geben jetzt an, dass sie nicht bereit war.
• Optionale Vorbereitung der Basis. „Prepare base for testing“ schaltet die Basis in den DirectInput-Modus und öffnet ihre Sperren für die Kraftausgabe, nachdem Ihre Einstellungen gesichert wurden, und „Restore my MOZA settings when finished“ (standardmäßig aktiv) stellt sie danach wieder her. Wegbegrenzungen, Kalibrierung und Force Sensing werden nie verändert.
• Eine sichere Stärkeobergrenze. MOZA-Flugbasen und Brunner-Basen führen die Effekttests mit höchstens 35 % Stärke aus, der Obergrenze von FFB-Bridge für diese Hardware, damit ein nicht gehaltener Stick nicht in seine Endanschläge gefahren wird.

Andere Programme, die Ihr Gerät verwenden

• Konkurrierende Programme werden gemeldet. Der Willkommensbildschirm warnt, wenn ein Programm läuft, das Ihr Gerät belegen kann: FFB-Bridge, MOZA Cockpit / Pit House, Brunners Tools, Logitech G HUB oder ein Flugsimulator.
• Klare Fehlermeldungen bei exklusivem Zugriff. Hält ein anderes Programm das Gerät exklusiv, nennt FFB-Probe dieses Programm, statt mit einem allgemeinen Fehler abzubrechen; unter Linux werden die Prozesse benannt, die das Gerät belegen. Diese Programmnamen sehen nur Sie; sie werden nie in den geteilten Bericht übernommen.

Teilen schlägt bei einem gültigen Lauf nie fehl

• Keine verlorenen Läufe mehr. Eine lange Notiz oder ein zusätzlicher Chip genügte früher, damit die Website den gesamten Bericht ablehnte. Jetzt wird jedes Feld vor dem Senden auf die Grenzen der Website gebracht: Alle Chips auszuwählen funktioniert, sehr lange Notizen werden gekürzt, und Platzhalter-Gerätenamen wie „test“ werden zu Unknown force-feedback device vvvv:pppp.
• Gründlichere Bereinigung von Pfaden. Dateipfade werden gründlicher aus Fehlermeldungen entfernt, auch Windows-Pfade mit Leerzeichen im Benutzernamen.
• Supportcode und Gerätelink nach dem Teilen. Beide werden in der App und über die Schaltfläche „Share“ im HTML-Bericht angezeigt.
• Gleiches Format, gleicher Datenschutz. Das Berichtsformat ist unverändert (schema: 1), und Ihre eingegebenen Notizen bleiben privat und erscheinen nie auf der öffentlichen Geräteseite.

Genauere Ergebnisse

• Vorzeichenbehaftete Bewegungsmessung unter Windows. FFB-Probe misst jetzt auch unter Windows bei jedem Effekt, wie weit und in welche Richtung sich der Stick bewegt, wie bisher schon unter Linux. Die Messwerte tragen ein Vorzeichen, zum Beispiel X peak +25.1%, und zeigen so die Richtung.
• Effekte stoppen pünktlich. Jeder Effekt stoppt, sobald sein Wiedergabefenster endet, und nicht erst, wenn Sie antworten. Manche Firmware, etwa die von Brunner, ließ eine 5-Sekunden-Kraft rund eine Sekunde länger laufen.
• Die Autozentrierung stört nicht mehr. Die geräteeigene Autozentrierfeder wird während der Live-Tests ausgeschaltet und danach wiederhergestellt, sodass sie dem getesteten Effekt nicht mehr entgegenwirkt oder ihn überdeckt. Auf Brunner-Basen blockierte sie jeden Effekt.
• Mehr Antworten gelangen in den Bericht. Ramp-Antworten werden jetzt übernommen statt verworfen, und Ergebnisse zu Polarität, zwei Achsen und Sättigung erscheinen in der öffentlichen Diagnose.
• Die Geräteklasse wird erfasst. Berichte halten fest, ob das Gerät ein Joystick, ein Flugstick, ein Lenkrad oder ein Gamepad ist, damit die öffentliche Datenbank Flughardware von Lenkrädern unterscheiden kann.
• Korrekte Effektparameter. Autozentrier-Tests sprechen die Autozentrier-Eigenschaft an (frühere Builds verwendeten die falsche Eigenschafts-ID), und Feder, Dämpfer, Trägheit und Reibung nutzen die Koordinatenkonvention, die DirectInput erwartet. Unbekannte Geräte melden unter Windows wieder ihren echten Treibernamen.

Die App

• Die Live-Anzeige folgt dem getesteten Gerät. Sie zeigte bisher den ersten Gamecontroller, den Windows auflistete, und bewegte sich daher bei mehreren Controllern am Rig nicht.
• Stop funktioniert überall. Stop funktioniert an jeder Stelle eines Laufs, Esc stoppt einen Lauf, und beim Schließen des Fensters während eines Laufs werden zuerst die Effekte gestoppt und das Gerät freigegeben. Nur das ausgewählte Gerät wird getestet, und die Probe-Engine stoppt, wenn die App geschlossen wird.
• Einfacher zu bedienen. Antworten lassen sich überspringen, die Fenstergröße lässt sich ändern, und der Text ist besser lesbar.
• Besser abgestimmte Update-Angebote. Updates werden nie während eines laufenden Tests angeboten, und Beta-Builds werden Nutzern der stabilen Version nicht angeboten.

Linux

• Einen Test wiederholen funktioniert. „Run test again“ spielt den Effekt jetzt erneut ab.
• Die Kernel-Autozentrierung wird pro Effekt gesteuert. Sie wird ausgeschaltet, während ein Effekt läuft, und zwischen den Effekten wiederhergestellt; auf dem Logitech G940, dessen Treiber die Einstellung ignoriert, wird sie nie verändert.
• Weniger Dateien pro Lauf. Normale Läufe schreiben nur den HTML-Bericht und die JSON-Datei zum Teilen; die alten Support-Dateien werden nur geschrieben, wenn FFB_PROBE_KEEP_LEGACY=1 gesetzt ist.

Gerätebenennung

• Neue und korrigierte Namen. MOZA 346E:1002 heißt jetzt MOZA AB6. Neu hinzugekommen: MOZA AY90 (346E:1003), Brunner FFB-G / FFB-H, der PicoWinder-Adapter für SideWinder FFB Pro (CAFE:4004) und Adapt-FFB-Joy (03EB:204E).

Eine Korrektur für das Teilen von Berichten unter Linux-Distributionen, die sich mit einem Distributions-Pretty-Name statt einer kernelartigen Linux-Zeichenkette beschreiben.

Berichte teilen unter Linux

• Ein einheitlicher grober os.family-Wert. Der os.family-Wert der Übermittlungsnutzlast ist jetzt immer einer von Windows, Linux, macOS oder Unknown. Ab .NET 8 meldet Linux den Pretty-Name der Distribution — zum Beispiel Fedora Linux 42 (Workstation Edition) —, den frühere Builds unverändert weitergegeben haben; die Website lehnt Werte über 32 Zeichen mit os_family_invalid ab.
• Pretty-Names werden über die laufende Plattform aufgelöst. Verteilungsnamen, die das Wort Linux nie enthalten — etwa der von Ubuntu —, werden jetzt über die Plattform aufgelöst, auf der die Probe läuft, statt über die Betriebssystembeschreibung; dadurch zersplittern die Fähigkeits-Momentaufnahmen pro Betriebssystem in der öffentlichen Datenbank nicht mehr.
• Bestehende Installationen können weiterhin teilen. Die Website normalisiert alte Werte bereits beim Eingang, sodass Berichte aus älteren Builds erfolgreich geteilt werden können, ohne zuerst zu aktualisieren.

Die automatische Aktualisierung erfolgt auf Windows und Linux und führt die am selben Tag veröffentlichten Arbeiten zur Bewegungsmessung und Hardwareidentifizierung fort.

Automatische Updates

• Ein privater Startup-Check. Die GUI liest beim Start ein kleines Stable-Release-Manifest. Es werden keine Installations-IDs, Abfragen zur aktuellen Version, Geräteinformationen oder Testergebnisse gesendet. Offline- und fehlerhafte Antworten bleiben stumm.
• Windows kann das Upgrade abschließen. Nach ausdrücklicher Zustimmung lädt FFB-Probe das Installationsprogramm herunter, überprüft seine genaue Länge und SHA-256, erfordert eine gültige Windows-Signatur von Rohsam Inc., führt das benutzerspezifische Installationsprogramm im Hintergrund aus und startet den neuen Build neu.
• AppImage-Installationen können sich selbst aktualisieren. Ein ausgeführter Linux AppImage kann den neuen AppImage herunterladen und überprüfen, seinen benutzerbezogenen Installationshandler aufrufen, den Desktopeintrag und die Symbole aktualisieren und die installierte Kopie starten.
• Sicherer Fallback für andere Installationen. Entwicklungs-Builds, extrahierte AppDirs, Distributionspakete und andere Nicht-AppImage Linux-Installationen werden niemals überschrieben. Die Eingabeaufforderung verweist stattdessen auf die Download-Seite und diese Versionshinweise, und jeder Benutzer kann eine Version zurückstellen oder überspringen.

Hardware- und Linux-Verbesserungen enthalten

• Gemessene Bewegung während Linux-Effekten. Live-Tests tasten jetzt die Geräteachsen ab, während eine Kraft wirkt, und zeichnen die Zielverschiebung zusammen mit der Antwort des Testers auf.
• MOZA AY210 Anleitung. Die AY210 (346E:1001) verfügt über einen kanonischen Namen und eine Anleitung vor dem Flug für die Anbietereinstellungen, die extern kommandierte Kräfte maskieren können.
• Korrekte, konsistente Hardwarenamen. MOZA 346E:1002 wird als die gemeinsame AB6/AB9-Basis PID identifiziert, und das angepasste SideWinder Force Feedback Pro bei 03EB:2056 verwendet einen plattformübergreifenden Namen in der App und der öffentlichen Datenbank.
• Robustere Linux-Erkennung. Treiberpfad und HID-Deskriptorauflösung sind defensiver und Autocenter wird nur geschrieben, wenn das Gerät diese Funktion ankündigt.

Upgrade-Hinweis

• Ein manuelles Update für bestehende Benutzer. Versionen bis 1.0.6 enthalten den Updater nicht, daher müssen sie 1.0.7 einmal manuell installieren. Releases nach 1.0.7 können dann aus der App heraus installiert werden.

Eine Hardware- und Linux-Beweisversion, die durch 1.0.7 ersetzt wurde, bevor der Website-Download-Kanal erweitert wurde.

Linux Messung

• Achsentelemetrie verbindet subjektive Antworten. Der Linux-Worker zeichnet die gemessene Verschiebung während der Wiedergabe von Effekten auf und hilft so, einen Arbeitseffekt von einer falschen „Nichts getan“-Reaktion zu unterscheiden.
• Sicherere Geräteeinrichtung. Eingabeereignispfade und HID-Berichtsdeskriptoren werden zuverlässiger aufgelöst, während FF_AUTOCENTER nur auf Hardware berührt wird, die es verfügbar macht.

Hardware-Identität

• MOZA AY210 hinzugefügt. Der AY210 (346E:1001) erhält vor dem Testen einen kanonischen Namen und MOZA Cockpit Vorbedingungen.
• MOZA AB6/AB9 PID korrigiert. Die gemeinsame Kennung 346E:1002 impliziert nicht mehr nur eines der beiden kompatiblen Basismodelle.
• Angepasster SideWinder-Name normalisiert. 03EB:2056 wird jetzt unter einem Windows/Linux-Namen zusammengefasst. Hierbei handelte es sich um eine Namenskorrektur, nicht um einen neuen Anspruch auf Betätigungsunterstützung.

Linux Verpackung

• Benutzerbezogene AppImage-Installation. Der AppImage verfügt über eine integrierte Desktop-Integration --install und --uninstall für die Anwendungs- und XDG-Verzeichnisse des Benutzers.

Eine Windows-Betätigungskorrektur für Firmware, die in ihrem eigenen Federmodus startet und ansonsten Sondenbefehle akzeptiert, ohne physische Kraft zu erzeugen.

Korrekturen

• Ein sauberer Gerätestatus vor Live-Effekten. Nachdem das Gerät erfasst und die globale Verstärkung eingestellt wurde, sendet der Windows-Worker ein Best-Effort-DirectInput STOPALL, bevor die Live-Testsequenz beginnt. Dadurch werden Firmware-eigene Standardkräfte gelöscht, sodass hochgeladene FFB Probe-Effekte ab dem ersten Test die Kontrolle übernehmen können.
• Kein destruktiver Reset. Der Fix vermeidet bewusst DISFFC_RESET, behält die Geräteeffekttabelle bei und reserviert einen vollständigen Reset für die Wiederherstellung nach einem Absturz.

Wer profitiert

• Standard-Feder- und DIY-Firmware. Die Änderung zielt auf Geräte ab – einschließlich von Fino abgeleiteter DIY-Jochs – die erfolgreiche Create- und Play-Aufrufe melden, aber von einer Startfeder gehalten bleiben, bis STOPALL ausgegeben wird.

Eine fokussierte Schnittstellenversion, die jede erforderliche Aktion innerhalb des Assistentenfensters mit fester Größe erreichbar hält.

Checklisten-Layout

• Die Benennung unbekannter Geräte deckt die Steuerelemente nicht mehr ab. Wenn die zusätzliche Karte „Dieses Gerät benennen“ angezeigt wird, scrollen die Checklistenkarten, während die Steuerelemente „Arm-Sonde“, „Zurück“ und „Fortschritt“ angeheftet und sichtbar bleiben.

Test-Antwort-Layout

• Lange private Notizen bleiben unter Verschluss. Der Antwortbereich kann gescrollt werden und das Feld für mehrzeilige Notizen verfügt über eine eigene Höhenbegrenzung, sodass „Weiter“ und „Test erneut ausführen“ unabhängig von der Notizlänge oder den ausgewählten Chips erreichbar bleiben.

Regressionsabdeckung

• Problemlayouts werden durch Screenshots abgedeckt. Der Screenshot-Harness stellt jetzt sowohl eine Checkliste für unbekannte Geräte als auch eine lange mehrzeilige Antwort dar und schützt so die Layouts, die sich zurückgebildet haben.

Ein Hotfix für Metadaten und Geräteidentifizierung, der öffentliche Hardwarezeilen sauber hält und unbekannte Geräte vor der Freigabe explizit macht.

Konsistente Übermittlungsmetadaten

• FFB Probe-Versionen verwenden stabiles SemVer. Uploads senden jetzt Werte wie 1.0.1 ohne SDK-Quellrevisionssuffix, sodass die öffentliche Datenbank eine Version nicht in mehrere Build-Strings aufteilt.

Gerätenamen

• Ein gemeinsam genutzter VID:PID-Katalog mit 138 Einträgen. Windows, Linux, die GUI und die Website haben eine viel breitere Force-Feedback-Namenstabelle erhalten, einschließlich der Kennungen MOZA AB9 und Logitech G940.
• Unbekannte Hardware muss benannt werden. Die GUI hält bei der Checkliste für einen Hersteller-/Modellnamen an, die interaktive CLI führt eine Eingabeaufforderung aus und die Automatisierung kann --device-name passieren. Generische Platzhalter werden vor dem Hochladen abgelehnt.
• Nützliche Plattformnamen bleiben verfügbar. Nicht interaktive Ausführungen behalten einen aussagekräftigen, bereinigten Betriebssystemnamen bei, sofern einer vorhanden ist. Andernfalls verwenden sie einen expliziten Fallback für das unbekannte Force-Feedback-Gerät VID:PID.

Website-Koordination

• App- und Datenbanknamen stimmen jetzt überein. Die Website hat den gleichen normalisierten Katalog erhalten, sodass alte und neue Einsendungen unter stabilen Namen zusammengefasst werden.

Die erste stabile öffentliche Version der eigenständigen Diagnose FFB-Probe für Windows und Linux.

Geführte Hardwaretests

• Ein vollständig auf Tester ausgerichteter Assistent. FFB-Probe erkennt ein angeschlossenes Force-Feedback-Gerät, präsentiert eine Sicherheitscheckliste, spielt kurze Live-Effekte ab und zeichnet auf, was der Tester nach jedem einzelnen Effekt empfunden hat.
• Breite Wirkungsabdeckung. Die Testsuite prüft das konstante, bedingte, periodische, Feder-, Dämpfer-, Trägheits- und Rampenverhalten mit Diagrammen und abschnittsbezogenem Fortschritt.
• Windows und Linux vom ersten Tag an. Der Worker Windows DirectInput und der Worker Linux evdev werden hinter derselben plattformübergreifenden Schnittstelle Avalonia betrieben.

Berichte und Teilen

• Menschen- und maschinenlesbare Ausgabe. Bei jedem Lauf werden lokal ein HTML-Bericht und die genaue Übermittlungsnutzlast JSON geschrieben, sodass Tester die Beweise prüfen können, bevor sie entscheiden, ob sie sie weitergeben.
• Das Teilen erfolgt per Opt-in. Es wird nichts automatisch hochgeladen. Der Ergebnisbildschirm und der gespeicherte HTML-Bericht machen die Freigabeaktion erst sichtbar, nachdem der Tester die gesammelten Felder überprüfen kann.
• Öffentliche Fakten, private Notizen. Hardwarefunktionen, Effektantworten und geschlossene Vokabulardiagnosen können die öffentliche Datenbank unterstützen, während Freitextnotizen zur Support-Triage privat bleiben.

Release-Pakete

• Eigenständige Veröffentlichungen. Die öffentliche Version umfasst ein benutzerspezifisches Windows-Installationsprogramm und ein Linux x86-64 AppImage mit der gebündelten .NET-Laufzeit.
• Signierte Windows-Verteilung. Stabile Windows-Binärdateien und das Installationsprogramm werden über den Release-Workflow unter der Rohsam-Herausgeberidentität erstellt.