Factorio Space Age SPIRAL級プラットフォーム改修、そして30kspmへ向かう
1,778時間経過、Research prod 75、Promethium SP生産速度ベースで14kspmです。
この一週間は、Promethiumを収集・SPを作成するSPIRAL級の改修・調整・テストおよび全体の出力底上げを行いました。システムが安定してきたので、SPIRAL級の2台運用による研究速度30kspm程度到達の目処が立ちました。
工場が大きくなると、自然とUPS optimizeや細かい制御の話が増えてきます。だんだん上級者（廃人？）向けの内容になっていきます。
SPIRAL級プラットフォーム改修・調整
しばらくSPIRAL級プラットフォームを運用し、いくつか問題が見えてきました。対応できたものもありますが、難しいものは次世代（第2世代）で対応します。
スラスター追加
まず、230km/sは遅すぎる！ということで、スラスターを追加しました。スラスターは、一定距離開ければ縦に並べることができます。uglyなデザインで個人的には好きではないのですが、仕様上許されているので採用することにします。その気になればもっと増やすことはできますが、それは必要であれば次世代にて。
スラスターの数を倍にして、速度は1.5倍になりました。
Promethiumの取りこぼし対策
速度を上げると、また奥の方まで進むとどんどん得られるPromethiumが増えますが、そのうち逆に多すぎて拾いきれなくなります。進むほど計算量は増えUPSが下がるので、むやみに速度を上げ奥へ進むのは無駄・非効率です。そこで、Solar system edgeより先では、経過時間に応じて段階的に航行速度を下げ、逆に帰りは段階的に速度を上げるようにしました。
現行世代では変更が難しいので対応しませんが、コレクターの密度を上げ、斜めの角度を急にすれば、もっと速度を上げてもPromethiumを拾い切ることができます。これは次世代で対応します。
Control behaviorsが高い
処理時間の内訳を見ると、マルチスレッド処理(MT)されているにも関わらずControl behaviorsがかなり高いことがわかりました。観察した結果、SPIRAL級プラットフォームがベルト上にPromethiumをいっぱい蓄えていると高くなる傾向のようです。
FFFにもControl behaviorsに関する記載があり、今回のケースではベルト上のアイテム数をカウントする処理に時間がかかっていると理解しました。敷き詰められたPromethium用ベルト倉庫の、ほぼすべてのアイテム数をカウントし、制御に使用しています。
ベルト倉庫のアイテム数をカウントする回路を外したところ、Control behaviorsの値は大幅に減らすことができました。その代わり、制御方式を大幅に変更しなくてはならず、一部は直感的でないトリッキーなやり方になってしまいました。
SPIRAL級複数運用の仕組み
3台4台と重ねられるよう、より汎用な仕組みにしました。プラットフォームの制御はあまり細かいことができません。そのため少しトリッキーなやり方になりました。
まず、SPIRAL級がPromethium収集後にNauvisで処理を行うのは1台だけに限定、それ以外はAquiloで待つ仕様とします。これは明示的に、プラットフォーム1台ずつ順番にPromethiumの在庫を吐かせたいからです。
SPIRAL級は、Promethiumを集めた後、Aquiloでフラグ（チケット）であるLight Armorを拾えたら、Nauvisで処理をし、その後Glebaでチケットを捨て、再びPromethium収集に行きます。
そしてこれは次のSPIRAL級へチケットを渡すプラットフォームです。Glebaでチケットを拾い、Aquiloで落とすことで、次のSPIRAL級へチケットを渡します。
プラットフォームの仕様上、一つのプラットフォームである特定のアイテムを落とす・拾うを条件判定して同じ惑星で行うことはできないので、このように2惑星に分け、回りくどいやり方になりました。
列車ネットワーク
Space Ageに含まれるelevated-railsによって、線路の立体交差ができるようになりました。これにより、列車ネットワークのレイヤー分けが簡単にできるようになりました。1.1以前は、ボトルネックとなる交差をなるべく減らすために、レイアウトにとても気を使う必要がありました。
特に以前やっていたBob's（30k時間くらいで止めました）では、大量の長大列車が走り回るので、レイアウトに苦労しました。
これは事ある毎に主張しますが、Factorioの列車ネットワークにおいて複々線以上の太い線路は見た目は面白いかもしれませんが、ほとんどの場合誤った使われ方をするので機能性は低いです。複雑な交差点も同様です。（適切に信号を置いていることが前提ですが）デッドロックが起きるということは、単純に列車の数がネットワークのキャパシティを上回っているということです。
ならばどうするか、ネットワークを分けましょう。汎用ネットワークは、ベルトで言えば寿司ベルトです。キャパシティの問題があるなら、用途ごとに分けるべきです。
レイヤーを分ける
Space Ageでは、VulcanusのTungsten ore、FulgoraのScrapの流量が多くなります。よって、これらの列車ネットワークは他のものとレイヤーを分けることにしました。ネットワークは完全に分離するのではなく、（燃料補給経路や保守のため）一箇所でだけ繋げています。
ここではFulgoraを例に説明します。黄は汎用（Scrap以外）ネットワーク、赤はScrap専用ネットワークです。黄と赤はピンクの丸で繋がっていますが、そこ以外の交差はすべて立体交差で、お互いの通行を邪魔しません。赤丸はScrap堀場です。
左のブロックを拡大すると、こうです。ここでも黄と赤は立体交差します。
公式フォーラムへの投稿
このsaveの拡張が落ち着いたら、過去そうしてきたように公式フォーラムへ紹介記事を投稿したいです。春までにはできるかな。
以下は過去投稿したものです。
Bob'sは1.1のgame.tick overflowを乗り越え、30k時間で止めました。2.0への移行はしないと思います。
Space-Explorationは19,884時間、1.1のgame.tickの上限に到達したところで止めました。こちらも2.0への移行はしないと思います。SEは1.0になってから改めて新規でやりたいな、と。
補足：1.1のgame.tick overflow
FFFでたまたま直近の投稿が紹介されていて、あたかもその頃最近見つかった問題のように勘違いする方がいるかも知れませんが、1.1で存在したgame.tick overflow、19,884時間でゲームが進行不能になる可能性がある問題はずっと以前から指摘されており、私がBob'sのsaveでそれに到達した際も、2022年12月にレポートを上げています。それ以来私は、2.0でgame.tickの桁が拡張されると公表されるまで、20k時間は短すぎると、機会がある毎に開発チームへ要望を伝えてきました。拡張されてよかったです。