ビデオ、つくっちゃいました～。
Video: Electrogram NITORO Black Side
KOBIKI-Z, The Black Stripes のみなさま、楽曲を使用しないでごめんなさい～。
ライブの模様を・・・ということでおゆるしください。
また、特設タワー崩壊のシーンもいれてみました。（事情をしらない人はかなり驚いたようです）
Yaz さんの曲で Live の模様の動画つくったの、、、N.M.R.7 ぶり?
[追記...] GION Experiment があったじゃない！（笑
みりおんきっし～ず
2008年7月6日日曜日
High Quality な動画を楽しむ その２
エレクトログラム、最高でした。
残念ながら1日目は参加できませんでしが、今日の2日目。
われらが Yaz さんはもちろんですが、、、KOBIKI-Z 最高でした、、、てか反則ｗ
「おもい・・」「おもい・・・」「どげんかせんと・・・」
ほんと、面白かったぁ。
ビデオは撮ってみました。でも、楽曲が Yaz さんのものしか手元にないので、、、、ビデオ編集悩みそうです。
で、前回から引き続いて High Quality な動画その２は Instant Sorrow でｗ
[該当の動画サービスが終了予定なので以下は削除いたしました。YouTube でお楽しみください。]
動画エリアの下のほうにマウスをおくとコントロールがでるので、再生ボタンをぽっちっとな、、してください。
（注）この動画を見るには専用プラグインのインストールが必要です。1-2分程度で終了します。
[追記] Firefox3 だとちょっとうまくいかないようです。FireFox3 の方は今しばらくお待ちください。。。
[追記] Firefox3 でもOKになりました。
ビデオおたのしみにぃ～ｗ
残念ながら1日目は参加できませんでしが、今日の2日目。
われらが Yaz さんはもちろんですが、、、KOBIKI-Z 最高でした、、、てか反則ｗ
「おもい・・」「おもい・・・」「どげんかせんと・・・」
ほんと、面白かったぁ。
ビデオは撮ってみました。でも、楽曲が Yaz さんのものしか手元にないので、、、、ビデオ編集悩みそうです。
で、前回から引き続いて High Quality な動画その２は Instant Sorrow でｗ
[該当の動画サービスが終了予定なので以下は削除いたしました。YouTube でお楽しみください。]
（注）この動画を見るには専用プラグインのインストールが必要です。1-2分程度で終了します。
[追記] Firefox3 だとちょっとうまくいかないようです。FireFox3 の方は今しばらくお待ちください。。。
[追記] Firefox3 でもOKになりました。
ビデオおたのしみにぃ～ｗ
2008年7月3日木曜日
HighQualityな動画を楽しむ
YouTube も高画質モードがでてきて、動画共有もますます楽しくなってきました。
で、ちょっと DVD クォリティまで可能な方法をためしてみました。
その試したサービスは 1.4Mbps のビットレートが再生時に可能、、、となっているので、かなり Second Life を実際みているクォリティがでると思いますし、、、地デジみたいに結構みたくないものまで見えるかもしれません。（笑
[残念ながら、YouTubeを除くサービスが終了・終了予定のため削除しました]
ということで、、、前に作ったビデオをアップしたのがこれ。GION の YazYaz な曲とビデオを使ってみました。
このビデオはフラッシュみたいに専用のプラグインが必要です。最近 GYAO とかでも使っているのでそんなに特殊なものではないと思います。
Windows, Mac, Linux でも OK で、ブラウザは IE, Firefox, Safari, Opera でも動くと聞いています。 そのビデオを見たい人は「続きを読む」をクリックしてください。 どうでしょｗ
かなりきれいにビデオを見ることができるような気がします。
ちなみに以下はこれまで使って、投稿してきた動画共有サイトの Embed リンクです。
YouTube
ますます、動画の世界が楽しくなってきましたね。
2008年6月21日土曜日
新しいデフォルトアバター
なかなかインできない日々が続いておりますが、Second Life Official ブログをみていたら、デフォルトアバターが変更されたんですね。
デフォルトアバター一覧はこちら
http://wiki.secondlife.com/wiki/Default_Avatar_Designers
こんなのとか、こんなのとか。
男性アバターはこんなのとか。
人間型じゃないアバターも。
Library から使えないかなぁ、、、
デフォルトアバター一覧はこちら
http://wiki.secondlife.com/wiki/Default_Avatar_Designers
こんなのとか、こんなのとか。
男性アバターはこんなのとか。
人間型じゃないアバターも。
Library から使えないかなぁ、、、
2008年6月13日金曜日
Race がまた・・・開催されます
Race 計測スクリプト、、、前回の SL Japan GP Steam Glider では IKAROS サーバーが動かなくて・・・
理由は「乗り物」（ビークル）にアバターが乗っていたせいでした。IKAROS はアバターが「素」のまま飛ぶので、ゲートを通過したとき llDetectedKey() でアバターの Key を採る方法でよかったのですが、乗り物にのるとアバターは乗り物にリンクされた状態になるようで、llDetectedKey() ではアバターの Key を取得することができなかったんですよね～。
なので、llDetectedOwner() でオブジェクトのオーナーKey をとってあげればよかったわけです。
前回は計測サーバーがまったく反応しないでごめんなさいです、、、。
6月22日(日)に SL Japan GP が開催、、、って、あちゃーｗ 計測スクリプトまだ完成してないしｗ 基本的なところはクリアしてるんですけど、、、ごめーん LIN ちゃん。
前回の Steam Glider の模様
って、思えば、レース系のイベントを撮影・編集した動画が増えましたｗ
Wing of IKAROS
SUZAKU GP
なんか、IKAROS のときに作った計測スクリプトって、今みても、、、、おもしろいｗ
この手の計測スクリプトは List 関数をいかにうまく使うかなんですよね。自分で見ても、よくまぁ、こんなに List 系関数を使ってる、、、と思いました。
簡単なのは llHTTPRequest で Web サーバーにデータを POST して、結果だけもらうのがいいんですが、こだわったのは「SLの中だけでやる」だったんです。
途中挫折しそうになるくらい処理のおもーいスクリプトにしたりしたのですが、結果的には List 系関数の多用で「そこそこ」動くようになったんです。
おおよそ普段使わないような List 関数をレース計測サーバーでは使ってます。
llListSort は当たり前としても、llCSV2List, llList2List, llList2ListStrided, llDumpList2String, llDeleteSubList.... このあたりを多用してます。
for 文でまわすと「ピッタッ」と止まるような処理でも、List 操作だと比較的高速に処理してくれるんですよね～。
機会をみてご紹介したいなぁ、、、と思ってます。
理由は「乗り物」（ビークル）にアバターが乗っていたせいでした。IKAROS はアバターが「素」のまま飛ぶので、ゲートを通過したとき llDetectedKey() でアバターの Key を採る方法でよかったのですが、乗り物にのるとアバターは乗り物にリンクされた状態になるようで、llDetectedKey() ではアバターの Key を取得することができなかったんですよね～。
なので、llDetectedOwner() でオブジェクトのオーナーKey をとってあげればよかったわけです。
前回は計測サーバーがまったく反応しないでごめんなさいです、、、。
6月22日(日)に SL Japan GP が開催、、、って、あちゃーｗ 計測スクリプトまだ完成してないしｗ 基本的なところはクリアしてるんですけど、、、ごめーん LIN ちゃん。
前回の Steam Glider の模様
って、思えば、レース系のイベントを撮影・編集した動画が増えましたｗ
Wing of IKAROS
SUZAKU GP
なんか、IKAROS のときに作った計測スクリプトって、今みても、、、、おもしろいｗ
この手の計測スクリプトは List 関数をいかにうまく使うかなんですよね。自分で見ても、よくまぁ、こんなに List 系関数を使ってる、、、と思いました。
簡単なのは llHTTPRequest で Web サーバーにデータを POST して、結果だけもらうのがいいんですが、こだわったのは「SLの中だけでやる」だったんです。
途中挫折しそうになるくらい処理のおもーいスクリプトにしたりしたのですが、結果的には List 系関数の多用で「そこそこ」動くようになったんです。
おおよそ普段使わないような List 関数をレース計測サーバーでは使ってます。
llListSort は当たり前としても、llCSV2List, llList2List, llList2ListStrided, llDumpList2String, llDeleteSubList.... このあたりを多用してます。
for 文でまわすと「ピッタッ」と止まるような処理でも、List 操作だと比較的高速に処理してくれるんですよね～。
機会をみてご紹介したいなぁ、、、と思ってます。
2008年6月6日金曜日
PRISMA!!
Yaz さんの曲がアップされましたよ！
PRISMA
この感じ、大好きなんですよね～。ジャンルが「Electronica」になっていますが（正直、ジャンルの違いがわかりません(笑)）、こういう曲を書いて、演奏できる Yaz さんってすごいなぁ、、、といつも思うわけです。
ACIDPlanet もいいですが、Dance Industries に進出しません？＞Yaz さん
いい感じの画像も Yaz さんのブログにアップされていました。 
もう一曲は Million Kisses 。メロディアスで Yaz さんのボーカルも入っている一品です（笑
なんか、Yaz さんのボーカル曲って、声質は DOA, メロディは PSB を連想させるので心地よいのですわ。
(DOA, PSB は脳内変換してください(笑)）
メロディアスになると、素人動画愛好家としては動画を編集するときにどうしても「ストーリー」を連想してしまうのです。
それはそれで楽しいのですが、、、絵コンテ書かない人なのでその時点ですでに限界（笑
たまたま先週くらいに結構 Yaz さんの初期の曲の Dark Celebration を使った動画を YouTube にあげたのですが、うーん、高画質モードになってくれないし～（泣
[追記：かなり時間たってから HQ モードになりました。] ということで、、、Soapbox で。動画編集実験みたいになっちゃってます。 Soapbox はサービス終了したので HQ モードの YouTube で。
2008年5月21日水曜日
セカンドライフのアニメーションを操る その７
これでシリーズ最終回 (笑) でしょう。
MLDU (Massive Link Dance Unit) のベンダー販売に最後まで躊躇したものは前の投稿でちょっとご紹介した「ラグのときのノートカードの読み込み」でした。
アニメーションを操る、、、という件名との関連性が薄い話題なのですが、ノートカードによるダンス記述は MLDU では欠かせないものだったということと、llHTTPRequest といった関数を使った外部サーバー、サービスからのデータ読み込み・書き込み方法 (Sine Wave AO 1.2 方式ですね) を除けば、ユーザーさんが唯一データの追加・変更をして、スクリプト・リセットしてもそのデータを再度使うことができる、、、というものなのでご紹介させてください。
ダンス・アニメーションの再生の順番やその再生時間を MLDU ではユーザーがノートカードに記述して保管しておきます。スクリプトはノートカードを読み込み、その情報を LIST に格納して、その順番で llStartAnimation を開始し、llSetTimerEvent には該当する秒数をセットしてタイマーをかけます。
timer() イベントが発生したら、LIST の次の項目のアニメーション名と秒数を使ってアニメーションを開始し、それまで動いていたアニメーションを止める、、、この繰り返しです。
ダンス記述ノートカードは1枚ではなく複数枚利用でき、MLDU 3.2 のデフォルトは 5 つのダンスセットを準備し、リセットすることなしに即時にダンスセットを切り替えることができます。ダンス記述ノートカード1枚につき、1つのスクリプトが割り当てられています。これはより多くのメモリーを利用したいためでした。
それぞれのダンス制御スクリプトはノートカードの読み込み時に指定されているダンス・アニメーションが本当にあるかどうかを llGetInventoryName を使ってチェックします。llStartAnimation / llStopAnimation の時に Avatar がいない場合エラーになることをご紹介しましたが、アニメーションが無い場合も当たり前ですがエラーになります。
意外にタイプミスが多かったり、半角スペースが2つ入っているのが本当の名前、、、などがあります。エラーの場合はどのダンスアニメーションがエラーになっているかを llOwnerSay を使って表示します。ダンスアニメーションを記述する際には、アニメーションのプロパティを開いて名前の部分をマウス・ドラッグでマーキングして、Ctrl+C でコピーし、ノートカードに Ctrl+V で貼り付けるのが一番確実ですね。
ダンス制御スクリプトをシーケンシャルにリセットしたい
このダンス制御スクリプトも含めたすべてのスクリプトを制御する親スクリプトがあります。
MLDU3.2 デフォルトだと、この親スクリプトが1本、ダンス制御スクリプトが6本、ダンススロットスクリプトが 15 本の計 22 本のスクリプトが llMessageLinked を使って連携するわけですが(ちなみに雷神の MLDU はその倍の数、、）、全スクリプトのリセットは親スクリプトからの llResetOtherScript により行っていました。
実は、この llResetOtherScript は、指定したスクリプトのリセットが終わるまで処理を待つことなく、次から次へとリセットをかけることが可能なんです。というか、、、リセットしてね～、を投げっぱなし、、、、というか、、、
for 文などでまわすと、どんどんリセットがはじまります。
ここにノートカードを読み込む llGetNotecardLine と dataserver イベントが非同期処理的に複数動き始めるわけですから、、、
これも、普通（何をもって普通、、、というか難しいですが、、、）はどんどんノートカードを読み込んで、アニメーションの存在チェックをしていくのですが、クラフターズカップなどが開催されてプリム数やスクリプトがSIMに多くなっている状態の雷神などはスクリプト・リセット時にノートカードが読めなくなり、エラーになることもしばしばありました。
親スクリプトによる全スクリプト・リセットを使わず、ダンス制御スクリプトをひとつひとつリセットしていくことで回避はできたのですが、これも、、、美しくないですよね、、、。
この「順番にスクリプトのリセットをかける」は、あまり難しくないように思われる方もいると思いますが、なにを悩んでいたかというと、MLDU の基本コンセプトは「スクリプトを動的に追加可能にする」だったんです。
たとえば、ダンススロットを 15 から 30 に増やしたい場合は、danceSlot というスクリプトをプリム内のコンテンツフォルダーに追加分をコピー（ドラッグ＆ドロップ）するだけ、、、ダンスセットを増やしたければ、ノートカードとダンス制御スクリプトをコピーするだけ、、、というものです。
親スクリプトはいったい自分がいくつのスクリプトを管理するかは、、、決めうちじゃなく、動的にとれるようにしたかったんです。
これは、、、いろいろなやり方があるとは思いますが、最終的に私がとった方法は以下でした。
1) 親スクリプトは子のスクリプトのリセットをかける前に llGetInventoryName と llSubStringIndex などを使って、ダンス制御スクリプトの数を取得します。ダンス制御スクリプトは SynchManager という名前でコピーしていくと SynchManager 1, SynchManager 2 と連番が振られますが、必ず SynchManager という文字列は含みますから、それを拾うわけですね。
2) その数ぶんだけ、親スクリプト内の slotStat という名前の List に "1" を入れます。6つあれば ["1","1","1","1","1","1"] となります。
3) 親スクリプトは llListFindList を使って "1" を slotStat から探します。
4) 一番はじめは 0 （つまり、一番最初）が戻り値としてくるので、0 の場合はなにも付け加えずに synchManager をリセットします。
5) 子スクリプトのダンス制御スクリプトはリセットが完了したら、llMessageLinked を使って、「正常に完了しました」 というメッセージと、自分の名前についている番号を投げます。番号がないときは 0 を投げます。
6) 親スクリプトは「正常に完了しました」をうけとったら、同時にもらった番号を index として使って、slotStat の中の "1" を llListReplaceList を使って "0" にします。そして、もう一度上記の 3) に戻って "1" を探します。その後は 3) ～ 6) の繰り返しです。
これで順次スクリプトリセットを可能にしてみました。途中でエラーが起こった場合はこの処理は止まります。ええ、とまっていいんです。そこは割り切りました。それでも上述のコンセプト的には80点はとれるんじゃないかなぁ、、、と、ちょっと自画自賛（笑
ちなみに、、、フリーのものも含めて、同じようなダンススクリプト、同期ダンススクリプトのソースは一度も見たことがありません。（というか、探せなかった？）
なので、上級者（プロ）の人にしてみればかなり「原始的」な処理もあると思います。ただ、半年以上のテストを比較的多くの Avatar が集まる、状況の厳しいクラブ雷神で続けてきた結果、まだまだ改善の余地はあるものの、エラーはあまり発生しない同期ダンス制御ユニットになったのかなぁ、、、と思います。
私にとっても、実践的な LSL ということで、とても勉強になりました。
クラブ雷神 : たぶん世界で一番クールなダンスを踊れます(笑
Snuript Library : MLDU 3.2 うってます。でも ネトラジ・チェンジャーが一番おすすめ（笑
[追記: 現在 MLDU は OEDO City SIM の Studio4D さんのお店にベンダーを設置しています]
このブログ「シリーズ」を書こうと思ったのは、実は、、、ダンス制御ユニットのパーソナル版を作ろうとしていて、ちょっとアイディアにつまったからでした。（笑
パーソナル版でやりたいことがこのブログを書く過程でだんだん固まってきたので、、、、お楽しみに。
でも、完成まではまだまだ先は長そうです。スクリプトって、どうしても売るの躊躇するんですよね、、、。
MLDU (Massive Link Dance Unit) のベンダー販売に最後まで躊躇したものは前の投稿でちょっとご紹介した「ラグのときのノートカードの読み込み」でした。
アニメーションを操る、、、という件名との関連性が薄い話題なのですが、ノートカードによるダンス記述は MLDU では欠かせないものだったということと、llHTTPRequest といった関数を使った外部サーバー、サービスからのデータ読み込み・書き込み方法 (Sine Wave AO 1.2 方式ですね) を除けば、ユーザーさんが唯一データの追加・変更をして、スクリプト・リセットしてもそのデータを再度使うことができる、、、というものなのでご紹介させてください。
ダンス・アニメーションの再生の順番やその再生時間を MLDU ではユーザーがノートカードに記述して保管しておきます。スクリプトはノートカードを読み込み、その情報を LIST に格納して、その順番で llStartAnimation を開始し、llSetTimerEvent には該当する秒数をセットしてタイマーをかけます。
timer() イベントが発生したら、LIST の次の項目のアニメーション名と秒数を使ってアニメーションを開始し、それまで動いていたアニメーションを止める、、、この繰り返しです。
ダンス記述ノートカードは1枚ではなく複数枚利用でき、MLDU 3.2 のデフォルトは 5 つのダンスセットを準備し、リセットすることなしに即時にダンスセットを切り替えることができます。ダンス記述ノートカード1枚につき、1つのスクリプトが割り当てられています。これはより多くのメモリーを利用したいためでした。
それぞれのダンス制御スクリプトはノートカードの読み込み時に指定されているダンス・アニメーションが本当にあるかどうかを llGetInventoryName を使ってチェックします。llStartAnimation / llStopAnimation の時に Avatar がいない場合エラーになることをご紹介しましたが、アニメーションが無い場合も当たり前ですがエラーになります。
意外にタイプミスが多かったり、半角スペースが2つ入っているのが本当の名前、、、などがあります。エラーの場合はどのダンスアニメーションがエラーになっているかを llOwnerSay を使って表示します。ダンスアニメーションを記述する際には、アニメーションのプロパティを開いて名前の部分をマウス・ドラッグでマーキングして、Ctrl+C でコピーし、ノートカードに Ctrl+V で貼り付けるのが一番確実ですね。
ダンス制御スクリプトをシーケンシャルにリセットしたい
このダンス制御スクリプトも含めたすべてのスクリプトを制御する親スクリプトがあります。
MLDU3.2 デフォルトだと、この親スクリプトが1本、ダンス制御スクリプトが6本、ダンススロットスクリプトが 15 本の計 22 本のスクリプトが llMessageLinked を使って連携するわけですが(ちなみに雷神の MLDU はその倍の数、、）、全スクリプトのリセットは親スクリプトからの llResetOtherScript により行っていました。
実は、この llResetOtherScript は、指定したスクリプトのリセットが終わるまで処理を待つことなく、次から次へとリセットをかけることが可能なんです。というか、、、リセットしてね～、を投げっぱなし、、、、というか、、、
for 文などでまわすと、どんどんリセットがはじまります。
ここにノートカードを読み込む llGetNotecardLine と dataserver イベントが非同期処理的に複数動き始めるわけですから、、、
これも、普通（何をもって普通、、、というか難しいですが、、、）はどんどんノートカードを読み込んで、アニメーションの存在チェックをしていくのですが、クラフターズカップなどが開催されてプリム数やスクリプトがSIMに多くなっている状態の雷神などはスクリプト・リセット時にノートカードが読めなくなり、エラーになることもしばしばありました。
親スクリプトによる全スクリプト・リセットを使わず、ダンス制御スクリプトをひとつひとつリセットしていくことで回避はできたのですが、これも、、、美しくないですよね、、、。
この「順番にスクリプトのリセットをかける」は、あまり難しくないように思われる方もいると思いますが、なにを悩んでいたかというと、MLDU の基本コンセプトは「スクリプトを動的に追加可能にする」だったんです。
たとえば、ダンススロットを 15 から 30 に増やしたい場合は、danceSlot というスクリプトをプリム内のコンテンツフォルダーに追加分をコピー（ドラッグ＆ドロップ）するだけ、、、ダンスセットを増やしたければ、ノートカードとダンス制御スクリプトをコピーするだけ、、、というものです。
親スクリプトはいったい自分がいくつのスクリプトを管理するかは、、、決めうちじゃなく、動的にとれるようにしたかったんです。
これは、、、いろいろなやり方があるとは思いますが、最終的に私がとった方法は以下でした。
1) 親スクリプトは子のスクリプトのリセットをかける前に llGetInventoryName と llSubStringIndex などを使って、ダンス制御スクリプトの数を取得します。ダンス制御スクリプトは SynchManager という名前でコピーしていくと SynchManager 1, SynchManager 2 と連番が振られますが、必ず SynchManager という文字列は含みますから、それを拾うわけですね。
2) その数ぶんだけ、親スクリプト内の slotStat という名前の List に "1" を入れます。6つあれば ["1","1","1","1","1","1"] となります。
3) 親スクリプトは llListFindList を使って "1" を slotStat から探します。
4) 一番はじめは 0 （つまり、一番最初）が戻り値としてくるので、0 の場合はなにも付け加えずに synchManager をリセットします。
5) 子スクリプトのダンス制御スクリプトはリセットが完了したら、llMessageLinked を使って、「正常に完了しました」 というメッセージと、自分の名前についている番号を投げます。番号がないときは 0 を投げます。
6) 親スクリプトは「正常に完了しました」をうけとったら、同時にもらった番号を index として使って、slotStat の中の "1" を llListReplaceList を使って "0" にします。そして、もう一度上記の 3) に戻って "1" を探します。その後は 3) ～ 6) の繰り返しです。
これで順次スクリプトリセットを可能にしてみました。途中でエラーが起こった場合はこの処理は止まります。ええ、とまっていいんです。そこは割り切りました。それでも上述のコンセプト的には80点はとれるんじゃないかなぁ、、、と、ちょっと自画自賛（笑
ちなみに、、、フリーのものも含めて、同じようなダンススクリプト、同期ダンススクリプトのソースは一度も見たことがありません。（というか、探せなかった？）
なので、上級者（プロ）の人にしてみればかなり「原始的」な処理もあると思います。ただ、半年以上のテストを比較的多くの Avatar が集まる、状況の厳しいクラブ雷神で続けてきた結果、まだまだ改善の余地はあるものの、エラーはあまり発生しない同期ダンス制御ユニットになったのかなぁ、、、と思います。
私にとっても、実践的な LSL ということで、とても勉強になりました。
クラブ雷神 : たぶん世界で一番クールなダンスを踊れます(笑
Snuript Library : MLDU 3.2 うってます。でも ネトラジ・チェンジャーが一番おすすめ（笑
[追記: 現在 MLDU は OEDO City SIM の Studio4D さんのお店にベンダーを設置しています]
このブログ「シリーズ」を書こうと思ったのは、実は、、、ダンス制御ユニットのパーソナル版を作ろうとしていて、ちょっとアイディアにつまったからでした。（笑
パーソナル版でやりたいことがこのブログを書く過程でだんだん固まってきたので、、、、お楽しみに。
でも、完成まではまだまだ先は長そうです。スクリプトって、どうしても売るの躊躇するんですよね、、、。
2008年5月19日月曜日
セカンドライフのアニメーションを操る （番外編）
512 日記念(?) ということで Sine Wave Island で女性用、男性用のダンス・アニメーションがフリーで配られていて、大変な混雑になっています。
SIM に入るのも大変なのですが、SIM に入った後でアニメーションを受け取るのも大変です。
単純に SIM が重い、ラグだからなのかな、、、と思ったのですが、、、どうもスクリプトに問題ありそうな気がします。
インベントリの中をちょっと見てみました。
配るダンス・アニメーション・ファイルが2つと、1つのスクリプトが入っています。プリムはリンクしていないようですから、このスクリプトのみだと思います。
たまたま運よく weloveyou-girl の（というか、girl しか手に入らなかった・・・）ダンスを貰うことができましたが、そのダイアログの流れは以下、、、、
1) タッチしても反応しないときが多く、根気強くがんばると以下のダイアログが表示されます。
Male (男性)用、Femal(女性)用のどちらがよい？と聞いています。
2) 好きなほうのボタンを押すと、しばらくして以下のダイアログが表示されます。
もちろん、[維持] を押します。これでしばらくするとインベントリにアニメーションファイルが追加されます。
プリムのコンテンツフォルダには1つのスクリプト、そして上記の流れ、、、多くのアバターが一斉にクリック(Touch)、、、場合によっては誤動作を発生させる、処理がたまる可能性があるスクリプトではないかと思います。
事実、Female をもらったあとで何度 [Male] を押しても [Female] しかもらえなかったり、、、(おかげで、、、weloveyou-girl が8個も、、、)
たぶん、llDialog を使わず、単純に男性用のアニメーションを配るベンダーと女性用のアニメーションを配るベンダーにしてしまったほうがよかったのだと思います。上記 2) だけであれば、スクリプトいらずで、料金を 0L$ にするだけでいいわけですからね。
SIM に 40 の avatar がやってきて、一斉にあるパネルをクリックしている状況なんてなかなかないですから、、、ただ、こういう状況が想定される場合の touch_start と llDialog はちょっと注意しなくてはいけません。
touch_start イベントではタッチしたアバターの数をうけとることができます。 integer total_number がそれにあたります。
touch_start(integer total_number)
{
llSay(0, "Touched.");
}
だれがタッチしたかを知るためにおおよそ llDetectedKey(0) とやりますが、これって最初に触った人、、、最初？？？と思われるでしょうし、ほとんど llDetectedKey(0) で問題ないのですが、こんなに一斉にタッチされるとなると、、、タッチを無視されるアバターも相当発生してしまいますね。つまり llDetectedKey(1) や llDetectedKey(2) は存在するのです。
touch_start(integer total_number)
{
llDialog(llDetectedKey(0), "Hi, let us know what", ["Male", "Female"], 12345);
llSetTimerEvent(10.0); //タイマーでのキャンセルもやってないような・・・
}
こんな感じなのかなぁ、、、
やるなら
touch_start(integer total_number)
{
integer i = 0;
for (;i<total_number;i++)
{
llDialog(llDetectedKey(i), "Hi, let us know what", ["Male", "Female"], 12345);
}
}
これでその瞬間にタッチしたアバター全員にダイアログを投げる処理になります。
そして、Dialog の返信をうけとって処理する Listen のイベントは、上記のサンプルより チャンネル 12345 しか聞いていないとすれば、
listen(integer channel, string name, key id, string message)
{
if (message == "Male")
{
llGiveInventory(id, "weloveyou-boy");
} else if (message == "Female")
{
llGiveInventory(id, "weloveyou-girl");
}
}
とにかく、message の Male/Female を判断して、無条件に llGiveInventory を使ってダイアログの返信をくれた id に対してファイルを投げる、、、
うわぁ、、、なんかキューにたまりそう・・・・
チャットの遅延って混んでいる SIM ではよく見かけるし、、、この場合遅延があっても大丈夫でしょうが、、、
で最終的には、、、boy もゲットしましたが、、、、その場である Avatar が「Someone has the dance girl? I have the boy.」（だれか girl 持ってる？私は boy を持っているんです）といっていたので、girl と boy を交換しました。（笑
配付されているアニメはコピー可なんです。
ですから、、、、今は持っている人からもらうのが一番かも。もうしばらくすると落ち着くとは思いますが。。。
それにしても Sine Wave 、、、すごい人気ですね～。
SIM に入るのも大変なのですが、SIM に入った後でアニメーションを受け取るのも大変です。
単純に SIM が重い、ラグだからなのかな、、、と思ったのですが、、、どうもスクリプトに問題ありそうな気がします。
インベントリの中をちょっと見てみました。
配るダンス・アニメーション・ファイルが2つと、1つのスクリプトが入っています。プリムはリンクしていないようですから、このスクリプトのみだと思います。
たまたま運よく weloveyou-girl の（というか、girl しか手に入らなかった・・・）ダンスを貰うことができましたが、そのダイアログの流れは以下、、、、
1) タッチしても反応しないときが多く、根気強くがんばると以下のダイアログが表示されます。
Male (男性)用、Femal(女性)用のどちらがよい？と聞いています。
2) 好きなほうのボタンを押すと、しばらくして以下のダイアログが表示されます。
もちろん、[維持] を押します。これでしばらくするとインベントリにアニメーションファイルが追加されます。
プリムのコンテンツフォルダには1つのスクリプト、そして上記の流れ、、、多くのアバターが一斉にクリック(Touch)、、、場合によっては誤動作を発生させる、処理がたまる可能性があるスクリプトではないかと思います。
事実、Female をもらったあとで何度 [Male] を押しても [Female] しかもらえなかったり、、、(おかげで、、、weloveyou-girl が8個も、、、)
たぶん、llDialog を使わず、単純に男性用のアニメーションを配るベンダーと女性用のアニメーションを配るベンダーにしてしまったほうがよかったのだと思います。上記 2) だけであれば、スクリプトいらずで、料金を 0L$ にするだけでいいわけですからね。
SIM に 40 の avatar がやってきて、一斉にあるパネルをクリックしている状況なんてなかなかないですから、、、ただ、こういう状況が想定される場合の touch_start と llDialog はちょっと注意しなくてはいけません。
touch_start イベントではタッチしたアバターの数をうけとることができます。 integer total_number がそれにあたります。
touch_start(integer total_number)
{
llSay(0, "Touched.");
}
だれがタッチしたかを知るためにおおよそ llDetectedKey(0) とやりますが、これって最初に触った人、、、最初？？？と思われるでしょうし、ほとんど llDetectedKey(0) で問題ないのですが、こんなに一斉にタッチされるとなると、、、タッチを無視されるアバターも相当発生してしまいますね。つまり llDetectedKey(1) や llDetectedKey(2) は存在するのです。
touch_start(integer total_number)
{
llDialog(llDetectedKey(0), "Hi, let us know what", ["Male", "Female"], 12345);
llSetTimerEvent(10.0); //タイマーでのキャンセルもやってないような・・・
}
こんな感じなのかなぁ、、、
やるなら
touch_start(integer total_number)
{
integer i = 0;
for (;i<total_number;i++)
{
llDialog(llDetectedKey(i), "Hi, let us know what", ["Male", "Female"], 12345);
}
}
これでその瞬間にタッチしたアバター全員にダイアログを投げる処理になります。
そして、Dialog の返信をうけとって処理する Listen のイベントは、上記のサンプルより チャンネル 12345 しか聞いていないとすれば、
listen(integer channel, string name, key id, string message)
{
if (message == "Male")
{
llGiveInventory(id, "weloveyou-boy");
} else if (message == "Female")
{
llGiveInventory(id, "weloveyou-girl");
}
}
とにかく、message の Male/Female を判断して、無条件に llGiveInventory を使ってダイアログの返信をくれた id に対してファイルを投げる、、、
うわぁ、、、なんかキューにたまりそう・・・・
チャットの遅延って混んでいる SIM ではよく見かけるし、、、この場合遅延があっても大丈夫でしょうが、、、
で最終的には、、、boy もゲットしましたが、、、、その場である Avatar が「Someone has the dance girl? I have the boy.」（だれか girl 持ってる？私は boy を持っているんです）といっていたので、girl と boy を交換しました。（笑
配付されているアニメはコピー可なんです。
ですから、、、、今は持っている人からもらうのが一番かも。もうしばらくすると落ち着くとは思いますが。。。
それにしても Sine Wave 、、、すごい人気ですね～。
2008年5月18日日曜日
セカンドライフのアニメーションを操る その６
シリーズものも第６回になってしまいました。（笑
こんなことしたい～、を実現するスクリプトはすぐに作れたとしても、前回書いたようにエラー処理や例外処理みたいなものをどんどん追加していくことになるんですよね。
まぁ、最初からそれらを入れて、、、というのが本来あるべき姿なのでしょうが、どんなことがおこるかその時は（今でも？）わかっていませんでしたから、雷神で何か問題があれば LINZOO さんから連絡をいただき、対処する、、、ということが数か月続いたわけです。
エラー処理、例外処理、メモリが足りない、、、
根本的にロジックがおかしい、、、というのはダメダメだとして（笑）、MLDU で私が経験させてもらった代表的なものは以下です。
1) llStopAnimation しようにも、Avatar がいない、、、
その SIM に Avatar がいない状況で Permission を持っているスクリプトが llStopAnimation を使ってダンス・アニメーションを止めようとするとスクリプト・エラーが発生します。「びょ～ん」とあのエラーマークがプリム上に現れます。
このマークはそのうち消えてしまうのですが、どうにも美しくないですよね。
センサーを使って確認する、、、なんて、最初考えたのですが、、、センサーリピートでぐるぐるまわす、、、それもどうかな、なんて考えていたらお友達からヒントをもらいました。
その Avatar が SIM にいないと本来機能しない LSL の関数、さらにエラーにならず、「いない」ということを戻り値として返してくれる関数、、これを聞いて「あっ！」と気がつきました。
llKey2Name です。[2009.5.19追記：こちらを参照ください]
llStopAnimation の直前に llKey2Name を使い、もし戻り値が NULL だったら llStopAnimation をぜずに、llRequestPermissions を行ったスクリプトを初期化して、他のアバターに使わせるようにすることでスクリプト・エラーを回避することができました。
2) ダンス・アニメーションをコンテンツフォルダーに入れられない、、、
MLDU の基本的な仕様はダンスを自由に操る、、、だったので、プリムのコンテンツ・フォルダに入れられたダンス・アニメーションは LIST に読み込むようにしていました。
ところが、LINZOO さんの所有しているアニメーションの数は 100 どころか 200 近く、、、よく使うアニメーションだけに絞ったとしても、たとえば「スローダンス・セット」、「グラマラスダンス・セット」などなど、1 セットに 20 前後のダンスを登録して、それが6セットとかになると 120 ものダンス・アニメーションをいれることになり、さらに新しいアニメーションを追加、、、、となると、、、
もともと、このエラーの原因になっていたのは、すべてのアニメーションを順番に固定の再生時間で動かす、というモードのためでした。しかし、LINZOO さんの使い方だとほぼいらない仕様だということ、さらに順番に動かすのであれば LIST にアニメーション名を入れる必要がない、ということから以下のような方法にしました。多くのダンス・アニメーションのスクリプトは、この方法が多いかもしれません。
- llGetInventoryNumber(INVENTORY_ANIMATION) でアニメーションの数を取得
- llGetInventoryName を使って 0 から取得したアニメーションの数-1まで順番にアニメーションの名前を取り出して、llStartAnimation にわたす
- timer() では上述の llKey2Name を使ってアバターチェックをした上で llStopAnimation/llStartAnimation を行う
全ダンスモードはこれでメモリー不足のエラーを回避できるようになりました。ダンスセットのノートカードに多くのダンスが記述された場合は上記の方法では対処できませんが、ノートカード読み込みの時に llGetFreeMemory を使い、メモリーが足りなくなりそうになったら警告を出すようにして、ノートカードの読み込みを中断するようにし、エラーを回避するようにしました。
3) アニメーションのつなぎでダンスがとまり、アバターが棒立ちになる、、、
この原因はスクリプトのせいだけではありません。アニメーションが SIM や PC にキャッシュされることで、つなぎがスムーズになることがほとんどなのですが、この「アニメーションのロード時間」というものは少なからず発生します。これが「棒立ち」の原因です。
アニメーションがキャッシュされていない時の「棒立ち」を回避する方法、、、これ、ある条件の下ではあるんです。
もし、利用するダンス・アニメーションの「優先順位」がすべて一緒ならば、、、、以下の方法がベストでした。
- llStopAnimation の前に、次に開始するアニメーションを llStartAnimation で開始する
- llSleep でスクリプトをちょっと止める
- llStopAnimation で「前の」アニメーションを止める
キャッシュされれば llStartAnimation で指定したアニメーションがすぐにはじまり、キャッシュされていない状況だと、その前のアニメーションが動いている、、、、
これ、良いアイディアだったのですが、、、はまりました。
キャッシュされる前のロード時間は長くても 5 秒くらい、、、ということで当初は llSleep で 5 秒を指定しました。これにより棒立ちは回避されたように見えました。
ところが、あるダンスの動きが予想しているものと違う、、、という話しがでました。
そこで前回ご紹介した「現在動いているアニメーションの表示方法」を使って確認してみると、、、優先順位が低いアニメーションがあるではありませんか。。。それも、、、OWENIMATIONS のものが優先順位 3 だったり、、、他のショップのものは 4 のものが多いのです。
これだと、動かすべきアニメーションがキャッシュされても、その前に動いていた優先順位の高いもののほうが常に 5 秒長く動くので「あれれ？」という動きになるわけです。
5 秒は長すぎ、、、ということで 0.5 秒くらいにしています。Stop-Start よりも Start-Stop のほうがロード時間を少しでもカバーできるのは確かです。llGetAnimPriority みたいな関数があればいいのですが、、、（笑
4) 使えるメモリーがどんどん少なくなる、、、
このようにエラー回避処理、メッセージの追加、メッセージの日本語化を行っていったら、どんどんアニメーション・リストのために使いたいメモリーが少なくなってきました。（= Stack-Heap Collision エラーが出やすくなってきた、、、です。）
以前に投稿しましたが、劇的にメモリーの節約になったのは以下の方法です。
- メッセージは直接日本語入力をする （以前の投稿はこちら） あと今ならこちらの方法も参考に。
- llMessageLinked の引数の key の指定で NULL_KEY を使っていたところを "" にする （以前の投稿はこちら）
- List 操作の関数を使うときは一度 LIST を空にしてから代入する （以前の投稿はこちら）
MLDU を作って良かったのは 16KB というメモリのサイズを意識するようになったことと、そして、ロジック上可能であれば、スクリプトをわければよい、ということを学んだことでしたね。
エラーがでちゃうと迷惑をかけてしまうので、MLDU は対面販売のみ、、、としていたのですが、今はベンダー販売をしています。最後の最後までベンダー販売したくないなぁ、、、と思っていた例外処理の対応ができたからでした。 Snuript Library ***SUZAKU***, SUZAKU (113, 230, 27)
[追記 2008.11] 現在は OEDO CITY の Studio4D さんにベンダーをおいています
Studio4D Dance Animations のブログ
ラグ（SIMが重い、動きが遅い状態)のときのノートカードの読み込み、、、この対策ができたのが、ベンダー販売をしてもいいかな、と思った最後の対応でした。
つづく？（笑
2008年5月14日水曜日
セカンドライフのアニメーションを操る その５
その５、、、です。ちょっと小難しいスクリプトの話が続いたので、今回はアニメーションそのもののお話になります。（笑
MLDU1 and 2 (Massive Link Dance Unit version1 and 2) ができたのは、LINZOO さんに「作ってみるー」と言ってから結構早かったんです。
ダンススロット（同時に Avatar が踊れる数）は 50 越えで、踊るダンスの組み合わせのセットは３つ、オーナーにはダイアログが表示されて、ダイアログのボタン操作でダンスセットを切り替え、アバターが踊っているダンスを変更する、ノートカードにダンスの順番、それぞれのダンスの再生秒数を指定する、、、など、現在の MLDU3 の基本仕様（というか、LINZOO さんの要求w) を含んでいました。
そのときのテスト模様は、、、こちらにあったり。
雷神を使った MLDU テスト。この時、同期ダンス 50 人を達成しました。
が、LINZOO さんから一言。「ダンスセット、3つじゃ足りないなぁ～」（笑
MLDU1 and 2 は１つのノードカードにタグ形式でセットを記述するタイプでした。
こんな感じ、、、
<Set1>
10.0, dance1
12.0, dance2
.....
.....
.....
8.0, dance3
</Set1>
<Set2>
18.0, dance4
....
....
10.0, dance1
</Set2>
<Set3>
8.0, dance3
16.0, dance5
....
....
12.0, dance2
</Set3>
なので、本当に安易にこのノートカードにダンスセットを追加していきました。
でも、、、LINZOO さんの持っているダンスアニメーションの数が、、、半端じゃなかったんです。
そのときで 200 以上は持っていて、、、当然ノートカードの項目も長くなります。
なので、スクリプトのメモリーが足りなくなってノートカードが読めなくなったんです。
アニメーションを操る、、、という意味でいうと、ノートカードに順番を入れるのはともかく、なんで秒数までいれるの？と思われる方も多いと思います。おおよそダンス・アニメーションとセットで配られているアニメーション再生スクリプトは 20秒から30秒くらいの「固定間隔」でダンスを切り替えます。これでも十分楽しいのですが、LINZOO さんがこだわったのは「ダンス終了後の立ち位置と、次に開始されるダンスの立ち位置の違い」でした。
高品質ダンス・アニメーションは開始位置と終了位置が一緒
フリーで配られているダンスの中にもすばらしいものもありますが、とくに Latin (ラテン) ダンス系のフリーものはダンスの開始位置と終了位置が大幅にずれているものがあります。ダンス・アニメーションはループアニメーションとして登録されている場合がほとんどなので、そのアニメーション単体を試してみるとすぐにその「不自然さ」がわかると思います。
最初、ラテン、サルサといったダンスはどうしても移動するので仕方ない、、、と思っていました。でも、ショップの有料ダンス・アニメ (ほとんどが 150L$ ～ 300L$ ですね) を見ると、、、これが見事に一致して、さらにはじめからループすることを見越して作っているようで、ループしても「切り替わった」ということを意識させないつくりになっています。
ですから、本来アニメーションがもっている「再生時間」を使ってダンス・アニメーションをつなげていくと、多くの場合は「基点」に戻るのでスムーズにダンスがつながって見えるのです。
せっかく基点にもどってきているのに、一定間隔で無造作に切り替えると台無し、、、というわけですよね。
また、開始位置と終了位置が違うものでも、もし、ダンスの移動中に開始位置に近い場所にくることがあれば、その時点でダンスを切り替えるとスムーズにダンスがつながってみえるわけです。
ただ、この作業、、、現在手作業でしかできませんね～。 LINZOO さんはストップウォッチ片手に計測しているみたいです。
llGetPos() を使って同じ位置近くにくる時間を自動的にとる、、、なんて最初考えましたが、アニメーションで動いているように見えても、実は Avatar の位置って、もともと立っていた位置の Vector 値を返します。スポットライトのスクリプトでアバターを追いかける、、、なんてのも、アバターを動かして歩いているのであればいいのですが、アニメーションによる動きだともともといた場所しか返さないので追いかけることができなかったりします。
このダンスの長さの情報、、、実はショップによってはきちんと公開しているところもあります。
Animazoo の場合
Animazoo は プロパティの Description にいろいろな情報があります。以下のようなものです。プライオリティ（優先順位）と秒数（赤字）が書かれています。
[Animzoo animations - Animazoo dance 25.0 - priority 3 - easing 1.0 - 9.15s l Chevvie dance 15.0]
[Animzoo animations - Animazoo dance 22.0 - priority 3 - easing 1.0 - 11.4s l Chevvie dance 8.0]
Sine Wave の場合
Sine Wave の場合は Animazoo のようにプロパティの Description に情報がないので大変、、、だったのですが、最近ものすごいことになっています。Sine Wave が配付している AO1.2 で Sine Wave の Web サイトと連携するようになりました。 Sine Wave AO 1.2 を Wear した状態で「/1 activate」とチャットすると Sine Wave Web サイトの自分専門の Page のリンクが Say されますので、それをクリックすることでそのページが開きます（最初はパスワードとかのセッティングが必要です）。
ページには Sine Wave が販売しているダンス・アニメーションのリストがあり、かつ、AO 1.2 に入れたダンス・アニメーションにチェックが入っていて、それぞれのアニメーションの時間まで、、、、Web 上で確認できます。(ただ、、残念ながら PlayList の使い方を把握しきれていないので、、、このサイトの使用はダンス・アニメーションの時間の確認のみですが、activation した上で AO を使うとそれぞれのダンス・アニメーションの再生時間はもっとも最適なものになっているのがわかります。）
OWENIMATIONS、Abranimations の場合
情報ないのでストップウォッチで計測するしかみたいですね、、、
と、ノートカードによるダンスセットの記述は手間がかかるものの、ダンスがスムーズにつながったり、曲調にあわせてダンスが切り替わるのを見ると時々「ぞくっ」とすることがあるくらい、綺麗に見えます。
万人向けじゃない、、、ですが、クラブでより多くの人に楽しんでもらいたい、と考えると、LINZOO さんの無茶な要求もわかるというもの、、、です。
話は戻って、、、メモリー不足への対応ですが、１枚のノートカードの情報を1つのスクリプトで読みきれないのであれば、ノートカードとスクリプトをそれぞれ分ければいい、、、とすぐに思いつき、それをやってみたわけです。それが MLDU2 となって LINZOO さんにお渡ししたわけです。
が、、、スクリプト、LSL 的には、ここからとっても勉強させられることになります。
とにかく、、、メモリが足りない、ノートカードにそれほど多くの情報がないのに Heap/Stack エラーになる、ちょっとでも SIM が重い・ラグな状態になるとノートカードの読み込みができない、、、、などなどに対応していくことになりました。。。
続く・・・かなぁ、、、（笑
MLDU1 and 2 (Massive Link Dance Unit version1 and 2) ができたのは、LINZOO さんに「作ってみるー」と言ってから結構早かったんです。
ダンススロット（同時に Avatar が踊れる数）は 50 越えで、踊るダンスの組み合わせのセットは３つ、オーナーにはダイアログが表示されて、ダイアログのボタン操作でダンスセットを切り替え、アバターが踊っているダンスを変更する、ノートカードにダンスの順番、それぞれのダンスの再生秒数を指定する、、、など、現在の MLDU3 の基本仕様（というか、LINZOO さんの要求w) を含んでいました。
そのときのテスト模様は、、、こちらにあったり。
雷神を使った MLDU テスト。この時、同期ダンス 50 人を達成しました。
が、LINZOO さんから一言。「ダンスセット、3つじゃ足りないなぁ～」（笑
MLDU1 and 2 は１つのノードカードにタグ形式でセットを記述するタイプでした。
こんな感じ、、、
<Set1>
10.0, dance1
12.0, dance2
.....
.....
.....
8.0, dance3
</Set1>
<Set2>
18.0, dance4
....
....
10.0, dance1
</Set2>
<Set3>
8.0, dance3
16.0, dance5
....
....
12.0, dance2
</Set3>
なので、本当に安易にこのノートカードにダンスセットを追加していきました。
でも、、、LINZOO さんの持っているダンスアニメーションの数が、、、半端じゃなかったんです。
そのときで 200 以上は持っていて、、、当然ノートカードの項目も長くなります。
なので、スクリプトのメモリーが足りなくなってノートカードが読めなくなったんです。
アニメーションを操る、、、という意味でいうと、ノートカードに順番を入れるのはともかく、なんで秒数までいれるの？と思われる方も多いと思います。おおよそダンス・アニメーションとセットで配られているアニメーション再生スクリプトは 20秒から30秒くらいの「固定間隔」でダンスを切り替えます。これでも十分楽しいのですが、LINZOO さんがこだわったのは「ダンス終了後の立ち位置と、次に開始されるダンスの立ち位置の違い」でした。
高品質ダンス・アニメーションは開始位置と終了位置が一緒
フリーで配られているダンスの中にもすばらしいものもありますが、とくに Latin (ラテン) ダンス系のフリーものはダンスの開始位置と終了位置が大幅にずれているものがあります。ダンス・アニメーションはループアニメーションとして登録されている場合がほとんどなので、そのアニメーション単体を試してみるとすぐにその「不自然さ」がわかると思います。
最初、ラテン、サルサといったダンスはどうしても移動するので仕方ない、、、と思っていました。でも、ショップの有料ダンス・アニメ (ほとんどが 150L$ ～ 300L$ ですね) を見ると、、、これが見事に一致して、さらにはじめからループすることを見越して作っているようで、ループしても「切り替わった」ということを意識させないつくりになっています。
ですから、本来アニメーションがもっている「再生時間」を使ってダンス・アニメーションをつなげていくと、多くの場合は「基点」に戻るのでスムーズにダンスがつながって見えるのです。
せっかく基点にもどってきているのに、一定間隔で無造作に切り替えると台無し、、、というわけですよね。
また、開始位置と終了位置が違うものでも、もし、ダンスの移動中に開始位置に近い場所にくることがあれば、その時点でダンスを切り替えるとスムーズにダンスがつながってみえるわけです。
ただ、この作業、、、現在手作業でしかできませんね～。 LINZOO さんはストップウォッチ片手に計測しているみたいです。
llGetPos() を使って同じ位置近くにくる時間を自動的にとる、、、なんて最初考えましたが、アニメーションで動いているように見えても、実は Avatar の位置って、もともと立っていた位置の Vector 値を返します。スポットライトのスクリプトでアバターを追いかける、、、なんてのも、アバターを動かして歩いているのであればいいのですが、アニメーションによる動きだともともといた場所しか返さないので追いかけることができなかったりします。
このダンスの長さの情報、、、実はショップによってはきちんと公開しているところもあります。
Animazoo の場合
Animazoo は プロパティの Description にいろいろな情報があります。以下のようなものです。プライオリティ（優先順位）と秒数（赤字）が書かれています。
[Animzoo animations - Animazoo dance 25.0 - priority 3 - easing 1.0 - 9.15s l Chevvie dance 15.0]
[Animzoo animations - Animazoo dance 22.0 - priority 3 - easing 1.0 - 11.4s l Chevvie dance 8.0]
Sine Wave の場合
Sine Wave の場合は Animazoo のようにプロパティの Description に情報がないので大変、、、だったのですが、最近ものすごいことになっています。Sine Wave が配付している AO1.2 で Sine Wave の Web サイトと連携するようになりました。 Sine Wave AO 1.2 を Wear した状態で「/1 activate」とチャットすると Sine Wave Web サイトの自分専門の Page のリンクが Say されますので、それをクリックすることでそのページが開きます（最初はパスワードとかのセッティングが必要です）。
ページには Sine Wave が販売しているダンス・アニメーションのリストがあり、かつ、AO 1.2 に入れたダンス・アニメーションにチェックが入っていて、それぞれのアニメーションの時間まで、、、、Web 上で確認できます。(ただ、、残念ながら PlayList の使い方を把握しきれていないので、、、このサイトの使用はダンス・アニメーションの時間の確認のみですが、activation した上で AO を使うとそれぞれのダンス・アニメーションの再生時間はもっとも最適なものになっているのがわかります。）
OWENIMATIONS、Abranimations の場合
情報ないのでストップウォッチで計測するしかみたいですね、、、
と、ノートカードによるダンスセットの記述は手間がかかるものの、ダンスがスムーズにつながったり、曲調にあわせてダンスが切り替わるのを見ると時々「ぞくっ」とすることがあるくらい、綺麗に見えます。
万人向けじゃない、、、ですが、クラブでより多くの人に楽しんでもらいたい、と考えると、LINZOO さんの無茶な要求もわかるというもの、、、です。
話は戻って、、、メモリー不足への対応ですが、１枚のノートカードの情報を1つのスクリプトで読みきれないのであれば、ノートカードとスクリプトをそれぞれ分ければいい、、、とすぐに思いつき、それをやってみたわけです。それが MLDU2 となって LINZOO さんにお渡ししたわけです。
が、、、スクリプト、LSL 的には、ここからとっても勉強させられることになります。
とにかく、、、メモリが足りない、ノートカードにそれほど多くの情報がないのに Heap/Stack エラーになる、ちょっとでも SIM が重い・ラグな状態になるとノートカードの読み込みができない、、、、などなどに対応していくことになりました。。。
続く・・・かなぁ、、、（笑
登録:
投稿 (Atom)