Note di rilascio di FFB Probe

Una correzione dell'intensità di test predefinita: solo il Brunner FFB-G Joystick parte dal 75%, e tutte le altre basi Brunner partono dal 35%.

Intensità predefinita Brunner

• Solo il Brunner FFB-G Joystick parte dal 75%. FFB-Probe lo riconosce dal tipo di base che comunica tramite il canale di configurazione Brunner, qualunque sia l'impugnatura montata, e la checklist mostra «Validated base (Brunner FFB-G Joystick) — default 75%». La versione 1.1.1 aveva assegnato il valore predefinito del 75% a tutte le basi Brunner.
• Le altre basi Brunner partono dal 35%. La CLS-E, la CLS-P, una pedaliera e ogni altra base Brunner partono dal 35%, come qualsiasi dispositivo su cui i test non sono stati validati. Come su ogni dispositivo, puoi alzare tu l'intensità fino al limite del 75%.
• Una base il cui tipo non può essere letto parte dal 35%. Finché Simux, CLS2Sim, il Brunner USB Config Tool o FFB-Bridge occupano il canale di configurazione, FFB-Probe non può leggere il tipo di base. La checklist ti chiede allora di chiudere il programma e fare clic su «Re-scan».

Ora puoi scegliere con quanta forza i test azionano il tuo dispositivo, mai oltre un limite fisso, e prima dell'avvio di un test confermi che lo utilizzerai in sicurezza.

Intensità del test

• Un cursore dell'intensità nella checklist. Prima di un test puoi impostare l'intensità del test dallo 0% al 75% a passi del 5%. Accanto al cursore vengono mostrati il valore, quello predefinito del tuo dispositivo e il massimo del 75%, e FFB-Probe ricorda l'ultima intensità che hai scelto per ciascun dispositivo.
• Valori predefiniti per dispositivo. Gli stick su cui i test sono stati validati partono dal 75%: il SideWinder Force Feedback 2, gli adattatori USB per SideWinder FFB Pro (03EB:2056, PicoWinder CAFE:4004), Logitech G940, Force 3D Pro e WingMan Force 3D, e tutte le basi Brunner. Tutti gli altri dispositivi, comprese le basi di volo MOZA e l'hardware che FFB-Probe non conosce ancora, partono dal 35%.
• Il 75% è un limite fisso. Nulla di ciò che FFB-Probe riproduce supera il 75% del fondo scala, su qualsiasi dispositivo e in qualsiasi test, compresi l'opzione da riga di comando --magnitude e le modalità diagnostiche. Gli effetti riprodotti contemporaneamente si dividono l'intensità che hai scelto, quindi insieme non la superano mai; il test di saturazione ora la suddivide tra le sue tre forze, 25% ciascuna al 75%.
• Le basi Brunner non sono più limitate al 35%. Con i guadagni DirectX alzati per il test, ora partono dal 75% come il SideWinder FFB2. Al 35% i test risultavano troppo deboli per poterli valutare.
• Per le basi di volo MOZA l'intensità si può alzare. Partono ancora dal 35%, il limite di FFB-Bridge per questo hardware, ma ora puoi alzare tu l'intensità. Il precedente limite fisso del 35% è sostituito dal valore predefinito e dal limite del 75%.

Conferma di sicurezza

• Un avviso di sicurezza prima di ogni test. La checklist spiega sempre che i dispositivi force feedback possono muoversi all'improvviso e con forza reale: tieni una mano appoggiata leggermente sull'impugnatura, tieni lontani dita, cavi e oggetti e interrompi in qualsiasi momento con Esc o «Stop». «Arm probe» resta disattivato finché non selezioni «I understand and accept responsibility».
• Un avviso aggiuntivo oltre il valore predefinito. Se alzi l'intensità oltre il valore predefinito del tuo dispositivo, l'avviso aggiunge che le basi direct drive potenti possono urtare con forza i finecorsa.

Rapporti

• L'intensità viene registrata. Ogni report registra l'intensità del test e se l'hai modificata. Il report HTML mostra «Test strength: 75% (default)» o «Test strength: 50% (chosen by tester)», e i dati condivisi contengono un nuovo oggetto run con strength_pct e strength_source. Il formato del report resta schema: 1.
• Il test a due assi ha un solo nome. Ora viene registrato come «Two-axis diagonal — diagonal» invece di «Two-axis diagonal — diagonal (X=75%, Y=75%)», così un'intensità regolabile non lo divide in una voce separata per ogni intensità. Il sito unisce il vecchio nome a quello nuovo.
• Le note restano private. Le note che scrivi restano private e non compaiono mai sulla pagina pubblica del dispositivo.

Riga di comando

• --magnitude imposta l'intensità del test. I valori fuori dall'intervallo 0..75 vengono limitati invece di essere rifiutati. Senza l'opzione si usa il valore predefinito del dispositivo (75% o 35%); le build precedenti usavano il 75% su Windows e il 50% su Linux, oppure il 60% se avviate dall'app. La console e il log di debug indicano l'intensità usata e se era quella predefinita.

Una release di consolidamento: un test completato non va più perso al passaggio «Share», i risultati che arrivano nel database pubblico sono più accurati e le basi di volo Brunner e MOZA ora funzionano subito.

Basi Brunner

• La modalità CLS2Sim viene rilevata. Le basi Brunner escono di fabbrica in modalità CLS2Sim, che non ha un'interfaccia force feedback, quindi le build precedenti non trovavano alcun dispositivo. Quando non trova alcun dispositivo force feedback, FFB-Probe ora cerca una base Brunner e propone «Switch to DirectX mode»; senza quel clic non viene cambiato nulla.
• Il ritorno alla modalità originale è automatico. «Switch back when finished» è attivo per impostazione predefinita: la base torna in modalità CLS2Sim dopo il test, quando chiudi FFB-Probe o all'avvio successivo dopo una chiusura imprevista. Viene scritta solo l'impostazione della modalità USB e, se un passaggio non riesce, la base viene riportata com'era.
• Effetti a piena intensità. La base scala ogni effetto in base a guadagni che memorizza da sé (50% di fabbrica), quindi gli effetti arrivavano al motore con circa un quarto della loro forza. Per i test dal vivo FFB-Probe imposta FX master e i guadagni degli effetti al 100%, poi ripristina i tuoi valori e riporta nel report i guadagni che avevi memorizzato.
• I programmi che occupano la base vengono indicati. Se Simux, CLS2Sim, il Brunner USB Config Tool o FFB-Bridge occupano la base, FFB-Probe indica quale e ti spiega come chiuderlo. Su Linux, se l'accesso all'interfaccia di configurazione della base viene negato, FFB-Probe mostra la riga della regola udev da aggiungere.
• Le direzioni ruotate vengono registrate come misurate. La rotazione di 90° delle direzioni che potresti percepire in modalità DirectX dipende da come la modalità DirectX di Brunner mappa i suoi assi; FFB-Probe la registra così come viene misurata.

Basi di volo MOZA

• Prima di ogni test si verifica che la base sia pronta. FFB-Probe legge, senza modificare nulla, se una MOZA AB9, AY210, AB6 o AY90 riprodurrà davvero gli effetti force feedback. Una base in modalità Telemetry di MOZA Cockpit, oppure con force feedback disattivato, uscita di coppia inibita o guadagno di gioco a 0, non si muove; le build precedenti lo registravano come «non ha fatto nulla», mentre ora i report di una base del genere indicano che non era pronta.
• Preparazione facoltativa della base. «Prepare base for testing» porta la base in modalità DirectInput e apre i blocchi dell'uscita di forza dopo aver salvato le tue impostazioni, e «Restore my MOZA settings when finished» (attivo per impostazione predefinita) le ripristina al termine. Limiti di escursione, calibrazione e Force Sensing non vengono mai toccati.
• Un limite di intensità sicuro. Le basi di volo MOZA e le basi Brunner eseguono i test degli effetti al massimo al 35% di intensità, il limite di FFB-Bridge per questo hardware, così uno stick non impugnato non viene spinto contro i finecorsa.

Altri programmi che usano il tuo dispositivo

• I programmi in conflitto vengono segnalati. La schermata di benvenuto avvisa quando è in esecuzione un programma che può occupare il tuo dispositivo: FFB-Bridge, MOZA Cockpit / Pit House, gli strumenti Brunner, Logitech G HUB o un simulatore di volo.
• Errori di accesso esclusivo chiari. Quando un altro programma ha il dispositivo in uso esclusivo, FFB-Probe indica quale invece di fallire con un errore generico; su Linux vengono indicati i processi che occupano il dispositivo. Questi nomi di programmi vengono mostrati solo a te e non vengono mai aggiunti al report condiviso.

La condivisione non fallisce mai con un test valido

• Niente più test persi. Prima bastavano una nota lunga o un chip in più perché il sito rifiutasse l'intero report. Ora ogni campo viene adeguato ai limiti del sito prima dell'invio: selezionare tutti i chip funziona, le note molto lunghe vengono accorciate e i nomi di dispositivo segnaposto come «test» diventano Unknown force-feedback device vvvv:pppp.
• Rimozione dei percorsi più accurata. I percorsi dei file vengono rimossi dai messaggi di errore in modo più completo, compresi i percorsi Windows con spazi nel nome utente.
• Codice di supporto e link al dispositivo dopo la condivisione. Entrambi vengono mostrati nell'app e sul pulsante «Share» del report HTML.
• Stesso formato, stessa privacy. Il formato del report non cambia (schema: 1) e le note che scrivi restano private e non compaiono mai sulla pagina pubblica del dispositivo.

Risultati più accurati

• Misura del movimento con segno su Windows. FFB-Probe ora misura su Windows di quanto e in che direzione si muove lo stick durante ogni effetto, come faceva già su Linux. Le letture hanno il segno, per esempio X peak +25.1%, e quindi mostrano la direzione.
• Gli effetti si fermano in tempo. Ogni effetto si ferma appena termina la sua finestra di riproduzione, invece che quando rispondi. Alcuni firmware, come quello Brunner, mantenevano una forza di 5 secondi per circa un secondo in più.
• L'autocentraggio non interferisce più. La molla di autocentraggio del dispositivo viene disattivata durante i test dal vivo e ripristinata al termine, così non contrasta né maschera più l'effetto in prova. Sulle basi Brunner bloccava ogni effetto.
• Più risposte arrivano nel report. Le risposte di rampa ora vengono incluse invece di essere scartate, e i risultati di polarità, due assi e saturazione compaiono nella diagnostica pubblica.
• La classe del dispositivo viene registrata. I report indicano se il dispositivo è un joystick, uno stick di volo, un volante o un gamepad, così il database pubblico può distinguere l'hardware di volo dai volanti.
• Parametri degli effetti corretti. I test di autocentraggio usano la proprietà di autocentraggio (le build precedenti usavano un id di proprietà errato), e molla, smorzatore, inerzia e attrito seguono la convenzione di coordinate prevista da DirectInput. I dispositivi sconosciuti tornano a riportare su Windows il loro vero nome del driver.

L'app

• La lettura dal vivo segue il dispositivo in prova. Prima mostrava il primo controller di gioco elencato da Windows, quindi su una postazione con più controller restava ferma.
• Stop funziona sempre. Stop funziona in ogni momento di un test, Esc interrompe un test e, se chiudi la finestra durante un test, prima vengono fermati gli effetti e rilasciato il dispositivo. Viene testato solo il dispositivo selezionato e il motore della sonda si ferma se l'app viene chiusa.
• Più facile da usare. Le risposte si possono saltare, la finestra si può ridimensionare e il testo è più leggibile.
• Aggiornamenti proposti al momento giusto. Gli aggiornamenti non vengono mai proposti durante un test, e le build beta non vengono proposte a chi usa la versione stabile.

Linux

• Ripetere un test funziona. «Run test again» ora riproduce di nuovo l'effetto.
• L'autocentraggio del kernel viene gestito effetto per effetto. Viene disattivato mentre ogni effetto è in riproduzione e ripristinato tra un effetto e l'altro, e non viene mai toccato sul Logitech G940, il cui driver ignora l'impostazione.
• Meno file per test. I test normali scrivono solo il report HTML e il JSON di condivisione; i file di supporto legacy vengono scritti solo se è impostato FFB_PROBE_KEEP_LEGACY=1.

Nomi dei dispositivi

• Nomi nuovi e corretti. MOZA 346E:1002 ora è identificato come MOZA AB6. Aggiunti: MOZA AY90 (346E:1003), Brunner FFB-G / FFB-H, l'adattatore PicoWinder per SideWinder FFB Pro (CAFE:4004) e Adapt-FFB-Joy (03EB:204E).

Una correzione per la condivisione dei report nelle distribuzioni Linux che si descrivono con un nome descrittivo della distribuzione anziché con una stringa Linux in stile kernel.

Condivisione dei report da Linux

• Un unico token generico os.family. Il campo os.family del payload di invio ora è sempre uno tra Windows, Linux, macOS o Unknown. Da .NET 8 in poi, Linux riporta il nome descrittivo della distribuzione — per esempio Fedora Linux 42 (Workstation Edition) — che le build precedenti inoltravano così com'era, e il sito rifiuta i valori superiori a 32 caratteri con os_family_invalid.
• I nomi descrittivi vengono risolti tramite la piattaforma in esecuzione. I nomi di distribuzione che non contengono mai la parola Linux, come quello di Ubuntu, ora vengono risolti tramite la piattaforma su cui è in esecuzione la sonda anziché tramite la descrizione del sistema operativo, quindi non frammentano più le istantanee delle capacità per sistema operativo del database pubblico.
• Le installazioni esistenti continuano a condividere. Il sito normalizza inoltre i valori legacy all'ingresso, così i report delle build precedenti vengono condivisi correttamente senza aggiornare prima.

L'aggiornamento automatico arriva su Windows e Linux, portando avanti il lavoro di misurazione del movimento e di identificazione dell'hardware pubblicato in precedenza lo stesso giorno.

Aggiornamenti automatici

• Un controllo di avvio privato. La GUI legge un piccolo manifest della versione stabile all'avvio. Non invia ID di installazione, query sulla versione corrente, informazioni sul dispositivo o risultati del sondaggio; le risposte offline e non valide rimangono silenziose.
• Windows può completare l'aggiornamento. Dopo il consenso esplicito, FFB-Probe scarica il programma di installazione, ne verifica la lunghezza esatta e SHA-256, richiede una firma Windows valida da Rohsam Inc., esegue il programma di installazione per utente in modo silenzioso e riavvia la nuova build.
• Le installazioni di AppImage possono aggiornarsi da sole. Un Linux AppImage in esecuzione può scaricare e verificare il nuovo AppImage, richiamare il relativo gestore di installazione con ambito utente, aggiornare la voce e le icone del desktop e avviare la copia installata.
• Fallback sicuro per altre installazioni. Le build di sviluppo, AppDirs estratti, i pacchetti di distribuzione e altre installazioni nonAppImage Linux non vengono mai sovrascritte. Il prompt si collega invece alla pagina di download e a queste note di rilascio e ogni utente può rinviare o saltare una versione.

Miglioramenti hardware e Linux inclusi

• Movimento misurato durante gli effetti Linux. I test dal vivo ora campionano gli assi del dispositivo mentre suona una forza, registrando lo spostamento dell'obiettivo insieme alla risposta del tester.
• MOZA AY210 guida. AY210 (346E:1001) ha un nome canonico e una guida pre-volo per le impostazioni del fornitore che possono mascherare le forze comandate dall'esterno.
• Nomi hardware corretti e coerenti. MOZA 346E:1002 è identificato come AB6/AB9 base PID condiviso e SideWinder Force Feedback Pro adattato su 03EB:2056 utilizza un nome multipiattaforma nell'app e nel database pubblico.
• Rilevamento Linux più robusto. La risoluzione del percorso del driver e del descrittore HID è più difensiva e il centro automatico viene scritto solo quando il dispositivo pubblicizza tale funzionalità.

Nota di aggiornamento

• Un aggiornamento manuale per gli utenti esistenti. Le versioni fino a 1.0.6 non contengono il programma di aggiornamento, quindi devono installare 1.0.7 manualmente una volta. Le versioni successive a 1.0.7 possono quindi essere installate dall'interno dell'app.

Una versione di hardware e prove Linux che è stata sostituita da 1.0.7 prima che il canale di download del sito Web avanzasse.

Linux misurazione

• La telemetria degli assi unisce le risposte soggettive. Il lavoratore Linux registra lo spostamento misurato mentre si verificano gli effetti, aiutando a distinguere un effetto funzionante da una risposta errata "non ha fatto nulla".
• Configurazione del dispositivo più sicura. I percorsi degli eventi di input e i descrittori del report HID si risolvono in modo più affidabile, mentre FF_AUTOCENTER viene toccato solo sull'hardware che lo espone.

Identità dell'hardware

• MOZA AY210 aggiunto. AY210 (346E:1001) riceve un nome canonico e MOZA Cockpit precondizioni prima del test.
• MOZA AB6/AB9 PID corretto. L'identificatore condiviso 346E:1002 non implica più solo uno dei due modelli base compatibili.
• Nome SideWinder adattato e normalizzato. 03EB:2056 ora si aggrega sotto un unico nome Windows/Linux. Si trattava di una correzione del nome, non di una nuova affermazione di supporto all'attuazione.

Linux confezione

• Installazione AppImage con ambito utente. AppImage ha ottenuto l'integrazione desktop incorporata --install e --uninstall per le applicazioni dell'utente e le directory XDG.

Una correzione per l'attuazione di Windows per il firmware che si avvia nella propria modalità a molla e accetta altrimenti i comandi della sonda senza produrre forza fisica.

Correzioni

• Uno stato del dispositivo pulito prima degli effetti dal vivo. Dopo aver acquisito il dispositivo e impostato il guadagno globale, il Windows lavoratore invia un massimo sforzo DirectInput STOPALL prima dell'inizio della sequenza di test dal vivo. Questo cancella le forze predefinite di proprietà del firmware in modo che gli effetti FFB Probe caricati possano prendere il controllo dal primo test.
• Nessun reset distruttivo. La correzione evita deliberatamente DISFFC_RESET, preservando la tabella degli effetti del dispositivo e riservando un ripristino completo per il ripristino da arresto anomalo.

Chi ne trae vantaggio

• Firmware predefinito a molla e fai-da-te. La modifica riguarda i dispositivi, inclusi i gioghi fai-da-te derivati da Fino, che segnalano chiamate Create e Play riuscite ma rimangono trattenuti da una molla di avvio finché non viene emesso STOPALL.

Una versione dell'interfaccia mirata che mantiene ogni azione richiesta raggiungibile all'interno della finestra della procedura guidata a dimensione fissa.

Disposizione della lista di controllo

• La denominazione dei dispositivi sconosciuti non copre più i controlli. Quando viene visualizzata la scheda aggiuntiva "Assegna un nome a questo dispositivo", le schede dell'elenco di controllo scorrono mentre i controlli Sonda braccio, Indietro e Avanzamento rimangono bloccati e visibili.

Layout delle risposte al test

• Le lunghe note private rimangono contenute. L'area delle risposte può scorrere e la casella delle note su più righe ha il proprio limite di altezza, quindi Continua ed Esegui nuovamente il test rimangono raggiungibili indipendentemente dalla lunghezza della nota o dai chip selezionati.

Copertura della regressione

• I layout dei problemi sono coperti da screenshot. L'imbracatura dello screenshot ora esegue il rendering sia di un elenco di controllo dei dispositivi sconosciuti che di una lunga risposta su più righe, proteggendo i layout regrediti.

Un hotfix per l'identificazione dei metadati e dei dispositivi che mantiene pulite le righe dell'hardware pubblico e rende espliciti i dispositivi sconosciuti prima della condivisione.

Metadati di invio coerenti

• Le versioni di FFB Probe utilizzano SemVer stabile. I caricamenti ora inviano valori come 1.0.1 senza un suffisso di revisione dell'origine SDK, quindi il database pubblico non suddivide una versione in più stringhe di build.

Nomi dei dispositivi

• Un catalogo VID:PID condiviso da 138 voci. Windows, Linux, la GUI e il sito Web hanno ottenuto una tabella dei nomi con feedback forzato molto più ampia, inclusi gli identificatori MOZA AB9 e Logitech G940.
• È necessario nominare l'hardware sconosciuto. La GUI si ferma sull'elenco di controllo per il nome di un produttore/modello, la CLI interattiva esegue il prompt e l'automazione può superare --device-name. I segnaposto generici vengono rifiutati prima del caricamento.
• I nomi utili delle piattaforme rimangono disponibili. Le esecuzioni non interattive mantengono un nome del sistema operativo ripulito significativo quando ne esiste uno, altrimenti utilizzano un fallback esplicito del dispositivo di feedback forzato sconosciuto VID:PID.

Coordinamento sito web

• Nomi di app e database ora corrispondenza. Il sito web ha ricevuto lo stesso catalogo normalizzato, quindi i vecchi e i nuovi invii si aggregano sotto nomi stabili.

La prima versione pubblica stabile della diagnostica standalone FFB-Probe per Windows e Linux.

Test hardware guidato

• Una procedura guidata completa incentrata sui tester. FFB-Probe rileva un dispositivo di feedback di forza collegato, presenta una lista di controllo di sicurezza, riproduce brevi effetti dal vivo e registra ciò che il tester ha provato dopo ciascuno di essi.
• Copertura ad ampio effetto. La suite di test controlla il comportamento costante, condizionale, periodico, elastico, damper, inerzia e rampa, con diagrammi e progressi in base alla sezione.
• Windows e Linux dal primo giorno. Il lavoratore Windows DirectInput e il lavoratore Linux evdev si trovano dietro la stessa interfaccia multipiattaforma Avalonia.

Report e condivisione

• Output leggibile dall'uomo e dalla macchina. Ogni esecuzione scrive un report HTML e l'esatto payload di invio JSON localmente, in modo che i tester possano ispezionare le prove prima di decidere se condividerle.
• La condivisione è attiva. Niente viene caricato automaticamente. La schermata dei risultati e il report HTML salvato espongono l'azione di condivisione solo dopo che il tester ha potuto esaminare i campi raccolti.
• Fatti pubblici, appunti privati. Funzionalità hardware, risposte agli effetti e diagnostica del vocabolario chiuso possono supportare il database pubblico, mentre le note di testo libero rimangono private per la valutazione del supporto.

Pacchetti di rilascio

• Rilasci autonomi. La versione pubblica include un programma di installazione Windows per utente e un Linux x86-64 AppImage con il runtime .NET in bundle.
• Distribuzione Windows firmata. I file binari stabili Windows e il programma di installazione vengono prodotti tramite il flusso di lavoro di rilascio sotto l'identità dell'editore Rohsam.