↑ 今の所のK-LXYSの見解 WebCTCを用いて、RailGroupの前後を、軌道回路のポイント転換の向きなどから「連鎖的に、軌道回路を連続的に取得する」ことで逆算し 現示もこれらと一緒に、距離に対しての値として返したいなと考えています

サーバー側による完全集中処理ではなく、ある程度分散型で必要に応じて現地処理……という方向性はなんとなく弊社システムと近い気がするので、何かしらのヒントになれば幸いです……

信号現示の連動も、論理の破綻が起きないよう単一の制御室で一旦連動を組むのですが、現地の信号機はロードされた時（誰かの画面に描画されている特）のみ制御室へデータを取りに行く仕組みになっていて、読み込み範囲外のチャンクをローダー等で常時読み込ませる必要が無く、チャンク凍結による回路不良も起こりにくい……という発想なんですが、まだ技術的に未完成のままではあります

Kaiz先生とお話して、望ましい仕様を思いついたのでまとめる ①WebCTCキャッシュ利用型（理想） WebCTCを使ってすばやい動作を目指す方式 WebCTCを利用して、前もって読み込まれた軌道のキャッシュから連続的なデータを取得し、距離を積算して進行可能な距離を割り出し、これをパターン動作の限界距離とする 現実のATACSに近い方式だが、デジタルATCのようにパターン開始位置は固定され、またパターンの動作タイミングは、原則軌道回路の切れ目に準ずる 最もハードウェア依存度の低いソフトウェア設計だが、そのぶんWebCTCのような「在線やレール接続が確実に読み出せるMOD」が無い限り、全くとして開発の見込みがない ②軌道DB構成、条件複合距離算出（現実） 軌道データをDB化して、組み合わせの呼び出し方を各軌道回路に覚えこませる方式 あらかじめ、軌道の状態を取得してデータベース化し、これを読みだして、「疑似的な軌道構成と軌道状態」を作り出す方式 もっとも現実のATCに近いが、応用力にかける上、ハードウェアとソフトウェアの依存度が高く、どちらかの更新時にもう片方の更新を伴い、工事が煩雑になる可能性が高い ③全軌道状態チャンク読み込み、条件複合距離算出 （強引） WebCTCが使えないなら、Worldのデータを常に有効にしておく方式 逆手にとって、あらゆる動作条件をレッドストーンやDataMapとして保存し、制御だけはスポーンチャンク等への集中も可能 ただし、こちらもハードウェアとソフトウェアの依存性が強く、頻繁に進路の変わる路線には適さない 以上３つの中から、最も適切な方式を検討する それまでは、弊開発陣は「列車側のデジタルATCを想定した表示機器類の、開発及び動作安定化と、コードの洗練化」すなわち、機能開発とリファクタリングに徹する予定 なお、「アクティブでワールド状況に合わせた距離取得、軌道状態を常に見ながら、列車の速度基準で計算した任意の距離から、列車の減速パターンを作る」タイプのデジタルATCは 現状でとっっっっっっっても開発が難しいので中止！！！ 理由はいくつかある 【主】 ・軌道状態をアクティブなチャンクに絞り、なおかつ前もってリスト化された軌道状態を読むには、MOD開発が必要になる 【副】 ・離れたチャンクの軌道データをキャッシュ化して、取得して列車の制御に生かせるようなMODは、現状でWebCTCしかない ・WebCTCはそのシステムの都合上、レールグループなどの距離や前後のつながりを、JSのスクリプトから取得することは、できない ・MOD開発が必須となると、大幅な時間がかかる事と、現状の知識では開発に届かないこと。デジタルATCを想定した動作を実現するには、WebCTCなどとリンクできる、複雑な処理とMOD開発が必要になること ・内部的には、ATSAのATACSのような動作を期待しており、代替策が複数考えられること 等々 なので、弊開発側では 「ATSAにより強く踏み込んで、あくまで既存MODの仕組みで、前方の信号をエミュレートする」方法で より簡単に確実に動く仕組みを考える

webCTCみたいに、一度読み込まれた事のあるレールをリスト化して、繋がってる隣のレールを判別して、都度距離を算出できれば、あとは距離を足し合わせつつ、間引き処理をするだけで 大分軽い動作で、デジタルATCっぽいやつが作れると思うんだけどなあ でも、都度距離基準にして、リストの更新をチャンクを読んだ瞬間にすると、不慮の進路変更に適切に対応できない気がしなくもない