レポートといえば、やっぱり自前で ODF 吐かせるしかないですね https://github.com/azyobuzin/reportyatsu2
レポートといえば、やっぱり自前で ODF 吐かせるしかないですね https://github.com/azyobuzin/reportyatsu2
ORM に CREATE TABLE させてるから CHECK 制約つけてなくて、不整合データが生まれてないかを調べられていないのが難点
未着手ジョブ数が減ってきていて、探索順をちゃんと決めてあげないと、もしかしたら最後の方に全然並列にならないかもしれないなぁという思いになってきた
docker build コマンドに --squash オプションつければ容量半分になりそうだな。そんなオプションがあることに初めて気づいた。というのもイメージがでかい原因が、 Dockerfile の ADD --chown がなぜか(Windows で作った tar.xz だからか?)効かなくて、所有者が root になってしまうので、ゲームファイルすべてに対して chown してイメージサイズが実質 2 倍になってる
✔ 4GB の tar.xz の展開が遅い
✔ Wine の依存パッケージが多すぎて apt-get install が遅い
とりあえず僕の予想値よりジョブ数が少なかったということは、選択肢到達回数が 1 回少ないパターンが僕が知っている範囲より多いということだから、それが何だったかを突き止めなきゃいけないかな
とりあえず結果の DB をバックアップし、ソースを push したので、いま HDD が壊れてもこの偉大な進捗は消えない
完全に理解した。 10 番のイベントが発生しないのは、最初の選択肢で下を選ぶ or 「3番目の選択肢で下を選ぶ」がトリガーっぽい。こっちは気づかなかった
1番目と3番目の選択肢は、かおるこの好感度に関わるので、かおるこの好感度がマックスじゃないと、学園祭前夜イベントが発生しないということっぽく、これは実際に全部手動で動かさなくても納得がいく結果
IReadOnlyDictionary<(int, ChoiceAction), IReadOnlyDictionary<Heroine, double>> 型が生まれた
ある選択肢を選んだときに誰のルートに行くかの確率を出してみた
jitaku. azyobuzi .net :30416 / results
んだけど、未尋以外は的確にそのキャラの好感度を上げる選択肢を選んでいかない限り到達できないということがわかってきた。逆に未尋に対する地雷は存在しない
実際の選択肢と番号を紐づけて見た感じ、そもそも未尋に関わりそうな選択肢はどっちを選んでも毒にも薬にもならないっぽい
ブログ書くために、まだ Docker 化する前の Windows 上で動かしていた時代のやつを動かして、スクリーンキャプチャ撮ろうと思ったら、選択肢全部記録させた DB 消しちゃったっぽいな……
今回書いた探索コードのアルゴリズム、1年半前のものと同じだと思ってたけど違かった。前のバージョンは深さ優先で探索していて、次に探索するリストでメモリを食わない仕組みになってた。ちょっとずつ記憶を思い返してみてるけど、このコードを書いていた時点では何パターンあるかの試算をしてなかったから、メモリに乗り切るのかが不安だったという説
> FreezePeach and SeaLion are down due to a bad RAM DIMM
最近あの鯖がハードの不具合で死にまくってる印象があるんだけど
ワガハイを Wine で動かし始めたときの作業ログが見当たらない、もしくは今死んでいる FreezePeach にいろいろ書いてたかもな……