1 にて @katabame さんに表示上のマスク処理を追加して頂きました。

根本の解決には人数制限解除のようなロールフリー申請を判別できるようにする必要がある。

qitana commented 4 years ago

ロールフリーパーティ構成中の際には、dps, dpsMax の後の2バイトでロールフリー人数と最大人数が入っているが、通常マッチングの際にはこのフィールドに不定の値が入ることがあるのでなにか判断基準が必要。

katabame commented 4 years ago

developブランチの変更をまだ手元でビルド/適用していないので不定の値の例が確認できておらず申し訳ないですが、 dps, dpsMaxの後ろ2バイトをパース試行して正しくパース出来るかどうか/24人を閾値として不正な値にならないかどうかで判断することはできませんか？

qitana commented 4 years ago

このissueに関しての修正はdevelopにまだ入れてません。確認用のツールをアップデートしただけです。 (すみません、一度入れたのですが、値が定まらなかったので戻している状態です)

本題ですが、現時点で観測している不定な値はすべて24を超えているので、 24人を閾値とすることで対応は出来るとは思いますので、その方向で対応してみます。

懸念としては、仮に不定な値として24以下の数字が入った場合には、判断が難しくなってしまいます。

qitana commented 4 years ago

明日はパッチなので、おそらくOpcodeの変更が入ると思われますので、その後の対応となると思いますが、ご了承下さい。

katabame commented 4 years ago

14側パッチ後の対応とのこと、了解しました。

通常パーティーの場合とオーバーレイの表示差異をなるべく少なくするために、新たにロールフリーパーティのステータスを用意してロールフリー人数と最大人数をオーバーレイ側に渡すことは可能ですか？

また、不定な値が24以下になる場合ですが

もしくは

あたりの対処で特に問題にはならないかなとは思いますが、如何でしょうか

qitana commented 4 years ago

ロールフリー人数と最大人数をオーバーレイ側に渡す

現在はこの方針で考えています。NonRole/NonRoleMax を追加しデータを取得後、最低限の処理(24を超えていたら0に置き換える等)を入れています。

直近N回のステータスと異なる場合無視 Matchedになった瞬間の状態で固定し、Cancelledになるまで維持

EventSource (C#)側では、受信したネットワークデータに応じた処理を実施するのみとしていて、
状態の保持を行わないよう設計しています。したがって、状態を保持するとしたら JavaScript 側での実装です。

また、おっしゃるとおり、Matched になった瞬間にロールフリーかどうかを判断する方法がわかればベストなので、その方法を調査しています。目星は付いているのですが、まだ試行数が少ないので調査中の段階です。

qitana commented 4 years ago

Matched にロールフリーかどうかを判断できそうなデータを見つけたので、この値を元に表示を切り替えるようにしました。しばらくdevelopでチェックし、問題なければmasterにマージする予定です。

qitana commented 4 years ago

html/js の互換性の確認が取れたので、master にマージし Pre-Release にしました。 v2.2.0 で表示を見てもらって、問題なさそうであれば Release します。

katabame commented 4 years ago

制限解除だけですが昨日のうちに動作確認できました通常CFは今日明日あたりに確認してみます🙌

5 あたりがSolveされてからRelease切るかと思うので、それまでに動作確認とオーバーレイの調整してPR出すかと思います

katabame commented 4 years ago

通常CFも試してみて特に問題は無さそうでしたオーバーレイは位置固定との都合上、現状のままの方が良さそうですのでReleaseして大丈夫だと思います！

qitana commented 4 years ago

ありがとうございます。