トラブルシューティング

まず症状を確認し、その下にあるものを修正します。ほとんどの場合、医師ページはすでに何が問題なのかを知っています。このリストを手動で処理する前に、そこを確認してください。ここで何も役に立たない場合は、サポートバンドルをエクスポートしてください。診断そしてフィードバックレポートを開く.

Windows 11 アプリが全く起動しない

Windows インストーラーは正常に実行されたが、 FFB-Bridge ショートカットはまったく何もしません - ウィンドウもエラーも SmartScreen プロンプトも表示されません - ほぼ確実に Windows 11 を実行していることになります スマートアプリコントロール (SAC) が有効になっています。 SAC は、信頼できる発行元によってコード署名されていないアプリをサイレントにブロックします。ベータビルドはまだ署名されていない (1.0 ロードマップに記載されている) ため、SAC はリリースを拒否しています。

修正するには、アプリをインストールして最初に実行するのに十分な期間、スマートアプリコントロールをオフにします。最近の Windows 11 の累積的な更新プログラムでは、Windows を再インストールせずに、後で SAC をオンに戻すこともできます。これは、オフに切り替えることが永続的であった以前のリリースよりも改善されています。 Microsoft 独自のガイダンス:

Microsoft: Smart App Control に関するよくある質問

SAC がオフになると、FFB-Bridge アプリが起動し、重要なことに、 起動し続ける SAC を再度有効にした後 - SAC は、以前に確認したことのないアプリのみをチェックします。したがって、回避策は 1 回限りです。コード署名されたインストーラーが 1.0 に同梱されると、このセクションは廃止されます。

スティックが全く動かない

武装しているのでしょうか？

コックピット上部のストリップにある ARM ゲージは次の値を読み取る必要があります。 武装した (琥珀色のグラデーション)。読めば 武装解除 (灰色のグリフ、暖かい境界線)、クリックして確認します。読めば 障害が発生しました (赤)、以下の「スティックは動作していましたが、突然停止しました」を参照してください。前提条件が低下しました。

デバイスは検出されていますか?

上部のストリップの DEVICE ランプが緑色 (「準備完了」) になっているはずです。赤 (「切断」) の場合:

スティックを抜き差しし直します。ブリッジは 1 ～ 2 秒以内に再検出します。
OS デバイスマネージャーで VID/PID を確認します (045E / 001B).
Linux Doctor の udev-rule 行は緑色になるはずです。赤の場合は、ワンクリックインストーラーを実行します。
窓フォースフィードバックを主張する他のアプリをすべて閉じます。DIY テスター、一部のジョイスティック診断ユーティリティは排他的アクセスを保持します。

SIMは接続されていますか？

上部のストリップの SIM ランプが緑色 (「Sim 接続中」) になっているはずです。そうでない場合は、を参照してください。 MSFS セットアップガイドまたは X-Planeセットアップガイドあなたのシムのために。その間、モックシムコネクトこのページでは、パイプラインの残りの部分が動作していることを確認できます。

MSFS は接続しますが、どの力も適切ではないと感じます

スティックは動いているが力が間違っていると感じる場合、問題は通常、プロファイルまたは機体の不一致です。

お使いの航空機に最も近い内蔵スターターから始めます:セスナ 172 スカイホーク (G1000)、ダーハー TBM 930、ビーチクラフトキングエア 350i、エアバス A320neo、またはボーイング 747-8 インターコンチネンタル。ほとんどの「間違った」感覚は、異なる航空機クラスに合わせて調整されたプロファイルから生じます。
ダッシュボードのスティックアクティビティパネルを確認します。これにより、ベースラインスプリングが、軸荷重、エンジン振動、地上ロール、乱流、機械的ワンショットなどの動的チャネルから分離されます。予期しなかったエフェクトがアクティブであると表示される場合、シムはそれらを引き起こしているテレメトリを報告しています。
サードパーティ製の航空機は、標準の SimVar の実装をスキップする場合があります。ブリッジはこれを許容します (欠落した変数はデフォルトでゼロになります) が、結果として一部のエフェクトは起動に失敗します。これは、ブリッジ内で簡単に回避できない既知の制限です。特徴を明らかにできるように、特定の航空機を報告してください。

トレイアイコンが表示されない（Linux）

一部のデスクトップ環境には、システムトレイホストが標準で付属していません。GNOME Wayland がその代表的な環境です。ブリッジがこれを検出すると、ウィンドウの上部にバナーを表示して、閉じるとアプリが (静かに隠れるのではなく) 直接終了することを説明し、閉じるボタンもそれに応じて動作します。 GNOME では、AppIndicator Support 拡張機能をインストールしてトレイアイコンを取り戻します。 KDE、Xfce、Cinnamon、MATE、および Budgie では、トレイはそのまま使用できます。

医師は、SimConnect は接続可能だがデータは流れないと言う

ブリッジは接続しています (TCP hello は受け入れられます) が、データストリームが開始されていません。 MSFS 2024 では、これは通常、SimVar サブスクリプションが失敗していることを意味します。通常、MSFS が内部 SimConnect サーバーの起動をまだ完了していないことが原因です。 MSFS が (イントロ画面だけでなく) メインメニューに到達するまで待ってから、再試行してください。

X-Plane は検出されましたが、データフローがありません

SIM ランプが一時的に緑色になり、実際にテレメトリが流れずに「SIM 実行なし」に戻った場合は、通常、ファイアウォールが UDP パケットを食べています。試してみてください:

確認のため、ファイアウォールを一時的に無効にします。
ブリッジプロセスで送信方向の UDP 49000 をホワイトリストに登録します。

窓準備完了または離陸直後に墜落する

ベータ.10以前の問題。以前の Windows ハードウェアモードビルドでは、論理シミュレーターキューごとに 1 つの物理エフェクトという、大規模な保持 DirectInput エフェクトテーブルが作成されました。一部の Sidewinder FFB2 / Windows pid.dll スタックが存在すると、その呼び出しパターンはアクティブな飛行中にクラッシュする可能性があります。 CreateEffect, SetPeriodic, or native ACCESS_VIOLATION パンくずリスト。これは MSFS の問題ではなく、スティックのファームウェアが悪いという兆候でもありません。

窓 MSFS の一時停止または長いスタッターの後、強制が消えます

Beta.11 は特にこのクラスのバグを対象としています。 MSFS ポーズとアクティブポーズは、スティックがニュートラルなデフォルトスプリングを保持している間、ダイナミックエフェクトを即座に抑制するようになりました。再開すると、エフェクトが再生される前に DirectInput スプリングパラメータが再アップロードされるため、ピッチとロールのセンタリングは両方とも回復します。

beta.11 以降で再開した後もロールフォースがまだ存在しないと感じる場合は、サポートバンドルを再現した直後にエクスポートし、その時点でダッシュボードに軸荷重、ベースラインスプリング、またはダイナミックチャネルが表示されたかどうかを説明します。これにより、パイプラインが停止したか、デバイスドライバーが軸を失ったかがわかります。

Beta.10 ではアーキテクチャが修正されています。ハードウェアモードでは、大きな保持テーブルの代わりに 1 つのベクトル定数、1 つの 2 軸スプリング、および小さな遅延周期プールが使用されるようになりました。ベータ 10 以降でもこの問題が発生する場合は、[Doctor] → [ハードウェア互換性] を開き、次のコマンドを実行します。 ハードウェア効果をテストするに切り替えます。 ソフトウェアブレンド定期刊行物 テストが失敗した場合、またはブリッジが次回の起動時にリカバリを提供する場合。残りのドライバースタックの特性を評価できるよう、サポートバンドルもお送りください。

エフェクトは終了後も最大 30 秒間再生され続けます

beta.9以前の問題。 Win11 + FFB2 ドライバーでは、終了時のブリッジのエフェクトごとのクリーンアップは、このスタック上で、エフェクトのファームウェア再生期間全体にわたって各呼び出しをブロックしていました。そのため、飛行中のランブルエフェクトやビュッフェエフェクトは、ブリッジが閉じた後、自然な ~32 秒のタイマーを使い果たし、アプリがスティックを駆動せずにデスクトップ上でスティックが音を立ててアクティブなままになっていました。 beta.9 で修正されました — シャットダウンパスはエフェクトごとの作業を完全にスキップし、すぐに戻る 2 つのデバイスレベルコマンド (すべて停止 + ファームウェアエフェクトテーブルのリセット) を使用するようになりました。同じ修正が、ベクトル化された例外ハンドラーを介したネイティブクラッシュにも適用されます。 beta.9 以降でこの問題が発生した場合は、フィードバックレポートを提出してください。

窓引用をやめるときにクラッシュする `0x80131506`

beta.9以前の問題。一部のインストールでは、ブリッジがクラッシュし、次のような Windows エラー報告ポップアップが表示されます。 coreclr.dll そして例外コード 0x80131506 「終了」をクリックするかウィンドウを閉じた瞬間。根本原因: シャットダウン時に UI スレッドとランタイムの制御ループの両方が同時に DirectInput を呼び出しており、最終的に COM マーシャラーがこれに気づき、プロセスを停止させました。 beta.9 で修正されました。すべての DirectInput アクセスはデバイス境界で単一のロックを通じてシリアル化されるため、2 つのスレッドがマーシャラーと競合することはありません。もしあなたが見ているなら、 0x80131506 beta.9 以降で終了する場合は、フィードバックレポートを提出してください。

起動時にクラッシュする

次回起動のリカバリフロー: 前回の起動がクラッシュした場合、ブリッジは次回起動時にスタックトレースとエラーメッセージを含むクラッシュレポートダイアログを表示します。 フィードバックフォームから送信する ボタン。それをクリックしてください。フォームにはクラッシュログが事前に入力されます。

ダイアログが表示される前にアプリがクラッシュした場合は、クラッシュログファイルが直接必要になります。

窓 %LOCALAPPDATA%\ffb-bridge\crashes\
Linux ~/.local/share/ffb-bridge/crashes/

Attach the most recent .log ファイルをフィードバックレポートに送信します。

「ブリッジが追いつかない」という警告

制御ループレートが低下すると、診断によって警告が表示されます。私たちが見てきた原因:

同じコア上の別のプロセス (ブラウザータブ、コンパイル) が CPU をバーストさせています。
On Linux, a cpufreq ガバナは CPU をクロックダウンしています。に切り替えます performance または schedutil.
ゲストに信頼できる 20 ミリ秒のタイムスライスを与えていない仮想化環境で実行されている。

複数の FFB2 スティックが接続されている

先に見つかったものが勝ちです。ブリッジは最初に一致する VID/PID を取得し、それを駆動します。曖昧さを解消すべき UI がリストにあります。ここでは、必要な接続を除いてすべてを物理的に切断します。

まだ行き詰まっていますか?

サポートバンドルをエクスポートする診断そしてフィードバックレポートを開く。バンドルには、セッションログ、クラッシュログ (存在する場合)、Doctor の出力、およびシステム情報が含まれています。これらはまさに、テストビルドを出荷せずに再現する必要があるものです。