RumiCar シミュレータ v8.4.0 を公開しました。リリースノートは GitHub でも読めます。
v8.4.0
コース・領域・車体スケールを切り替えたとき (と ▶/🏁 の直前) の「車が収まるか」の判定を速くしました (Stage BA・走行と配置の答えは 1 ビットも変わりません)。この判定には以前から 1 回が重い組み合わせがありました (v8.3.0 で判定の中身を単独で測れるようにして初めて数字が出ました。出荷 66 コース × 3 領域 × 6 段階の車体スケール = 1,188 通りで、最悪は約 4.5 秒)。推測で直さず、先に内訳を測りました — 最悪の組み合わせでは「6 台置けるか」の評価を 27 回行っており、時間の大半がスタートから廊下伝いに置き場所を探す処理でした。そこで縮めながら収まる大きさを探す刻みは変えずに、評価そのものを減らし・軽くしています: ① 同じ判定の中で同じ寸法の評価を二度しない ② 置き場所が決まった時点で廊下の探索を打ち切る ③ 壁との当たり判定・見通し判定で壁ごとの一時データを作らない。いずれも答えは変わりません (② ③ は計算式と計算の順番まで同じです)。判定 1 回のコスト (常設ゲート node wf_az2_fitguard.mjs の E・同一マシンで改修前後を測定。値はマシンで変わります。▶/🏁 の直前にだけ行う実走での確認は含みません): 中央値 約 20ms → 約 6ms、最大 約 4.5 秒 → 約 0.35 秒、画面操作の目安 50ms を超える組み合わせ 434 → 約 180 (1,188 通り中)。落ち着き先・初期配置・公式記録は変わりません — 1,188 通りの落ち着き先が改修前と一致し、配置オラクルの出力 (6 台の配置の並びなど) のダイジェストも改修前と一致します (新設ゲート wf_ba1_fitcore.mjs で固定)。公式レースの verifyHash (c731ecce) と凍結ハッシュ f0〜f3 も同じです。「縮めながら収まる大きさを探す」手順を二分探索にしなかったのは、「収まるか」が車体スケールに対して単調でないためです (コース×領域 198 組中 65 組に反例があります。車体スケール 0.5〜4.0 を 0.1 刻みで調べた表で、入口で収まらない 5,562 通りのうち 877 通りは、二分探索にすると縮小の答えが変わります)。50ms を超える組み合わせはまだ残っており、ほとんどが「収まらない」評価を何段も繰り返す経路です (答えを変えずにここを縮める方法は、今回試した範囲では見つかっていません)。このほか、README と REBUILD に書いていた検証ゲートの本数を実数 (65 本) に、JS モジュール数を実数 (46) に直しました。