OTRP開発終了によせて
私，ひめしが4月より就職することをうけ，OTRPの開発を3月末で終了することにしました．OTRPの今後の扱いなどについては，下のツイート群を参照してください．
【 #OTRPatch 開発終了のお知らせ】
— OTRP【公式】 (@OTRPatch) 2021年3月2日
4年あまりにかけて皆さまにご愛用いただいたOTRPですが，このほど @himeshi_hob の就職に伴い，3月末をもちまして開発を終了します．皆さまの多大なるご支援，ご愛用ありがとうございました．
（次ツイートに続きます）#Simutrans
アナウンス的なお話は先のツイートで済んでいるので，この記事ではポエムっぽいことを書き連ねていこうかなと思います．
結局OTRPとは何だったのか
ひめしが欲しかったSimutrans．これに尽きます．
本家にあまり取り合ってもらえなかったので派生版として自分で自分が欲しい物を作った，というだけの話です．
OTRPの成果物に関する研究は皆さんがんばってください（丸投げ）．ひめしは主にローカルマップで楽しく遊んでおります．
開発者の育成の試み
Simutransのメジャーな派生版として，Extendedがあります．ExtendedはExperimentalの時代から随分と長い間開発が続けられていますが，これは継続的に複数の人々が開発に関わっているから，というのが大きいです．
OTRPの開発を始めた当初から，私には就職というタイムリミットがある，という話は分かりきっており，この4年間，OTRPのコードをいじれる人をどうにかして作れないかと試行錯誤してきました．2017年の夏には新宿で丸一日の開発ゼミをやり，18年の年末には教科書を書き，20年にはそれをフリーアクセス化，同時にDiscordで開発ゼミも開催しました．
この試み自体が失敗に終わったのかどうかは，まだ結論には早すぎると考えています．ただ，OTRPの開発を引き継げる人を作るという観点では，完全に失敗です．
この話をTwitterに投げたところ，コードに関するドキュメントを整備してくれというご意見をいただきました．たしかに，コレコレこういう処理はここに書いてありますという日本語のドキュメントがあれば便利だとは思います．しかし，全てのクラスのドキュメントを整備することはあまりにも工数がかかりすぎ，かつコードは頻繁に変更されるので，せっかくコードに関するドキュメントを整備しても一瞬で陳腐化してしまいます．結局，ヘッダファイルをドキュメントとして読めるように書いておくのが現実的であり，現在のSimutransのコードはそのようになっています．こういったコードの読み解き方については「Simutransの本体開発」に書きましたので，ぜひお読みください．
OTRPと格言
OTRPはおかげさまでそこそこの完成度をもったプロジェクトに成長できましたが，開発，運営にあたってアタマに置いていた格言がいくつかあるので，紹介します．
千里の道も一歩から
古くからよく知られたことわざです．OTRPの開発では，二車線走行や増解結など，実装の難易度が高い機能の開発がいくつかありました．
こういった機能の開発で大切なのは，まず青写真を描いたあとに，手のつけられそうなところから少しずつやっていくということです．最初に青写真を描いておかないと，手を付けるべきところがわかりませんし，途中で軌道修正が必要になったときにゴールを見失ってしまいます．
全体像が見えたら，大事なところから実装...とはあまり考えずに，小さなところでも手のつけやすいところから実装していくと精神衛生上良いと思います．実装を進めるうちにこちらもレベルアップしていくので，難題にも立ち向かえるようになる，といった具合です．コアとなる処理はだいたい難易度が高い場合が多いので，いきなり手を付けるとたいていわけがわからなくなります．
Done is bettern than perfect.
（完ぺきにするよりまず終わらせろ）
FacebookのCEOであるザッカーバーグ氏の有名な格言です．
OTRPは，機能実装のスピードをきわめて重視していたので，とりあえず動きそうな状態になったら細かい調整をする前にリリースしていました．完ぺきを目指していたらいつまでもリリースできないからというのもありますが，どうせリリースすれば開発段階で見えていない問題がたくさん出てくるので，それらをあぶり出してから全部いっしょに解決してしまうほうが効率がよかったからです．
ただし，リリースするにしても「終わらせる」必要はあります．プロダクトが部分的にしか完成していない場合，既存のものと組み合わせるなど何かしらの形で可用性はしっかり確保してから出す，といった具合です．
なお，これは途中から気がついたのですが，特に日本のユーザーを相手にする場合，いたずらに開発途中の状態でリリースするのはユーザーの信用を損ねます．ユーザーがはじめてそのプロダクトを触ったときに，致命的なバグを踏むような状態では，あとからアップデートしてもそのユーザーはもう戻ってこないからです．なので，特にOTRP後半からは，基本的に手元のテストで何かしらの明らかな問題が見られるときはリリースを見送っていました．
早く行きたければ、ひとりで行け。
遠くまで行きたければ、みんなで行け。
ビジネス書とかで幾度となくお目にかかる格言です．OTRPは本家フォーラムとの交渉（みんなで行く）に耐えきれず，ひとりで行くことを選択してしまったプロジェクトなので，そんなに遠くまでは行けなかったわけです．
スクリプトツールの開発のときは，本家に載せないとどうしようもなかったこともあり，スピードを犠牲にしてきちんと交渉することを選択しました．「みんなで行く」ことを選択するのであれば，進捗に期限を設けてもだいたいどうにもならないので，いつか話しが通ればいいな程度の考えでどっしり構えるのがいいと思います．本家フォーラムでは，話が数ヶ月放置されたあとに突然拾われて採用，みたいな話がよくあります．
ひとりでやることと，みんなでやることははっきりと分離しましょう．そうすることで，ひとりでやることについてはスピード感をもって取り組むことができます．
今後のSimutransはどうなるのか
今後こうなりますという未来予想図を正確に描くことはおそらく誰にもできないと思います．ですが，これから4-5年はザックリこんなもんだろうと予想しています
- 2021年いっぱいまではOTRPが引き続き日本のデファクトスタンダードであり続ける．
- 22年あたりぐらいになると，本家standardが完成度の高い状態で様々な新要素を搭載するようになり，OTRPが見劣りし始める．
本家standardのスクリプトAPIがさらに拡充され，高機能なスクリプトを利用するためにstandardへの移行が始まる． - 23年になると，OTRPと新standardの勢力が拮抗するようになる．この頃になると，新standardでしか使えないアドオンが出現する可能性がある．この時期Extendedがなんか楽しいことをしてくれるかもしれない．
- 24年以降になると，OTRPを引き続き使い続ける人は少数派となり，今とは全く違う本体シェア構成となる．新しい派生版が出てくるかもしれない．
いずれにせよ2020年末からのstandard開発の盛り返しを見ると，OTRPの陳腐化は相当な速さで進むと思います．
謝辞 Acknowledgement
OTRPの開発にあたり， ahakuokuくんとLeartin氏の貢献は特筆すべきものとしてここに書き残しておきます．
ahakuokuくんには，OTRP開発と運営にあたり，コーディング以外のほぼ全てにおいて本当に助けてもらいました．彼は錯綜するバグ報告を見事にまとめ，ユーザーからの相談に的確に対応し，諸々の雑用を一瞬で片付けてくれました．4月以降TwitterのOTRP公式アカウントは彼が担ってくれるとのことで，本当に頭の下がる思いです．
Leartin (in the simutrans international forum) showed me deep insights and proper ways when I was stucked in difficult problems. The convoy coupling feature is one of the most difficult problems for me and I did the implementation of it three times. Leartin proposed me an uncomplicated and effective solution for this and the current architecture is based on Leartin's proposal.
（Leartin（本家フォーラム）さんは，私が難しい課題で悩んでいる時に，的確な道筋を示していただきました．特に，増解結は3回も実装をやり直す難題でしたが，Leartinさんは完結で効果的なアーキテクチャを提案してくださり，増解結の現在の仕様はLeartinさんの提言によるものです．）
おわりに
OTRPの時代はここに終わりました．Simutransがどのような形であれ今後も進歩を続け，多くのプレイヤーを魅了し続けるゲームであり続けることを心から願っています．
スクリプトツール機能開発の背景と今後の展望
どうも，ひめしです．
この記事は，Simutrans Advent Calendar 2020 ６日目の記事です．
私にとって学生生活最後の年となった2020年は，OTRPの開発を続ける傍らでスクリプトツール機能の開発を行っていました．
この記事では，スクリプトツール機能の開発の背景と，中長期的な今後の展望についてお話したいと思います．
開発の背景
スクリプトツール機能を開発したのは，過去に幾度となく登場したfork版に存在する問題を解決するとともに，ゲームの機能開発を加速し，C:Sやminecraftといった商用MODゲームにSimutransを近づけるためです．
SimutransはC++で書かれており，一般に機能追加を行うためにはコードを変更し，コンパイルすることが必要です．この状況では，本家ではない外野の人間が機能追加を行う場合，コードをforkして，独自版として開発を行うことになります．これまでに私が知る限りでも，iron bite，ttt（tiny time table patch），OTRP，extendedが派生版として登場しています．
機能を追加するためにforkして派生版を作ることには2つの問題があります．1つめは，複数の作者による追加機能を同時に使うことができない点です．例えば，extendedに搭載された旅行時間に基づく旅客経路選択をOTRPで使うことはできません．派生版Aにある機能を派生版Bで使うためには，手動による移植を行い，コードの再ビルドを行う必要があります．これは大変手間のかかる作業であり，新規性のない機能移植作業に開発者は膨大なリソースを割く必要があります．
もう一つの問題は，本家追従の難しさとそれに伴う陳腐化の問題です．extendedを除くSimutransの派生版はほぼすべてが事実上単一の開発者によってコードの維持管理が行われているため，本家の変更点を継続的に取り込むことは容易ではありません．追従作業が行われなくなった派生版は本家と比べて陳腐化し，ユーザーは派生版独自の機能を諦めるか陳腐化した派生版を使い続けるかの選択を迫られることになります．大抵の場合取られる選択は前者であり，派生版で開発された機能は利用できなくなります．
機能開発をスクリプトによって行うことは，これらの問題を完全ではありませんが解決します．ユーザーは異なる作者によるスクリプトを（競合する場合はあれど）同時に使うことができますし，スクリプト自体の維持管理がされなくなった後も本体側との互換性が失われるまでは本家の新機能も問題なく利用できます．本家統合を目指す場合と比較した場合，統合に関するすり合わせが必要ないため，圧倒的な自由度と開発スピードを得られることは言うまでもありません．
C:Sやminecraftといった商用MODゲームが台頭する中，Simutransにおいてスクリプトで機能を開発できるようにすることは喫緊の課題でした．商用MODゲームがそのMODシステムにより有志の力を借りながら加速度的に機能を充実させていく中で，Simutransが本家コミュニティによる機能開発だけを待つのでは，他のゲームと比較しても急速に陳腐化が進むことは明らかだったからです．Simutransはソフトウェアの構造上C:Sのような自由度の非常に高いMODシステムを導入することが難しいのですが，少しでも外部からのアルゴリズム注入をしやすくするのは非常に重要です．
Dwatch氏の尽力により，Simutransではプレイヤー，シナリオ，ツールの3つをスクリプトで記述可能になりました．今後は本体開発とコミュニティ形成の両面から，有志によるスクリプト開発を促進し，新機能開発を加速させていく必要があると考えています．
スクリプトツールにおける今後の展望
とかく難しそうなイメージを持たれがちなスクリプトツールですが，スクリプトツールはアドオンと同等，もしくはそれ以上にプレイヤーが簡単に導入，使用ができるべきだと考えています．既存ユーザーの心理的障壁を考慮し，アドオンと全く同じように使えることが必要です．これを踏まえて，今後行われるべきであろうことがらを以下に3つ列挙します．
スクリプトツールのpak化
現行の仕様ではスクリプトツールの導入を行うとき，tool.nutおよびdescription.tabが含まれたフォルダをpak/tools/に配置し，カーソルpakをpak/に配置します．単一のpakファイルを配置すれば良いアドオンの導入と比較して若干煩雑に見えます．生のテキストファイル（nutとtab）を配置するこの仕様は，開発のしやすさを考慮した上での仕様なのですが，完成品のツールに関してはカーソルpakも含めて単一のpakファイルにまとめて配布できるようにするべきだと考えています．
menu項目の標準命名規則の策定と普及
ツールをメニューバーに表示させるためには，menuconf.tabで定義されたキーと同じ値をdescription.tabのmenu項目に記述する必要があります．このキーに関する取り決めがないと，ツールを導入するごとにツールに応じてmenuconf.tabを編集する必要があります．そこで，menuconf.tabにおけるスクリプトツールのキーの命名規則を策定し，日本語化Wikiで提案しています．
Ayura氏の「らくらくクリックくん」は，この規格に準拠したメニューバーです．
https://www.simutrans.sakura.ne.jp/portal/articles/らくらくクリックくん-ver2-0
GUIのサポート
ツールの中にはパラメータを渡すのが望ましい（例えば信号の等間隔設置ツールでは，間隔を数値で渡したい）ものがあります．しかし，現行のスクリプトツールの仕様では取れる入力はツールの実行座標のみです．このため，パラメータは予めコード内で定義してある必要があります．例えば，JCT自動建設ツールも，コードを編集して道路アドオン名を指定する必要があります．この仕様がユーザーにやさしくないのは言うまでもないでしょう．
この問題に対する一つの答えは，GUIのダイアログを用意してあげることです．スクリプトでウィンドウを構成できるようになれば，対話的なツールを実装することも可能になります．しかし，現行のSimutrans Squirrel APIはGUI部品およびウィンドウの表示をサポートしていません．したがって，GUIをサポートするための本体開発が必要になるでしょう．
おわりに
本稿では，スクリプトツール機能を開発するに至った背景と，今後必要な施策についてお話しました．私に残された時間を考えると，これらの施策は私がやるというよりは，誰かやってくださいという感じのものですが，今後スクリプトツールが多くの人に使われるようになれば幸いです．
路線図メーカーの使用状況データを眺めてみる
どうも，ひめしです．
いつも路線図メーカーをご利用いただきありがとうございます．
先日OTRPの使用状況ログを解析したので，路線図メーカーについても合わせて解析を行いました．
基本諸データ
- データ集計日：2020年11月28日
- データ収集開始：2019年12月
2020年3月23日〜4月9日は，ログ収集用サーバーに障害が発生したため，ログ収集件数がゼロとなっています． - 対象本体バージョン：バージョン12以降（バージョン11は集計項目が不足しているため対象外です．）
OTRPとは異なり，MACアドレスを収集しているため，MACアドレスをもとに集計を行います．これにより，端末としての利用実態を把握できます．
累計ユーザー数
路線図メーカーは，一般的にたま〜に使うソフトウェアであるため，特定期間のアクティブユーザーではなく，累計ユーザーを第一の指標とするのが妥当です．
横軸は月（月の末日を基準としています），縦軸はその月までの累計ユーザー数です．2020年の1月から11月までを表示しています．
路線図メーカーはそんなに頻繁にアップデートしているわけではないのですが，コンスタントに新しいユーザーが流入し，概ねリニアにユーザー数が増え続けているのが非常に興味深いところです．
なお，11月27日までログ収集非対応のv10_5を安定版として案内しており，そちらはDL数がv15の5倍以上あるので，実際の累計ユーザー数はこの数字の5倍程度と推測できます．OTRPのダウンロード数がせいぜい250程度で，実ユーザー数が200弱であることを考えると，路線図メーカーは実はかなり巨大なユーザーを抱えていることになります．今なお新しいユーザーが流入し続けていることを考えると，路線図を簡単に作るというニーズは実はそれなりの市場規模を持つものだったのかもしれません．
日ごとのアクティブユーザー数
先月2020年10月の，日ごとの起動端末数です．OTRPが毎日100〜130人に起動されているのに対して，路線図メーカーはせいぜい30人です．路線図メーカーはOTRPと比較して「たまに使う」ものであることがわかります．
OSの割合
MACアドレスごとに，最後に稼働したときのOSを集計したものです．約86%がWindows 10上で走っているという結果になりました．Macは5%強で，レガシーなWindows OSで動かしている例も散見されます．文字が重なっているところはLinux（2件）とWindows Server 2016（1件）です．
本体バージョンの割合
MACアドレスごとに，最後に稼働したときの本体バージョンを集計したものです．15系が多いですが，これは単純にリリースタイミングを反映したものだと考えられます．路線図メーカーは「たまに」使うソフトウェアですので，長い間使用せず本体もバージョンアップされないケースが多いと考えられます．
おわりに
こうして眺めてみると，OTRPとはだいぶ違った傾向が見れておもしろいですね．今なおコンスタントに新しいユーザーが流入していることは大変喜ばしいことです．今後とも路線図メーカーをよろしくお願いいたします．
OTRPの使用状況データを眺めてみる（10・11月）
どうも，ひめしです．
いつもOTRPをご利用いただきありがとうございます．
今年5月に使用状況データの取得を開始して半年が経ちましたが，結局ちゃんと分析することなく放置していたので，ここらで最近の動向を簡単にまとめておこうと思います．
アクティブユーザー数と起動バージョン
10月1日〜10月31日
11月1日〜11月21日
v28系のシェアはリリースから伸び続け，6-7割ぐらいになったところで伸び悩んでいます．v26〜v28_1は影響の大きいバグが残り続けた時期であり，その中で比較的安定したv26_5を一部のNSが使い続けていることが影響していると考えられます．
ユーザーごとのメインのpakセット
一番多く使われているpakセットをIPごとに数えました． 最近の動向を見るということで，11月のデータだけで集計するとこうなりました．
NSの影響かはわかりませんが，128jp系に勢いがあるようです．前回5月に分析したときは，128jpと128無印，nipponが拮抗していたので，128jp系がココ最近になって伸びてきたと言えます．最近はアドオンもたくさん出ているようなので，実際に流行っているのでしょう．
起動時間の分布
IPアドレスごとの，1日の起動時間を集計してみました．いくつかの日にちをピックアップして傾向を見たいと思います．
起動時間1分未満は除外しています．
11月11日（水）
起動時間の中央値は2.7時間です．11月15日（日）
起動時間の中央値は2.6時間です．
プレイヤーの数自体は平日よりも休日のほうが多いようです．あたりまえですが．
休日は起動時間3時間未満のライトユーザーの割合が増える傾向にあります．一日に5時間も6時間もSimutransするヘビーユーザーは平日も休日も区別なくシムトラ廃人しているようですw
6時間以上起動しているユーザーも一定数見られますが，これらのユーザーはプレイしていないときも起動したまま放置していると考えられます．
なお，現状話が止まっていますが，OTRPがSteamに載った時点で使用状況の収集は終了する予定です．
OTRPユーザーの使用状況データ分析（速報版）
どうも，ひめしです．
OTRPでは，v24_4から使用状況の収集を行うことにしました．
#OTRPatch では，v24_4から皆さまの使用状況を収集させていただくこととしました．データは個人が特定できないもののみ収集し，統計解析に役立たせていただきます．
— ひめし (@himeshi_hob) 2020年5月6日
現時点での主な収集事項は以下のとおりです．
・バージョン
・言語設定
・OS
・使用pak（名前だけ）
・ネットワークモードか
日本のSimutransプレイヤーにおけるpakセット動向などは，ペルリさんが過去2回に渡ってアンケート調査をしています．年齢層や居住地，遊んでいる本体や使用pakセットの分布が明らかになっています．
しかし，このアンケートは有志による回答であるため，日本のSimutransプレイヤー全体の動向をきちんと反映しているかは疑問が残ります．
対して，OTRPによって得られる統計データは使用者からほぼ強制的に取得しているため，OTRPのユーザー層に限られますが，より実情に近い結果になっているものと考えられます．なお，v24_4はまだリリースから10日しか経っていないため，現時点ではOTRPのアーリーアダプター層による回答と考えるべきです．
能書きはこのくらいにして，データを見てみましょう．グラフ作成の手間削減のため論文に貼ったら殺されそうな体裁のグラフばかり出てきますが，許してくださいorz
基本諸データ
より実情を反映するため，日にちは日本時間午前5時を境目として集計しています．すなはち，1日は24時間表記で5時~29時です．
日ごとのユーザー数
横軸は日にち（5月），縦軸は1日のアクティブユーザー数です．オレンジはその日に新しくOTRPv24_4を使い始めた人の数を表し，オレンジ+青全体でその日のアクティブユーザー数を表します．
16日はデータを取得した時点でまだ1日が終わってませんので，数字が少なめです．9日（土）〜15日（土）で一週間の動向を見るのがよいと思われます．
この一週間は一日あたり60人前後の人がOTRPを起動したようです．曜日ごとにあまり差が出ていないのは，アーリーアダプターの大勢を占めると考えられる学生の方々が今の時期盛大に暇していることが効いていると考えられます．今現在見えているユーザー数は間違いなくコロナブーストが効いているので，曜日ごとの傾向などを見るにはもうう少し長期でデータを集める必要があります．
ちなみにOSDNから取得したOTRPのダウンロード数推移は下の図のとおりです．
5月6日以降はほぼv24_4のダウンロードと考えて問題ないと思います．6, 7日は起動ログによる新規ユーザー数よりOSDNでのDL数が上回ってますが，10日以降はそれが逆転する傾向が見られます．ダウンロードだけして数日寝かせておく人が一定数いると推測されます．
pakセットの分布
この分布は，各IPごとに最も起動回数が多かったpakセットの属性を示したものです．使用されているpakセットの名前から128系，128jp系，nippon系，64系の4種類に分類し，円グラフにしてみました．カッコ内の数字は各属性の実数を表しています．
128系，128jp系，nippon系の勢力が拮抗しているようです．ペルリさんによる過去2回の調査でも似たような傾向が出ているので，そういうことだと考えて良さそうです．pak64系勢力は，ペルリさんによる勢力よりも小さめです．64系のプレイヤーは保守的な傾向があり，他の勢力よりもstandardユーザーの比率が高いと考えられます．
以上，v24_4リリース10日目時点での使用状況を紹介しました．もう少し時間が経ったら，また改めて集計し直してみようと思います．
OTRPのスケジュール機能を使いこなそう
どうも，ひめしです．
この記事はSimutrans Advent Calendar 2019の記事です．
OTRPでは，車両の運行スケジュールにいくらかの機能が追加されています．下図の点線で囲まれた部分がOTRPで追加されている機能です．
追加されている機能は
- Route Cost調整（乗車不可/降車不可/臨時系統）
- 増解結（連結相手を待つ/連結を試みる）
- 発車時刻指定
の3つです．今回は，これらの機能の活用例を，いくつかのシチュエーションを想定してまとめてみようと思います．それぞれの機能の使い方自体についてはOTRPのページを参照してください．
ケース1) 長距離寝台列車を設定する
例えば東京，品川，岡山，広島に停車する在来線寝台列車を設定すると考えましょう．このとき，ふつうにスケジュール設定して運行すると次の問題が生じます．
- 品川→岡山のルートコストが減少（東海道新幹線のぞみで6駅のところが新設列車で1駅になる）する．これによって，不必要に岡山を経由するトラフィックが生まれる可能性がある．
- 東京→品川はとても需要が大きい（ということにする）ので，東京駅出発直後の下り列車に品川行きの客が大量に乗る．（東京⇔品川のような短距離客は寝台列車に乗らないでほしい）
- 品川→東京の上り列車で，品川駅から東京行きの客が乗ってくる
これらの問題は，次の対策によって解決できます．
- この運転スケジュールを臨時系統とする．すると，旅客の経由地点検索ではこの路線（寝台列車）は考慮されず，品川→岡山の最小ルートコストは14のまま（基礎点9+6駅）になる．
- 品川駅下りは降車禁止とする．すると，東京駅下りでは岡山，広島行きの客が優先して乗るようになる．（現時点での仕様では「上り品川駅で降りることはできる」ため，最後に品川行きの客が乗ってくる．なお，降車禁止は旅客・貨物の積載にのみ影響を与え，実際に降車を禁止するわけではないため，東京駅で乗ってきた品川行きの客は下り品川駅で降車する．）
- 品川駅上りは乗車禁止とする．すると，品川駅上りでは一切客は乗らなくなる．
似たようなシチュエーションとして，混雑路線を高速バスで救済するときにも使いやすいと思います．
ケース2) 拠点駅近辺でのみ混雑するのでそこだけ輸送力増強したい
JR東の高崎線では輸送力調整のため，籠原で付属5両編成を切り離します．それと同じことをしましょうという話です．
OTRPでの増解結の設定方法自体については，↓のページで図解しています．
混雑対策をするにあたって，都心側の駅のみで混雑し逆側では空気輸送になってしまうという状況はよくあると思います．Simutransにおいてこのような状況への対応としては従来，末端各駅停車になる急行を設定して遠近分離を行うという方法がよく取られてきました．OTRPではこれに加えて，末端では短編成として途中駅から増結する方法を選択することが出来ます．
例えば，高崎線で籠原駅にて上り列車は増結，下り列車は解放する場合を考えます．このとき，付属編成を親編成として先に籠原駅に入線させ，増結待ちをし，基本編成は子編成として付属編成に連結させます．スケジュールとしては，上り籠原駅のエントリで付属編成に「連結相手を待つ」，基本編成に「連結を試みる」を設定する形になります．現実の高崎線とは連結の順序が逆になりますね．（現実では高崎方の11〜15号車が付属編成として籠原で切り離されます．）
↑上り列車（東京方面行き）での編成の位置関係の図
付属編成を親編成として籠原駅に先に入線させるのは，都心側で折り返して下り列車となったときに遠距離客を可能な限り主編成に乗せるためです．OTRPを含むstandard系のsimutransでは，折返しをしても付属編成が先頭になることに注意してください．Simutransでは「近距離の客から」順番に「先頭車両から」乗っていきます．よって，籠原止まりの編成を先頭側にすることによって，籠原までの客が籠原止まりに乗り，基本編成のキャパシティが遠距離客に割り当てられるようになります．
記事執筆時点では，旅客積載は近距離の客から先頭車両から積載されるルールがあるため，高崎線のような輸送力調整のための増解結はやりやすいです．その一方，東北新幹線はやぶさ&こまちのような増解結運用はやりにくいと思います．例えばはやぶさを先頭にした場合，下り列車において東京〜盛岡間の旅客がはやぶさ側に集中することになり，盛岡以北への需要を拾うことが難しくなります．盛岡までの客がこまちに乗るのは，はやぶさが満員でこれ以上積載することができない場合のみです．
ケース3) 優等退避を安定してキレイにきめられるようにしたい
需要に応じて複数の種別を設定し，同じ路線の上に流すことはSimutransの醍醐味の一つです．速度差のある種別を設定すれば，途中で追い越しをかけることが必要になります．
従来，Simutransでキレイな追い越しを実現することはきわめて困難でした．キレイな追い越しのためにはパターンダイヤ化が必要不可欠です．従来，運転間隔を揃えるために下のような設備がよく使われてきました．
ここでは，まず列車を検車区（オレンジ）に入線させ，折り返して発車待機地点（水色）に移動させます．そこで1/32月待機なり1/64月待機なりをして，発車させます．発車待機地点から列車が出発した後すぐに検車区から次の列車が供給されれば，間隔は概ね一定になるという仕組みです．
しかしここには次の問題点があります．
- 何らかの要因で発車待機地点からの発車が一度でも遅れると，その間隔乱れは回復できない．
- 特に運行間隔が短い路線の場合，検車区の入線する線路によって発車待機地点までの移動時間に差が生じ，間隔にばらつきが生じる
OTRPやextendedで導入されている発車時刻指定機能は，「1ヶ月に何本発車させるか」を指定した上で，1ヶ月を指定された数に等分して発車させますので，こうしたばらつきを排除することができます．
正確なパターンダイヤを実現できることを利用して，所要時間を計測して緻密なダイヤを組むのは一つのやり方です．しかし，それはとても大変な作業になるのでココではもう少しラクにすることを考えましょう．基本的な方針は以下のとおりです．
- 1複線あたりの種別数は基本的に2種別に抑え，本数比は1:1や1:2といったわかりやすいものにする．
- 種別ごとの使用車両は統一する
- ダイヤの構築とともに待避設備の整備も一緒に行う
この条件下で，待避設備が一切ない路線で待避設備を作りながら優等（急行）を導入する作業を想定します．以下の作業を繰り返すと，比較的かんたんにキレイなダイヤが出来上がります．
- 各駅停車と急行を必要な本数分流す．基本的には端の1箇所で発車時刻を指定する．この時点では急行は各停を抜けないので，急行はひたすら各停のケツをほっている．
- 運転間隔が指定されている場所から急行を追跡して，急行が各駅停車に追いついた場所に待避設備を作る．各停が退避するようにスケジュールを変更し，しばらく放置する．
- 再び急行を追跡して，各駅停車に追いついた場所に待避設備を作る．各停が退避するようにスケジュールを変更し，しばらく放置する．
- 急行が行程を一周するまで以上のプロセス（2・3）を繰り返す
基本的には「急行が追いついた場所に待避設備を作ればスムーズに走れる」という単純な整備方法です．路線のある1箇所以外では発車時刻を指定しないのが特徴です．しかし，地形的な制約などで待避設備を作れない場合が生じると思います．この場合は，以下の2つの対処方法があります．
- 発車時刻指定をする駅において，発車時刻にオフセットをかける．
- 急行が追いつくより前の場所に待避設備を設けた上で，三現示信号（Priority Signal）を使用して各停を退避させる．
OTRPはstandardベースなので三現示信号が使えます．その点で，追い越し制御に使える信号が特に存在しないextendedよりもダイヤが簡単に組みやすいのではないかと考えています．この方法であれば，駅間の所要時間を計測する必要はありませんし，Oudiaを使ってせっせとダイヤを組む必要もありません．NSなどでも十分使いやすい方法であると考えています．
以上，OTRPのスケジュール関連機能について，3つのユースケースを取り上げてみました．皆さんの素敵なOTRPライフの一助になれれば幸いです．
OTRPのバグ報告について
どうも，ひめしです．
OTRPは日々多くの皆様からバグ報告をいただいております．残念ながら全ての報告に満足に対応ができているわけではありませんが，皆様のバグ報告は確実にOTRPの品質向上に役立たせていただいております．
近ごろ，「バグ報告をしたいけど何を投げればいいのかよくわからない」という声をいただきますので，バグ報告として投げていただきたいものを開発者目線から嬉しい順に列挙していきます．ご自身のできる範囲で情報を投げていただけると幸いです．
1) バグを修正するプルリクエスト
GitHub上のteamhimeh/simutransのOTRPブランチ向けにバグ修正のプルリクエストを投げていただけると泣いて喜びます．
2) バックトレース（クラッシュする系のバグの場合）
クラッシュする系のバグの場合，gdbやlldbなどといったデバッガなどで得られるバックトレースを投げていただけると，クラッシュの原因となったコードが直接わかりますので大変助かります．
なお，最近のOTRPの実行ファイルは容量削減のためデバッグ情報を削減しています．意味のあるバックトレースを得るためには，ソースコードをデバッグ情報つきでコンパイル（config.defaultのDEBUGを1以上にする）してからデバッガで実行する必要があることに注意してください．「デバッガの使い方はわかるけどコンパイルするの面倒」という場合には，私にお声がけいただければデバッグ情報付きの本体をコンパイルしてお渡しします．
3) バグを再現するセーブデータの提出
ここからは開発の知識がなくてもできる報告手段です．
バグ修正にはまずバグを再現しなければなりません．そこで，以下の仕様を満たすセーブデータを作成し，提出いただけると，速やかにバグの調査に入ることができます．
- セーブデータを開いたら画面内に当該不具合が即時（もしくは数秒後に）発生するようにする．
- 本家無印pak128を用いてマップを作る．（特別に必要な場合をのぞき，追加のアドオンは用いないでください．）
- 不具合と関係ない車両などはマップ中に配置しない．
ある特定のマップでのみバグの発症が見られる場合（バグを再現するデータを新たに作成することが困難な場合），simutransフォルダ一式（pakやsaveデータ，configなど全てが含まれている状態）をzipなどで固めてご提供いただいても構いません．
4) できる限りバグの発生条件を特定し，文章やスクリーンショットで説明する
バグの発生条件はできるだけ詳細に説明してください．最低限，
- 使用しているOTRPのバージョン
- どのような不具合が発生しているのか
- その不具合はいつ発生するのか
を説明してください．
バグ報告は2019年11月現在，twitter（@himeshi_hob），Discord（simutrans_japan），GitHubのissue（https://github.com/teamhimeh/simutrans/issues）で承っております．皆様のご協力をお願いいたします．
