VRM入道

チラシの裏的備忘録。

●おそらく簡単に実装できて、それなりに効果があるもの

【編成】GetTurnStatus [Variable(int)]

ビュワー起動時の先頭車方向へ向けて走行しているか、あるいはその逆かを取得する。要するに、[Home]キーを押した回数＋Turn命令を使った回数の合計が偶数か奇数か、ってだけの話。

【編成】GetMe [Variable(train)]

この命令が実行されたコンテキストが所属する編成オブジェクトを取得する。こちらのエントリで言及したObjMeに相当。要するに動的なthis。

【ポイント】SetEventBranchChange [Method] [Event Handler]

ビュワーメニューまたはSetPointBranch命令によってポイントが切り替わった際に、任意のメソッドをトリガするイベント設定。コレとかコレでやっている“タイマーイベントでGetPointBranchの値を監視する”って手法は、あまりスマートでないので。

【信号】SetEventSignalChange [Method] [Event Handler]

SetSignal命令によって信号灯火が遷移した際に、任意のメソッドをトリガするイベント設定。ポイント位と異なり、信号遷移はスクリプトでしか起きないのでSetEventBranchChangeほどの重要性はないが、これがあれば、区間閉塞や中継信号その他を実現するために、無駄なタイマーイベントやアドオン記法を弄せずに済む。

●実装が厄介そうだけども、あれば面白くなりそうなもの

【編成】GetGradientRatio [Variable(float)]

先頭台車が乗っているレールの、両端の高さの差÷レール長（つまり勾配率）を取得する。GetDirectionの値と合わせて評価すれば、上ってるか下ってるかもわかる、みたいな。後述するSet/GetAccelerateと対で使う想定。

【編成】Set/GetAccelerate [Variable(float)]

直接的には、トラコンモードでノッチが入っていないときの減速率を設定/取得する。ノッチに応じた加減速に影響するならなおベター。前述したGetGradientRatioと組み合わせて使うことで、下り坂で加速し、上り坂で減速するギミックを実現できる。

【編成】Set/GetTrainCameraRoll [Variable(float)]
【カメラ】Set/GetCameraRoll [Variable(float)]

カメラの左右への傾き角を設定/取得する。値はラジアンか。取得はなくてもいいような気もするが、カントレールが使われていれば、編成が曲線を走行中か否かをスクリプトで知ることが出来る（編成先頭が振り子車かどうかも判別できるわな）というオマケが付く。何の役に立つかは別にして。

【全般】GetObjectPosition [Variable(Object)] [Variable(vector)]

任意のオブジェクトの座標をベクトル変数に取得する。出来ればすべてのオブジェクトに対応して欲しいが、とりあえず編成と車両（いずれも進行方向台車座標でOK）に対応してくれれば神。あとは適当に何とかする。

●とりあえず、とっととリファレンスの記述通りに動くようにして欲しいもの

【編成】SearchPoint
【編成】SetTopSpeed
【編成】AutoSpeedCtrl

コイツらが放置状態な現状では、上に書いたような要望も虚しいわな。っつーか、対応する気がないならないで、中の人にはその旨を明言して欲しい。そのくらいしても罰は当たらんだろう。

と、アウトプットしておかないと忘れそうなので、チラシの裏的に書き出してみた。まぁ、実装されたところで、ボクしか使わないんだったら意味ないけど。

結論から言うと、厳密には編成スクリプト内でcall/SetEvent〜命令のパラメータにthisは使わない方がいい、という話。まぁ、言っているボクもそこまで徹底してませんが、来るべき次期自動運転スクロール/フレームワークでは、以下に紹介する方法論を採用したいと思ってます。


まず、基本的なところをおさらいしておきましょう。たとえば“TRAIN1”と命名された編成があるとします。ここに以下の編成スクリプトを書いたとします。

＜編成スクリプト＞

BeginFunc MtdA
  call this MtdB //thisのMtdBをcallする
EndFunc

BeginFunc MtdB
  SetTimerVoltage 0.0 10000 //10秒かけて停車する
EndFunc

まぁ、普通は書かないスクリプトですが、説明の便宜上こうしておきます。要するに、メソッドMtdAを何らかの方法で実行すると、メソッドMtdBがcallされ、編成が停車する、という流れです。

さて、メソッドMtdAを実行すると常に編成は停車する、と言えるでしょうか。答えはNoです。これは特別な識別子であるthisの挙動によるものです。thisは、ビュワー起動時に「thisが書かれた部品の名前に読み替えてコンパイルされる」という性質を持っています。従って、編成以外の部品であれば、上に示したサンプルスクリプトは常に意図通り動作します（SetTimerVoltageは編成部品以外に書いても意味がないですけども）。

しかし、編成部品についてはこれが成り立ちません。問題になるのは、編成の分割と併合に際してです。

ここまでの流れ。

SearchPoint命令って使い道ねーじゃん
　　　↓
いや、こんなことが出来るぞ、ゴメンよI.MAGiC！！
　　　↓
そしたら、こんなことも出来るんじゃねーの！！
　　　↓
あれ・・・仮組みしたけど意図通りに動かねーぞ？
　　　↓
やっぱり駄目じゃん・・・＠ ← 今ここ

結論から言うと、SearchPoint命令が検出できるのは、命令を実行する編成の先頭台車が踏んでいるレールの（進行方向に）次のレールがポイントの場合に限られることがわかりました。

つまり・・・

＝［編成＞＝□＝(128mm)＝□＝(128mm)＝□＝(ﾎﾟｲﾝﾄ)＝・・・

こんな経路があったとします。編成が左から右へ向かって走行しており、タイマーイベントでSearchPoint命令の第1パラメーターに256.0を与えて実行し続けているとしましょう。製品付属のスクリプトリファレンスの記述通りであれば、編成が1つ目のジョイントを通過した時点でポイントが検知できるはずです。が、実際には、2つ目のジョイントを通過して、ポイントまでの距離が128mmを切らないと検知されません。

現時点でリリースされているVRMの最長レールはIFLX384（384mmフレキシブルレール）であり、これを伸ばして得られる最大直線は512mmです。ポイント切替のためのガイドメッセージを出したり、ポイントを閉塞点と見做したりするには些か短距離であり、それ以前に、ポイントの直前に必ずロングレールを配さねばならない、というのはナンセンスです。

ゆえに「SearchPoint命令はやっぱり使い道がない」と言わざるを得ません。いや、厳密に言えばコレしか使い道がない、と言うべきでしょうか。っつーか、リファレンスの記述を真に受けて、ボクが投じた無駄な時間を返してください、な気分。

そんなこんなで、ちょっとvrm4cv用スクロール開発は、頓挫とは言わないまでも、対応要度がボクの中では激減してしまいました。まぁ、誰に求められているワケでもないのでどっちでもいーですが。

どちらかというとI.MAGiCの中の人向けアイデアメモ。

独り言：
今回の事例もそうですが、せめてスクリプトで部品や変数の有無を確かめる条件式が欲しいですねぇ。それがあれば必要パッケージを持っていなかったり、編成を変えたりしても今より柔軟にスクリプトを組めると思いますけど。

slack diaryのCaldia氏のコメントより

Caldia氏の言っているのは、たとえばC言語におけるディレクティブに当たるものになると思うんですが。

(1) ほとんどのVRMユーザーは、VRMスクリプトがコンパイル型言語処理系であることについて無自覚であること。すなわち、スクリプトの字面はビュワーが起動する瞬間にのみ意味があり（thisに関する挙動が典型的）必ずしもそれぞれのスクリプト命令が実行される瞬間と一対一対応しないこと。
(2) ゆえに、階の異なる言語処理系（VRMスクリプトがビュワーの挙動を決定するのに対し、Caldia氏の言う仮称“VRMディレクティブ”はコンパイラの挙動を決定する）を、一般的なVRMユーザーが理解できるとは思えないこと。
(3) 仮に理解するユーザーがいるとして、VRMユーザーのスクリプトを書く目的は、第一に自分のVRM環境で動作することであり、他人のVRM環境での動作を保障するためにVRMディレクティブを厳密に記述する人がいるとは思えないし、仮に記述したとしても、記述した本人のVRM環境ではその記述が正しいか否か判断できないこと。

以上の3つの理由により、ちょっと違うんでないかい、と思ったワケです。

で、以下は、ユーザーにはどうでも良くて、中の人にご一考いただきたいと思うことなのですが。

第4号の音源部品を使った作品であっても、そのメソッド/グローバル変数を外部から参照しなければ・・・つまり、音源部品が他の部品の状態をタイマーイベント等で監視して発声するようなロジックを採用すれば、第4号が欠落した環境であってもビュワー起動を阻害することはない。

音源部品はアップデータでみんなに配るべきじゃね？ より

について無問自説。

2つのオブジェクトが連携して何かが起きる仕掛け（もっともイメージしやすいのは、センサーが編成を検知したら何かが起きる、というパターン）を実現するには、大雑把に考えて二通りの考え方があり、それぞれに一長一短があるという話なのだが、上掲引用元つながりで「編成がセンサーを踏んだら音源部品で音が鳴る」を例に示してみる。

音源部品を例にしてはいるが、理屈は信号機などの「主にセンサーから駆動され、一部のパッケージにのみ収録されている部品」すべてに共通する考え方だと思ってもらっていい。


上掲例が“普通の書き方”になる。センサーが編成を検知すると、SetEventSensor命令のイベント設定従ってメソッドMtdSenseTrainが実行される。その中のcall命令によって音源BELL1のメソッドMtdPlaySoundが実行され、音が鳴る、という流れだ。

図中、オブジェクト（部品）間の名前の参照を赤い矢印で示している。具体的にはオブジェクト名BELL1とメソッド名MtdPlaySoundが、センサーSENSOR1側から音源BELL1に向かって参照されていることがわかる。

このようなスクリプトを含むVRMレイアウトを、音源部品を含む第4号がインストールされていない環境で開くと下掲図のような状態になる。


色を薄くしている部分は、スクリプトも含めて、ファイルを開いた時点でレイアウト上から消えてなくなる。この結果、参照先を失った赤い矢印（×印で“参照できない”ことを示している）がビュワー起動時にエラーとなり、レイアウトをビュワーで見ることが出来なくなる。