Rosso Laboratory

Rosso Laboratory

主に鉄道模型シミュレーター(VRM)などの仮想鉄道アプリを扱うブログです。またHDR写真の記事も書いています。

編成を解結する話・新規命令提案編

さて、前回の続きで解放と連結に関する話ですが、こちらは難しい話ではなく、こういうスクリプトの命令を準備しておいた方がイイんじゃねぇ?という提案です。そのうち会議室に放り込むかも。

仮にこの命令を「CoupleMode」と名付け、編成の連結制御を決定するものとします。

あ、よくよく調べたら、
2007/1/16 VRM入道「そんな餌にオレ様がクマー
と見事なぐらい被ってるなぁ。まぁイイっか。


---*---*---*---

CoupleMode 0
 これが書かれた編成に対しては、一切の連結を受け付けない。

これは「LAYOUT SUPPORRT BOOK」レイアウトを作っていた時に欲しいなぁと思った命令です。あのレイアウトは手動運転なので、間違って編成がぶつかり連結してしまうということが発生し得ます。一度連結すると編成が長くなり過ぎて、以降の運転が不可能となるケースもあります。

また、あのレイアウトはキーによる操作を前提としており、キーで編成をアクティブ化しようと思っても、編成の連結で元の編成が消滅した場合、そのアクティブ化キーでビューワーが即自爆ということになります。Turn命令も同様なので、アクティブ化と反転をキーに割り当てられず、操作性がイマイチになったという経緯があります。もし、この「連結不可」の設定が出来れば、この問題を回避することが出来るでしょう。連結したい時は連結したい場所で他のモードに変更すれば良いだけですし。


CoupleMode 1
 これが何も指定しなかった時のデフォルト値。

つまり、現在の連結動作の設定なので省略。


CoupleMode 2
 これが書かれた編成は「CoupleMode 1」とは逆に連結時ぶつけた方が優先となる。
 また、解放時にはスクリプトの複製を実行しない。

 そうするとSetEventUncoupleなるものも出来るかも。

これは「西濃鉄道ホッキホキ(仮称)」を作っていた時に欲しいなぁと思った命令ですし、多分こちらの方がユーザーにとって解り易いだろうと思われる設定です。

現状の連結は停止している編成が優先されるので、機関車をぶつけると機関車の編成が消滅してしまいます。まず、根本的にこの考え方がイマイチと感じますし、幾つかの問題点もあります。

<問題点1>最高速度設定が食われる
機関車の編成が消滅し、貨車・客車側の設定のみが生き残るので、機関車毎の性能差がなくなってしまいます。

<問題点2>方向設定が食われる
当初「西濃鉄道ホッキホキ(仮称)」ではDE10とEF65をGetDirection2で判別していたのですが、これも貨車・客車側の設定のみが生き残るので、連結・解放を実行すると初期状態がなくなってしまいます。なので、GetDirection2の利用意義も弱まってしまうでしょう。

<問題点3>名前が変わっていく
「機関車入換えホッキホキ」では具体的に追跡カメラによってビューワーが強制終了させられるという問題も起こしている部分です。機関車がそれぞれDE10やEF65といった初期設定状態のままでいられれば、恐らくこちらの方が使い易いでしょう。

<問題点4>車両数の違う機関車編成に換装しづらい
現仕様でも恐らくは出来ると思いますが、多分スクリプトは少し複雑になることでしょう。もし、機関車側の設定が生き残れば、その機関車側のスクリプトに書き込んだ自分の車両数の位置で切り離しが出来るのでかなり楽になるはずです重連北斗星用DD51がなかなか出てこないのもこの辺の影響もあるのかな?)

といった問題点が挙げられますが、どうして現状がこのような仕様になっているのかを想像することも出来ますので、それを書いた上で、この「CoupleMode」の仕様及び使用方法を絡めます。

<こういう連結方式になった経緯の推測>
連結・解放で最も馴染みがあるのは、貨車や客車を牽引する機関車付きの編成です。この場合、貨車や客車は自力走行出来ませんから、貨車や客車にスクリプトを複製する必要はないでしょう。しかし、「EF63+あさま」や「行き先の違う編成」といった併結運転の場合には、分割後それぞれが動作できる状態にする必要があります。そこで、スクリプトの複製ということが必要になります。

さて、このスクリプトの複製が必要になるということはどういう問題を引き起こすのかというと、機関車側が優先されると、

「EF63」+「あさま」
   ↓(連結)
「EF63」
   ↓(解放)
「EF63」+「EF63_1」・・・①
   ↓(連結)
「EF63」
   ↓(解放)
「EF63」+「EF63_1」・・・②

となりますが、1度消滅した①の「EF63_1」が再び②で復活します。どうもこれがうまくないのではなかろうかと思われます。複製されたスクリプトが1度消滅し、再び復活する。VRM4の連結では、編成は消えてもスクリプトはメモリ内に残っているようなので、これを実施するとまたビューワーが強制終了する状況になるのではないでしょうか。故に今のような方式で、どんどん名前が変わっていく仕様が必要になるということなのだろうと推測します。

さてここで、「CoupleMode 2」の「解放時にはスクリプトの複製を実行しない」という仕様が意味を持ちます。複製しなければ多分問題ないでしょ?という結構安易な考え方ではありますが(笑)。

よって、連結させたくない編成には「CoupleMode 0」、併結運転が必要な編成には「CoupleMode 1」、自力走行を必要としない貨車や客車を牽引する編成には「CoupleMode 2」とすれば、恐らく連結・解放は大分扱い易くなるのではないでしょうか。そして、多分併結運転用の「CoupleMode 1」は殆ど必要とされないことでしょう。

---*---*---*---

細かい技術的な部分で問題もあるかもしれませんが、光源を256個も使う腕があるアイマジック社ならきっと何とかしてくれることでしょう。折角、VRM4以降には連結・解放の機能があるのですから、より使いやすく、そしてより多く利用されることを願って。