ロキナ

『Lightning Stinger』をどうぞよろしく #event_bof #BOF21 manbow.nothing.sh/event/event.cg…

この方法、ランダム分岐があるBMSだと破綻するという致命的な欠点があるのでダメです

案 github.com/Kuroki-Narumi/…

これはそもそも「譜面の同一性」の定義が人によって変わり得ることが一番問題かもしれない。極端な話、BGMやBGAのノートは「演奏には影響しない」し、そもそも各ノートの定義番号も「譜面(ノート配置)だけを見る」なら関係ない

しばらく考えてたけど、レベル詐称とか作者名の書き間違いとかを修正したいケースを思うと、やはり特定のヘッダーのみハッシュ関数に突っ込む形のほうが理想的ではあるな

あとgithubだとツイッター上で全然関係ないサムネになっちゃうからnoteとかにしようかな

採用するヘッダーを別で定義(引数として渡す)する場合、もはやハッシュ値は統一されない。そういう色々な「最悪の場合」を考慮して、先の案はあくまで「最小構成」にした。 この一連のツイットを書いていて思ったことがあるので、案を更新しておこう。

2.について、これが一番の理由で、「演奏に関係ないヘッダー」を排除する場合文字列マッチで条件分岐しなければならない。 処理負荷自体は問題ではないが、採用するヘッダーをハードコーディングすると、今後演奏に影響するヘッダーが追加される度に、ハッシュプログラムを更新しなければならない。

BMSのハッシュ化においてメタコマンドをそもそも全部無視しちゃえばという話だが、先の案でヘッダーを全て巻き込んでいるのには2つ理由があって、 1. 理論上「譜面と定義番号が全て一致するが内容は異な楽曲」が存在しうるため 2. なるべく前処理を少なくするため (続く)

@lokina K-Shoot MANIAのIRだと、譜面からメタ情報の行を取り除いてからハッシュ化していますね これであればメタ情報の行の順序だけでなくレベル変更なども吸収できるかなと思います mz-kb.com/blog/2019/12/1…

@lokina 外から失礼します。 一応beatorajaに類似のものとしてchartHashという譜面内容のみのsha256ハッシュがあります（タイトルやWAV定義など一切のメタデータを含まない） 記録だけされて活用されていなさそうですが…… #L505-L561" target="_blank" rel="nofollow noopener">github.com/exch-bms2/jbms…

@hyrorre 普通にjsonオブジェクトとして読み込んで、プロパティの順番をソートした上でjson文字列に戻してハッシュ化、って感じになりますかね？　そもそもbmsonって現状BMSONE以外で作成されることがあるのでしょうか(エディタが1種類しかないなら表記揺れの心配はない)

@lokina bmsonの場合はどうなるんでしょう

複数の本体が乱立するとハッシュ関数が独自実装になって散る恐れがあるので、できれば規格化しちゃいたいですね(俺がやっても見てもらえなさそう)

なんか反応見てると思ったよりBMSプレイヤー本体を作ろうとしてる人が多いみたいなので、各位これを意識してもらえると助かります。

@sack_magiclight IR自体にはBMSデータそのものではなくハッシュ値を送信することになるので、そうなりますね

@lokina IR側じゃなくてBMSパーサー側で対応するべきっすねこれ

コメントや空行を全て無視して、全てのコマンドを一貫した順序で並び替えて、そうして加工された新たなデータに対してハッシュ関数を適用するのが、理想的な対策だろう。そのための追加のメモリと倍近い時間を要するが……

新しくIRシステムや本体を作る人はどうか一考を……

BMSのidentifyにMD5ハッシュを使うの、自然な発想ではあるんだけど、実質を変えない変更(例: TITLEとARTISTの位置を入れ替える)でも全く異なる譜面として扱われてしまう問題はどうにかするべきだと思う

正解でいいか

どうしてこうなったですよね