とりあえずメモ、時素の照査は、絶対にパターンに示された移動距離より遠くへは進めない

時素式照査は変数が一つで演算が比較して楽な反面、一度照査が掛かるとなんらかの解除条件を満たすまで照査に食い付かれるから、できれば距離制御でマージン取りたいなあって顔 今の所行けそうなのは、どちらも50〜100Tick程度でデータを更新する方式で 速度差と加速度で算術平均から距離を導出するか、ないしは速度データを等間隔で取って直前までRMS計算してパターン修正し続けるか・・・（SQRTは基本的にあまり軽い動作ではないのでやりたくない）

しょうみこちらのforum https://discord.com/channels/799152792518393917/1199543664712614029/1200010026543231037 の内容がもっとも正攻法で、負荷が嵩むようなら処理間隔開けて「より大きな方の速度×時間」って処理すれば、一番簡単かつ軽量で、パターンが込め遅れることもなく、もっとも汎用性高くなりそうだなあ （時間的Tick処理と距離的Tick処理を棚に上げるオタク）

RMS処理をする場合は、足す前にデータを二乗してしまい、足した回数を都度分母に増やしていく事で、結果として高い精度の走行距離を求めたい目論見 一方でその為にかかるコストがデカすぎるので（サーバに負荷もかけそうだし） 今の所は既存の距離照査併用で、時素式パターンで行こうかなと思ってます（時素パターンも語通過防止程度の機能になればそれで良いし）

RMSはむしろ距離変化に対して当てる物で、速度に充てると移動距離に誤差でちゃうな、、、、って顔になってきた（おそらく平均を取らなきゃいけない）

単位系が一致してるのもなお良い（m^2\s^2の差）／（m = 距離） = ( m /s^2 ) = 加速度

できればこれの数値利用して、sqrt使わずに積だけでパターン速度出したいな・・・（メーターにパターン速度を出したいので）

メーターに速度出すのはたぶん余計な計算がいるから ブレーキ動作をやるには B5の加速等価 = 導出加速度110%〜125%（余裕みて125%にするつもり） くらいでマージン見て 15km/h下回った時点で一旦パターン解除、EB加速度で絶対停止パターンに変更 運転士の操作で正しく止まれるならよし、超えそうならEBかなあ

ーーーーーーーーーーーーーーーーーーーー 元々の本題「時間的tick処理と距離的tick処理どちらが重いのか？」は おそらく「距離」は積算、「時間」は値比較のどちらも単純な計算であり、取得回数はTickに沿うため同じで、保存回数は距離積算の方が多いので dataMapがそこまで重くなければ、時間比較と距離積算は、おそらくそこまで差はない ーーーーーーーーーーーーーーーーーーーー Tickに基づくdataMapの保存が、どの程度重い負荷をかけるかどうかが、元の本題の焦点になりそう ーーーーーーーーーーーーーーーーーーーー

そもそもATSA積んでれば https://discord.com/channels/799152792518393917/1148184638762782840/1148998351665242143 なんて感じにATSA内部の値引っ張ってこれんだよな

ーーーーーーーーーーーーーーーーーーーー ①現在速度 ②残存距離（できれば開始のみ） ③車両常用ブレーキ減速度（今回はB5想定） から 「現在速度に対応する現在のパターン速度」 って出せないかなあ 車両のブレーキの減速度引っ張って比較とかできると尚良い ーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーー そもそも現在地に合わせた適正速度を出す以上、パターン開始時点で距離積算の計算はおそらくいりますね、、、、 （速度は何度も同じ値にできてしまうので一意ではなく、パターンにどれだけ近づいているかを値として一意に定められるのは、距離か時間しかない） ーーーーーーーーーーーーーーーーーーーー んで、トラブルや誤操作があれば、時間が過ぎた後に目的の地点にいるとは限らないから 正確なパターン処理をしようとするなら、距離積算は絶対に実装としているなあ・・・ ーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーー ひーさんの式に当てはめるなら、パターンにぶつかる条件は B5相当の加速度 [ m/s^2 ] = 　目標の速度^2 - 現在の速度^2 ーーーーーーーーーーーーーーー 2 × ( パターン有効距離 - 走行距離 ) ┃ ┗ ❶ より求まる これの処理は仮に4tick = 0.2秒毎に行うとする。sqrtもいらないし、掛け合わせるくらいの処理なら0.2秒毎くらいなら重くならないだろう、という算段 これが定められたブレーキ加速度を超えた時（絶対値的に超えた時、ブレーキの加速度はマイナスであることから） B5ブレーキをかけるとおそらく良い ーーーーーーーーーーーーーーーーーーーー パターン現示の処理は、sqrtが必須なので、仮に2秒毎に走らせて補完させるつもり パターン速度を導出するには、❶の式を変形して パターン速度 [ m/s^2 ] = √ ( パターンの終端速度 +2 × ブレーキ加速度 × 残存距離 [m] ) のような式の形で求まる ーーーーーーーーーーーーーーーーーーーー 必要な値を列挙すると 01,V [ m/s ] 現在速度 : Velocity 02,VP [ m/s^2 ] パターン速度 : Velocity of safety Pattern 03,VPG [ m/s ] 最終到達速度 : Velocity of safety Pattern at Goal 04,DD [ m ] 照査区間距離 : Distance of Detection 05,D [ m ] 現在走行距離 Distance 06,AB5 [m/s^2 ] ブレーキ加速度 : Acceleration of B5 の5つより VP = ( VPG^2 - 2AB5 ×( DD - D ) )^0.5 ┃ ┗❷ から求まる、ただし VPG^2 - 2AB5 ×( DD - D ) ≧ 0 を満たす。これは条件入れといた方がいい（ 虚数は出せないからnullになるはずなので ） 大抵の場合、ブレーキパターンに入るAは A < 0であるから、項 -2AD ≧ 0 を満たし VPGは確実に VPG ≧ 0を満たすので、変な事がない限り判別処理はいらない（バグ防止というだけ） ーーーーーーーーーーーーーーーーーーーー マージンを取らなきゃいけない条件は二つ ①パターン終了距離 ≒ 全体距離 10m程度手前に取るべきだな、変数で定義して変えられるコードにするつもり ②ブレーキ開始挙動 = ある速度まで掛けっぱなし、特定速度で一度解除 （必要に応じ絶対停止パターン設定） ひーさんも触れているが、「加速度の等価で判別しブレーキを作動させると、現在距離と現在速度の兼ね合いで「ブレーキが外れる」ことがある。これは現在速度を分子、現在距離を分母に持つ関数が関係している ともすれば、一度パターンにあたってしまった場合、すぐに解除するのではなく パターンにあたってしまっている以上、かなり速度は出ているので 「解除速度」を判別した上で、目的の速度でブレーキを解除する これの条件は時素でも良いが、時素の場合掛けては崩れる可能性もあるので、速度を決めて強制減速でいい気がしている ーーーーーーーーーーーーーーーーーーーー 余談：Tick飛ばしの計算について 特に式❷に関する記述 サーバースクリプトの動作条件は1tick毎と聞いた つまり、1tick毎に毎回値を呼び出し ある数を下回っていれば、インクリメント等で値を足してdataMapに保存し、一度処理を終え 呼び出したdataMapが特定の値に到達したら、値を初期化した上で目的の処理を行う そうすれば、「tickを足す処理」が、「目的の処理」より『十分に負荷が小さい』時に限って、総合的な負荷軽減を目指すことができる この処理はおそらく一つの関数で行えるので、オブジェクト指向で開発すると「複数のTick間隔での処理」を一つの関数で行えてスマートだと考える ーーーーーーーーーーーーーーーーーーーー

ここまで書いてて分かったけど、JavaScriptの処理において確か指数の掛け合わせくらいはサポートされてるから、普通に指数に0.5掛ければsqrtいらんとちゃうか？

ーーーーーーーーーーーーーーーーーーーー 式❷の VP = ( VPG^2 - 2AB5 ×( DD - D ) )^0.5 を使って、実は現在速度と見比べながらパターンを叩くこともできるが 負荷を考えるとあまりやらない方が良いかもしれない ーーーーーーーーーーーーーーーーーーーー 【自分用メモ】 ・パターンは距離で変化する関数 ・距離積算はtick毎の結果としろ ・一連の処理に使う値は全て変数を定義して、必要なところに初期化処理を入れろ ・オブジェクト指向の開発を意識しろ ・分からないことは他のオタクに聞け ・冪乗根の計算は指数を使え ・重い処理は間引いてやれ ・長く間隔の開く処理は補完をしろ ・無茶な開発をするな ・パターンにつけるマージン等は運転士のフィードバックを取り入れろ ・メーター表示数値の計算方法を考えろ 大きさの比較をして差を取れ、位毎の値に分けろ。丸め込みは四捨五入 ーーーーーーーーーーーーーーーーーーーー

いやサポートされとらんかったかもしれん、、、（よく考えると何も思い出せない）

ーーーーーーーーーーーーーーーーーーー 本方式策定の理由 ーーーーーーーーーーーーーーーーーーー ・dataMap同期 ごく単純に、二つ動くとちょっとめんどくさそうだなあって思ったからです（最悪） サーバースクリプトを開発の基準として、描画スクリプトは動作において「子」という認識で、ペアレンタルな開発を進めた方が あとで迷いにくいかなぁという認識 ただここで心配なのは、dataMapの値受け渡し時「グローバル変数」を宣言していいのかどうか、宣言すべきでない、ないしは非効率であると考えられる場合、class的なものにまとめてから、持っていった場所でインスタンス化すばきなのか ここら辺の方式の認識が甘いので、勉強してからやりたい所存 ーーーーーーーーーーーーーーーーーーー ・速度積算関連 従来のスクリプトの速度積算は、「現在時刻」における「現在速度」と「経過時間」の積を足し合わせ、区分求積のようにする方法は 「目的の速度曲線が到達しうる距離よりも、より【多い】距離を導出してしまう」（図X） ここで、「過去距離積算」という概念を導入する 大まかな原理は ①計算開始時の「１回目の積算」の解を「ゼロ」とする（距離積算を行わない） ②２回目の積算時、サンプリングする「経過時間」に対し、「計算開始時 t1 から２回目の計算時間 t2 までの走行距離 D2-1 」を、【 ２回目の計算を行う瞬間の速度Vd2 】で行う ↑ これがミソ ③以上のパターンの通りに、計算開始から目標速度 VPG まで、距離の積算に「現在の速度」×「一つ過去と現在の間の時間」の積を、積算し続ける この方式は、現在速度を「過去の走行区間導出」に用いる事で、目的の速度曲線が時間次元でなす積 ≒ 時間×速度 = 距離の、望ましい曲線変化より、必ず「少なくなる」と分かる なので、走行中の列車は、どのような線形を描いていたとしても、確実に「わずかに少ない距離」のパターンを得ることができる ーーーーーーーーーーーーーーーーーーー ・理想 これらの処理って毎Tickやる必要ないと思ってて、間引き処理をしたいなあと思っています 今の所4tickか5Tick程度で考えてます、tick間隔は可変にしたい 特に絶対に積むのは ・Tick間隔可変（サーバー配布車両向け） 保安装置の動作間隔（更新間隔）を遅くする代わりに、負荷の低減を目指す ・パターン処理の、「運転権限がある先頭車」のみの有効化（運転士の不在問わず。中間車等ではこれらの演算は無効化する） プラスして、「負荷が同期しないための分散処理」を入れたいなと思います 同じような負荷分散タイミング（Tick分散）を持った車両が、同じタイミングで何度も処理してしまうと 特定の時間で負荷が増大してしまいがたつきの原因になります なので、列車が設置された順等で、処理を行うTickを「自動的にずらす」機能を入れたいなあと思います （衝突した場合は両方ともこの保安装置を無効化。カスタムボタン等で再起動しない限り無効） ーーーーーーーーーーーーーーーーーーー ↑ 追記します

これは個人的な意見ですが、ひーさんご提案の「処理は別々、制限開始点までの直線距離計算」もかなりすきです おそらく、この「距離計算２・直線距離」の方式は 「絶対に、線路は制限地点までの直線距離より、遠回りして走る」事から 必ず本来のパターン曲線に対して、「残り走る距離が過小に評価される」事においしさがあると思います 本来のパターン目標距離まで短く評価されるので、一時的に恐ろしい減速を強いられたりしますが ご提案の通り、この「制限開始点までの直線距離」は、制限開始点までに「必ず0に収束する」ので 値は真値では無くとも、十分な精度とスムーズな計算やコードをもって実装できると考えます ちょっと心配なのは、この方式は （例えば、制限開始地点の地上子に、終了点の座標X,Zを入れたとして） 連続する2乗根計算が必要になる事（現在の座標位置と目的の座標位置までの距離を、三平方の定理の冪根の形、で計算しなければならない） 「180°ターンとかをする路線には使えなくなる可能性が高い」事くらい（2次元（3次元？）的に開始地点を計算するから、異常にパターン開始点に近寄ると望ましくない値が返ってきて、パターンの実際の曲線が漸減曲線で無くなる）

ただ、まだ試してないのでなんとも言えませんが JavaScriptって冪乗演算（

**

）サポートしてるっぽいので NGTLib側で跳ね除けられなければ（ここ心配） X,Y : 列車の現在座標, Xp, Yp : パターン終了座標

(   ( X-Xp )^2 + ( y-yp ) ^2 ) ** 0.5

↑2分の1乗 みたいなコードでも行けそうじゃね？みたいな

調べてみたところ、べき乗の演算子(**)はES5では実装されていないようです。RTMのスクリプトはES5で動作します。

代用できるものを考えた方が良いか・・・RTMのJSがimportPackageできる中で、Math.sqrt()以外ありましたっけ

https://discord.com/channels/799152792518393917/1205026806315618315/1205823197140746260 これにも書いたけど、うちの今の所の開発方針は ーーーーーーーーーーーーーーーーーーーー ① dataMapは合わせる（コードミス防止と親子関係明確化） 現状： 受け渡しグローバルで良いのか ② 距離はベクトル方式ではなく求積方式を取る（ただし曲線未満） 現状： dataMapの１回目計算の無視の処理を積みたい ③ Tickに間引き処理を入れてMath.sqrtの呼び出し回数を減らす 現状： 望ましくないTick計算の偏り防止を目指して、車両ごとにタイミング衝突を見て負荷を分散させたい ④ パターン開始時間は、現在速度から「加速度」を導いて判別 パターン開始時、特に15km/h以上等、任意高速域では、終了距離を車両側の指定で「減らす」事で、確実な速度コントロールを目指す 現状： 距離の積算処理が正しいかどうかに全てかかっている処理なので、実装が不安 ⑤ パターンブレーキの遷移域（加速度がぶち当たりやすくなる場所）では、いちどパターンブレーキにあたると、時間又は速度変化量、走行距離のどれかを基準に、ブレーキをかけっぱなしにする（ガタ付き防止） 現状： でもこれって、要するにパターンに当たったらブレーキを掛ければ良いんだから ブレーキ解除はプレイヤーの任意にして、パターンに当たった瞬間で任意加速度のブレーキ（たとえばB5）を一回だけ掛ける、とかじゃダメかなあ？ 注） ・以上の考察において、ブレーキパターンの加速度は、車両から取得する。今回はB5の加速度を取得するものと考える ・加速度計算は、ブレーキ開始距離の演算に用いる※１ ・速度計算は、パターン速度現示の為に用いる※１ （※１：パターン速度の現示の計算のみとし、現在速度をこれに当てはめてブレーキ開始をしても良い。しかし速度の更新を間引きたいので、振り遅れが発生する可能性がある） 修正： ②, 速度 → 距離 （減算求積方式） ーーーーーーーーーーーーーーーーーーーー

ありがたやありがたや……………

ひとつ質問 今回は サーバ → レンダー（描画）間でdataMapの値を共有するけど dataMapメソッドって、引数にあるString ≒ 文字列があってれば、音声スクリプトやワールド内のjs実行可能ブロック（例：ATSA,IFTTT）でも引っ張り出せます？ 修正： サーバー → レンダー 矢印の向き （描画スクリプト側から送信は行わない）

どのみち間引いて更新って形になるので、要求加速度（パターン比較）・現在速度・残存距離はdataMapで保存と呼び出しを繰り返すつもり

一連のシステムは今度配布する車両に搭載してみたいな〜と考えていたりします 色んな方からのご意見お待ちしてます☺️ とりあえず試験やって欲しいって名乗り出てくれてる鯖があるから、そこでβテストしてからどこかの線区で実際に試運転かなあ

ちょっと動かせそうなので考えをまとめておく RTM向けパターン制御式保安装置システムの概要 【目的】 ・列車の保安装置として、ブレーキ動作閾値となる「照査パターン」を作り、車両情報を参照して、「ブレーキをかけるシステム」を作る （アクセルは含まない） 【前提】 ・RTMは、すべての車両において、各ノッチ毎の「ブレーキ加速度」は同じはずである ・各スクリプトはRTMのcore？によって、毎tickや毎fps繰り返し実行されている →dataMapと照らし合わせることにより、簡易的な「forコード」を作ることができる（擬似的な区分求積ができる） ・RTMやMinecraftには様々なメソッドがあり、中にはエンティティ間の座標を取得できるものがある ・環境はKaizPatch環境を用いて、ATSAssitMODの機能を最大限活かせる環境だとする

https://discord.com/channels/799152792518393917/1211662850917929010/1212404824264671253 これに連動して、将来的にMOD化を考えたい パターン式ATSのシステムの根幹に、「進行を指示する距離（以下：進行距離）」がある 進行距離を定義して、「進行距離より先に進んではならない」という前提を作ることで 車上側で「残りの進行距離」を速度発電機により計算して、「進行距離限界まで進める"パターン"を用意する」という制御ができ この「距離基準の進行指示」によって、パターン式ATSは「安全に走れる距離」を厳格に決定し、相互に安全距離を保って走行が可能なシステムである つまり、パターン式ATSを実現させるには ・自列車のブレーキ加速度 ・自列車速度 ・進行距離（停止まで） ・進行距離（指定速度まで） ・指定速度 ・自列車の走行距離（積算和） →走行距離に基づく残存の進行距離 の情報が必要になる これら「進行距離」は、進路ごとの「残り進めるレールの距離」として表される パターン式ATSにおける、この「進行距離」を計算する方法として 俺はリンク先のチャットの通り、 ①レールの長さを取得し積算して車両に送る方法（車上アクティブ式）と ②あらかじめ進行距離を調べてブロックなどに格納し、進路ごとに車両に送信する方法（車上パッシブ式） の二つを考えた ①はRTMの特性に合っており、頻繁に付替のされる線路に素早く順応できるが y字分岐など、難しい進路においても、進路ごとに距離を自分で積算しなければならず、距離走査の処理に負荷がかかることが予想され ②は現実の仕組みに近く、地上子に「進行距離」を格納することで、各進路の切り替えに対し、仮に線路から進行距離を類推できなくとも、決まった値で進行可能である 一方で、ハードウェアの更新に弱く、都度更新工事を必要とする 以上の課題点から、RTMで速度パターンを作るためには ❶更新工事覚悟で、地上主体のシステムを作る か ❷開発が難航する事を前提に、車上主体のシステムを作る かの二つが考えられた 俺はまず❶で開発を試みるが、RTMのその「可変的なワールド」の特性を鑑み、将来的に車上主体のシステムを作りたいと考えている ・・・ ❷の提案 たとえば、車両から全ての計算を行うことは大変なので 全ての車両がサーバー内で共有する「ATSデータベース」を作り、これにアクセスして進行距離を得る（ATS-Dx）などの方式も良いと考える つまり、一度列車の走行が必要になるが、WebCTCのRailGroupなどの機能と組み合わせ、レールをUUIDの連鎖で管理することにより（一本のレールに対し、前後関係をUUIDで作ることにより） 試運転列車にてレールのつながりをサーバーに記録（または上書き）していき サーバー独自の「レールデータベース」を作ることで 進路に応じ「残り距離」を自列車に送られた信号で決定して レールデータベースから進行距離を生成する、なんてのもアリかなと考えた 現状の考えうる仕様は以上、他にも提案があると助かる🙏 2025-03-25 K-LXYS パターン式ATS開発室