フリーズアローの判定処理を修正

[goe0]

🔨 変更内容 / Details of Changes

• フリーズの終点と次のフリーズの始点が近いとき、キーを押しても次のフリーズが判定されないことがあるバグを修正

🔖 関連Issue, 変更理由 / Related Issues, Reason for Changes

フリーズAの終点と次のフリーズBの始点が近いとき、
Aを見逃しイクナイで判定するとBの始点でキーを押しても反応しないというバグが報告される #1529
（途中離しイクナイなら反応し、早押しイクナイは実質的に見逃しイクナイと同等の処理になるので反応しない）

↓

#1530 にて修正される

↓

Speedの速さなどにより、Bが作成済みか否かで現象が分岐するようになる

1. Bが作成済みのとき、Aが削除されるので反応する
2. Bが未作成のとき、Aが削除されないので反応しない
   おそらく1の条件のみをチェックしたのでプルリクが取り込まれてしまった

↓

Aを削除するのではなく、judgeArrow にて判定を次のフリーズに移すことで対応しました

📷 スクリーンショット / Screenshot

📝 その他コメント / Other Comments

[cwtickle]

PRありがとうございます。
確かにその方がわかりやすいかもしれませんね。

なお変更したコードにある「g_workObj.judgFrzCnt[_j]」ですが、
矢印・フリーズアローのオブジェクトを削除したときにカウントアップしています。

発生頻度はあまりないと思いますが、判定時と消去時で時間差ができるので

if (currentFrz?.judgEndFlg) {

の部分はwhileに変えておいた方が良いのかもしれません。（要検証）

PRで変更頂いたソースは試験的に下記サイトで動作確認できるようにしました。
https://danonicw.skr.jp/?v=v35.4.2-a1

[cwtickle]

上記サイトで検証してみました。
下記のデータで試したところ、このPRで修正したスクリプトにて、途中で止まることを確認しました。
（フリーズアローが３つあり、真ん中が極端に短いパターン）
Speed＝5.5xです。動作がわかるようにあえてステップゾーン位置をずらした状態で確認しています。

|stepY=120|
|frzDown_data=200,235,237,240,243,270|

[cwtickle]

stepY=70（デフォルト）でも再現したので、コードの見直しが要ると思います。
ちなみに上で言っていたif -> whileにしても変わらなかったので、別原因かと。

[codeclimate]

Code Climate has analyzed commit 24fe542 and detected 0 issues on this pull request.

View more on Code Climate.

[goe0]

ご確認ありがとうございます。
再度調査したところ元々は #1376 の修正が原因だったようです。
強制削除は行うが判定は重複しないように条件を修正しました。

自環境でテストし #1376 および #1530 双方の問題が解決していることを確認しましたが、
このあたり処理が複雑なのでまた別のバグが発生している可能性もあります。

[cwtickle]

ありがとうございます。
先ほどの問題は解消していることを確認しました。
念のため、Discordの方で確認して問題なければマージするようにしますね。