バニラ2.0で作る自動配車システム｜割り込み活用

バニラ2.0の割り込み（Interrupt）は、MOD の LTN を入れなくても需要駆動のオンデマンド配車を標準機能だけで組めるようにした、列車運用の転換点です。
自分は駅が20を超えたあたりで固定スケジュールの手編集が限界になり、路線を1本足すたびに30分ほど溶かしていましたが、割り込みに切り替えて駅名を統一する運用へ変えてからは、100駅超まで無理なく回せるようになりました。
割り込み、ワイルドカード信号、列車リミットの3機能が噛み合うことで、「空なら出荷駅、満載なら要求駅」という配車ロジックが自然に成立します。
この記事では、待機所・出荷駅・要求駅を分けた最小構成から、回路でのリミット開閉や頻出トラブルの切り分けまで、実戦で詰まりやすい順に整理していきます。

バニラ2.0の自動配車システムで何ができるか

バニラ2.0の列車スケジュールは、割り込みと回路を組み合わせることで、LTN mod に近い需要駆動の運用まで持っていけます。
仕事があるときだけ列車が動き、終われば待機所へ戻るので、固定往復のように全編成へ同じルートを押し込む必要がありません。
駅を増やすたびに本体スケジュールを触らなくていいため、拠点が広がるほど差が出てきます。

固定往復スケジュールの限界と『オンデマンド』への発想転換

自分の拠点でも最初は、とりあえず全列車を鉄板のピストン輸送で回していました。
ところが銅や石が増えた瞬間に、A駅→B駅を延々と複製しただけの管理が一気に重くなり、列車が増えるほど手編集の地獄が待っていたのです。
割り込み方式に切り替えると、追加作業は駅名を揃えるだけになりました。
これがオンデマンド配車の気持ちよさで、需要が出た瞬間だけ動かし、不要な走行を消していく考え方です。

LTN mod が担っていた役割をバニラ2.0のどの機能が肩代わりするか

LTN mod が担っていたのは、需要を検知して空いている列車を割り当てる pull 型物流でした。
バニラ2.0では、その役割を割り込み、列車リミット、そして回路ネットワークが受け持ちます。
割り込みは条件と対象駅の2要素で成立し、ワイルドカード信号を使えば列車の中身に応じて行き先を変えられます。
実績解除を維持したいプレイヤーやマルチ環境でも使えるMOD非依存の構成なので、導入の敷居が下がるだけでなく、分業中に「触ると壊れる」事故も起きにくいのが利点です。

この記事で組み上げる完成形の全体像

完成形は『待機所で待機→要求発生を検知→出荷駅で積込→要求駅で荷降ろし→待機所へ帰還』の5段ループです。
列車は待機所で眠り、必要になったときだけ出ていくので、走行距離と渋滞を抑えながら、拠点全体の輸送を回せます。
自分がマルチサーバーで運用したときも、他の人が駅を足すたびに本体スケジュールを共有編集しなくてよいこの方式は、かなり扱いやすく感じました。

この記事では、出荷駅1・要求駅1・待機所1の最小構成から始め、回路制御、トラブル対処、スケールアップへ進みます。
まず1編成が往復する形を作り、そこから燃料補給や優先度、待機所の分散を足していきましょう。
最初の一歩を小さくすると、応用が見えやすくなります。

土台となる3つの機能：割り込み・ワイルドカード・列車リミット

バニラ2.0で列車スケジュールに追加された割り込み、ワイルドカード信号、列車リミットの3つがそろうと、MOD の LTN を入れなくても需要駆動の配車が組めます。
しかもこの仕組みは、駅名の付け方と回路制御をきちんと揃えるほど素直に動くのが面白いところです。
自分も最初は、個別の機能を単体で見ていて空振りの原因を見落としましたが、役割分担までつながると一気に理解しやすくなりました。

割り込み（Interrupt）＝スケジュールへの条件付き横入り

割り込みは「条件」と「対象駅」の2要素で構成され、条件が成立した瞬間に、いま走っているスケジュールへ一時停車として横入りします。
ここで押さえたいのは、割り込みが本体の予定を上書きするのではなく、必要なときだけ経路を差し込む仕組みだという点です。
だから「いま空だから出荷駅へ」「在庫が切れたから要求駅へ」といった状況判断ができ、列車を手動で呼び戻さなくても運用が回るようになります。

この考え方を理解するまでが少しややこしくて、自分は最初、割り込みが空振りする原因を2時間ほど探しました。
結局つまずいていたのは、条件を満たした列車が「何を積んでいるか」を前提にする部分でした。
空の列車に荷降ろし割り込みを期待していたので、そもそも発火条件が成立していなかったわけです。
割り込みは便利ですが、条件式の作法を外すと静かに何も起きない。
この地味さが、逆に設計の精度を試してきます。

ワイルドカード信号で『積んでいる中身』を駅名に代入する

ワイルドカード信号は、割り込み内でのみ使える特殊信号で、アイテム・燃料・流体・信号の4種類があります。
役割はシンプルで、列車が積んでいる中身をその場で読み取り、駅名の該当部分へ代入することです。
つまり鉄板でも銅でも、積荷に合わせて同じ割り込みを使い回せるので、個別の駅を何十個も手書きで分ける必要がなくなります。

ここがオンデマンド配車の肝です。
たとえば「中身に一致する要求駅へ行く」という一文を作っておけば、鉄板を積んだ列車は鉄板向けの駅へ、銅を積んだ列車は銅向けの駅へ自然に向かいます。
自分はこの挙動を最初に勘違いしていて、空の列車でも荷降ろし先を選べると思い込んでいました。
ですがワイルドカードは、まだ積荷がある列車の内容を読むための仕組みであって、存在しない中身を作るためのものではありません。
理解してからは、割り込みが急に賢く見えました。

列車リミットで『何本まで受け入れるか』を制御する

列車リミットは、駅が同時に受け入れる列車の本数上限です。
静的に数値を置けるだけでなく、回路ネットワークで0や1へ動的に変えられるため、駅ごとの受け入れ可否をその場で切り替えられます。
リミット0にしておけば実質その駅を配車対象から外せるので、無駄な進入や滞留をかなり減らせます。

自分は以前、列車リミットを enable/disable と混同していて、駅の点滅に引きずられるように配車が乱れました。
無効化で止める発想だと、解除時の挙動や経路再計算が不安定になりやすいのですが、リミットで受け入れ本数を制御すると動きが素直になります。
要求がある駅だけ1本を受け入れ、満ちたら0に戻す。
この切り替えにすると、ネットワーク全体の信頼性が一気に上がります。

3機能の噛み合いは分かりやすいです。
ワイルドカードが「どのアイテムか」を決め、列車リミットが「いま受け入れられるか」を決め、割り込みが「その条件で動くか」を決めます。
この3つが同時に働いて初めて、積荷と需要が一致した列車だけが必要な駅へ流れるようになります。
駅名を役割ごとに統一し、本体スケジュールを待機所への1行に絞ると、この仕組みはおすすめです。
まずは小規模な線で試してみてください。
挙動が見えた瞬間、配車の設計がかなり整理されるはずです。

駅を3役に分ける：待機所・出荷駅・要求駅の設計

待機所、出荷駅、要求駅をきちんと分けると、列車がどこで待ち、どこへ積み、どこで降ろすかがぶれなくなります。
共通スケジュールで全アイテムを回すなら、まず名前と役割を固定し、割り込みの行き先を迷わせないことが出発点です。
そこが崩れると、配車は急に読めなくなります。

待機所（Depot）：仕事がないときに列車が眠る場所

待機所は、仕事がない列車をいったん退避させるための場所です。
全列車の本体スケジュールを「待機所へ」の1行にしておくと、出荷先にも要求先にも条件が合わないとき、列車は自然にそこへ戻ります。
常時どこかの駅へ向かわせる設計よりも、割り込みが成立したときだけ動く形になるので、ネットワーク全体の挙動が読みやすくなるわけです。

この構成にしておくと、拠点の拡張で駅数が増えても、待機中の列車が変な場所で詰まりにくくなります。
命名規則を後から変えたせいで全割り込みが空振りし、拠点全体が止まった経験があるならなおさらで、最初に紙へルールを書いて固定しておく価値が出ます。
待機所は単なる空き地ではなく、共通スケジュールを成立させるための戻り先です。

出荷駅と要求駅の命名規則をワイルドカードに合わせる

出荷駅はアイテムを供給する側、要求駅はそれを消費する側です。
この2つは駅名をアイテムアイコン＋役割で統一し、たとえば [鉄板]出荷 と [鉄板]要求 のようにそろえます。
ワイルドカードはこの名前の一致で行き先を決めるので、少しでも表記がずれると配車条件が成立しません。
見た目は地味でも、ここが配車の根幹です。

実際、命名を途中で変えると、それまで動いていた割り込みが一斉に空振りします。
増設した駅だけを新しい表記にしてしまうと、列車側は同じアイテムを探しているつもりでも候補を拾えず、待機所に戻るしかなくなるからです。
最初に「アイコン＋役割」の型を決めておけば、後から駅を増やしても崩れにくくなります。
おすすめの考え方は、名前を装飾ではなく配車条件そのものとして扱うことです。

1駅1アイテム原則とリミット設定の目安

1駅につき1アイテムだけを扱う構成が、最も安定します。
複数アイテムを混ぜると、ワイルドカード代入が意図しない側を拾いやすくなり、列車が誤った要求駅へ向かう事故が起きます。
駅ごとの責務が混ざるほど、どの在庫が足りないのか、どの列車がどこへ行くのかが追いにくくなるので、まずは単純化してしまうのが安全です。
おすすめです。

要求駅の列車リミットは基本1に設定しましょう。
1編成が満タンでさばける消費量に合わせておくと、複数編成が同じ要求駅へ殺到して荷余りになる過剰配送を防げます。
リミットを2にしていたとき、2編成が同時に来て片方が荷降ろしできず詰まったことがありましたが、1に戻すと順番待ちが自然にできて渋滞が消えました。
少ない本数で確実に回す方が、結果として全体の流れはきれいになります。
おすすめの設定です。

割り込みスケジュールを組む手順

最初に押さえるべきなのは、共通スケジュールの本体を最小化し、判断のほとんどを割り込み側へ逃がす組み方です。
列車の行き先を本体と割り込みで二重管理すると挙動がぶれやすく、迷子の原因になります。
だからこそ、待機所を基準点にして、条件が成立したときだけ各割り込みで動かす形にすると安定します。
優先順位は割り込みの並び順で決まるため、燃料、荷降ろし、積込の順で設計しておくと安全です。

Step1：スケジュール本体を『待機所へ』の1行に絞る

まず、スケジュール本体には『待機所へ』だけを書きます。
積込先も出荷駅もここには入れず、移動先の決定をすべて割り込みに任せるのがコツです。
自分も最初は本体に出荷駅を書き込んでいましたが、割り込みと役割が重なって列車が行き先を見失い、思った通りに回りませんでした。
本体を1行に絞ると、その場で条件が成立しない列車は素直に待機所へ戻るだけになり、全体の流れが見通しやすくなります。

Step2：積込・荷降ろしの割り込みをワイルドカードで組む

次に、積込と荷降ろしをワイルドカード前提の割り込みとして追加します。
積込は「貨物が空で、出荷駅が開いていれば、中身ワイルドカードに一致する出荷駅へ」という形にしておくと、空車だけが出荷側へ向かう流れを作れます。
荷降ろしは「満載なら中身に一致する要求駅へ」と組み、貨物が空になるまで待機させます。
ここで効くのが、荷降ろし用ワイルドカードは貨物が空だと発火しない仕様です。
だから積込→荷降ろしの順序が自然に守られ、空の列車がいきなり納品先へ飛ぶような不安定さを避けられます。

荷降ろしが空車で発火しないので、条件の噛み合わせがそのまま安全装置になります。

Step3：燃料補給の割り込みを一番上に置く

最後に、燃料補給の割り込みを条件リストの一番上へ置きます。
燃料ワイルドカードで残量を読み、たとえばロケット燃料が残り10個を下回ったら補給駅へ向かわせる設計です。
これは単なる「ついでの補給」ではなく、路線停止を防ぐための最優先処理になります。
燃料割り込みを一番下に置いていた時期は、満載の列車が燃料切れで路上停止し、そのまま路線を塞ぎました。
上へ移したあと、配送より補給を先に処理するようになり、長時間放置しても止まりにくくなったのです。
複数の条件が同時に成立した場合はリスト上位が優先されるため、燃料→荷降ろし→積込の順で並べるだけで、安全側に倒れた運用になります。

回路で需要を検知して駅を開閉する

回路で需要を見て駅のリミットを開閉すると、列車は「呼ばれたときだけ動く」形になり、余計な往復を減らせます。
要求駅は在庫が要求量を下回った瞬間だけリミットを1にし、満たされたら0へ戻すことで、欠品が出たときにだけ配車を呼び込めます。
出荷駅も同じ発想で、満載1編成分の在庫がたまるまで待たせるのが安定です。

要求駅：在庫が閾値を割ったらリミットを開く

要求駅側は、チェスト群の在庫を回路で読み取り、合計が要求量を下回ったら駅のリミットを0→1に上げます。
逆に条件を満たしている間は0に戻しておけば、列車は常時張り付かず、需要が出た瞬間だけ呼ばれる形になります。
要求量を消費速度より少し下に置いてしまうと、在庫が枯れてからしか列車が来ず、生産が止まりやすいので、少し余裕のある閾値にして切らさない運用へ寄せるのが扱いやすいです。

配線は複雑に見えても、やることは単純です。
複数のチェストをつないで合計在庫を取り、その値を定数である要求量と比べるだけでよく、比較結果を駅のリミット入力へ流せば足ります。
点滅で開け閉めするのではなく、本数上限として制御するので、列車網全体の動きが落ち着きます。

出荷駅：満載できる在庫があるときだけ開く

出荷駅は逆に、満載1編成分の在庫があるときだけリミットを1にします。
中途半端な在庫で列車を出すと、要求駅側で半端積みの車両が発生しやすく、その列車が駅を占有してしまうからです。
満タンまで待たせれば、出す側も受ける側も扱いやすくなり、配車のたびに在庫が揺れにくくなります。

自分も最初は出荷駅を enable/disable で止めていましたが、無効化の瞬間に向かっていた列車が No path でつっかえることがありました。
リミット制御へ統一してからは、向かい中の列車も含めて破綻しにくくなり、停止と再開の境目で挙動が荒れなくなったのをはっきり覚えています。
開く条件を「満載できるか」に寄せるのが、見た目以上に効きます。

enable/disable ではなくリミット制御を使う理由

駅の停止に enable/disable を使わず、リミット制御を優先する理由は明快です。
無効化された駅を割り込み列車が選んでしまう競合を避けやすく、解除した直後の挙動も読みやすいからです。
2.0では「リミット0＝配車対象外」と考える方が素直で、駅の存在自体は残したまま流量だけを調整できます。

この方式なら、回路の出力を駅のリミット入力へつなぐだけで、需要があるときだけ開き、条件が外れれば静かに閉じます。
停止と再開を状態遷移として扱うより、数の上限として扱うほうが列車網は安定しやすいです。
おすすめです。

うまく動かないときのトラブルシュート

自動配車が止まったときは、まず症状を分けると原因が見えやすくなります。
No path は「駅名のミス」「信号の向きや配置」「線路の断絶」のどれかであることが多く、列車が暴走する前に止まる仕様なので、慌てず経路の切れ目を探しましょう。
割り込みが入らない、待機所に戻らない、といった詰まりも、条件やリミット、スケジュールの残り方を順に確認すると整理できます。

『No path』の3つの原因を切り分ける

No path が出たら、存在しない駅名を指していないか、信号の向きや配置ミスでブロックがつながっていないか、線路そのものが物理的に断絶していないかの3点に分けて見るのが近道です。
自分の感覚では、原因の8割は駅名のアイコン1個違いでした。
目視では気づきにくいので、命名をコピペで統一する運用にしてから激減しました。

交差点で詰まったときは、マップ表示でCtrlを押しながら線路をなぞると、経路が消える地点で原因を特定できます。
自分もこの方法を知らずに1時間さまよったことがありますが、消えた場所を見れば信号ミスか線路断絶かが一発で分かるので、調査の順番が崩れません。
存在しない駅を指した列車は No path 状態で停止し、想定外の駅へ暴走しないため、まず駅名の一致を確認してから配線を疑うのが安全です。

割り込みが起動しない・列車が待機所に戻らないとき

割り込みが起動しないときは、条件と駅名が一致しているか、ワイルドカードの前提が崩れていないか、リミットが0のまま開いていないかを順に見ます。
たとえば荷降ろし系の割り込みは貨物が空だと発火しないので、列車の状態が条件と噛み合っていないと反応しません。
条件が1つずれているだけで、見た目は正しくてもまったく動かないのがこの仕組みのややこしいところです。

列車が待機所に戻らない場合は、本体スケジュールに帰還用の『待機所へ』が残っているか、待機所のリミットが列車数に足りているか、割り込み条件が意図せず成立し続けていないかを見ます。
リミットが少ないと帰れず路上待機になり、結果として次の配車まで詰まります。
ここは「戻る処理」と「戻れる受け皿」を両方そろえる発想が必要です。

デッドロックと同名駅ループの回避

同名の出荷駅・要求駅が複数ある構成では、列車が同じ駅を選び続けてループすることがあります。
こういうときは『Not at specified station』を割り込み条件に加えると、別の同名駅を選び直すよう強制でき、1つの駅への偏りやデッドロックを避けられます。
駅数が増えるほど選択の偏りは目立ちにくくなるので、早めに入れておくと運用が安定します。

この手の詰まりは、止まる原因そのものよりも「止まり方」を読めるかで対処速度が変わります。
No path で止まるなら命名と接続、割り込みが沈黙するなら条件と前提、戻らないなら帰還先とリミット。
症状ごとに切り分けていけば、複雑な路線でも落ち着いて復旧できます。

優先度・流体・スケールアップへの応用

基本形を組めたら、次は複数の出荷元と要求先をどうさばくかが焦点になります。
駅の優先度を使えば、近い出荷元や在庫の厚い拠点を先に選ばせられるので、回送距離を抑えつつネットワーク全体の動きを整えやすくなります。
流体列車も同じ割り込みの枠組みに載せられるため、アイテム系と分けて整理しておくと運用が一気に軽くなります。

優先度で複数の出荷元・要求先をさばく

駅の優先度はデフォルト50で、0〜255の範囲を使えます。
スライダーは10〜90を目安にしておくと扱いやすく、回路でも設定できるので、在庫量や混雑状況に応じて動的に振り分ける設計も組めます。
複数の出荷駅があるなら、近距離の駅を高優先度に寄せるだけで走行距離が縮まり、列車が遠回りしにくくなります。

この仕組みの良さは、単に「早い駅から使う」だけではありません。
要求先が増えたときも、どの駅を先に埋めるかを優先度で制御できるので、拠点全体の偏りを抑えやすいのです。
出荷元が増えるほど、優先度は手作業の順番待ちではなく、列車網の交通整理そのものとして効いてきます。

流体列車を同じ割り込み枠組みに載せる

流体列車も、考え方は同じです。
流体ワイルドカードを使えば、原油・硫酸・軽油などを「中身に一致する流体要求駅へ」割り込み1つでまとめて捌けます。
手動で系統ごとに管理していた流体を、アイテム列車と同じ発想で統一できるので、経路設計と駅管理の見通しがよくなります。

実際、流体を別系統でいちいち手動管理していた時期は、原油系のトラブルが起きるたびに確認箇所が増えました。
流体ワイルドカードで割り込み設計に統合してからは、駅名と要求の対応がそろい、どこで止まっているのかを追いやすくなったのです。
アイテムと流体で割り込みを分けておけば、混線も防ぎやすいでしょう。

待機所分散と大規模化のコツ

出荷駅・要求駅が複数に増えても、命名規則さえ守れば本体スケジュールは1行のまま維持できます。
スケールアップのやり方は単純で、同じ命名の駅を足していくだけです。
割り込み方式の強みは、列車本数や駅数が増えても設定の骨格が崩れにくいところにあります。

大規模化で詰まりやすいのは、列車を1つの中央待機所に集めたときです。
朝の需要ピークで待機所前が渋滞し、出たい列車と入りたい列車が重なって流れが止まりました。
そこでエリアごとに小さな待機所を分散配置し、列車が最寄りで眠る形に変えると、入口の渋滞が解けただけでなく、需要発生から到着までの応答も速くなりました。
拠点が広がるほど、待機所は集約より分散のほうが扱いやすくなるはずです。