やるにはどうするかを考えてみたけども

というわけで、続き。
なんかエロ中学生みたいなタイトルになってしまった

なんか効果的でおもしろいやり方ってないんかなぁ。
とは言え、私が興味があるのは３なんですね。

あと、２と３の間がないことが気になります。
実際、in worldでは初心者講座が多いのですが
もっと目的を絞ったものがあってもいいんじゃないかなと。
たとえば、Pay系とか物理系とか。

こういうのはどうかなぁというのを書いてみます。


１．グループ作成
　　noticeを誰でも送れるようにして
　自己紹介をnoteに書いて流す
　→それぞれの経験や興味を知る
　　自己紹介のタイムロス軽減

　※一ヶ月でnoticeは消えるので
　　いつでも閲覧できるような工夫をする

２．テーマ発表
　　webを使ってテーマを提案する
　たとえば「風見鶏を作ってみよう」とか
　単純なテーマにします
　 ネタ元としてはBBSなどに出てくる質問とかもありですね

　　教えてセカンドライフ(LSL)
　　　http://oshiete.slmame.com/c497.html
　　LSL-BBS
　　　http://bb2.atbb.jp/lslbbs/index.php

　このテーマについて、各自スクリプトを書きます
　最後まで完成できなくても、「こんなふうに作ろうと思った」とか
　どこで実現が難しくなったとか、そういうことを書きます。
　※もちろん、スクリプトを書いた人も、工夫したポイントとかを書きます。

　これをPrimにつめて、noticeで流します。
　※この放流の日は、以下のように設定します。
　　テーマ発表＜放流解禁日＜披露日

３．披露日
　各自のスクリプトを披露します。
　　※テーマを出した人は必ず完成品を披露するという保険をかけます
　この披露日でそれぞれのスクリプトやアイデアについて意見交換します。
　　※必要に応じて解説もいれます。
　その後、意見交換に入ります。
　ここでは、「いいな」と思ったことを評価することを中心にします。
　気になったことも、
　「こうすればもっとよくなるんでない？」という視点を必ずいれます。

　※テーマに詳しい人が中心になって解説をいれてもいいですね

という感じ。

参加する人が、テーマについて事前に考えられることで
　・自分で考える時間をもてる
　・聞くだけの参加では弱い気がします
　　みんなで話す時に、材料を持てると
　　自然と積極的に参加できるんじゃないでしょうか
　・交流会の日は、自己紹介などの時間を省き
　　徹底的に話せる

webなどを利用することで
毎回の内容を蓄積することもできます。
in worldでの場所を確保して
各自が作ったものを展示しておくことで
途中からの参加でも、入りやすいようにできるんじゃないかなと。

なんか効果的というよりは、自分が参加したい妄想なだけですね、これは。
これもまた継続してやっていくのが難しいって課題があります。
難しいなぁ講座

個人的に、講座は、やる人にとってどんなメリットがあるのかも興味があります。
講座やってる人は、どんな動機でやってるんかなぁ。
自分にメリットがないと続けられないと思うし

と、オチなく今回の講座ネタは終了

効果的に

結局、７月は全く更新せず
何を書こうとしても、黒くなるので困ったもんです。

さて、ここんところ、
LSLの講座のことをぼーっと考えてたんですが
なかなかぴんとこないものです。

ちょっと考えていることを整理してみます。
※講座以外もありますが

１．体験型
　これはものすごく初心者向けの内容です。
まず、見せる。
そして、「こういうものができますよ」とか
SLそのものに不慣れな人には、
「いろんなものにスクリプトが入ってるんですよ」という感じです。
LSLの講座というよりも、in worldのツアー的なもので
Scriptに興味を持つきっかけになるようなものを考えています。
新人オリエンテーションの一環として取り組んでもいいんじゃないでしょうか。

　　他のネットゲームから、SLに来た人は
　　アイテムのデザインだけでなく、その「仕組」もユーザによって
　　 作られていることに驚くようです。

LSL-CON(http://lsl-con.org/2008/)の展示にも
これと同じねらいがふくまれています。

　　 Scriptとは違いますが、実際に目にできる場としては
　　 パーティクルラボなどは有名ですね
　　 The Particle Laboratory * Learning Center
　　 http://slurl.com/secondlife/Teal/192/55/21

２．講座型
　スクリプトを勉強するには、webにはたくさん資料があります。
しかし、プログラムそのものに不慣れな人には、
なかなか厳しい道のようです。

　　 LSL Portal
　　 http://wiki.secondlife.com/wiki/LSL_Portal

　　 Makapu@BlackSheep-LSL
　　 http://miz.slmame.com/
　　 ※日本人の場合、ほとんどの人は見ているのかもしれません。

　　 LSL-BBS
　　 http://bb2.atbb.jp/lslbbs/index.php
　　 ※まだまだマイナーですが、日本人向けのBBSもあります。

そこで、実際にスクリプトの説明をし書きながら、
ありがちなミスなどをサポートをする形で講座をします。

　この講座では、講座そのものを受け持つ担当と
進度や理解度の違う人を個別に対応するメンバーが必要になります。
ここで注意しないといけないのは、
参加する人が初心者だからといって、
質問が初歩的な内容だとは限らないということです。
そのため、講座をする人には深い知識が求められます。
また、講座の目的を明確にすることも大事だと思います。
その講座で、どこまでの到達を目指すのか
場当たり的にスクリプトの説明をするだけでは
継続した講座にはならないのではないでしょうか。

３．交流型
　これは正確には講座とは違います（１もそうですけど）。
やりたいことを実現するためには、いろんな方法があります。
そんなお互いの技術交流をする場です。

また、LSLそのものの不具合や、
in worldの環境の特性についての知識も必要です。
それらを全て一人で追うのは難しいので、
得意分野の情報を出し合えるといいなと思います。

　　 Scripter's cafe
　　 http://ja.secondlife.wikia.com/wiki/Scripters_cafe
　　 http://scripterscafe.slmame.com/

これも、なかなか難しいものがあります。
技術交流だけでなく、人同士の交流の側面もあるため
多くのコミュニティが抱える問題があります。
　・常連/非常連の溝
　・参加者の興味のベクトルの差
　・知識/技術の差
　などなど

ということを考えていたわけです。

長くなったので次回に続く

Persimmonは柿です。Permissionの話(3/3)

刑事物語のDVD出ますね。
「違うー！木のやつー！」ですよ。
って、このセリフの出るやつかな、どうかな

前回と今回は
スクリプトの出力を載せてますんで
文字サイズ小さくしたり
なんか工夫して見やすくしてください。

そうさ、見る気のある人だけ見ればいいさ




さて、ここからが本番です。

■重複 Yes/Yes(その１)

[22:55]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:55]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:55]  Object: llRequestPermissions
○you Xiao ダイアログ放置

●you Pizzicato touch
[22:56]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:56]  Object: llRequestPermissions
●you Pizzicato ダイアログ放置

○you Xiao Yes押す
メッセージ出ません
●you Pizzicato Yes押す
[22:56]  Object: run_time_permissions perm[16] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

ほー、こうなるんだ
llRequestPermissionsした瞬間、その前のllRequestPermissionsは無効ですか


■重複 Yes/Yes(その２)

[22:57]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:57]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:57]  Object: llRequestPermissions
○you Xiao ダイアログ放置

●you Pizzicato touch
[22:58]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:58]  Object: llRequestPermissions
●you Pizzicato Yes押す
[22:58]  Object: run_time_permissions perm[16] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

○you Xiao Yes押す
メッセージでません

この結果は、その１から考えても想像できますよね

一応、No/Yesもやっておきます

■重複 No/Yes

[22:59]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:59]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:59]  Object: llRequestPermissions
○you Xiao ダイアログ放置

●you Pizzicato touch
[23:00]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[23:00]  Object: llRequestPermissions
●you Pizzicato No押す
[23:00]  Object: run_time_permissions perm[0] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

○you Xiao Yes押す
メッセージでません

やはり、llRequestPermissionsした後の結果に関係なく
llRequestPermissionsを実行したら、前のは無効ってことですじゃのう


なるほどなぁ
理解が深まりましたよ、ほんとに。

えーと、あれだ
「２．無視して別の人の権限要求をする」でいいのかってことでしたね。
結論としては、
「最後のllRequestPermissionsだけが有効なので、それでいいさ」ってことですかね
ダイアログを押すタイミングは問題じゃありませんでした。

あ、ついでに補足実験
「llGetPermissionsKeyは、いつ変わるのか
　要求した瞬間変わってんじゃねーの？」です。

default
{
  state_entry()
  {
      llOwnerSay("state_entry perm["+(string)llGetPermissions()
                      +"] name["+llKey2Name(llGetPermissionsKey())
                      +"] key["+(string)llGetPermissionsKey()+"]");
  }
  touch_start(integer total_number)
  {
      llOwnerSay("touch_start perm["+(string)llGetPermissions()
                      +"] name["+llKey2Name(llGetPermissionsKey())
                      +"] key["+(string)llGetPermissionsKey()+"]");

      llRequestPermissions(llDetectedKey(0),PERMISSION_TRIGGER_ANIMATION);
      llOwnerSay("llRequestPermissions");
      llOwnerSay("touch_start perm["+(string)llGetPermissions()
                      +"] name["+llKey2Name(llGetPermissionsKey())
                      +"] key["+(string)llGetPermissionsKey()+"]");
  }
  run_time_permissions( integer perm )
  {
      llOwnerSay("run_time_permissions perm["+(string)perm
                      +"] name["+llKey2Name(llGetPermissionsKey())
                      +"] key["+(string)llGetPermissionsKey()+"]");
  }
}

これはダイアログが押された時っぽいです

[0:41]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[0:41]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[0:41]  Object: llRequestPermissions
[0:41]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao Yes押す
[0:42]  Object: run_time_permissions perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

Persimmonは柿です。Permissionの話(2/3)

駐車場の隣の田んぼから
カエルの鳴き声がします。

カエルは、種類を問わず苦手です。
カエルというか、両生類・爬虫類
実は鳥類も苦手です。
哺乳類もちょっとやばいかもしれない。
イヌ・ネコ程度が限界です。

ということで、基本的な動作確認からやってみます。




※冗長かもしれませんが、毎回resetしています

■権限要求にYesする

[22:49]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:49]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:49]  Object: llRequestPermissions
[22:49]  Object: run_time_permissions perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

普通に権限とれてますね。これはわかります。


■権限要求にNoする

[22:50]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:50]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:50]  Object: llRequestPermissions
[22:50]  Object: run_time_permissions perm[0] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

え、こうなんの？
run_time_permissionsそのものがこないのかと思ってた。
つまり、権限はとれなくても、「その人への権限要求はやったよ」ってことになるの？

ここにはこんなふうになってます。
http://wiki.secondlife.com/wiki/LlGetPermissionsKey
「Returns a key that is the agent that permissions are enabled for.
　NULL_KEY if not enabled.]

ここでちょっといやな予感がしてきました。

一応、muteもやってみます。

■権限要求にMuteする

[22:50]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:50]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:50]  Object: llRequestPermissions
[22:50]  Object: run_time_permissions perm[0] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

これは想像できましたが、スクリプトの反応そのものはNoと一緒なんですね。

さて、ここから二人体制です。
と、いっても片方はAltです。
登場人物はyou Xiaoとyou Pizzicatoです。

■順番にYes

[22:51]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:51]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:51]  Object: llRequestPermissions
○you Xiao Yes押す
[22:51]  Object: run_time_permissions perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

●you Pizzicato touch
[22:51]  Object: touch_start perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]
[22:51]  Object: llRequestPermissions
●you Pizzicato Yes押す
[22:51]  Object: run_time_permissions perm[16] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

まあ、これはそうなるでしょうね。普通です。

■順番にNo

[22:51]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:52]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:52]  Object: llRequestPermissions
○you Xiao No押す
[22:52]  Object: run_time_permissions perm[0] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

●you Pizzicato touch
[22:52]  Object: touch_start perm[0] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]
[22:52]  Object: llRequestPermissions
●you Pizzicato No押す
[22:52]  Object: run_time_permissions perm[0] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

これも、そらそーだって感じです。

ということで、次の実験が、さっきの「イヤな予感」です。
you XiaoがYesした後、
you PizzicatoがNoするってパターンです。

■順番にYes/No

[22:52]  Object: state_entry perm[0] name[] key[00000000-0000-0000-0000-000000000000]
○you Xiao touch
[22:53]  Object: touch_start perm[0] name[] key[00000000-0000-0000-0000-000000000000]
[22:53]  Object: llRequestPermissions
○you Xiao Yes押す
[22:53]  Object: run_time_permissions perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

●you Pizzicato touch
[22:53]  Object: touch_start perm[16] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]
[22:53]  Object: llRequestPermissions
●you Pizzicato No押す
[22:53]  Object: run_time_permissions perm[0] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]

やっぱり、こうなんだ...
念のため、you Xiaoがタッチしてみます

[22:53]  Object: touch_start perm[0] name[you Pizzicato] key[a64ee0a7-3cf6-40f9-bb33-1138cf8be7d7]
[22:53]  Object: llRequestPermissions
[22:53]  Object: run_time_permissions perm[0] name[you Xiao] key[f7d1fc77-08ac-47e1-8881-e9d9e03194e7]

つまり、llRequestPermissionsを実行すると
そのYes/Noの結果に関係なく、
llGetPermissionsKeyとllGetPermissionsが返す値は変わるってことみたいです。

なんとなく、「Yesで権限とれた場合のみ変わる」という認識でした。
うへー

続く

Persimmonは柿です。Permissionの話(1/3)

もうyouはblogをやめたのかという噂も
流れてるような気もしますが
単にコード書きとエロ画像収集に忙しかっただけです。
※ここんところ、文字ばっかりなので
　画像をつっこんでおきます










先週のOH(※1)では、midoriさんの記事(※2)から、
スクリプト管理(LnkMsgの量などの部分)にちらっと触れました。
この手の複数スクリプト管理は、すでに何度もやってるんですが、
権限がからむのはやったことがなかったので
ちょっとそそられてしまいました。

※1 Scripters Cafe
http://scripterscafe.slmame.com/
http://ja.secondlife.wikia.com/wiki/Scripters_cafe

※2 シンクロダンスボールのまとめ
分割しなければならないスクリプト4
http://midorin.slmame.com/e647638.html

ということで、今回はちょっとPermissionの話です。
　　※Permissionそのものについては例のごとく割愛
　　※これは先日、iNNXの大将と実験してた結果をまとめるために、再実験したものです

スクリプトを書いていると、いろんなところで権限が必要になります。
で、そのオブジェクトを身につけていたり、座っていたりすると
許可を得ずに権限をとることができます(PERMISSION_DEBIT等は別)。

ところが、身につけていないアイテムの場合
こんなダイアログが出ます。







私は、この「他人の権限を要求する」というアイテムを
ほとんど作ったことがなかったので
今まで深く考えたことがなかったのです。
今回、ちょっと考えてみたんですが、
なんだかすんなりいかない気がしてきました。

たとえば、タッチすると、権限の要求をするオブジェクトがあるとします。

こんなコードです。※誤解の余地がないように、かなりベタにしてあります

default
{
state_entry()
{
   llOwnerSay("state_entry perm["+(string)llGetPermissions()
                   +"] name["+llKey2Name(llGetPermissionsKey())
                   +"] key["+(string)llGetPermissionsKey()+"]");
}
touch_start(integer total_number)
{
   llOwnerSay("touch_start perm["+(string)llGetPermissions()
                   +"] name["+llKey2Name(llGetPermissionsKey())
                   +"] key["+(string)llGetPermissionsKey()+"]");

   llRequestPermissions(llDetectedKey(0),PERMISSION_TRIGGER_ANIMATION);
   llOwnerSay("llRequestPermissions");
}
run_time_permissions( integer perm )
{
   llOwnerSay("run_time_permissions perm["+(string)perm
                   +"] name["+llKey2Name(llGetPermissionsKey())
                   +"] key["+(string)llGetPermissionsKey()+"]");
}
}

気になったのは「誰かがタッチしてダイアログを放置した場合」です。
llDialogなどはタイムアウト処理として
Listenを閉じてしまえばいいのですが
権限要求の場合、タイムアウトするにはどうすればいいのか
この場合のタイムアウトにはいくつかの処理が考えられます。

１．なんらかの方法で権限要求をなかったことにする
２．無視して別の人の権限要求をする

まず、１．ですが、結果的にいうと、スマートな方法はないようです。
　　portalをじっくり見るまでは、こんなこと考えてました。

A)NULL_KEYに対して権限要求してみる
　　llRequestPermissions(NULL_KEY,PERMISSION_TRIGGER_ANIMATION);
　　　→エラーになります
　　　　　　"Unable to find specified agent to request permissions."

B)ゼロを権限要求してみる
　　llRequestPermissions(llDetectedKey(0),0);
　　　→権限要求そのものが発生しません
　　　　ダイアログがでませんでした。

llGetPermissionsのところに、jiraへのlinkがはられていました。
"Unable to release permissions" https://jira.secondlife.com/browse/SVC-1006
「とった権限をリリースする方法がねぇよ」って感じかな

これに関してはStrife Onizukaがこんなコメントつけてます
「Try this instead, It might work.
　llRequestPermissions(llGetOwner(), 1)」
　※この1っていうのは、ここにもUnknownですが書いてありますね

　ああ、無効な権限の要求するのね、ゼロじゃダメなのかとやってみたら
　こんなダイアログでました。ちょっとヘンですね。








タイムアウトのたびに、ダイアログ出すわけにもいきません。

今のところの結論としては、スクリプトをresetするしかないようです。
何かいい方法をご存知の方はコメントでもください。

さて、２．なのですが、これは実験する前にこんなことを妄想してました。

ある人(Xiao)がタッチ
　↓
ダイアログ出る
　↓
寝落ち
　 ↓
別の人(Pizzicato)がタッチ
　 ↓
ダイアログ出る
　 ↓
Yes押す
　 ↓
Xiaoがハッと目覚めて、Yesを押す

これはどうなるんだろう...

次に続く

影

やあ、影だ影だとエロ写真を撮っていたり
別にステレオグラムなエロ写真を撮ったわけではないです。
なんかいろいろやってるうちに、なんか影が変わったりしたので
比較写真です。

これ影で見ると左の方が荒いです。
Flickrのオリジナルサイズで見ないとわからないくらいです。
ただ、これ画面ではもっとヒドイのです。



これは一目でわかりますよね。
上の方が粗いです。
これ撮影時間もほとんど一緒で、
設定は完全に同じです。















AVにマウスのカーソルが乗ってるかどうかで、影が変わるようです。
注目すべきオブジェクトはコレだ！みたいな判断になってるんでしょうか。
確かに、常時細かい描画してたら死ねますよね。

ということで、こんなこともあったよーという話でした。
影が思ったよりもキレイにでてるので、びっくりしました。

ちなみに、Helpのとこのやつは、こんな感じです。

Shadow Viewer 1.23.0 (1) Apr 1 2009 15:44:35 (Cool Viewer)
Release Notes

Built with MSVC version 1400

CPU: Intel Core 2 Series Processor (2666 MHz)
Memory: 3583 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GTS/PCI/SSE2
OpenGL Version: 3.0.0

Link系の関数をもっと使ってみるの４

さて、これでルートのスクリプトだけで
ある程度のことができるようになりました。
これで最後です。

では、こういう処理と、llMessageLinkedを使った処理
どっちがいいのかという話。

まず、長々と書いてきた、ルートからの操作の方を考えてみます。

１つのスクリプトにすることで無駄なメモリを減らせます。
※スクリプトを減らすことで、
　コーディング時の注意を一箇所に向けられるというおまけもあります

また、llMessageLinkedの情報送信はprimを指定して行います(リンク番号やLINK_SET等)。
スクリプト指定ではありません。
そのため、ルートに複数のスクリプトがあれば、
子primからルートに情報を送った時に
全てのスクリプトのlink_messageイベントが発生します。
(link_messageがなければ問題ナシ)
これは意外とイラっとさせられます。

一方、llMessageLinkedの使用にも、変えがたい魅力もあります。
たとえば、タッチで処理を行った時に、その処理が少し時間がかかるとします。
その場合、その処理が終わるまで、スクリプト全体が無反応になります。
llMessageLinkedを使って複数のスクリプトを並行に動かせば
これは軽減することも可能です。

と、このように「どうしたいか」によって
処理の仕方を変える必要があります。

"ボタン→スクリプトいれておこう"ではなく
「どうしたら、もっとコンパクトになるかな」とか考えることは、
ある種、パズルのような楽しさがあります。
楽しいだけでなく、コンパクトになるなら、
使う人や周りの人にとってもお得です。

今回の投稿は、どうせスクリプトを書くなら、
その選択肢の幅が広がればいいなというのが動機でした。

LSLについては、みんな手探りでやっている状態です。
こんなやり方あるよーとか、いろいろ出し合って腕を磨いていきませんか

※今回のコード部分には、これを使ってみました
http://lsl-users.jp/codehighlight/

Link系の関数をもっと使ってみるの３

さて、これまで、タッチ→処理ということでしたが
その処理部分で何ができるかも、少し考えてみます。

ルートから子を操作する関数は今のところ以下の通りです。
llSetLinkAlpha
llSetLinkColor
llSetLinkTexture
llSetLinkPrimitiveParams
※漏れてたら教えてください

まあ、llSetLinkPrimitiveParamsがあるので
かなりのことができます。
ただし、Delayも考えると、単純にllSetLinkPrimitiveParamsだけとはなりませんが。

※蛇足ですが、jiraにはllSetLinkTextを求める声もでています。
"llSetLinkText or a FLOATING_TEXT option for llSetLinkPrimitiveParams"
→ http://jira.secondlife.com/browse/SVC-2367

でも、お気づきの通り、ルートから子primの情報を取得するための
Get系がありません。これはセキュリティ等が考慮されているのかもしれません。

むりやり、なにか情報をとろうとするとllGetObjectDetailsなんかも
有効なケースもあります。

default
{
   state_entry()
   {
       integer i_lnkno = llGetNumberOfPrims();
       list l_detail = [];
       for (;i_lnkno>=2;--i_lnkno){
           l_detail = llGetObjectDetails(llGetLinkKey(i_lnkno)
               ,[OBJECT_NAME
               ,OBJECT_DESC
               ,OBJECT_POS
               ,OBJECT_ROT
               ,OBJECT_VELOCITY
               ,OBJECT_OWNER
               ,OBJECT_GROUP
               ,OBJECT_CREATOR]);
           llOwnerSay((string)i_lnkno+":"+llList2CSV(l_detail));
       }
   }
}
 

と、まあこんな感じで、あまり有効なものはとれません。
※というか、この部分は半分ネタとしてみてもらってもいいです

こんな時はどうするかってことですが、
初期化時に、ルートから各primの設定を行い
実行中にその状態を更新していくことが考えられます。

処理：ボタンAを押すたびにボタンの色が赤と黒に交互に変わる

【初期化】
ボタンAを黒くする
　　→管理用変数に黒をセット
【実行】
ボタンAが押される
　　→管理用変数が黒なら赤くする
　　　　→管理用変数を赤に更新
　　→管理用変数が赤なら黒くする
　　　　→管理用変数を黒に更新

ちょっとめんどくさそうですが
子prim内で処理する場合でも、llGetColorなどで
いまの色を取得して処理するのではなく
なんらかのフラグで処理しているはずです。
あまり変わりません。

こんなふうにルートから子primの操作も
制限があるとはいえ、工夫次第で可能ですよね。

４に続く

Link系の関数をもっと使ってみるの２

さて、この名前とリンク番号ですが、
この対応は、リンク順を変えた時しか変わりません。
※当たり前のようですが、AVが座った場合を考えると
　よく考えられているなと思います。

ということは、先に名前からリンク番号を取得しておいて
タッチした時には、リンク番号だけで判断すればいいのではないでしょうか。

では、スクリプトリセット時にprim名からリンク番号を取得しておいて
それを使って分岐する例です。

integer gl_i_primA = -1;
integer gl_i_primB = -1;

integer f_init()
{
gl_i_primA = gl_i_primB = -1;
integer i_lnkno = llGetNumberOfPrims();
string s_primnm = "";
for (;i_lnkno>=2;--i_lnkno){
    s_primnm = llToUpper(llGetLinkName(i_lnkno));
    if (s_primnm=="A"){
        gl_i_primA = i_lnkno;
    }else if (s_primnm=="B"){
        gl_i_primB = i_lnkno;
    }
}
if(gl_i_primA<0)
    return FALSE;
if(gl_i_primB<0)
    return FALSE;
return TRUE;
}

default
{
state_entry()
{
    if(f_init()==FALSE)
        llOwnerSay("設定エラー");
}
touch_start(integer total_number)
{
    integer i_lnkno = llDetectedLinkNumber(0);
    if(i_lnkno==gl_i_primA){
        llOwnerSay("A");
    }else if(i_lnkno==gl_i_primB){
        llOwnerSay("B");
    }else{
        llOwnerSay("ELSE");
    }
}
}

一応、求める名前が全てない場合は、エラーとするようにしています。
この処理にはいくつか問題があるかもしれませんが
基本の考え方は、こんなふうになると思います。
※no modアイテムとして配布するような場合は
　これでも問題ないかもしれません。

ひとまず、これで各primにスクリプトを仕込まなくても
ルートに１つスクリプトがあれば、処理ができることがわかります。

リンクprimがいっぱいあれば、それなりに初期化に時間がかかります。
　※リンクできる上限までリンクして、試してみてください。
初期化時の時間が気になるなら、
必要な名前のprimが出揃ったらループを中断するようにしましょう。
また、同じ名前のprimをうっかりリンクした場合などの
エラーチェックもあってもいいかもしれません。

他にも製作過程では、リンクなんてしょっちゅう変えるので
Changedイベントを設定しておくのもありでしょう。

    changed( integer change )
 {
     if (change & CHANGED_LINK){
         if(f_init()==FALSE)
             llOwnerSay("設定エラー");
         //llResetScript()でもいい
     }
 }

※リンクを変えなくてもAVが座った時にも、このイベントは発生します。

今回の例では、integerの変数にリンク番号を格納しましたが
押されたprimに対してメッセージを返すだけならListを使うことも考えられます。

作りたい処理にあわせて、工夫してみると楽しいです。

また、touch系の関数も組み合わせると
タッチされた子primの面や位置なども取得できます。

３に続く

Link系の関数をもっと使ってみるの１

最近、見たり聞いたり買ったりするオブジェクトが
子primにみっしりとスクリプトが入っていることが多く、
これは意識的にしてるのかなという疑問がおこりました。

ということで、４回にわけて、スクリプトをまとめることについて書いてみます。
わりと一般的なことしか書いていませんので、
Hack的な内容は期待しないでください。

では。


LSLのプログラムを書いていると
llMessageLinkedを使うことがあります。
というか、これナシには話が進まないほどです。

これは大きく２つの用途があります。
A)他のprimとの通信
B)他のスクリプトとの通信
(メモリ制限のため/機能をスクリプト単位で分けるためなど)

B)の場合は、自主的に選択してスクリプトを分けていますが
A)の場合は、「これしか方法がないから」という人も多いのではないでしょうか。
たとえば、ボタンがたくさんあって、それぞれに機能が違うので
各ボタンにスクリプトを仕込んで、押されたよということを
ルートprimに伝えるとかですね。

でも、条件によっては、llMessageLinkedを使わなくていい場合があります。
たとえば、単純にタッチされたprimに応じて処理を行いたい場合です。

一番単純な方法では、llDetectedLinkNumberだけを使います。

    touch_start(integer total_number)
  {
      llOwnerSay((string)llDetectedLinkNumber(0));
  }

これで、どのprimがタッチされか区別できます。
試してみるとわかるのですが、
子primでは２～の番号
ルートprimでは、１が返ってきます。
(※リンクされていない場合、タッチすると、0が返ってきます)

さて、これでなんかできそうな気がしてきます。
ただ、この状態では、どのprimがどのリンク番号なのかぴんときません。
任意のリンク番号がつくようにリンク順を調整するなんてやってられませんし。

ということで、次にllGetLinkNameを使ってみます。
これは、指定されたリンク番号のprimの名前を返します。

    touch_start(integer total_number)
  {
      integer i_lnkno = llDetectedLinkNumber(0);
      string s_primnm = llGetLinkName(i_lnkno);
      llOwnerSay((string)i_lnkno+":"+s_primnm);
  }

各primに名前をつけておくと、それをルートから取得できるわけです。
これなら、リンク順に関わらず一定の結果を得られます。
これでかなり実用的になります。

この段階でも、単純に名前で処理を分岐させることもできます。
ただ、タッチするたびに、この処理をしてから
名前で分岐するのかと考えると少し気が重くなりますよね。

２に続く