実行委員関係のお友達からお願いされ、まったく気軽に展示してしまいました、、、MLDU4 RC。 (笑
多人数同期ダンスをしたくて作った MLDU3 をこの半年(!!!) くらいかけて、少しずつ改良、機能を追加していったものです。
なので、、、もともとあまり商売っ気がないダンサー/スクリプタですが、、、まだ売ってません（笑
LSLCON JAPAN 2008 の空中会場のテレポート近くのブースで展示中です。
この数ヶ月、いろいろな方の助けをもらいながら試していたのが
時間差ダンスやシャッフルダンス。以前の投稿にも書きましたが、時間差ダンスのアイディアはすぐに出たのですが、やっぱり、この手のものは半分は「エラー処理」になってしまいますね。基本的なところから例外的なところまでいろいろエラー処理をいれてきました。
Mono 化でメモリーに余裕がでたおかげです。
使い方や、MLDU4 の仕組みみたいなことはブースのパネルでも説明しています。（ええ、トリセツがなくて本当に迷惑をかけていた MLDU3 でした、、、）発売するときはこのパネルもいれようかと思っています。
で、、、展示2日目でエラー発見、、、、@@
ダンススロット管理は MLDU のもっとも重要なところです。たとえば、踊りながら落ちちゃった、他の SIM にいってしまった、、、などという場合は使用しているダンススロット（スクリプト）を解放して、次の人が使えるようにしないといけません。
相当このあたりは MLDU3 からテストしてきたつもりだったのですが、今日ブースにいくとだれも踊っていないのに１つのスロットが使用されている状態になっていました。
そこからいろいろと可能性を考えたのですが、どうやればこの状態になるかしばらくわかりませんでした。
llStartAnimation を Avatar に対して行って、もし Avatar がいなければそれによりスロットの解放をするので、
llStartAnimation は動いていないと想定。とすると、、、以下の場合があてはまるのではないかと予想しました。
llRequestPermissions により「アバターに動きをつける？」ダイアログが表示されているときに落ちる。
試してみると、、、見事に（？）スロット利用状態のままでした。。。（追記 注２）
たしかに、、、
llDialog は使っていませんが、
llRequestPermissions によりダイアログは表示されているわけです。通常
listen イベントで受け取るダイアログとは違って、
llRequestPermissions は
run_time_permissions イベントでうけとる特殊なダイアログですが、ダイアログはダイアログですよね。
ダンススロットが埋まって解放されないのは致命的なので、、、以下のようなエラー処理をいれました。
llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION);
llSetTimerEvent(60.0); // 60 秒タイマーをかける
run_time_permissions(integer perm) {
llSetTimerEvent(0.0); //なんらかの返信があったのでタイマーを止める
if (perm&PERMISSION_TRIGGER_ANIMATION) {
llStartAnimation("animation file name");
llInstantMessage(id, "ダンスを止めたい場合は、、、、");
} else reset(); // [ いいえ ] が押されたのでダンススロット解放
}
timer() {
llSetTimerEvent(0.0);
if (llKey2Name(id)!="") {
llInstantMessage(id, "タイムアウトです～");
}
reset(); //ダンススロットの解放サブルーチン
}
ダンスを踊るかどうか聞く前にスロットを一時的に予約して先にタッチした人を優先させるMLDU の管理・アニメ処理方法が、上記のエラー処理を必要としているかもしれません。その部分のロジックを変更するのはつらいので上記の方法をとりましたが、もう1年近くも使ってきて、
llRequestPermissions のあとで
llSetTimerEvent って、、、ぜんぜん気が付きませんでした。
llRequestPermissions をタイムアウトさせてしまう副作用は、、、、あるんです。
llRequestPermissions によるダイアログへの返答、はい、でも、いいえでも、タイムアウトした後で押すと、、、
run_time_permissions イベントに記述されている関数が、、、動きます。@@
これを無効にする方法が、、、、、ないんです。
そんな、、、と思われるでしょうが、この状態でスクリプトをリセットしても、、、、表示されているタイムアウトにしたダイアログに返答すると
run_time_permissions のスクリプトが動くのです。。。＠＠
つまり、、、あくまで想像ですがこの状態になったときの返答への処理は、スクリプトをよんで処理するのではなく、そのブロックがメモリというかスタック上にあって、それを使うような気がします。（注１）
ですが、、、この例外対応、この状態になったら「落ちている」のがほとんどのはず。故意に60秒間放置して、、、という状態の対応は優先順位が低いと考えました。たしかに「はい」を押すと、
run_time_permissions イベントのブロックに書かれている初期のダンスアニメーションは始まりますが、それ以上はなにも起こらないので、タイムアウトの際のメッセージに「いいえ、を押して再度ダンスボールを押してください」という運用の対応にしてみました。
スクリプトって楽しいけど、難しいですねぇ、、、
[追記] 注１
基本的に LSL もそのときそのときにスクリプトファイルからスクリプトを読むようなことはしていないはず。なので、該当のスクリプトをリセットしても、そのスクリプトから出された llRequestPermissions に対する処理である run_time_permissons の部分がスタック上クリアされていない、、、というのが正しいのかもしれません。（すみません、本当に想像です。。。） run_time_permissions イベントにある llSay や llStartAnimation は効きますが、上記の例だと reset() というユーザー関数は呼ばれません。さすがにそこはスクリプトのリセットによりクリアされているのでしょうね。
[追記] 注２
注、、、というほどのものではないのですが。（笑
通常のご利用だと、今回示した llSetTimerEvent を ｌｌRequetPermissions のあとに入れなくても、スロットが解放されないことはありません。というのも、他のだれかがダンスを開始して管理スクリプトから実行ダンススロットのスクリプトにアニメーション開始命令が出された時点でアバターがいないチェックが入るので、このスロットは解放されます。他の人が使える状態になります。 考えすぎかもしれませんが、、、展示品の状態で「アニメーション許可のダイアログに答えずに落ちる」をスロットの数ぶん
10回繰り返されると、スロットが埋まってしまい、このときオーナー（私 ^^)以外はスクリプトのリセットをかけられないので、展示品のダンスだまでは誰も踊れなくなる、、、というのを回避したかったのです、、、。
[追記] 上記のように思っていたのですが、llRequestPermissions に対する返答をしていない状態なので llStartAnimation がダンススロット側で開始されていません。管理スクリプトからダンス開始命令をだしても、ダンススクリプトは保留中のまま、、、でした。なので、やはりこの処理はもしものために必要だと考えたほうがよさそうです、、、
