FF11 フリーサーバー Valhalla 日本語WIKI

PacketFlowは、2022年5月にByrth氏が公開したデータ転送の基本的な問題を改善するプラグインです。ディフォルト設定ではインスタンスエリアのみとなっていますが、すべてのエリアで有効化することも可能です。2023年11月現在検証中ですが、もし何か問題が発生したら報告します。実際にエリチェンしてテストしてみましたが、PacketFlowがない状態で17.59秒かかっていたエリチェンが導入後は12秒で完了しました。

アップデート(2024/3/7)： 4か月動かしてきましたが、特に問題ないようです。


インストール方法

1. Windower4を起動してPluginsタブをクリック
2. コナミコマンドを叩く (↑↑↓↓←→←→BA)
3. PacketFlowが表示されるので有効にする

設定

• ログイン中であれば、ゲーム画面で/reload packetflowコマンドを実行
• ..\Windower4\plugins\settings\packetflow.xmlというファイルが作られるので、<instanceOnly>をfalseに変更
• もう一度/reload packetflowコマンドで変更を有効にする

<settings>
    <global>
        <instancesOnly>false</instancesOnly>
    </global>
</settings>

https://www.ffxiah.com/forum/topic/56713/packetflo...
※ChatGPTの翻訳結果に修正を入れています。


お知らせ
AshitaとWindowerの両方に対して、PacketFlowを導入しました！

数年にわたり、プレイヤーはインスタンスでのメッセージの欠落を引き起こすラグに悩まされてきました。実際には、このラグは2つの問題に集約されます。

1. インスタンス内でのチャンクの優先順位が正しくない。
2. インスタンスは多くのチャンクを生成する。

PacketFlowは2番目の問題に対処しようと試みています。

FFXIネットワークのダイナミクスと用語の簡単な概要については、以下の解説を読むことをお勧めします：


優先順位付け
非インスタンスゾーンでは、SEはクライアントがより重要なチャンクを受け取るように優先順位付きシステムを使用しているようです。たとえば、コロロカのモンスターを一度に引き寄せ、自分自身にファランクスをかけた場合、常に「ファランクスの効果を得た」というメッセージが表示されます。一般的に、キャラクターに関する情報を含むチャンクは、より文脈に関連するチャンク（モンスターの移動など）よりも優先されます。ほとんどの場合、この優先順位付けシステムは問題になりません、なぜならFFXIは2.5KB未満のデータしか送信しないため、すべてがUDPパケットに収まるからです。しかし、非常にアクティブな環境にいて、2.5KBを超えるデータが送信される場合があると、この問題が発生します。

複数のモンスターを引っ張ると、この問題が発生することがあります。5匹のモンスターが追いかけてきた場合、通常はかなり適切に移動します。しかし、20匹が追いかけてきた場合、一部のモンスターは位置を移動することがあります。なぜなら、これらのモンスターの位置を更新するチャンクは優先順位が低く、パケットに収まらないからです。しかし、20匹が追いかけてきても、彼らの攻撃に関するメッセージは一般的に含まれています(チャットログに表示されます)。この優先順位付きシステムにより、FFXIはかなり低い帯域幅要件で済ませることができ、ほとんどの人々が実際にそれについて考えたことがないという事実は、それがかなりうまく機能していることを示しています。

しかし、インスタンス内では、優先順位付きシステムは最善の場合には機能せず、最悪の場合には通常のゾーンとは逆の方法で機能しているようです。デュナミス(D)のインスタンス (バフの獲得、アクションの完了など)については、通常のデュナミスエリアでは決して見逃さないメッセージが頻繁に欠落します。これはすべてサーバーサイドの問題ですので、パケットの優先順位付きシステムの詳細やインスタンスでの問題がどのようにおかしくなっているのかについては推測するしかありませんが、明らかに設計された方法とは異なる方法で機能していません。

どういった解決策が考えられるか？

1. 送信されるチャンクの数を最小限に抑える：一度に1匹のモンスターと戦う、パーティのバフ情報をオフにする、GearSwapを使用しないなど。FFXIに送信されるチャンクの数を減らすことは、パケットが満杯にならない限り優先順位付けが問題になることはありません。
2. サーバー → クライアントの帯域幅を増やす

オプション1は不便で制約が多いため、オプション2が興味深いものです。
帯域幅はほぼ最大パケットサイズ×周波数です。FFXIのサーバー → クライアント接続では、通常は（2.5KB / 1パケット）×（1パケット / 0.4秒）= 6.25KB/sです。これらのパラメータを直接変更することはできないので、サーバーは送信されたUDPパケットに別のUDPパケットで応答することに気づきました。したがって、送信されるUDPパケットの頻度を調整することで、間接的に受信するUDPパケットの頻度を制御できます。このアイデアは、FFXIクライアントをより頻繁にUDPパケットを送信するようにトリガーする方法がわからなかったため、ほとんどの場合は何も変わりませんでした。

KnugenJulianがオデシーのラグの修正策を求める投稿をWindower Discordにしたとき、私は純粋に理論的な修正を持ち出し、Thornyがatom0sのUDPパケットハンドラのリバースエンジニアリングと結びつけて実現させました。

かくして、AshitaとWindowerの両方にPacketflowという名前のプラグインが開発され、パケットごとの時間を400msから250msに短縮し、帯域幅を効果的に60％増加させました。これにより、インスタンスでのチャンクのドロップの問題は完全に解決されるわけではありませんが、確実に改善します。さらに、ロードゾーンの読み込みがかなり高速になります。



理論は機能し、安全でしょうか？
これは大きな懸念事項です。すべてのサードパーティツールと同様に、このプラグインを使用するとアカウントが危険にさらされます。Packetflowは一目瞭然に検出でき、FFXIに対する送信帯域幅コストを増加させます。したがって、WindowerではランチャーのKonamiコードセクションにあります。

このプラグインはほぼ4月中旬に完成し、私はそれ以来メインと倉庫キャラでWindowerのプラグインを約1か月間24/7使用していますが、まだ垢バンされていません。それ以上のテスト方法はなく、これまでに行われたテストのすべてです。

これらの問題についてSEに連絡を取り、提案された解決策の状況を確認しようと試みてきました。
2016年AMA - 帯域幅 - 基本的に「修正が難しすぎる」
2022年AMA - 優先順位付け
2022年AMA - 帯域幅
SEがこれらの質問に答える2022年AMAフォーラムのフォローアップを1週間待ちましたが、何の進展もありませんでした。


Special Thanks to
Thorny - 実装と経験的なテスト
atom0s - これを実現するためのリバースエンジニアリング
KnugenJulian - コンセプトを再活性化させた会話を開始したことに対して