トラブルシューティング
まず症状を確認し、その下にあるものを修正します。ほとんどの場合、 サポートページの [ヘルスチェック] タブはすでに何が問題かを把握しています。このリストを手動で処理する前に、そこを確認してください。ここで何も解決しない場合は、サポート ページからサポートバンドルをエクスポートしてください。 診断 タブと フィードバックレポートを開く.
デバイスの自動起動前チェック
起動時、FFB-Bridge は Windows、Linux、macOS のデバイスバックエンドを静かに確認します。Linux では、対応イベントノードへの読み書きアクセスと、インストール済み udev ルールが現在のすべてのデバイス権限を含むかも確認します。WARN または FAIL があると、各問題を示す非ブロッキングの[確認して修正]バナーが表示されます。
- すべてのチェックに合格した場合は、何も開きません。
- 起動時はシミュレーターやネットワークを検査しません。シミュレーターが閉じている状態は正常で、実行時に扱われます。
- ダイアログが開いている間、Auto-arm は待機します。問題を確認して修正するか、意図的にデバイスを外している場合は閉じます。閉じた後も、ほかの前提条件を満たした場合にのみ Auto-arm が続行します。
Windows 11 SmartScreenまたはSmart App Controlが起動を停止する
Windows インストーラーは Rohsam 発行者 ID によってコード署名されていますが、新品の署名付きファイルは依然として SmartScreen または Smart App Control の評価が低い可能性があります。 Windows に警告が表示された場合は、ファイルの送信元を確認してください。 FFB-Bridge.com、利用可能な場合は公開されたハッシュを確認し、発行者が次のとおりであることを確認します。 Rohsam Inc. または Rohsam Inc.
SmartScreen プロンプトは通常、次のように拡張できます。 詳細情報 発行者を確認した後。一部の Windows 11 システムではスマート アプリ コントロールがより厳格になる可能性があり、評判が改善されるまで新しいビルドがブロックされる場合があります。 Microsoft 独自のガイダンス:
Microsoft: Smart App Control に関するよくある質問
Windows レピュテーション プロンプトではなくウイルス対策検疫が表示された場合は、フラグが設定されたサンプルの詳細を電子メールで次の宛先に送信してください。 supportffb-bridge.com それで調査できます。
スティックが全く動かない
アームされていますか?
コックピット上部のストリップにある ARM ゲージは次の値を読み取る必要があります。 アーム済み (琥珀色のグラデーション)。読めば アーム解除 (灰色のグリフ、暖かい境界線)、クリックして確認します。読めば フォルト (赤)、以下の「スティックは動作していましたが、突然停止しました」を参照してください。前提条件が低下しました。
デバイスは検出されていますか?
中央の Arm ボタンの下にあるデバイスまたは準備状況のメッセージを確認し、次に Hardware → Device を確認してください。目的のデバイスを使用できない場合は、次を確認してください:
- スティックを抜き差しし直します。ブリッジは 1 ~ 2 秒以内に再検出します。
- 現在のID: SideWinder FFB2 045e:001b; Logitech G940 046d:c287 および Windows 別名 046d:c2a8; Force 3D Pro 046d:c286; WingMan Force 3D 046d:c283; MOZA AB9 346e:1000; AB6 346e:1002; AY210 346e:1001; Brunner FFB-G 25bb:00d2 および 25bb:0120、DirectXモードのCLS MZ 25bb:0121(Brunnerはグリップごとに別の製品IDを割り当てます;未登録のグリップIDを報告すると追加されます);PicoWinder cafe:4004; Adapt-FFB-Joy 03eb:204e.
- Linux 古いルールは、MOZAのTTYラインやLogitech G940フォースプロトコルパスが必要とする書き込み可能なhidrawアクセスなど、現在のデバイス許可がない場合にWARNとして報告されます。ファイルが既に存在していてもFixを使用してください。アプリはそれを完全な生成ルールで置き換えます。 修正に成功するとルールは有効になり、アプリは再起動を勧めます。[今すぐ再起動]は新しい権限でジョイスティックを開き直し、起動時のフォールバックを解除します。先に続行する必要がある場合は[後で再起動]でも安全です。
- Windows フォースフィードバックを主張する他のアプリをすべて閉じます。DIY テスター、一部のジョイスティック診断ユーティリティは排他的アクセスを保持します。
SIMは接続されていますか?
フライトを読み込んだ後、上部バーの SIM と機体名を確認してください。シミュレーターが接続されていない場合は、次をご覧ください: MSFS セットアップ ガイド または X-Planeセットアップガイド あなたのシムのために。その間、 Mock Sim このページでは、パイプラインの残りの部分が動作していることを確認できます。
MSFS は接続しますが、どの力も適切ではないと感じます
スティックは動いているが力が間違っていると感じる場合、問題は通常、プロファイルまたは機体の不一致です。
- お使いの航空機に最も近い内蔵スターターから始めます:セスナ 172 スカイホーク (G1000)、ダーハー TBM 930、ビーチクラフト キング エア 350i、エアバス A320neo、またはボーイング 747-8 インターコンチネンタル。ほとんどの「間違った」感覚は、異なる航空機クラスに合わせて調整されたプロファイルから生じます。
- Check the 制御系の感触 は、ページレベルの Control system カード内、Advanced controls スイッチのすぐ後にあります。大型ジェット機を マニュアル、または軽 GA 航空機に設定 フライ・バイ・ワイヤ、他の点ではゲインが良好であっても違和感が出ます。航空機(手動、油圧ブースト、またはフライ・バイ・ワイヤ)に合わせてください。
- ダッシュボードのスティック アクティビティ パネルを確認します。これにより、ベースライン スプリングが、軸荷重、エンジン振動、地上ロール、乱流、機械的ワンショットなどの動的チャネルから分離されます。予期しなかったエフェクトがアクティブであると表示される場合、シムはそれらを引き起こしているテレメトリを報告しています。
- サードパーティ製の航空機は、標準の SimVar の実装をスキップする場合があります。ブリッジはこれを許容します (欠落した変数はデフォルトでゼロになります) が、結果として一部のエフェクトは起動に失敗します。これは、ブリッジ内で簡単に回避できない既知の制限です。特徴を明らかにできるように、特定の航空機を報告してください。
トレイアイコンが表示されない(Linux)
一部のデスクトップ環境には、システム トレイ ホストが標準で付属していません。GNOME Wayland がその代表的な環境です。ブリッジがこれを検出すると、ウィンドウの上部にバナーを表示して、閉じるとアプリが (静かに隠れるのではなく) 直接終了することを説明し、閉じるボタンもそれに応じて動作します。 GNOME では、AppIndicator Support 拡張機能をインストールしてトレイ アイコンを取り戻します。 KDE、Xfce、Cinnamon、MATE、および Budgie では、トレイはそのまま使用できます。
ヘルスチェックで SimConnect には到達できるがデータが流れないと表示される
FFB-Bridge は接続しています (TCP hello は受け入れられます) が、データ ストリームが開始されていません。 MSFS 2024 では、これは通常、内部 SimConnect サーバーがまだ起動しているため、SimVar サブスクリプションが失敗していることを意味します。 MSFS がイントロ画面の後、メイン メニューに到達するまで待ってから、再試行してください。
X-Plane は検出されましたが、データ フローがありません
X-Plane が一時的に表示された後に「no sim running」に戻る場合は、Health checks を実行し、Diagnostics のログを確認してください。Bridge には、新しく有効な飛行データが必要です。機体名だけの応答では、実行中のフライトを確認できません。次の点を確認してください:
- ファイアウォールは有効なまま、X-Plane と FFB-Bridge のローカル通信を許可してください。
- ブリッジ プロセスで送信方向の UDP 49000 をホワイトリストに登録します。
Windows 準備完了または離陸直後に墜落する
以前の Windows ハードウェア モード ビルドでは、論理シミュレーター キューごとに 1 つの物理エフェクトという、大規模な保持 DirectInput エフェクト テーブルが作成されました。一部の Sidewinder FFB2 / Windows
pid.dll スタックが存在すると、その呼び出しパターンはアクティブな飛行中にクラッシュする可能性があります。 CreateEffect,
SetPeriodic、またはネイティブ ACCESS_VIOLATION
パンくずリスト。これは MSFS の問題ではなく、スティックのファームウェアが悪いという兆候でもありません。
Windows MSFS の一時停止または長いスタッターの後にフォースが消える
現在のビルドは特にこのクラスのバグを対象としています。 MSFS ポーズとアクティブ ポーズは、スティックがニュートラルなデフォルト スプリングを保持している間、ダイナミック エフェクトを即座に抑制するようになりました。再開すると、エフェクトが再生される前にスプリング パラメータが再アップロードされるため、ピッチとロールのセンタリングが両方とも回復します。
現在のビルドで再開した後もロールフォースが感じられない場合は、再現した直後にサポートバンドルをエクスポートし、その時点でダッシュボードに軸荷重、ベースラインスプリング、ダイナミックチャンネルのいずれかが表示されていたかを説明してください。これにより、パイプラインが停止したのか、デバイスドライバーが軸を失ったのかが分かります。
再接続後にフォース出力の一部が欠ける場合は、アームを解除して Diagnostics を確認し、Hardware → Effects にハードウェアエフェクトの確認機能が表示される場合は実行してください。利用できるレンダラーと復旧方法は、正確なデバイスによって異なります。互換性設定を変更する前にサポートバンドルをエクスポートし、その後、次を実行してください: ハードウェア効果をテストするに切り替えます。 ソフトウェアブレンドのペリオディクス テストが失敗した場合、またはブリッジが次回の起動時にリカバリを提供する場合。残りのドライバー スタックの特性を評価できるよう、サポート バンドルもお送りください。
Linux [武装解除]および arm の再設定後は力がありません。
[1.4.1では、同じLinuxセッションで2回目のアームがすべてのデバイスで失敗しました。アプリは解除時にforce feedbackの効果スロットを解放せず、カーネルのデバイスごとのプールが切れ、その後のarmはアプリ再起動されるまで失敗しました。1.4.2はこれを修正します。オペレーターが1.4.1にいる場合は、回避策としてアプリを更新または再起動します。[1.4.2はまた、次の起動時にクリーンクイットがクラッシュとして報告されるのを防ぎます。
別の force feedback プログラムが実行中の間、力は失われます。
例えば、SteamVR のようないくつかのプログラムは、起動時に見つけたすべての force feedback デバイスをリセットし、FFB-Bridge がロードしたエフェクトを消去します。1.4.2 以降、ブリッジはアーム中に 1 秒ごとにデバイス上でエフェクトがまだ存在するかを確認し、他のプログラムによってリセットされた場合には自動的に再構築するため、フォースは自動的に戻ります。デバイスが繰り返しリセットされる場合、再構築のリトライには制限があり、何が起こったのかを説明するメッセージとともにラッチします。競合しているプログラムを閉じてから、再度ディスアームして arm してください。
エフェクトは終了後も最大 30 秒間再生され続けます
以前の Win11 + FFB2 ドライバーの問題です。このスタックでは、終了時のブリッジのエフェクトごとのクリーンアップが、エフェクトのファームウェア再生時間の全体にわたって各呼び出しをブロックしていました。そのため、飛行中のランブルやバフェットのエフェクトは、ブリッジが閉じた後も自然な約 32 秒のタイマーを使い切るまで続き、スティックを駆動するアプリがないのにデスクトップ上でスティックが音を立ててアクティブなままになっていました。現在のビルドでは、シャットダウン時にエフェクトごとの処理を完全にスキップし、すぐに戻る 2 つのデバイスレベルのコマンド(全停止 + ファームウェアエフェクトテーブルのリセット)を使用します。ネイティブクラッシュ時にも Vectored Exception Handler を介して同じ修正が適用されます。現在のビルドでこの症状が出る場合は、フィードバックレポートをお寄せください。
Windows 引用をやめるときにクラッシュする 0x80131506
前号。一部のインストールでは、ブリッジがクラッシュし、次のような Windows エラー報告ポップアップが表示されます。
coreclr.dll そして例外コード
0x80131506 [終了]をクリックするかウィンドウを閉じた瞬間。根本原因: シャットダウン時に UI スレッドとランタイムの制御ループの両方が同時に DirectInput を呼び出しており、最終的に COM マーシャラーがこれに気づき、プロセスを停止させました。現在のビルドでは、すべての DirectInput アクセスがデバイス境界で単一のロックを介してシリアル化されるため、2 つのスレッドがマーシャラーと競合することはありません。もしあなたが見ているなら、 0x80131506 現在のビルドを終了する場合は、フィードバック レポートを提出してください。
起動時にクラッシュする
次回起動のリカバリ フロー: 前回の起動がクラッシュした場合、ブリッジは次回起動時にスタック トレースとエラー メッセージを含むクラッシュ レポート ダイアログを表示します。 フィードバックフォームから送信する ボタン。それをクリックしてください。フォームにはクラッシュ ログが事前に入力されます。
ダイアログが表示される前にアプリがクラッシュした場合は、クラッシュ ログ ファイルが直接必要になります。
- Windows
%LOCALAPPDATA%\ffb-bridge\crashes\ - Linux
~/.local/share/ffb-bridge/crashes/
最新のものを添付してください .log ファイルをフィードバック レポートに送信します。
「ブリッジが追いつかない」という警告
[診断] タブでは、制御ループ レートが低下すると警告が表示されます。私たちが見てきた原因:
- 同じコア上の別のプロセス (ブラウザー タブ、コンパイル) が CPU をバーストさせています。
- Linux では、
cpufreqガバナは CPU をクロックダウンしています。に切り替えますperformanceまたはschedutil. - ゲストに信頼できる 20 ミリ秒のタイム スライスを与えていない仮想化環境で実行されている。
複数のサポートされているスティックが接続されています
サポートされているスティックが複数接続されている場合、デバイス ピッカーでブリッジが駆動するスティックを選択でき、その選択は再起動後も記憶されます。から再開します ハードウェア — 。選択したデバイスを変更するには再起動が必要です。
私の force feedback スティックはサポートされているものではありません。
一覧にないジョイスティック系デバイスは、控えめな既定値 20% で使用する実験的なオプトイン機能です。ステアリングホイール、ゲームパッド、単軸デバイスは対象外です。未対応ハードウェアの特性確認には FFB Probe を使用します。
ffb-probe.com 代わりに。
まだ行き詰まっていますか?
サポート ページのサポート バンドルをエクスポートします。 診断 タブと フィードバックレポートを開く。バンドルには、セッション ログ、クラッシュ ログ (存在する場合)、最後のヘルスチェック出力、およびシステム情報が含まれています。これらはまさに、テスト ビルドを出荷せずに再現する必要があるものです。
Aircraft Library で読み込み中の機体が見つからない場合
Aircraft Library で一般的な機体名や ICAO コードを検索し、正しい機体ファミリーとシミュレーター用エディションを選んでください。機体が登録されていても、未知のアドオン名では自動照合できない場合があります。接続やアクセスのエラーは「見つからない」とは別の状態です。取得済みの資料はオフラインでも利用できる場合があります。資料ビューアーは有効なフォースプロファイルを変更しません。