2010年6月30日水曜日

XPS M1730 の BIOS

SpeedFanでファンを制御できるようにする方法はないかと思って検索中。
まだ無いらしい。
これからもずっと無い気がする。

で、偶然発見したんだけど
DELLのコミュニティサイトでXPS M1730のBIOSのBIOSのアップデートしてくれコールが、ささやかに巻き起こっていた。

日付が2007~2009年で、ポストもそう多くは無いので少数派だとは思うが氷山の一角かもしれない。

一部の放熱ファンが75度超えないと回りださないので、そのせいで壊れていると思っている人が何人か報告していた。

うちもその線のような気がする。

うちの場合、モデラーでぐりぐりやると、一瞬のうちに10度ぐらい跳ね上がるので、気が付かないでいるとファンが回りだすまでのタイムラグで100度も越える。

ファンが回りだすと50度前後まで落ち込むので、常時回ってれば、かなり有効に機能するのだが。
もったいないことに普段は全く機能していないのだ。

回りだしても、音はデスクトップほどじゃないので、気にするほどでも無いと思うのだけど。
ファンの回転をここまで押さえ込む必用があったのだろうか。


このマシンで、オーバークロックはやった事が無いんだけど。
XPSは、BIOSで4段階、手軽に変更できるようになっている。

で、3.2GHz以上にすると、そのファンが回りっぱなしになるらしいんだけど。
もしかしたらそっちのほうが、延命できるんじゃないかと思ってしまう。

XPSの底面切り取って、今のGPUのヒートシンクとっぱらって、別なのつけたりできないものか。

自分の使い方が悪いのかと思っていたが、フォーラムを読む限り、地雷だな。対戦車地雷なみだ。
買ってはいけないPCのような。

Inspiron 8100 はいいPCだったんだけどな。

まあ今とは時代も工場も違うか。
ROHSとかもあるし。
いろんな方面で世界の転換期だったし最悪な時代の産物だった気はする。


臨時にアパート住まいにならなければ買わなかった気はするが。
どうして、そこまでしてゲームがしたかったのかという・・・。
あれか。
COD4 か。
そうだった・・・。


見積もりはまだ出てないけど。
たぶん修理代は3-4万。
修理屋さんに問い合わせて連絡があったので送ってみる事にした。

諸行無常

XPS M1730のGPUの修理は2回目なので、前にもましてガタがくるはず。
それに約3万でチップ交換するのと、GPU2枚交換で9万払うのとマシン新調するのとで悩む。

2度あることは3度あるっていうし。
修理しても、たぶんまた壊れる気がして全く信用できないマシンとなってしまった。

9万あればちょっと足せば、普通のマシンなら買えてしまうし。

空冷には以前から限界を感じていたので、そろそろ我が家も水冷にしたいのだけど、どうせなら、ラジエーターとリザーバーはケースの外に出したい気もする。
で、ひさびさに自作してみようかと考え中。

試しにドスパラで 9万のマシンをベースに見積もりを出してみた。
で、約12万。
GTS250
i7-860  2.8G
水冷パックで + 10000。
OSをProにして + 10000。
電源を500W から 750Wにして + 8000。
HDDを500GBに落として -5000。
サウンドカード + 9000

HDD無しでOSありというオプションがあったら嬉しいのだけど。
それを言ったらケースもいらないのだけど。
サウンドカードはCreativeに昔から愛着があったので選べるみたいだし入れちゃった(テヘ

MSIでも同条件で見積もりを出してみた。
OS,マザー、CPU、GPU、メモリ、HDD容量、電源容量は一緒。
水冷なし。サウンドは選べない構成なのでオンボード。
で、約12万。
そういえば、嫁さんに上げたGF6800が載ってるのも MSI のやつで、G-Tune だった。
G-Tuneは、ケースが高いのかもしれない。
妙にこった作りになってる気がする。

kakaku.comで主要パーツの値段を調べて、だいたい同じ構成にして計算すると約10万。
MBは、ASUS の Maximus III Formula。
サウンドボードと、電源、ケース、光学ドライブ無し。
電源買ってケース買ったら12万ぐらいになるだろうから、自作でもBTOでも大差ないらしい。
OSが高いせいかな?
MBが好きなの選べるというのは魅力だ。
ケースも余ってるし。
やっぱ作るかな。

とりあえず修理の見積もり見てからだな・・。


テクスチャがおかしいかも

低解像度で艦内をうろついていたら、テクスチャが黒っぽいノイズ状になっている部分をいくつか発見。

なので、ミップマップが設定されていないテクスチャがいくつかあるかもしれない。

dxt5でアルファが設定されているやつばかりな気がする。
dxt5のテクスチャのノーマルマップのほうがおかしいのかもしれない。

2010年6月29日火曜日

オリジナルでテスト

動いたので終了。

あいかわらずの顔です。


部屋

オブリビオンの設定のパフォーマンスを VeryLow
にすると CS で A 押して明るくした時のようにシェーディングがなくなる。
暗くても明るくても色が一緒。
初めて知った。
オンボードGPUでもかなり軽い。
Flybookでも遊べるかもしれない。
勉強になった。

Mobile Intel 965 Express Chipset Family

仕方ないので、Latitude D830 にオブリビオンを入れることに。

主にコーディングと2D絵の編集、ネットブラウジングぐらいの用途で使ってたマシンで3Dは、荷が重い。

Mobile Intel 965 Express Chipset Family

いかにも動かない感じだ。

オブリビオンをインストールして、起動させてもてもクラッシュしてたので、無理かとも思ったが、とりあえずドライバを新しくしたら動いてくれたので良かった。

ずっと古いドライバを使っていたとは全く気が付かなかった。
まあ2Dオンリーだったから、ドライバなんか別にどうでもよかったのかもしれない。


で、とりあえず 640x480 で 全て lowend な設定で動かした所、ぜんぜん問題ないレベルでFPSもでてる。
これからテクスチャ入れたり、MOD追加してどんどん重くなっていくのだろう。

とりあえず、素の状態でテストする機会が出来たので、このまま何も居れずにスターフリートだけ入れてみようかと思う。

SLI

XPSはSLI なのだけど、私は普段1枚しか使ってないわけで。
(SLIにするとかえってカクツク)
なので、使ってない1枚と入れ替えたら動かないだろうかと思った。

ということで、ちとやってみることにした。

--

入れ替えはできないっぽい。
どーも左右非対称な気がする。
専用基板といったような感じだ。

修理しかないなこれは・・・。
修理しても3ヶ月しかもたないとは。
やっぱGPUごと交換するべきなのかもしれない。

STARFLEETリリースしておいて良かったなーとホント思う。

やっぱVRAMだった

まただなー
修理したばっかりなんだが。

ロゴ画面でドットノイズが無数に入る。
で、GPUを認識しないと。



とりあえずオンボードGPUでセーフモードで起動して
データ移動して、また修理に出さないと。

うーむ。
どうしたもんだか。

さっきのUSBメモリも死んでる模様。
一気にきた感じだ。

USBメモリがお亡くなりになった

ReadyBoost に使っていたUSBメモリがどうも調子悪い。
多分もう駄目。

1年たってない気もする。
読み書きはかなり頻繁に行っていただろうし、熱もすごかったから、まあそんなものだろう・・・。

ブリッジ部品の角が目立つので、モデリングしてた最中にハングアップしたのでGPUがまた死んだかと思ったが、USBメモリのせいだったらしい。

USBメモリで済んで良かった。

後方のスロットに差し込んでいたのだけど、すごい熱くて、ここも冷やさないとまずい感じだ。
背面には重要な部品はとくに無いので、温度をひろってくれるセンサーもついてなかった。
ノートといっても、手の届かない所において、デスクトップみたいに使ってるから、熱くなっているのに全く気が付かなかった。
USBメモリにもヒートシンクが必用かもしれないな。

やっぱノートは良くないな。

一昔前は今ほど熱も無かったし、ハイエンドでもそれなりに放熱はなされていただろうけど。
今はもはや限界なのだろう。
水冷でもきつそうな感じだ。

氷点下PCが巷で話題だけど。
ほんと冷蔵庫にPCを組みたくなる。

DROID X

DROID-X がたまらなくほすい。
http://www.google.co.jp/images?q=DROID%20X

2010年6月28日月曜日

コーヒーを追加しました

レプリケーターとフードディスペンサーでコーヒーが作れるはずだったのですが
作れなくなっていたので作れるように修正しました。

(普段は別のエディタでスクリプトを書いているのですが、おそらくコーヒー追加時に、CSで直接書いてしまって、昨夜のちょっとした修正の時にエディタで書いた物をコピペして、元に戻ってしまったのだと思います)


ファイル置き場の STARFLEET_MAIN.7z (esp only) のアーカイブだけ新しくなってます。
http://sites.google.com/site/eisenbase/games/oblivion/the-starfleet-for-oblivion

すでにコンパニオンの自宅登録済みで、セーブデータを使いまわしたい場合は、利用せずに次のアップデートまで待ったほうが良いでしょう。

コーヒーが追加されるだけですので。

(セーブデータを使いまわすと、とたんに不安定なります)

手間を惜しまずに セーブデータを本MODの利用前に戻せる場合は、アップデートしてもOKだと思います。


個人的に、焼いてあるステーキとコーヒーだけは前から欲しかったのです。アールグレイホットはまだです。

以上です。

--
お風呂の前のライトが床に落ちているのも発見し修正済み(ver 0.83b)
(CSでFキーを誤操作してしまったのだと思う)
アールグレイホットもPHで入れておきました。

STARFLEET:フォトフレームには触らないほうがよいです

艦の各部屋にフォトフレームが置いてある場合があるのですが、これには触らないほうがよいです。

コリジョンが細かすぎるらしく、地面に落とすとめり込んで、さらに落ちてしまいます。
次のアップデートでコリジョンを箱ポリゴンにします。

2010年6月27日日曜日

THE SHUTTLE FOR OBLIVION

シャトルもアップしました。
同じ所においてあります。

(乗ったまま飛ぶことは出来ませんので注意してください)

SS撮る暇すらなかった

前にも何度も書いたような気がしないでも無いんですが、寝不足気味で良く覚えていないので、再度書きます。


メインブリッジにある操縦桿ですが、お試し的な機能で、スターフリートを使い続ける場合は、使わないほうが良いです。

おかしくなると、オブリビオンを終了させないと直りません。

操縦桿を使う前にセーブして置いたほうが良いと思います。

おかしくなった場合、セーブデータをロードしても、おかしいままなので、いったんオブリビオンを終了させて、それからロードしてください。

あと艦にワープエフェクトを実装したので、ハイエンドなマシンをお使いの方は、ぜひ一度は空を見上げた上で、艦をJump In させてみてください。

公開しました

以下のサイトで公開しています。
大変お待たせいたしました。

http://sites.google.com/site/eisenbase/games/oblivion/the-starfleet-for-oblivion


esp, mesh, texture, sound のファイルに分かれています。
7z で圧縮されており、7-zip で解凍できます。
http://sevenzip.sourceforge.jp/

で、解凍してできたDataフォルダにあるものを、オブリビオンのData フォルダ以下にほうりこんでください。

ファイルが結構たくさんあるので、OBMM で、OMOD 化したほうが良いと思います。


ファイル数が多いので、BSA 化する事も検討していたんですが、結構面倒で、ちょっと時間がかかりそうで本日中に間に合わないという事で、今後の検討事項にします。

けっきょくヴァニラ環境ではデバッグしていないんで、他の方が動かせるのか全く分からないので、動いたら、主要なMODの一覧を添えて、ご一報いただけるとありがたいです。
(OOO、FRAN、MMMとか。)

ちなみにうちの環境は、オンラインマニュアルにあるとおりで。


OBSE 0018
JPWikiMod
JPBooks_Vailla+SI
OOO1.34b
MBP 1.4(Full)
MPC 1.2.2


となっています。


補足

燃料が切れそうになったら ZPM という青く光る物体が艦内のあちこちにおいてあるので、それをリサイクルシステムに突っ込めば当面は持つと思います。

ベータだといえばそれまでですが、esm で配布したいと言っておきながら、esp 版しかまだ出来ていません。

先ほど、esm 化して、スクリプトメッセージを全部エクスポートして、スターフリートの部分だけ日本語化して、それを新規に作成した esp に読み込んで日本語化しようと試みたんですが、ヴァニラの世界がおかしくなってしまうようで、どこにいっても地面がおかしくて、水の中にプレイヤーが沈んでしまうという現象に悩まされて、断念しました。

シャトルは、スターフリートとはまったく関係の無い構成になっていて、それはそれで今日中に公開できると思うので、しばらくお待ちください。
ソファベッドの問題がまだ解決してなくて、今からそれに取り組みます。

ちなみに、スターフリートのほうにも同じソファベッドのモデルがありますが、NIFファイル的には、全くの別物で、スクリプトも仕込んでいないのでアニメーションはしません。
シャトルは回転するので、ソファベッドの座標と回転軸をシャトル本体にあわせてあるのですが、スターフリートのほうのソファベッドはXYの中心が軸になっています。(Zは0です)

一応、アニメーションデータは用意してあるのでスクリプト次第なのですが、配置されたソファベッドの数が多いので、ないほうが安定するかと思いまして、アニメーションは無しで、ただのベンチとなっています。

20時以降

足りなかったアイコンの作成中。

本日の20時以降ぐらいに来ていただければ
ダウンロードできるようになっていると思います。

book の挿絵は 低解像度、中解像度、大解像度で3つ用意しなきゃいけないらしいので、フロアマップ1つだけだったから、用意したのだけど、アイテムのアイコンはどうなんだろう。

1種類しか作ってないのだけど。

うちでは一応問題なく表示できるんだけど、謎だ。

船体に沿った部屋がエクステリアにもあるので、インテリアとエクステリアの行き来で分かりづらいだろうと思って、ローディングスクリーンを1つだけ用意してあるのだけど、適当なやつなので暫定という事で、将来マシな物を作りますので、我慢していただきたい。

一応ヴァニラの絵がでれば外に出たという事で、スターフリートの絵がでれば中に居るという事です。

支援火器

"artillery" なのか "air-to-surface gun" なのかどっちなのか。

用途も見かけも、"artillery"が近いと思うんだけど、空対地だから "air-to-surface gun" なのだろうか。

悩むなぁ・・・。

2010年6月26日土曜日

予定通りアップできそう

予定通り明日中にアップできそう。

(主要なメッセージは日本語化してあるので、日本語化した環境が必要)

随所に変な英語が使われているけど、その辺は見逃していただきたい。



今も細かい所を修正中。
ときどき妙に不安定になるけど、たぶんセーブデータを使いまわしているせいだと思いたい。

スクリプトは、根本的に間違っていなければ、大丈夫だと思う。

スターフリートは、インテリアセルに配置されてて、それをワールドスペースに引っ張り出すので
その辺がまずいような気もするのだけど。

一応、3日待ってセルリセットさせても、元のセルに戻ることなく、ちゃんとワールドスペースで待機しているようなので大丈夫だと思うけど、長期間スターフリートを使ったことが無いので実際の所は分からない。

Persistent は大丈夫なのかもしれない。

あとは、ナビゲーションパネルで行き先を設定して、操縦桿でその場所に艦を動かすこともできるように一応したのだけど、こっちは見事に不安定になるので、実用の段階ではないです。
お試し程度でお願いします。

ちなみに、この機能は、トランスポーター用の機能の使いまわしで、プレイヤーの行き先を艦にもあてはめただけなので、スクリプトは全く同じで、なぜおかしくなるのか全く分からない。

プレイヤーがインテリアーセルにいる状態でインテリアーセルに配置した物をワールドスペースにはMoveToで動かせない という事なのかもしれないけど。
どうなんだろう。

一応当初は、この機能はプレイヤーを1回ワールドスペースの空高く飛ばして、そこで艦を移動して、プレイヤーを元の位置に戻すというような事を考えていたのだけど、やはりそうしないといけないのかも。

クリーチャー以外はセルリセットの時に帰ってしまうと CSWiki に書いてあったような気もするのだけど。
なぜ帰らないのかも謎。


もう少し時間があれば、この辺の調査したり、あとはインテリアセルのテクスチャも少し変化に富んだ感じにしたかったのですが、まあ、資金もそろそろ底をつきそうなので本業に戻らねばなりません。

そういえばトイレが無かった。
スタトレには一切出てこなかったので、触れてはいけない所なのかもしれない。

2010年6月25日金曜日

いろいろ変更

戦艦(探査船)としての機能を優先していたので、使われないであろう部屋があったので
切り替えスイッチで居住スペースに変更できるようにしようと思った。


たとえば会議室。
会議室は無駄なだけなので、ゲストルームに切り替えられるようにし、衣食住が可能なスペースにもなるようにした。

他は必用ないとは思うけど将来的にも1つ1つ検討していきたい。

2010年6月24日木曜日

そろそろ熱対策が厳しくなってきた

最近暑いせいもあって、主力のノートPCも熱暴走気味。

ノートなので熱が篭りやすい。

少し前にアパート暮らしを強いられてその時に当時主力だったデスクトップの変わりに購入。

(騒音とか消費電力とか、いろんな意味でアパートで使えるマシンではなかった)

で、そのノートが数ヶ月前にGPUが一度故障している。
そういえば、スターフリート関連のモデリングの最中の故障だった。
その頃からやってたんだなーとしみじみ思う。


修理後、一応動くようにはなって、GDIを使っての入出力が若干おかしい挙動をする事以外は以前のように使えるようになった。

修理はビデオチップの交換だったので、メモリ転送のタイムラグが諸々のプログラムが想定する値に満たないような仕様になってしまっているのだと思うが、故障前にいろいろドライバを入れ替えたりしてたので、ドライバのせいかもしれないし、よく分からない。
やる事が色々あって調査もしてない。ドライバぐらい入れ替えたい気もするが。

昨日1回クラッシュし、今日もはすでに3回クラッシュ。
再起動でGPUを認識しなかったのが1回。

メモリーのパリティエラーで1度ブルースクリーンに。
GPU以外もやばい状態のような気がする。

GPUが85度前後に1度到達し、それ以降調子が悪い。

75度でうるさい警報音を鳴らすようにして、常時70度以下をキープするようにはしていたのだけど。
瞬間的に90度ぐらいまでは大丈夫だろうと思っていたのだが、どうなんだろう。
経験的に100度ぐらいでも1分以上耐えるぐらいは余裕だろうと思っていたのだけど。
最近のPCは、やわになりつつあるな。

で。
今は、氷で冷やしている。
XPS M1730は下から冷やすのが良く無いようだ。

修理後、ファン付冷却台を作って、それにのせて使うようにしていたのだが、ファンをまわすと温度の上下のスパンが短くなり、センサーが冷えすぎるか、吸気の邪魔をしているかで、放熱に支障が出てるようだった。
なので、せっかくつけたファンはまわしていないのだけど、そのファン用の穴が、GPUファンの廃熱の際の吸気を助けるようになってくれたみたいで、調子もよかったはずだった。

氷で冷やした冷たい風を下から豪快に送り込んで、強制廃熱させようと思ったのだが、どうもGPUから後方排気へのエアフローは発生しないらしく、なおGPUが放熱しなくなるようで、かえって危険だった。

で、ペットボトルに水を入れて凍らせた物を金属トレーにのせてノートの上に置くようにしたのだが、それに関しては効果的に冷えてくれるようで、GPUの温度推移も緩やかになり、SLIで、かつ負荷のかかる仕事をさせても、PC全体が普段と比べて-5~-10度ぐらい温度が下がって良好なようだ。

GPUに負荷を掛けていない時は、45度~55度と、約10度近く下がっているようにグラフでは見えるのだが、そこまで冷えるとは驚異的だ。
最初から氷にすればよかった。

氷を取り替えるのが面倒だが致し方あるまい。
(500mlのペットボトルで3-4時間。
凍らせるのはたぶん6時間ぐらい。
1個前のを使おうとすると半分ぐらいしか凍ってないので、およそ2倍の時間がかかるんじゃないかと)

一応、スターフリートの公開日は今度は27日に設定していて、ベータ版の完成はしたという状態で、今でも出せる状態にはある・・・とは思う。
先週あせりすぎて、どうもやっつけ仕事が多かったと思うんで、ちょっとゆとりをいただいて、まあ27になるだろうと先週の土曜の段階で考えていたのだけど、こっちで告知してなくて申し訳ないです。

それでもやるべき事はけっこうあって、27日まで出来る分だけ実装したり修正したりという感じ。
もう7月になってしまうし、27日には何が何でもアップロードにこぎつけます。

バックアップは近頃良くやるので、PCが壊れてもサブマシンでなんとかなるので、ご心配なく。

2010年6月20日日曜日

チェックしてよかった

チェックが終わった。
足りないファイルも余分なファイルも結構あったもよう。
これから修正に入ります。

DDSとNIF

Vistaのファイル検索がいまいち分からない。

で、XP で手作業で、検索ダイアログを使って DDSファイルの有効性を検査していたのだが
効率が悪すぎていつ終わるか分からない。

そこで、以下のようなプログラムを作成する事にした。

1. 指定されたディレクトリ下にあるDDSファイルの一覧を作る
2. 指定されたディレクトリ下にあるNIFファイルの覧を作る
3. NIFファイル中の DDSファイルの指定部分を抽出
4. NIFで指定されているのに、存在しないDDSファイルを列挙
5. NIFで1度も指定されていない DDSファイルを列挙

要するに、足りないDDSと、いらないDDSの一覧が欲しい。
あと _n なども足りてるかどうかついでにチェック。


あとは、まとめてリサイズがしたいのですが・・・そういうソフトウェアって無いものだろうか。

さすがに DDSファイルのフォーマットを理解して、ゼロからプログラムを書いたのでは、いつ終わるのか分からない。
一応、以前なにかで使ったプログラムで、DevIL(OpenIL)でDDSを扱っていて、雛形になりそうな物があるので、流用すれば、すぐできそうな気はするものの、アルファチャネルがどうなるのか不明で、いまいちプログラムを書く気にならない。

今は、フォトショで nvidia の dds converter を使っているのですが、DDSを読み込むと、アルファチャネルがふっとんでしまう。
出力だけならOKのようだけど。

で、アルファチャネルを DXTBmpで、作り直さなければならないという二度手間になってこっちも作業が難航。

とりあえず、小さいオブジェクトなのに 2048のテクスチャが指定されているようなものに関しては、128ぐらいにリサイズ。
1024以下は、そのまま公開することにした。

一応、全部で150M以内には収まるもよう。

2010年6月19日土曜日

主要な作業終わり

スクリプトの修正、モデルの整理が終わってテクスチャの整理のみ。

ゲーム内の簡易マニュアルを若干修正して、あとはテクスチャの整理が終わり次第公開します。

2010年6月18日金曜日

公開時期

期待していた人もいたかもしれないが、作業が難航中。
すでに金曜になってしまった。

作業量的には毎日かなりの量をこなしているので、大変申し訳ないがご了承いただきたい。
土曜日曜フルタイムで、なんとかなるよーな気はするもののTODOリストを見ると微妙な感じです。

日曜の夜までに仕上げられるようがんばりますので、いましばらくお待ちください。

-
いや無理かも。
ジェネレータは一応修正出来て、デバッグ中。
まだ何度か修正が必要だと思うんで、どーなるか。
ジェネレータ修正、コンパイル、スクリプト出力、TESCS起動、PASTE、オブリ起動デバッグ
というけっこうだるいプロセスが延々と続く。
某コンパイラがけっこう遅くていらつく。

導入後に利用者が若干苦労するような気がする部分があるのでその辺の修正も必要なのだが、この調子だとその辺の修正は放置かもしれない。

マニュアルも未完成なのだけど。

一応、マニュアルはこちら。

STARFLEET取扱説明書

艦長室においてあるマニュアルやreadme.txtとか、他のマニュアルは若干情報が古い。
このマニュアルは常に最新。


TESNEXUSは、いまいち使い方が分からないので、とりあえず、マニュアルの置いてある場所か、うちのサーバーにアップする方向で検討してます。


私は7月ぐらいから忙しい身なので、まあ、6月中にリリースしておいて、何度か修正したいと思っているのだけど、6月が終わるとしばらく放置になる可能性が高いので、けっこー焦りがある。
1年たつとスクリプトとか読めなくなってるだろうし。

進捗

機関室、一応完了。
でかいコンピュータの中をつぶす事に。
将来ホロデッキにするということで。
ホロデッキ以外は完了した。

機関室にの隅にスパコンみたいなものが置いてあって、それが部屋のようになっていた。
機関室の中に、さらに小部屋みたいなのがあったのだ。
特に用途も無く、家具なども配置すると変な感じになってしまいもったいないだけなので、妥当な選択なのではないかと思います。

他。
エンジンなどを搭載。

残り。
テクスチャの整理が数が多すぎてだるい。

あとで小さくしようと思って基本512か1024で作ってあるので、オブジェクトの大きさの割りにでかいテクスチャなどは256とか128ぐらいにしなければ、ならないだろう。
ヴァニラのテクスチャなどは、32x32以下のサイズのもあったと思うのだけど、照明類のテクスチャなどは、そのくらいでも確かに十分かもしれない。

変なループテクスチャもけっこうある。
初期の頃の特徴の無いテクスチャのほうが良かったかもしれない。

ローエンド向けのポリゴンデータを用意するかどうか悩み中。
エンジン類のポリゴン数が多めで心配。

うちのマシンで動くのだから、たぶん問題ないとは思うが・・・。
やはりテクスチャなどは、VRAM2Gぐらいだとして、それに対しては、少しばかり、でかすぎる気がする。
コリジョンも、モンスを召喚して、衝突させてテストした結果、重かった。
なのでエンジン類は、polyheaderはやめて、boxにしました。

2010年6月16日水曜日

エアロック全般

ミドルデッキのエアロック前の改修。
以前から気密度に無理があると思っていたのでその対策。
エアロックを二重にすることで対処。

3つ作ってアニメーションさせてみて、いろいろ検討した結果、2つを没に。



(あちこち動くのでもったいないが、でかいだけで使いづらかったので、没に)

1.前面押し出し方式
見た目はごつくていいが、入りづらい

2.上に開閉する方式
普通すぎる

3.前に出て横にスライドする方式
1と2のハイブリッドのような感じ

3番目のを製作中で、明日アニメーションを定義してテストする予定。



ついでに全てのエアロックのうすっぺらい見た目の修正。
厚みと中心座標が変化したので、座標の修正。

(初期の頃のモデルは、自作ゲーム用なのでオブリビオンでの見え方を考慮してなかった。
角が90度で薄っぺらいと段差が見えなかったり、テクスチャが同じだと平面に見える)


エアロックは基本的にリバーシブルだったのだけど表と裏を別々のモデルとして分離。
場所によってはローポリ化に貢献してくれるはず。
その他諸々。




今週中のリリースは、この調子だと間に合わない。
せめて土日でなんとかなるといいんだが。

全体的なスクリプトのバグは、ほぼつぶれたと思う。
移動に関する問題のあったスクリプトはジェネレータのほうを修正中。
それができれば一括して修正される予定。



2010年6月13日日曜日

格納庫の改修

ひたすらTODOを消していくしかないという事で。
長らく物が無くて寂しかった、エクステリアの前方の格納庫に階段と諸々のパイプライン等(消火設備とか)を装備しました。




CTD多発

セーブデータを使いまわすと、やっぱ不安定になるみたいだ。
ちょこっとスクリプトをいじっただけなのに、おかしくなるのだ。

ワールドスペース移動中のローディングの直前とか、セルの切り替わりでのオートセーブの直前など。

いったんセーブしてロードすると、何事も無かったかのように、進行できるわけなのですが。

MOD導入前のセーブデータを使って新規にMODを導入してやれば、落ちることも無いのです。

うーん。

そういうものなのか。

ミドルデックのエアロック

中層のエアロック前は、小さな菜園があり、船室も並んでいる。
そこにエアロックが1つあって、外に出れるわけだけど。

宇宙で開けたら大変なことになるわけで。

2重にしないと変かもしれない。

マテリアル

テクスチャを張った物体に Emmisive で白を設定すると、真っ白になってしまう。
当たり前といわれれば、それまでなのですが。

ブリッジの各ステーションのオブジェクトがEmmisive で暗闇でも明るく見えるようにしている。

が、テクスチャを張った部分は、真っ白になってしまうので、そうはいかない。
はてさて。
どうするか・・・。

大規模な修正が必要

長い間、保留していて忘れていた部分で、問題があることが判明。
無効なポインタの参照的な問題。

戦艦の移動の基本のスクリプトなのだが、手入力では書く気にならないほどのオブジェクト数があるので、当初からスクリプトジェネレータみたいなものを作って、それにオブジェクト名と座標などをつっこんでおいて、テキストに出力させて、それをスクリプトに貼り付けて利用しています。
ある程度決まった構文にしか対応できないので、手入力による修正は必要となりますが。


最初から手でやるよりは効率はよく、オブジェクトが1つ増えたら、ジェネレータ側のオブジェクトも1つ増やすというように1つずつやってきました。

で、大きな変更があると、プログラムを修正して、スクリプトを出力して、貼り付けて、修正してという作業をやり直してきました。

初期の頃のスクリプトはOnActivateに、まさにジェネレータの出力結果を貼り付けただけで、動かしていたので楽だったのですが、何フレームかに分けて処理できるようにスクリプトを書かないと、移動や、disable/enableがおかしくなるということなので、現在は何フレームかにわけて処理できるように、GameMode で実行されており、それ以外にもいろいろと修正がなされています。

なのでスクリプトジェネレータが、そのままでは役に立たないという事に。

ということで、前置きが長かったけど。
スクリプトジェネレータの修正が必要という、かなり面倒な問題に直面してしまった。
現状、面倒なのでコアな部分も本体に込みで、毎回コンパイルしている。
今回は、詳細にケースバイケースで出力しないとなら無いので。
コード生成のコアな部分をDLL化してやらねばなるまい・・・。

2010年6月12日土曜日

自分の声

ちとスクリプティングとデバッグに疲れてきたので、息抜きがてら、音声リソースを作成してみようかと思った。

で。

WARNING



INTRUDER ALERT

の音声があったほうが良いかもと思って、声を録音してみた。

で、加工してみたが、何をどうやっても使い物にならない。

まあ無くてもいいか・・・。

アイアンマン2

まだ見てない。

なんと。
日本語吹き替版が、こっちではやってない。
地域限定なのか。
昔は字幕じゃないと嫌だったが・・。

ちと遠くまで行かないと日本語版は見れないらしい。

しくしく。

射程

けっこう前の版は砲撃を開始するには以下の条件を満たしている必要があった。

・艦がワールドスペースに居る場合
・艦がプレイヤーと35000ユニット以内である
・砲撃開始位置と目標の距離が11000ユニット以内である
・上の距離的な制限のため砲撃は、ほぼ垂直に行われる

現在は

・艦がプレイヤーのそばにいなくとも砲撃可能
・艦がプレイヤーのそばに居る場合、砲撃開始位置は、砲台の少し下
・艦がプレイヤーのそばに居ない場合、砲撃開始位置が目標の上空に移動

当初から悩んでいて、最近、後者の方法でテストしてみた。
砲台の回転まで実装したが、前のほうが良かったかもしれない。


(Zが浅い角度(砲台の真下とか tcl 使わないといけない場所)では、回転がおかしいものの、それ以外では、ほぼその方向を向くようにはなった)

オブリビオンの魔法の射程距離は、10000~13000ユニットぐらいしかない。
艦は、プレイヤーの10000ユニット上空で滞空する。

10000ユニットというのはけっこうぎりぎりの値で、7000前後だと、ちょっと近すぎて圧迫感が在り、これ以上低いと空が無くなる。

で、射程もそのくらいしかないので、ほぼ垂直にしか砲撃が出来ない。
斜めに砲撃を行うと、射程距離が足りなくなり、9割は届かない。

水平距離1万、垂直距離1万だと、斜めは 約14142ユニットになる。

目標地点は、プレイヤーから見下ろした地点になりやすいと思うし、実際デバッグでも、無意識に高台に移動してしまいがちだった。
なのでさらに、その距離は伸びる。
実際、水平距離5000、7500前後で、射程距離が足りなくなる場合が多かった。

一応、射程を延ばすアイディアはあるものの、手間がかかるので次期バージョンにしようと思う。
(コリジョンのない砲撃アニメーションを上空に設置し、目標直近でファイアーボールという手法。
アニメーションと爆発の同期が難しそう。)

ということで、ほぼ垂直の砲撃というやり方に戻すことにした。
垂直だけかよと思うかもしれないが、ご了承いただきたい。




他の修正
・アニメーション予定だったモデルにアニメーションを追加(残り2個)
・カウンターだけでなくエネルギーゲージもきちんと動くように。

6月中にはベータっぽいものは、リリースできると思います。
もう12日ですが。この調子なら、たぶんあと1週間ぐらいで、なんとかなります。

2010年6月11日金曜日

進捗

普通の船室9つ全部完了。

ブリッジのエンジニアリングとバトルステーションの修正も完了。

TODO残り17個。優先度1が7個。
増えたり減ったりし、なかなか収束しない。
主にバグフィクスなのだが。

ライティング

ライティングが結構難しい。



インテリアなど学んだことも無く。
まあ素人が、どうがんばったところで、綺麗な配光など期待できるわけもないのだが(;;

ワープコア周りの青い光がけっこう綺麗な感じで、それにあわせて他も綺麗にしてやりたいところだ。

オブリビオンは基本的に、光源が球体のようになっていて、球体の内側に接触している面が明るくなる。
接触していないと光っていても、光源として役に立たない。

で、光の届く距離というのが、そのまま球体の大きさ となるようだ。

おそらく、もっと減衰率がなだらかな大きな球体状の光源というのがあると、なだらかな配光となると思うのだけど、それができない。

現状だと、全体的にスポットライトが点在したような配光となってしまい、明るい部分の重なった部分が、ただ明るくなるだけではなく、その球体のエッジが、やや黒く影のようになってしまう。

プロパティを調節することで、最適なものは出来るのかもしれないが、うまくいかない。
Lightオブジェクトには、Dynamic というプロパティがあるが、これの使い方もいまいちわからない。
Dynamic を指定すると、なんとなくその光の減衰のカーブがなだからないなるような気がするが
たぶん気のせいだろう。

他の携帯可能な光源MODや、ヴァニラのTorch オブジェクトなどは Dynamic が指定されているようなので、おそらくそういった移動可能なオブジェクトで利用する物、つまり動的に配置される光源という事なのだろうと推測しているのだが・・どうなんだろう。
そう思って間違いは無さそうだが。

CSWikiを見ても、Dynamic です。 ぐらいしか書いてないので、まったくもって謎だ。

HDRをオンにしていると、まぶしくなりがちなので、船のインテリアは若干暗めに設定してみた。


で、メインの照明と、セカンダリな照明はオン・オフができるようになった。
足元の光や、ドアの前の照明などは、常時点灯とした。

メインとセカンダリのオフ

常時点灯の照明


これでまあ雰囲気はでるようにはなったが、その光源の形の問題で、なかなか綺麗な演出ができない。

とりあえず Fade とかFalloff exponent というプロパティがあるようなので、調節してどうなるか様子見中。
---
追記 at 06/11

Fade を 0.5 ぐらいにすると、それなりに淡くなってるような気はする。
はっきりとした違いは感じられない。
Falloff はよくわからない。
減衰の始まる距離みたいな感じだと思うのだが、違いが出てこない。

結局、メッシュの無いただの光源オブジェクトを2-3個おいてやり、影が出来ないように調整する事にした。
ヴァニラもそうやってるみたいだし、基本的に、光源は光源でおいてやるものなのだろう。

2010年6月10日木曜日

音は、サイバーショットで録画したものから音を取り出して加工してつくっている。

弾薬箱の音は、中古で買った本物の弾薬箱の音で、ほとんど加工してない。
開け閉めのタイミングのみ調節。
一番リアルな音で一番手間がかかってない・・・。

砲撃音などはダンボールや鉄板、壁、ドア、ありとあらゆる物を叩いた音を合成した物。

ダンボールが実に使える。

1回叩いた音だと、まあダンボールを叩いた音にしか聞こえないのだが。

それを0.25秒感覚で、連続して鳴らすと、たったそれだけで、マシンガンぽくなる。
で、発射のタイミングで金属の衝撃音や、その反響音の周波数を変えて合成すると、けっこう本物っぽくなる。


市販のFPSゲームのマシンガンの音なんかも、もしかしたら、ダンボールがベースになっている音が、けっこうあるのかもしれないと思った。


意識的に音をよく聴くと、録音したダンボールの音に非常に似ている。
いままでダンボールの音だと思って聴いたことはないが、今では、そーに違いないとしか思いようがない。
海外製のゲームなんかでも、射撃音がけっこう軽い音だったら、ダンボールの疑いがあるかもしれない・・・。

ちなみに戦艦の砲撃音は15発用と60発用が用意してあって、1発ずつ音を出しているわけではない。
1発ずつだと、次の音を出す時に前の音が消えてしまうようで、反響音がカットされてしまうので無理だった。
サウンドオブジェクトを複数用意すればいけるかとも思ったが、実験の段階で、すでに制御が面倒だったので、今回はやめ。
そういえば60発用の音のタイミングがずれてたような気がする。
直さなければ。

ワープの音は、バスタオルを両手で広げて振り下ろした音を現在、編集中。
今使ってる「うにょん」という音はちょっとかっこ悪いので、没にします。
しかし、音が軽くて、周波数を変えても、なかなか重い音が出ない。
今度はタオルを水でぬらして挑戦する予定。いつになるか分からんが・・・。
洗濯した時にやってみるか。

ドアの音はうちのサッシの開閉音+モーター音。
サッシは軽いので音も軽い。なので周波数は下げて合成。
こっちは適度な重さになった。


モーター音などは、PCのファン音を プログラム書いて加工したもの。
ビープ音なんかは10年以上前に自作ゲーム用に作ったのを再利用している。
あんまりいい音じゃないので、まあ作り直さなければならないだろう・・・。

2010年6月9日水曜日

進捗 gdgd

スクリプトもほぼ完了。
これ以上改良する予定は無く、バグ修正のみとなった。
そういや船室がまだだった。
まあ船室は、物を配置するだけなのだけど。

あとはテクスチャの整理と音作り。
うるさかったり、音が聞こえづらかったり場所によって音量の調整もしなければならない。
アイコンもいくつか作ってないものがある。
使ってないテクスチャがディレクトリに放りこまれているのでそれも削除しなければならない。

インテリア用とエクステリア用で一応分けているのだが、重複している物もけっこうある。
そういうのは、今後改良する場合の利便性を向上させるための工夫なので、目をつぶって欲しい。
反射のきついオブジェクトのテクスチャのアルファチャネルの調整なども必用。

あとはマッピングしてない小物で、必用な物はマッピングしてテクスチャを描き直さなければならない。
武器や盾、棚などの小物はマッピングしてあるのだが、他のは基本的にキューブマッピングだ。


戦艦本体のテクスチャもキューブマッピングだが、部分的に位置の調整はしてある。
まあでも、斜めにあわせるのがけっこう難しくて、マッピングしてしまいたくなる。
だが、でかいし解像度もかなり大きくないと、難しいと思うので、まあ無理な気がする。

nVidiaのDDSツールが最大で4096x4096 までだったと思うので、それ以上だと分割するしかない。
特徴のある部分のみ、マッピングしようかとも思ったが、それはそれで難しそうな作業だ。


あとは、金属のテクスチャが傷が有りすぎるので、撮り直さなければ成らない。
わざわざDIY店で買ったフラットバーという1メートル前後の建築用の鋼材をマクロ撮影して加工して作ったもので、ほどよく傷がついていて、加工時についたであろう縦線みたいなのがあるので、丁度良いかと思ったのだが、傷が多すぎる模様。
100均で買った金属プレートのほうは、良好。
金属は撮影時の反射があるのでけっこう手間がかかる。

Iron Man

Iron Man のDVDが借りれない。

2の公開をひかえているせいか、某T屋にいついっても借りられてる。

この手の映画は、GUI を考えている時、いろいろとインスピレーションをうけるためにバックグランドで流してたりすると良いのだが。

時期が悪かった模様。

しかたがないので、11日に Iron Man 2 を見に行ってこようかと思う。

雑誌コーナーを見ていたら、PANZER が売っていたので購入。
学生時代にたまに買っていた雑誌だったのだが。
ミリタリー系雑誌は、近頃まったく買わなくなった。

AH-64Dの記事があって PNVS の拡大写真があった。

他にもシャトルの内装の参考になりそうな写真が多い。
いまさらなので、今回は参考にしようがないが。
次に作る時には、こういうのも参考にして、もうちょっと細かく作ってみようと思う。

PNVS っぽい物も、すでに作ってしまってあったのだが、比較するとけっこう違う。
まあ、致し方あるまい。


照明のオン・オフ

OBLIVIONのスクリプトの話。
照明のオン・オフに取り掛かった。

ユーザーが単純に照明をオン・オフしたい場合に利用するためだけに用意するわけではなく
船のコンディションに応じて照明に変化をつけるのが主な目的。
侵入者警報とか、その類のものです。


今回実装するのは、CONDITION GREEN, GRAY MODE, RED ALERT のみ。
(STARTREK系 Wiki を参照)
順に通常の状態、省エネモード、緊急事態みたいな感じか。

クエスト的なものは、1回目の公開では、導入しないので
RED ALERTをどう利用するかまだ考えていないが、各所に回転灯がせっかく付いているので、機能の実装だけしておく。
GRAY MODEは燃料切れの警告でも使う予定で、その時に回転灯をまわしてもいいかもしれない。


で、まじめに全ての照明オブジェクトに光源設定をしてしまったので、今からそれに変更を加えるのが作業量的に面倒。(色とか照明が届く距離も、けっこう悩みぬいて設定したので同じ作業を繰り返すのはかなりきつい)

ダミーの照明オブジェクトと、光源のみのオブジェクトで準備しておけば、光源のみのオン・オフで実現可能だったのだけど、後の祭り。

で、どうすればよいかあれこれ考えた。

とりあえず、明るい主要な照明をオフにすることにして、補助的な照明は残すことにした。
一応コンソールとスクリプトで、全部消してみたが、真っ暗闇だと、(セルの環境光は、元から暗め)味気ないというより、幽霊船状態になるので、ある程度照明は残しておいたほうが、雰囲気的にもよさげだったので、そうすることにした。

2010年6月8日火曜日

砲台の回転

オブリビオンのオブジェクトの座標系が理解しがたい。

CSでオブジェクトを回転させると、どうにも直感的ではないと思う人は多いと思う。
ある軸を回転させると、軸まで回転してしまうような印象を受けるからだと思う。

というよりも、通常のプログラミングで物体を回転させるには、回転結果が累積する場合が多く、計算にはマトリクスを使い、たんに重ねてやれば良いだけなので、日常的に3Dプログラミングをしている人でも悩むと思う。

なので、普通は、Zを90度回転後、Xを90度回転した場合と、Xを90度回転後、Zを90度回転させた場合では結果が異なる。

しかし、オブリビオンは、常に X,Y,Zの順で回転させてあるっぽい(たぶん)

SetAngle Z 90
SetAngle X 90

とやろうが


SetAngle X 90 
SetAngle Z 90
とやっても、同じ結果になるのだ。


で。砲台は長いこと下向き固定だったのだけど、詰めの段階なので、回転スクリプトが必要になった。試行錯誤しているのだが、どうにもうまくいかない。

シャトルも似た様な計算で、動いているが、そっちは適当。
シャトルは、水平方向で回転が発生した際に、バンクするように作ってあるのだが、目標角度に到達するまでバンク角の回転パラメータが増えつつも、スタビライザー(安定化の機構)で水平に寄るように減らされ続ける。
目標角度に到達すると、スタビライザーによって、バンク角が減らされ続け、最終的に0になると水平を保つ。
こういう感じなので、若干計算に誤差があっても、スタビライザーで補正されるので、適当でも見た目悪くない。

砲台は、一度その方向を向いたら、射撃が終わるまで動かないので、正確に計算してやら無いと、ずれたままユーザーに見られることになるので、なんとかしなければならない。

で。

目標の座標を(X1,Y1,Z1)とする。
砲台の座標を(X2,Y2,Z2)とする。

砲台を 目標に回転させて正面を向かせてやるには、どうすればよいか。

初期値
砲台の初期状態での正面は真下を向いた状態で、回転角度は、XYZともに0。


X軸 奥(-)から手前(+)
Y軸 左(-)から右(+)
Z軸 下(-)から上(+)


砲台を 目標に向ける場合、まず、砲台の水平平面と垂直平面で回転を考える。
直角三角形を2つおいて考えてやればよい。

直角三角形の辺の長さ
DX = X1-X2
DY = Y1-Y2
DZ = Z1-Z2

水平方向の回転角度
θ1= arctan (dy,dx) + 90

斜辺(水平(XY)平面上での距離)
dr = sqrt ( dx * dx + dy * dy )

垂直方向の回転角度
θ2= arctan (dz,dr) - 90


普通ならここで計算は終了して、
Z軸を θ1 回転させた後に、X軸を θ2 回転させればOKだと思うのですが、今回はそうは行かないらしい。

回転の順序が X,Y,Z と決まっているので、X軸を回転させた状態で、Z軸を回転させても、先に述べた結果とは異なるので、この計算式はそのままでは使えない。


で、実際どうなるのか、どういう変換をすればいいのか見当も付かない。

CSで動かして値を確認。
(1)物体 B は、X=90,Y=90,Z=0 の時、正面が手前方向を向きます。

(2)物体 B は、X=90,Y=180,Z=0 の時、正面が奥を向きます。
(3)物体 B は、X=0,Y=90,Z=90 の時、正面が左方向を向きます。
(4)物体 B は、X=0,Y=270,Z=90 の時、正面が右方向を向きます。
(5)斜め方向たとえば、物体Bほ左手前方向に向ける場合
X=45,Y=45,Z=325(概算) ぐらいになる模様。

Z軸で、まず水平方向の向きを合わせて、そこから垂直方向をX軸とY軸であわせるという考え方で行きます。

(1)~(5)の各値を見ると、ある軸が0の時、ある軸が90なので、sin cos でいけそうな気がする。
リニアで補間してやってもそれらしくなるような気はするが、面倒なので三角関数で球面補間をする。というより、むしろそれが正しいと思う。


それぞれの座標軸に対する回転角度 θx,θy,θz を求めてやる。

θx = θ2 * sin θ1
θy = -θ2 * cos θ1
θz = θ1

砲台の初期位置による向きを補正する

θx = θ2 * sin θ1
θy = -θ2 * cos θ1
θz = -θ1+90

で。

まだおかしい。

はてさて・・・

2010年6月7日月曜日

最近沈黙しているのは

それだけ集中しているという事なのだ。

ブリッジはほぼ完了。
残弾表示やエネルギー残量表示もほぼ完了。


今まで、艦は、ワールドスペースにいないとインテリアにも飛べない仕様だったのですが
艦が初期位置(衛星軌道上という設定)に居るときも、インテリアに飛べるようにした。


その代わり、衛星軌道上にいる時は、外部へのアクセスハッチやエアロック(シャトル格納庫とか展望ラウンジなど)は全て、アクセスを拒否するように仕様変更。

宇宙の景観を作るかどうか悩んでいる最中。
なくてもいい気がするが。
作業慮的には今までのに比べればたいした事は無い気もする。

一部の部屋では、窓の外に宇宙っぽいのは、一応既にあるのだけども。
それと同じような感じでやろうかどうか。


あとはセーブとロードを繰り返すと、安定しない。
スクリプトに変更を加えてセーブとロードというのは、そもそもよくないのかもしれないが
スクリプトの止め方が分からん。

tscr とかそういうのではなくて、現在走っているスクリプトのインスタンスを消去する方法が分からない。
できないのかもしれないけど。

tscr は、script disableにしても、もう一度 tscr するとまた走り出す。
suspend してるだけのような感じだ。
terminate したいのだ。

セーブして、ゲーム終了して、CSでスクリプト書き換えて、ゲーム起動して、ロードすると
前のスクリプトがまだ走ってる気がする。
メニュー表示などで古いテキストが出てきたりする。
(OBSEのstringは使っていない)

セルのrespawn を1時間にして、testhall 行って待機して cell のリセットをしてみたが
効果なかった。

MOD導入前のクリーンなセーブデータから、ロードしてやるか、その手のツールでセーブデータをクリーンにしてやらないと、駄目らしい。

という事で、スクリプト周りは公開後に修正を繰り返すという方法は、あまり好ましく無いのかもしれない。

2010年6月4日金曜日

NIFのAttachLightはアニメーション可能な模様。

試しにAttachLightをアニメーションさせてみようと思ったら、うまくいった。

BlenderでEmptyを配置し、回転するオブジェクトをParentに設定。
でそのオブジェクトを回転させると、Emptyもついていく。

で、EmptyにAttachLightと名前をつけてもおそらくOKだと思うが、とりあえず、そのままエクスポートして、NifSkopeで、そのEmptyにAttachLightと名前をつけてやる。

で、BSXでEnable HavokとEnable Animationにチェックをつけ(その他は適宜)れば、ゲーム内とCSのHavokEnabledの状態でアニメーションする。

回転灯の光源をどうやってまわすか悩んでいたのだが、これで解決。

OBSEのSetDoorTeleport

既存のコンパニオンを船に帰宅させるために、ワールドスペースと船を結びつけておく必要がある。
そこで、ワールドスペースに船と繋がった1つのドアを配置可能なようにしようと思っていたので実装した。

ドアには、スタトレのパターン強化装置のような形を採用。

これで任意の場所と、船の転送機の1つを結びつけたり、必要なければドアを消したりする。


CSの関数ドアのマーカーは移動できないのでOBSEを使う。

SetDoorTeleport というのがそれなのだが。

引数がややこしい。

動かすのはパターン強化装置のほうなのだが

set tx to パターン強化装置.GetPos x
同様に ty,tz, GetAngle z で az

転送機.SetDoorTeleport パターン強化装置 tx,ty,yz,az

のようにやる。
最初、パターン強化装置.SetDoorTeleport でやっていて、うまくいかねーと数時間悩んだ。


SetDoorTeleport は OnActivate、OnEquip、GameModeで試したが、どれでやっても大丈夫な模様。
MoveTo,Enableの流れで1フレーム以上処理がかかる場合があるということなので、Activate、OnEquip後 GameModeで回したほうがよさそう。


インテリアーセルに配置したドアは、MoveToでワールドスペースに移動して SetDoorTeleport をやっても、うまくいかない模様。(実験継続中)
PosWorldなども試してみる予定。
移動の関数は、全て同じ関数の実態を呼んでるらしいという見方が強いが、MoveToとMoveToXMarkerに関しては、コードに違いがあったという投稿の引用をCSWikiのどっかで読んだ気がする。
なのでもしかしたら挙動が違うかもしれない。

ワールドスペースに配置したものは、ワールドスペース内で、移動させても大丈夫だった。

進捗。シャトルのfurniture marker その2

どうやら、enable の前に moveto しないと
furniture marker が、おかしくなってしまうらしい。
ただの Activator のように、プレイヤーがそれに向ってひたすら直進してしまう。
Player.GetSittingで値を見ても 0 のままになる。


着陸アニメーションでの回転操作のロジックで効率化を図るためにいろいろ処理を削っていたのだが、そのせいだった模様。

(1). shuttle.disable
(2). moveto player で現在のワールドスペース、セルに移動
(3). shuttle.enable
(4). getpos で呼び出した直後の位置を取得
(5). setpos で (4)の値に高度と方向を加えてアニメーション
(6). (5) を地上付近の所定の位置まで繰り返す

最後にコリジョンを正すためにアップデート
(7). shuttle.disable
(8). getpos,setpos
(9). shuttle.enable

のような感じになっていた。

CSWiki のTutorial にある、おなじみの推奨されるオブジェクトの移動方法なのだが

disable, moveto, enable, getpos, setpos

というのがある。

CSWiki:MoveTo

この王道のやり方を変えると、いろいろと問題が出るのは分かっていたことだが

基本 disable して enable すれば、なんとかなる
と思っていたのは間違いだった模様。

コリジョンは確かに正されるが、それ以外は何ともいえないという事なのかも。
moveto は playerの周辺に1回やれば良いかと思っていた。

で、この操作を行うオブジェクトが1つではないので、最初と最後で、これをやるのは、コードが巨大になって、スクリプトのサイズ制限に引っかかりそうだったので (7)-(9)までをブロック化し、(8)の前に moveto を入れた。

で、きちんと座れるようになった。

ソファベッドで、最初座れないのに、ソファとベッドの切り替えのアニメーション後には、座れるようになっていたのは、そのスイッチ型のアクティベーターのアニメーションスクリプトでmoveto が呼ばれていたため。

以上。


関連: 進捗。シャトルのfurniture marker

現在のメインブリッジ

2010年6月3日木曜日

進捗。シャトルのfurniture marker

解決しました

進捗。シャトルのfurniture marker その2



シャトルのコクピットの椅子とソファのfurniture markerがどうもおかしい。

コクピットの椅子はアクティベートは出来るものの、背もたれが邪魔なのか、プレイヤーが座ろうとすると、直進状態が続き、それがタイムアウトして座れない。
NPCが座る分には問題ない模様。

背もたれ付の椅子は他にもあるのだが、他の椅子は座るときに背もたれのコリジョンは、無視されていて得に問題が無い。


ソファのほうは、いったんアニメーションさせると座れるようになるのだが。
それまで、同じように椅子に直進してタイムアウトして座るのをやめてしまう。
何が原因なのだろう。

コリジョンとマーカーの位置を修正してテスト中。

回転非対応の前の版では問題なかったのだが、今のは回転するので、その辺でも何か絡んでそうな予感が。


--

コクピットの椅子のほうは、土台のコリジョンを小さくしたらすんなりうまくいった。
ソファのほうが座れないのは、まだ未解明。


ソファベッドは3つのソファベッドを別々に用意してあるだけなので、座れる時と座れない時で、オブジェクトに何か違いがあるわけではない。

1.ソファ
2.アニメーション用
3.ベッド

シャトルが飛行中は最後にenableされたものがシャトルに一緒についていく。
デフォルトでは、ソファなので、ソファがついていく。

プレイヤーの前にシャトルが現れて、ドアが開くとソファがある。
その時点でソファには座れない。

ソファのスイッチをアクティベートすると、ソファがdisableされ、アニメーション用のモデルが配置され enable されて、アニメーションを開始する

アニメーションが終了するとベッドが配置されて enable される。

もう一度スイッチをアクティベートすると、同じようにベッドが disable されて、アニメーション後、ソファが再び enable される。

で、そのソファには座れる。

試しに、コンソールで disable, enable は試してみたが改善しない。
コリジョンのせいではないと思うのだが、とにかく謎。

違いといえば、シャトル移動中、ソファはシャトルの座標を使って移動するのに対してソファのスイッチのアクティベート時は、スイッチの座標を計算に使っているという点か。
回転軸は同じにしてあるので、座標はどちらも同じはずなのだが。

とにかくその辺で悩んでいる最中。

ソファ/ベッドの切り替えの前後で、ソファベッドがちらつく現象は改善した。
以上。