Second Life 見たこと・聞いたこと

Second Life で外人の方とのコミュニケーションは珍しくありませんよね。
ダンスクラブに来られた外人の方にダンスの開始方法を教えるのも、、、まぁ、英語ならなんとかチャットで教えてあげていました。

サーバー 1.24 でいくつかの新しい関数が追加されていますが、llGetAgentLanguage という関数は、その Avatar の Agent が使っているビューワーの言語のバージョンを取得する関数です。これを使うと、スクリプトのメモリが許せば、日本語、英語、がんばれば他の外国語のメッセージをスクリプト内に保存しておいて、Agent が利用しているビューワーの言語情報によって切り替えることが可能ですね。

MLDU(ダンス玉） でいうと DDManager みたいなダイアログの操作でストリング（文字列）とリストを多用していると、メモリの問題から1つのスクリプト内で処理するのはつらいのですが、個々のアバターのパーミッションを管理して、ダンスの開始、停止を行うスクリプトなどは、複数の言語メッセージを保管しておいて、llGetAgentLanguage の情報からメッセージを切り替えることが可能になりますね。

こんな感じです。  
続きを読む

Linden の Official Blog に「Mono Launch」という記事がついに投稿されましたね。

Linden Official Blog - Mono Launch

20日から 1.24 サーバーの展開が始まって、その 1.24 サーバーには Mono が含まれている、ということらしいです。
サーバーが 1.24 になっただけでは Mono は使えず、スクリプト作成者はクライアントビューワーの 1.21 RC が必要になるということです。1.21 RC のビューワーではスクリプトエディタの下に [Mono] というチェックボックスが追加されるので、それをチェックして保存、コンパイルで Mono 対応に移行完了、ということらしいです。逆に [Mono] にチェックをいれなければ、従来のまま動くようです。
ちなみに サーバー 1.24 のリリースノートによれば、ビューワーの 1.21 RC は 8月25日の週にリリースする予定ですね。

Mono はスクリプトを動かすための新しいエンジンで、従来のものと並存して提供されるとのことです。すべてのスクリプトを変換する必要はなく、また、LSL の書き方が変わるわけではありません。ちょっと安心ですね。

この Mono ですが、この新しい実行環境はスクリプトの「実行スピード」と「メモリー管理」が現行のスクリプト エンジンよりも強化されている点が特徴です。

この 1ヶ月ほど、ダンス玉 (次の MLDU) に機能をどんどん追加していったらメモリーがかなり厳しくなって、スクリプトを分けないと 10人以上踊れない、、、という状況になっていてのこの記事だったので、早速ベータ グリッドにいって試してみました。メモリーに関していえば、これまで 1つのスクリプトは 16KB しかメモリーを使えませんでしたが、Mono では 64 KB まで拡張されていることは知っていました。

今の環境だと、一番メモリーがくるしい DDManager (Dance Slot と Dialog 管理スクリプト) は残りのメモリーが 1.1K しかありません。これ、リストの操作で空のリストを使う方法じゃないと、エラーでスクリプトが止まる状態だったりします、、、


  
続きを読む

造形のセンスまったくなしなので、クールな HUD を作ってスクリプトを埋めこむ、、、なんてことができないので、どうしても llDialog を使うことになってしまいます。

llDialog で表示するダイアログには12個のボタンしか表示できない、ボタン内に表示できる文字数に制限がある、同じ場所から出てくるので「複数ダイアログ表示」できないことはないのですが、あまり使い勝手が良くないなど、制約が多いのですが、、、これを使うしかないわけで（笑

そこそこ多くのダイアログを作ってみて、気がついた点などを再度まとめてみようと思いました。

1) 複数の人がダイアログを押して、それを処理するような状況になるべくしないほうがいいかも

用途にもよりますが、複数の人がダイアログを押すような状況を仮定してスクリプトを組まないほうが懸命のようです。できないことはないのですが、if 文を駆使して、そのロジックをいろいろと悩むよりも、「前の人の処理が終わるまで待ってもらう」としたほうが当然のことながらスクリプトがシンプルになります。

[追記] ダンス玉（つまりアニメーション操作）など Permission を必要とするものなどは、touch されたら、アバターの Key を他のスクリプトに渡し、そちらで処理する方法があります。この場合は、複数の人が1つのプリムをタッチしても、個別に処理するスクリプトの数の最大に達するまで処理をさせることが可能になります。1つの Prim には複数のスクリプトを入れることが可能なので、touch を管理するスクリプトを親として、詳細の処理を子スクリプトに渡す、、、ということができます。

2) state を使ったほうがラクかも

これも人によりけりでしょうが、私の場合は、タッチされたら（もしくは、なんらかのイベントが発生してダイアログを呼ぶようなことになったら）、そのアバターの key を拾って state を変える方法を使うことが多くなりました。メリットは llListenRemove を使わなくても state が変わることによって　listeners を溜めなくてすむこと(64 だったかな?、Remove せずにそのくらい溜まるとエラーになります）、他の人が touch　したときの処理をシンプルにできること、だと思っています。また、state_entry, state_exit を使った初期化処理/終了処理が可能でスクリプトが見やすくなることもあげられます。デメリットは必ず llSetTimerEvent を使ってタイムアウトを検知させること。これをやらないでダイアログの [無視] ボタンを押されたら元の state に戻って来れません。
（以下は可読性を高めるためにグローバル変数をあまり使ってません）

key toucher = NULL_KEY;
list buttons = ["button1", "button2", "button3"];

default {
    state_entry() {
       toucher = NULL_KEY;
    }
    touch_start(integer detected_num) {
       toucher = llDetectedKey(0);　//一番最初にタッチいた Avatar の Key を取得
       state dialog;　//ダイアログ・ステートに移動
    }
}

state dialog {
    state_entry() {
       integer hDialog = llListen(-5555, "", toucher, ""); //-5555チャンネルで、タッチした Avatar の声だけ聞く設定
       llListenControl(hDialog, TRUE); //リスナーを追加（要は聞き始める、ということ）
       llDialog(toucher, "好きなボタンを押してください。", buttons, -5555); //ダイアログを表示。返信は -5555 チャンネル
       llSetTimerEvent(30.0); //30秒でタイムアウトにさせるため
    }
    touch_start(integer detected_num) {　//ダイアログ処理中にタッチした Avatar への処理
       integer i = 0;
       for(; i<detected_num; i++) {　//タッチした人分の処理をする for ループ
           llInstantMessage(llDetectedKey(i), "ダイアログ使用中です。しばらくまってください。");
       }
    }
    timer() {
        llInstantMessage(toucher, "タイムアウトになりました。");
        llSetTimerEvent(0.0);
        state default;
    }
   listen(integer channel, string name, key id, string message) {
        if (llListFindList(buttons, [message]) != -1) { //一応のチェック処理。この程度なら必要ないですが・・・
            llSetTimerEvent(0.0);
            if (message == "button1") {
                xxxxxxxx;
            } else if (message == "button2") {
                yyyyyyyy;
            } else if (message == "button3") {
                zzzzzzzz;
            }
        state default;
        }
   }
   state_exit() {
        toucher = NULL_KEY;
        llSetTimerEvent(0.0); //しつこいですが、、、過去に timer が戻らなかったことがあったので・・・
   }
}
  
続きを読む

Race 計測スクリプト、、、前回の SL Japan GP Steam Glider では IKAROS サーバーが動かなくて・・・
理由は「乗り物」（ビークル）にアバターが乗っていたせいでした。IKAROS はアバターが「素」のまま飛ぶので、ゲートを通過したとき llDetectedKey() でアバターの Key を採る方法でよかったのですが、乗り物にのるとアバターは乗り物にリンクされた状態になるようで、llDetectedKey() ではアバターの Key を取得することができなかったんですよね～。

なので、llDetectedOwner() でオブジェクトのオーナーKey をとってあげればよかったわけです。

前回は計測サーバーがまったく反応しないでごめんなさいです、、、。

6月22日(日)に SL Japan GP が開催、、、って、あちゃーｗ 計測スクリプトまだ完成してないしｗ　基本的なところはクリアしてるんですけど、、、ごめーん LIN ちゃん。

前回の Steam Glider の模様

Video: Steam Glider 1  
続きを読む

これでシリーズ最終回 (笑) でしょう。

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 で貼り付けるのが一番確実ですね。  
続きを読む

512 日記念(?) ということで Sine Wave Island で女性用、男性用のダンス・アニメーションがフリーで配られていて、大変な混雑になっています。



SIM に入るのも大変なのですが、SIM に入った後でアニメーションを受け取るのも大変です。
単純に SIM が重い、ラグだからなのかな、、、と思ったのですが、、、どうもスクリプトに問題ありそうな気がします。

インベントリの中をちょっと見てみました。

  
続きを読む

シリーズものも第６回になってしまいました。（笑

こんなことしたい～、を実現するスクリプトはすぐに作れたとしても、前回書いたようにエラー処理や例外処理みたいなものをどんどん追加していくことになるんですよね。

まぁ、最初からそれらを入れて、、、というのが本来あるべき姿なのでしょうが、どんなことがおこるかその時は（今でも？）わかっていませんでしたから、雷神で何か問題があれば LINZOO さんから連絡をいただき、対処する、、、ということが数か月続いたわけです。


エラー処理、例外処理、メモリが足りない、、、


根本的にロジックがおかしい、、、というのはダメダメだとして（笑）、MLDU で私が経験させてもらった代表的なものは以下です。

1) llStopAnimation しようにも、Avatar がいない、、、

その SIM に Avatar がいない状況で Permission を持っているスクリプトが llStopAnimation を使ってダンス・アニメーションを止めようとするとスクリプト・エラーが発生します。「びょ～ん」とあのエラーマークがプリム上に現れます。

このマークはそのうち消えてしまうのですが、どうにも美しくないですよね。
センサーを使って確認する、、、なんて、最初考えたのですが、、、センサーリピートでぐるぐるまわす、、、それもどうかな、なんて考えていたらお友達からヒントをもらいました。
その Avatar が SIM にいないと本来機能しない LSL の関数、さらにエラーにならず、「いない」ということを戻り値として返してくれる関数、、これを聞いて「あっ！」と気がつきました。

llKey2Name です。

llStopAnimation の直前に llKey2Name を使い、もし戻り値が NULL だったら llStopAnimation をぜずに、llRequestPermissions を行ったスクリプトを初期化して、他のアバターに使わせるようにすることでスクリプト・エラーを回避することができました。

  
続きを読む

その５、、、です。ちょっと小難しいスクリプトの話が続いたので、今回はアニメーションそのもののお話になります。（笑

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 さんがこだわったのは「ダンス終了後の立ち位置と、次に開始されるダンスの立ち位置の違い」でした。
  
続きを読む

アニメーションを操る、、、ということでシリーズもの（？）になってしまいました。
前回からの続きです、、、

LINZOO さんお得意の「つぶやき」にまんまと引っかかり（笑）、でも、今考えると本当に「安易」にダンス玉を作るといってしまった、、、と思います。

同期ダンスの仕組みはおおよそ予想がついていました。ちょうど大運動会のイカロスの順位表示スクリプトを作ったので、メッセージを使ったスクリプトの連携などをすでに経験していました。なので、当時のエントリにもあるように llMessageLinked で「これ踊って～」というメッセージを投げ、それを複数のスクリプトが拾って llStartAnimation を Avatar に対して行う、この繰り返しでしょう、、、くらいの理解でした。

ビデオ玉や音楽玉もすでに作っていたので、複数の人がひとつのスクリプトを利用する問題点と対応方法、ダイアログの使い方、ノートカードの読み込ませ方などもある程度わかっていたつもりでした。


当時のビデオ玉のダイアログ

スクリプトでアニメーションを操作して、アバターにダンスやポーズをさせる場合、Permission が必要だという話しはすでに書きましたが、この permission 、、、ちょっと危険な香りがする function なんです。それと （複数の人を対象としたダンス・スクリプトとしては、、、逆にかなり難しいですが） 複数の人がひとつのスクリプトを使った場合の llRequestPermissions の動きって、ちょっとトリッキーなんです。すぐに気がつきましたが、アニメーションを操る上では理解しておかないといけないポイントがいくつかあります。


llRequestPermissions... 許可をするときは覚悟が必要？（かも）


llRequestPermissions を使ったスクリプトは実はこれが初めてではありませんでした。はじめて llRequestPermissions を使ったのは「詐欺スクリプト」を検証してみた時だったんです。

詐欺注意　2007年6月23日の投稿です。

お金に絡む Permission　の場合はダイアログが黄色になる、、、みたいな改善がその後行われてきましたが、いずれにせよ、この llRequestPermissions によるいくつかの制御の許可 （自分たちにしてみれば制御権限の委譲) は結構慎重にならなくてはいけないのかもしれません。

たかがダンス、、、といっても、スクリプトの書きかたが十分でないと、、、ダンスがとまらない、、、なんてことになっちゃうんです。
  
続きを読む

前回からの続きで「その３」になりました。
チャットキーボードの次は立ち姿の AO (Animation Override) を、、、と思ったわけですが、スクリプト以前にポーズというものが面白くて、QAvimator などを使って自分でポーズや短いアニメーションを作ってみたりしました。ポーズは Free のものでも相当の数、そしてなかにはクオリティが高いものが出回っていて、Secondlife を始めたころはひとつひとつ試してみたり、「その１」でご紹介したジェスチャに登録して使っていました。

アニメーションとポーズ、、、これは同じものなんですよね。
そのあたりは「ポーズは腰が命 全4回」（笑 や 「QAvimator って面白い」のエントリの中で紹介しています。 QAvimator の使い方、bvh ファイルの作成とアップロードの方法からわかってきました。

でも、自分の作ったポーズ（つまり、フレームを 2 つしか使っていないループアニメーション）って切り替えると「パッ！パッ！」とそのポーズになって、それが「不自然」ということに最初は気が付いていませんでした。それに気が付いたのが Maitreya のポーズを試してみたときでした。


Maitreya - CCRunwayPose21

それはポーズというよりも、立派なアニメーションでした。

これ、フォトだとまったくわからないと思いますが、「きめのポーズ」になるまでの体の動きがものすごくしなやかなんです。そして、数秒たったら、また違うポーズに変化する、、、、というものもありました。
  
続きを読む

前回の投稿でチャットキーボードを作ることでスクリプトによるアニメーション操作を意識した、、、と書きましたが、チャットキーボードをつくった当時は「意識」しただけで、スクリプトが何をやっているのかほとんど理解していませんでした。（笑

チャットキーボードはアニメーション理解の原点（かな？）

チャットキーボード、、、チャットをしているときにアバターがキーボードをタイプするような動き（アニメーション）をするわけですが、せっかくキーボートをタイプしているような動作をするなら、キーボードだしちゃえ！っというのが出発点で、そのうちタイプしているアニメーション自体を変更（このアニメーションの変更を Animation Override （AO: アニメーション・オーバーライド）といいます）して違う動きにしちゃおう、などなど、本来提供されている動き・アニメーションをもとにいろいろなカスタマイズができちゃうわけです。

キャット・ウォークとかセクシー・ウォーク、つまり、飛んだり、走ったりするアニメーションを違うアニメーションに入れ替える AO も、基本このチャットキーボードの仕組みと同じものです。一番はじめにこの単純な「チャットのアニメーション」を利用・変更するということにトライしたのは、今考えると最初の入り口としてはとても敷居が低くてよかったんでしょうね。

ちなみにそのとき作ったチャットキーボードは以下です、、、


この時、同じ「アニメーション」でも「テクスチャ・アニメーション」というものの存在を知りました。黒の背景に緑の文字がばらばらと流れるものをこのテクスチャ・アニメを使って作りました。簡単に言うと、プリムに貼り付けるテクスチャも アニメーション GIF みたいに「動きがある」ものを使うことができて、それをスクリプトの llSetTextureAnim でコントロールすることができるんですよね。llSetTextureAnim も実は奥がとっても深くて、それだけで結構ながーいエントリになるかもしれません。アニメーションだけじゃなくて、たとえば瞬時に画像を切り替えたい場合などは llSetTexture で個別の画像を切り替えるより、llSetTextureAnim と使用する複数の画像を一枚にしたものを使うと、画像切り替え時に灰色になることを避けることができたりします。もちろん、、、画像サイズにもよりますが。

（脱線、脱線、、、）話しを戻して、、、
  
続きを読む

商売っ気がまったくない、、、といえばないのですが、、、（笑
いろいろな「玉」を作ってきましたが、お友達から予想以上に評判がいいのが ネットラジオ・チェンジャー (NetRadioChanger - NRC) です。

やっぱり、自宅、お店、クラブなどなど、、、音楽があったほうが楽しいわけで。
でも、いちいち土地情報開いて、、、なんてめんどうだったり。

そこで、llSetParcelMusicURL を使って、ノートカードに登録している URL をダイアログに表示して、ボタンで切り替える、、、という「玉」を作って、お友達にお渡ししていたわけです。

といっても、あまりエラー処理とか日本語のメッセージとかにしてなかったので、それらをいれて SUZAKU の "Snuript Library" にベンダーとしておきました。

といっても、、、 100 L$ ですけど（笑


（青いグローな玉です、、、、って、パッケージングとかほんと、手抜き、、、）

でもね、実は、この単純な NRC2.2 は Snuript の技術を結集、、、（笑
  
続きを読む

先ほど、ReleaseCandidate 1.19.1.1 をためしたら、AutoScale がちゃんとなっているのを確認しました～。

よかった、よかった。（笑

これって、前にも書きましたが、Land 設定の Media URL の AutoScale は良かったのですが、Script から Agent を指定して Media を動かす場合の AUTO ALIGN,　”true” が効かなくなっていたんです。

Video 玉、、、なんとかいけそうｗ  

先日エントリした llParcelMediaCommandList での AUTO_ALIGN が効かない、、、などいろいろあるので、secondlife.com のブログをよく読むことにしました。

http://blog.secondlife.com/2008/03/06/parcel-media-changes-in-1191-release-candidate/

（ここから意訳・簡略訳です。カッコ内は私のコメント、補足、その他（笑）です）
1.19.1 からいろいろなタイプの Web コンテンツを表示できるようにした、というのが売りです。現在の Parcel Media Player はストリーム オーディオとビデオ(mp3/mov 等 QuickTime で扱うことができるデータ)を利用できますが、新しい media on a parcel 機能は Web ページ、ムービー、イメージ、テキストドキュメント、オーディオといった広い範囲の Web ベースのメディアコンテンツの選択と表示ができるようになりました。
この変更は既存のQuickTime parcel media 機能の置き換え(!!)と拡張であり、さらに柔軟なメディア プレゼンテーションを提供します。現在はほぼ「non-interactive」（対話性なし）で Web リンクをクリックしたり、スクロールバーを使ったり、ボタンを押す、、、なんてことはできません。近い将来にこの手の機能は追加したいけどね。

新しい Parcel Media の機能について知っておいたほうがよい重要なことを以下にハイライトしておきます。  
続きを読む

起こるときは立て続けに起こるのが世の常で・・・・

Video Ball の調子があまり良くないことは前にエントリしましたが、その動きがなかなか理解できず、いろいろなところに llSay を組み込んで様子を見ていたのですが、たまーに出る、ものすごく不思議な動きだったんです。

簡単に言うと、llSetTimerEvent を 15秒に設定したのに、すぐに timer() イベントが動いちゃう、、、という現象です。

最初は自分のスクリプトを疑いましたが、、、変な分岐などもしてないし、ちょっとあれかな、と思うのは state change を行っているのですが、それでも、llDialog の次に llSetTimerEvent を 15秒にするというシンプルな処理で、すぐに timer() イベントになる、、、という動きに確信を持つようになりました。

こういうときは wiki とか jira で検索してみるのですが、wiki に同じような現象で悩んでいる、、との書き込みがありました。

http://lslwiki.net/lslwiki/wakka.php?wakka=llSetTimerEvent&show_comments=1#comments

結局、私も同じ方法 (15秒のタイマーの前に llSetTimerEvent(0.0) をおこなう) と、state から抜けるときに再度 state_exit() を使って llSetTimerEvent(0.0)をしつこくやることにしました。美しくないけど、しょうがありませんねぇ。。。

それでもう少し様子見ですが、いまのところ同様の現象は出ていないようで「やったぁ！」と思ったのですが、、、、

あれれ?　ビデオ表示しているプリムで、AUTO SCALE が、、、、利いてない！！！




なおかつ、そういえば昨日お友達から LAND の MEDIA 処理が 1.19.1 で機能拡張したことを聞いたのを思い出し・・・

嫌な予感・・・  
続きを読む

はぁ～、先日投稿したビデオ玉、ちょっとトラブル発生。

トラブルの原因はまだわかってなのですが、（たぶん、あるパターンで解放されないことがあると思う）ちょっとそこでわかったことをメモ的に。

オブジェクトのインベントリの中のノートカードとかスクリプトのチェックに llGetInventoryKey を使っていました。
ところが ASUKA だと、この llGetInventoryKey をつかっていたことが「あだ」となって、うまくスクリプトのリセットがかからないことが判明しました。

インベントリの中のアイテムの数が多くなったり、重めの SIM で編集からプリムのインベントリを開くと表示されるまで時間がかかることを経験された方も多いと思います。

そんな中で、if (llGetInventoryKey("NOTECARD") != "") みたいなことをやって存在の有無をチェックすると、軽い SIM なら問題なくても、重めの SIM だと存在しているにもかかわらず NULL と判断されて、エラー発生処理になってしまいました。

ということで、この存在有無チェックは却下しました（笑

これで問題が発生したときはスクリプトのリセットができるようになりましたが、、、

根本的な問題は解決してません・・・・もう少し様子見ですね。  

Video 玉やダンス玉 (MLDU) などでダイアログを多用しているわけですが、以前のエントリでも書いたように一人で楽しむならあまり問題がない llDialog も、クラブのような大勢の人がタッチする環境になると問題が発生することがあります。

ダイアログから結果を受けとるチャネルの混線なども代表例ですけど、ある日突然ダイアログが表示されなくなって "Too many listens" というエラーが出るのも、大勢の人が使った結果だといえます。有効な Listen の数は 64 個までで、それを超えるとこのエラーがでます。

llListenRemove による Listen の閉じ忘れ、、、なのですが、じゃぁ、llListenRemove を入れれば必ず回避できるか、、、というとそうでもないんです。

それは timer() と複数人対応と「無視 (ignore)」の組み合わせでスクリプトのある llListenRemove　が働かないことがあるからなんです。   
続きを読む

あの謎の球体の正体が・・・わかりました。
あれって、light の radius の表示なんですね。以前、light の radius の範囲の表示の仕方を投稿していたんですが、Nullpo さんとも話しをして、なんかあの白い球体は light の radius の表示に似てない？みたいなことをいわれていました。

で、、、実は昨日 Yaz Rockett 生DJ がゲリラライブ的に ASUKA で行われｗ



で、ゲリラライブにもかかわらず30人くらいの人がいたのですが、「も、もしや、、、」と思いダンス玉をクリックしてみたら、案の定巨大な白い球体がw
  
続きを読む

年始早々に YazPod 2007 の不具合を発見して、「あ～、なるほど～」と反省。

これまで「玉」しか作ってなかったから（笑）、Rotation ってあまり意識してなかったんですよね。。。

HUD にすると必ずオブジェクトを Rez した時の東側西側の面が正面を向かって表示されます。オブジェクトを編集している間に回転させても、rez した時の rotation は記憶されたままです。言い換えれば、オブジェクトの Primitive Parameter の rotation が <0,0,0> で画面に装着されることになるんですね。



これでも・・・編集で回転すればいいのだけど、それはちょっと面倒ですね。
立方体であれば東側西側を正面として HUD オブジェクトを作成すればいいですが、他の形を使用すると必ずしもそうはいきませんよね。
そこでこの状況を回避するために attach イベント時にこの Rotation の値を変更することで、見せたい面を HUD の正面とすることが可能なんですね。つまりは、HUD  の場合には必ずいれるべきスクリプト、、、なのでしょう。 今頃、、、気がつきました。（笑
  
続きを読む

以前ご紹介した Alissa さんの日本語対応 SL Viewer 「その場入力」 ですが、、、ものすごいことになりました。

というのも、、、LSL で日本語を直接扱うことができるようになったんです。

これ、、、ものすごくインパクトが大きいんですよ。list 型のオブジェクトに直接日本語を入れることもできるんです。

この利点は

1) 日本語のメッセージがどんなものかをエンコードされていない「文字（＝日本語）」で確認可能
2) エンコードされた文字数よりも少ないのでメモリの節約になる
3) デコードするための関数がいらないので、その分処理の高速化とメモリの節約になる

ほんと・・・すごいです！
そこでどのくらいメモリの節約になるかを試した結果が以下です。

Alissa バージョンだと以下のように LSL を書くことができます。

--- LSL code begin -------------------------------------------

list msgList = ["これはテストです","日本語がリストに入ります",
"Alissa さんサイコー","メモリの節約にもなります","確認も楽です"];

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        integer i;
        for(i=0; i<5; ++i) {
            llSay(0, llList2String(msgList,i));
            llSleep(0.5);
        }
        llSay(0,(string)llGetFreeMemory());
    }
}

--- End of source ---------------------------------------------

最後に FreeMemory をとって Say してますが、その結果は以下。  
続きを読む