見どころ {#highlights}
デバイス範囲の設定の書き込みは、書き込みを実行したクライアントセッションだけでなく、そのデバイスを所有するすべてのクライアントセッションに同期されるようになりました。2つ目の閲覧端末は、もはやポーリングを行わず、代わりに自身の セッション更新済み イベントの更新——このデバイスを保持している各セッションは、ちょうど1つのイベントを受信し、書き込み元が2つのイベントを受信することは決してありません。
これで、セッション内で設定された設置方法ではなく、デバイスの実際の設置場所をクライアントに報告できるようになりました。現在表示されているインストール位置の種類を示すラベルは、設計上、正確性が保証されており、すべての出力形式に対応しています。
当該デバイスがメンテナンス用の設定値を独自に更新する場合、サーバー側はその変更に追従します。これまでは、サーバー側はデバイスの起動時に取得した値を返しており、その後再確認されることはありませんでした。現在、サーバー側はクライアント側のレンダリングのペースに合わせて必要に応じてこの参照値を更新し、サーバー側でレート制限を行うことで、高頻度で更新を行うクライアントによってデバイスの通信回線が占有されるのを防ぎ、また、設置方向が実際に回転した後にのみ変更を通知するようにしています。
内部の改善 {#internal-improvements}
実験的なグリップのヨー漂流の自動補正。新たに追加されたサービスモジュールは、Wireless VerseGripの慣性によるヨードリフトに対して閉ループ補正を行います。このモジュールは、グリップの絶対ヨー角と、ペアリングされたInverse3 またはMinverseの動作を適合させます。一連の品質閾値がすべて満たされると、グリップのファームウェアに補正値が一度書き込まれます。この機能はデフォルトで無効になっており、実験的な有効化スイッチがオンになっている場合にのみ利用可能です。また、実行時のスイッチが用意されており、これを切り替えることで、オンライン中のすべてのグリップに対してこの機能を即座に無効化できます。これは、デバイスのファームウェアに書き込みを行う機能にとって不可欠な措置です。すべてのデバイスに対する設定の書き込みは、現在「すべて適用」または「すべて適用しない」のいずれかとなるよう変更されました。いずれかのデバイスを変更する前に、システムは選択範囲全体（ファームウェアの機能やデバイスの準備状況を含む）を検証するため、ファームウェアのバージョンが異なるデバイス群であっても、2台目のデバイスでエラーが発生したために「半切り替え状態」にとどまることはなくなりました。ハンドルのファームウェアによる確認信号は、現在、リクエストごとに個別に追跡されるようになりました。以前は、すべてのリクエストが1つの結果スロットを共有していたため、2つの並行するリクエストが互いの応答を上書きしてしまう可能性がありました。また、同じ曖昧な値が「拒否された」と「結果なし」の両方を同時に表していたため、これにより、拒否が再試行が必要であると誤って判断され、再試行の連鎖を引き起こす可能性がありました。現在は各リクエストに固有のトークンが付与されており、実際に送信されなかったリクエストは記録に残らず、失われた応答は失敗としてマークされ、システムがハングアップする原因にはなりません。この処理を行うクリーンアッププログラムは、処理待ちのリクエストがない場合、一切のオーバーヘッドを発生させません。Inkwellのドックによるキャリブレーションは、新しいグリップのファームウェアにおける機能チェックの影響を受けません。ペンをドックにセットすると、完全な姿勢の再キャリブレーションが実行されます。これは、ファームウェアのバージョンに関係なく、出荷済みのすべてのペンにおいて正しく機能します。この処理は、計算によって導き出される航法補正のために導入された機能の下限から明確に除外されており、その除外条件は推論によるものではなく、呼び出し箇所に明記されています。修正 {#fixes}
重力補正のリセットにより、過度な補正ではなく、本来のデフォルト値に戻せるようになりました。 その名称にもかかわらず、config/重力補正 上の スケーリング係数 「フィールド」は乗数ではありません。これは、装置が自身の重量に加えて、末端アクチュエータの負荷質量（単位：kg）を補正する値です。以前のリセットでは、この名称を文字通りに解釈し、係数を「中性」の状態に戻していました。 1――つまり、架空の1キログラムの荷重――であるため、リセット後、デバイスはジョイスティックを上方向に押し上げるが、これは新しく接続されたデバイスの挙動ではない。現在、リセットを行うと、本来のデフォルト値が復元される：補正が有効になっており、かつ スケーリング係数 「為」 0，これは、デバイスが自身の重量のみを支え、いかなる負荷も想定していないことを意味します。これまでリセットを利用して補償強度を高めていた場合は、必要な値を明示的に設定するように変更してください。リセット・リセット機能は、これで確実に再有効化されるようになりました。 それ以前、～に対して config/home_return リセットを行うと、リセット機能が無効化される一方で、呼び出し元にはその機能が有効になっていると通知されます。現在、リセットを行うと、工場出荷時のデフォルト値（有効）に確実に復元され、その後アプリケーションが読み取る値は、デバイスが実際に使用している値となります。デバイス範囲のインストール方法や向きに関する書き込みによって、他のクライアントのデータが古くなることはなくなりました。バージョン 3.5.6 以前では、デバイス自体（そのデバイスを保持するすべてのセッションで共有される）への書き込みが行われた場合、書き込みを実行したクライアントの設定のみが更新され、デバイス範囲のルーティングについてはどのクライアントの設定も更新されませんでした。同じデバイス上の他のクライアントは、自らポーリングを行うまで、常に古い値が表示されたままでした。現在では、そのデバイスを保持するすべてのセッションに通知が届くようになりました。Inkwellのベースにおける再ドッキングの試行は、1回の拒否後に放棄されることはなくなりました。前回のドッキングの状態は複数のドッキング試行の間も保持されるため、2回目のドッキングでは、最初の拒否が再試行ウィンドウの終了とみなされます。現在、ドッキングの試行が行われるたびに再試行ウィンドウがリセットされます。Wireless VerseGrip デバイスのティック周期におけるデータ競合を修正しました。接続スレッド内でデバイス識別子が再割り当てされる可能性がある一方で、ある一時パスでは別のロックを使用してその識別子を読み取っている場合がありました。現在では、この識別子は適切なロックで保護された状態で一度だけスナップショットが取得され、下流の各パス（拒否ケースを含む）はすべてこのコピーに基づいて処理されるようになりました。4つのWireless VerseGrip送信側における、同期されていないメッセージのバッファリングに関する問題を修正しました。これら4つの送信メッセージパスでは、ペイロードとチェックサムの組み立ておよび送信要求の際、いずれも書き込みロックを取得していなかったため、2つの送信側間で共有バッファの競合が発生する可能性がありました。潜在的な互換性破綻 {#potential-breaking-changes}
API、通信プロトコル、設定のいずれも変更されていません。デフォルトの出力はバージョン 3.5.5 とバイト単位で一致しており、ルーティングパスが削除または変更された箇所はなく、公開 C API にも差異はありません。また、設定キーの名称変更、削除、または新しいデフォルト値の割り当ても行われていません。SDK プレビュー版または実験的インターフェースを有効にしているアプリケーションについては、本サイクル中に移行作業を完了する必要があります。これには、スイッチレベルの変更 1 件と、削除されたトークンセットが含まれます。各変更内容は、プロジェクトに付属する更新ログに記録されています。重力補正のリセット時に返される値は、バージョン 3.5.5 とは異なります。 フィールド、ルーティング、レスポンス構造のいずれも変更されていませんが、依存関係のリセットにより、 スケーリング係数 「写」と表記する 1 このアプリケーションでは、現在、工場出荷時のデフォルト値が設定されます 0——補償機能自体は、いかなる場合でも有効なままとなります。リセットに依存せず、この値を明示的に設定してください。上記の修正手順を参照してください。リセット後、リセット機能は「無効」ではなく「有効」のまま維持されるようになりました。フィールド、ルーティング、レスポンス構造に変更はありませんが、リセットによってリセット機能を無効にしていたアプリケーションでは、この機能が有効になっていることが確認されるようになります。無効にするには、リセット後に明示的に「無効」に設定してください。詳細は上記の修正説明を参照してください。クライアントには追加の設定イベントが送信されます。 当初の想定では セッション更新済み 以前は、イベントはそれ自体が書き込まれたアプリケーションにのみ到達していましたが、現在は、別のクライアントが両者が共有するデバイスを変更した場合にも、そのイベントを受信するようになり、その後、完全な構成のレンダリングも受信するようになりました。これは前述のファンアウトメカニズムによる予期された結果であり、イベントの到達後にのみ再読み込みを行うクライアントについては、何の変更も必要ありません。
