2008/2/19

SearchPoint命令の使い道がない件  VRMスクリプト禅問答
数あるVRMスクリプト命令の中でも、特に変だなぁ、と思っているのがアップデータ4.0.7.0で追加されたSearchPoint命令。

ここしばらく、ボクの中で自動トグルポイントスクロールが流行っているんだけれども。もし、レイアウト上の編成が(1)進行方向直近のポイントの名前を常に知ることが出来て、かつ、自分の(2)侵入経路がポイントのどの“口”かを知ることが出来たら、トグルポイントと組み合わせることで、どんな複雑なトラックプランを組んでも(エンドレスである限りは)絶対にポイントで行き詰ることのない自動運転なんてのを実現できるじゃん、とか思ったワケ。

トグルポイントだとトラックプランによっては一部絶対に編成が通過しない経路、なんてのが出来るかも知れないけれども、トグルロジックをランダム切替に変えたスクロールを作るのは簡単だし。最低でもリバース区間が1つあれば、進行方向のせいで進入できないポイントも克服できるし。まぁ、編成が2つ以上あると、衝突のことを考えないといけないけども、これは閉塞とかをちゃんとやればなんとでもなるので。

でも、賢明な人はもう気付いていると思うけども、SearchPoint命令で前述の下線部(1)の条件は満たされるんだけども、編成が(2)を自律的に知る(ユーザーがセンサーとかで教えなくても良い、の意)手段がないので、今のところはそういうのは作れないのね、残念。んで、そういうことを考えてたときに、おや?と思ったのが冒頭に書いたSearchPoint命令が変だってこと。いや、動作が変なんじゃなくて、小難しい言い方をすると“実装ポリシー”が変だ、って話。


最たるものは、いったい「いつSearchPointを使うの?」という話。厳密にいうと、どのイベントをトリガに使うかって話で、まぁ、普通に考えるとセンサーイベントなんだけども、よくよく考えてみると、センサーを配置したユーザーは進行方向のポイントが何になるか知ってるんだから、命令で(しかも距離まで指定して)調べる理由がないのね。しかも、ポイントオブジェクトを取得するのは編成なので、結局そこからポイントのメソッドをcallしなきゃなんない。だったら、センサーから直接(パートナーとなることが自明な)ポイントのメソッドをcallした方が素直でしょ。

で、センサーイベントでないとすると、もう実用に供するのはタイマーイベントしかないのよ。つまり、数秒毎にSearchPointして、進行方向のポイントをみつけたら何かする、ってこと。でも、これはこれで変なのよ。だって、下線部(2)を知る方法がないから、ポイントがわかっても、そのポイントをどっちに切り替えたら意図した方向へ行けるのか、いや、そもそもそのポイントを通過できるのか、がわからない(厳密に言えば、ロジックだけで決定できない)。結局、センサーで「次のポイントは正/反位だよ」と教えないと使えないワケで、だったらそのセンサーでポイントを制御すりゃいいワケ。

仮にその問題が解決されたとしてもだよ。SearchPointは指定距離内にポイントがあれば常にオブジェクト名を返すんだから、これはタイマーイベント毎にポイント制御ロジックが実行されるのと等価。ってことは、ポイントを見つけて然るべく制御した時点でタイマーイベントをKillEventするのが正道なんだけども、すると、こんどは、ポイント通過後にイベントを再設定するためのセンサーが必要になって、結局レイアウト上のセンサーの数はSearchPoint命令があっても減らないのね。

まぁ、最初にポイントが検出された時点でポイントまでの距離はわかっているから、以降、別のタイマーイベントから走行速度を監視し続け、走行距離の近似値を得てポイント通過後にイベントを再設定する、って手もないではないけど、普通しないでしょ、そんなこと。

で、思うワケ。何に使って欲しかったんだI.MAGiC?

揚げ足取りばっかでもアレゲなので、答えを書いてしまうんだけれども、本当は以下に示すような命令を実装すべきだったと思うワケよ(命令名や引数仕様は適当、心を汲め)。

・SetEventFoundPoint {メソッド名} {イベント変数}

ポイントが進行方向一定距離(SetPointSearchRange命令みたいなので検知範囲を変更できるとなおベター)に現れた時点で発生するイベントを設定する。

・GetFoundPoint {ポイント変数}

センサーイベントに対するGetSenseTrainと同じ。SetEventFoundPointで見つかったポイントの名前が得られる。

・GetApprorchingBranch {変数}

進行方向に検知したポイントのどの経路に編成が進入するか、がわかる。Set/GetPointBranchのパラメータと対応。非分岐側から進入する場合、または、ポイントが検知されていない場合=これは「何もしなくて良い」等しい・・・場合は-1が返ってくる。

こんな実装だったら最強なんだけど。要するに、実装ポリシーをセンサーや地上カメラの編成検知に揃えましょうや、というお話。

最後のヤツ(GetApprorchingBranch)は、VRMが内部的にそういう情報(ポイントの任意のジョイント部が、そのポイントにとってどの口になるか)を参照可能な形で持っているかがわからないので、原理的に実装できない可能性もあるけれども、上の2つは、条件待ちメソッドを書けば今でも実現できるロジックなので、VRMシステムに埋め込めないはずがないんだな、コレが。

まぁ、仮にこういう命令が将来実装されたとしても「何に使うんだ?」という気がしないこともないんだけれども、何と言うか、コレは美学の問題かも。あと、以上はボクが阿呆で使い道が思いつかないだけの話かも知れないので、何か面白いアイデアをお持ちの方は教えてください。
0

2008/2/19  7:05

投稿者:ghost
その発想はなかったわ!>moko殿

2008/2/19  0:48

投稿者:moko
センサー未収録の1号限定でレイアウト作る際にポイントを制御させられるように・・・とか思ってたんでしょうかね。

コメントを書く

この記事にはコメントを投稿できません




teacup.ブログ “AutoPage”
AutoPage最新お知らせ