なぜかわからずにいたのですが、ooyodoで操舵していると、それに合わせて左右に大きくF1M2のラダーが動いているのを見つけました。
原因を究明できてはいませんが、ooyodoのFDMであるShip FDMの仕業を疑っています。ｒｕｄｄｅｒと名の付いた部品を動かすプログラムが記述されているのではと考え、F1M2のラダーの３Dオブジェクトの名称をrudderからrudder1に変更してみました。
以来、ラダーが異常な動きをすることはなくなり、その他の不都合も発生していません。
私の場合は、しばしば地味な軍用機塗装を目立つ明るい色に塗り替えています。
わがF1M2にも、いくつかの塗装のバリエーションをつくったのですが、これらをAI機としてooyodoに搭載しようとして、少々困ったことになりました。
すでに解決したことですが、パス指定が不適切でF1M2の機体が黄色く異常発色したこととあいまってパニクり、指定通りにテクスチュアが表示されないとあわてたのです。
よくよく考えてみれば、めったにしないことなので失念していましたが、何もペイント毎に.acファイルをもうけなくても、ペイント毎にフォルダをもうけてそれぞれのテクスチュア画像をいずれも同じ名称にして入れておき、フォルダを指定することでペイントを選択することができるのでした。
AI用のF1Mをフォルダごと刷新し、問題の解決したF1M2本体や搭載のためのF1M2のAI機を同梱したooyodoなどとともに、今一度ダウンロードできるようにしました。
FlightGearの日本のサイトに、F1M2の画像を投稿していたら、さっそくHiTouchさんが反応してくださり、深夜にもかかわらず機体をチェックしてくださったようです。ほんとうにありがとうございます。
HiTouchさんによれば、テクスチャの記述は何かとややこしいそうで、「,ac
ファイルと同じフォルダ階層にリンクされたテクスチャファイルが必要だったり、最近ではExitで終了するとその時点でのliveryの状態が保存されるようになっているためテクスチャファイル名を変更したりすると読み込めなくなり黄色く発色することがあります」とのこと。
問題は、3DモデルファイルのF1M2.xml中のテクスチャ指定箇所でfgfsのルート下からパス指定していなかったことが原因。フォルダ名を含めずファイル名だけの指定だと黄色く発色しますが、HiTouchさんのご教示どおりにテクスチャ<texture>Aircraft/F1M2/Models/texture.png</texture>とすれば、黄色く発色することはありません。
本機の他、AI機、あるいはooyodo搭載、AI用ooyodoに搭載のものと、4つのF1M2のファイルを扱っていたもので、私の頭が混乱していたのでしょう。上手く問題点をきりだすことができなかったようみたいです。
AI機の方は、パス指定まできちりとしていたつもりですが、テクスチャが指定どおりには表示されなかったため、また別な問題があるのかとすっかりあきらめていました。今一度、落ち着いてチェックしてみます。
おかげ様ですっきりしました。救われたのはF1M2というよりも自分勝手なvirt_flyでした。
