2008年11月28日金曜日

感謝祭と環境SIM

今日はアメリカでは感謝祭、Thanksgiving Day ですね。
この時期のアメリカのお祭と言うと
日本ではやたらとハロウィーンばかりが有名で
10月のSLはどこへ行ってもカボチャだらけでしたが、
感謝祭の方はあまり馴染みがないようですね。
このお祭に賭けるアメリカ人の情熱もまたすごいものがありまして、
例のバンコク空港の閉鎖の件でも、
自宅で感謝祭を祝えないじゃないか、と空港の係員に食ってかかる人の
映像がBBCだったかCNNだったかで出ていました。
それほどに大事な感謝祭。。。

リンデンの社長のMさんから感謝祭を祝う書き込みがありました。
http://blog.secondlife.com/2008/11/26/happy-thanksgiving-from-all-of-us-at-linden-lab/

うん。おめでとう。
だけどさ、Mさん、もっと他にみんなに言わなきゃいけないこと
あるんじゃないの? って言いたくなりますね。

例の、環境SIMの件、
11月13日のフォーラムにとうとうM社長が登場、
みんなの発言に感謝すると共に、
この件に関しては土地についての担当者である
ジャックが適任だと思うので、
彼から返事させます、との一言があり、
お、とうとうM社長現れたか!
ジャックの回答は? と待つまでもなく、
その1時間後にこのフォーラムはクローズします、
みなさんありがとうございました、とのロビンの発言と共に
あっけなく終わってしまいました。
Mさん、自分が行いたいのは対話だとして、
そのために舞台をフォーラムに移したのでしたが、
結局この一言だけでフォーラムを閉じてしまい、
対話も何もあったものではありませんでした。
しかもフォーラムなんか細かくチェックしてる人
そんなにいるとは思えないから、
何となく闇に葬られたような感じもしてます。

最終的に当初の予定通りの価格設定にすると決定するとしても、
それはそれで企業の判断なので構いませんが、
これだけ多くの住民を騒がせておいて
一言もないままに感謝祭おめでとうはないな、と思うのです。

最近のリンデンのブログはやたらと前向きな記事が多いのですが、
環境SIMの件について触れなければ触れないほど、
これらの記事がご機嫌とりのように見えて
何とも虚しく感じてしまうのは僕だけでしょうか?

本当に住民のみんなを大切に思っているのなら
社長としてちゃんとけじめをつけてほしいなぁ。

というわけで、Happy Thanksgiving!

2008年11月26日水曜日

スクリプトの話〜番外編・色の名前

ここ2回ほど、色を指定する話題を出しましたので
それに関連して色の話を。。。

僕は会社に勤めながら
一方ではWEBの制作なんかもしてるわけなんですが、
そうするとどうしても色を扱うことになるんですね。
で、例えば「白」を表現するのに、WEBであれば
「#FFFFFF」というコードを使いますし、
会社でエクセルのマクロを組む時なんか
(「あ〜、ヒロシ君、この管理表ね、
終わった課題の行はグレーにして
重要度が「高」のものはピンクになるようにしといてねー。」)
RGBで「255, 255, 255」と表現したりします。
これだけでも一杯一杯なのに、
リンデンスクリプトでは <1.0, 1.0, 1.0> というのを
覚えなきゃならなくなりました。
うわー、大変!
どれか一つに統一してくれ〜!

ところが、実はこの3つ、同じものだったのですね。
RGBというくらいで、光の3原色、
赤と緑と青をどのくらい混ぜるか、というのを表しています。
ご存知のように、赤と緑と青、全部を全て100%ずつ混ぜると
白になります。
そして、この3つ全てが全くない状態、
それが暗闇の黒、というわけですね。
と、すると、リンデンの <1.0, 1.0, 1.0> というのはわかりやすい。
最初、色はベクトル型、と聞いて、
数学の時間を思い出し、妙な矢印を思い出していた僕ですが、
何のことはない、この3つの数字は、赤、緑、青を
どのくらい混ぜるかを示しているだけですね。
<1.0, 1.0, 1.0> は全てが100%ということですから白、
そして、<0.0, 0.0, 0.0> は黒、というわけです。

となると、いわゆるRGBは?
WEBカラーのしくみは?

そう。まず、RGBの方は名前から言っても
リンデンと同じなのでしょう。
(255, 255, 255) は赤と緑と青のレベルだ。
でも何故255なのか?
これが0スタートということを考えると、
つまりは256の段階があることになり、、、
うーん、256とはいかにもコンピュータらしい数字だ。
そもそもこの数字は何なのか。。。

実はこの10進法の255を16進法で表すと「FF」なのです!
16進法で最大の数である「F」が2つつながった形、
つまりは16×16を表現しているわけですね。
ということは!
そう。
無意味に思えたWEBカラーの「#FFFFFF」も
何のことはない、「FF, FF, FF」だったのであり、
つまりは「255, 255, 255」であったわけなのです。
で、255では扱いにくいので、これを1.0に置き換えたのが
リンデンのスクリプトというわけです。
みんな同じ数字だったのだ!^^

と考えると、つまりこれらは全て、
赤と緑と青の組み合わせを示しているわけですから、
一々覚えたり、チャートを見たりしなくても
感覚的に、簡単に表記できるようになりますね。

つまり、「赤」は赤100%なので    <1.0, 0.0, 0.0>
「青」は青100%なので、      <0.0, 0.0, 1.0>
「緑」は緑100%なので、      <0.0, 1.0, 0.0>
「黄色」は赤と緑の組み合わせなので、<1.0, 1.0, 0.0>
「空色(アクア)」は緑と青で、   <0.0, 1.0, 1.0>
「赤紫」は赤と青で、        <1.0, 0.0, 1.0>
そして3色全開の白が         <1.0, 1.0, 1.0>
暗闇の黒は              <0.0, 0.0, 0.0>
というわけですね。

気づけば何てことないですし、
気づいている人には何を今更、という話でしょうが、
僕自身、これらの色を覚えられずに手こずりましたので、
敢えてここにメモとして残しておくことにします。
ご参考まで。w

スクリプトの話(19)〜リストを使おう

前回はバーニング・ライフで使った
色が順番に変わるオブジェクトを例に
周期的に状態を変える方法について考えました。
そこで今回はその続きのような感じで、
もう少し考えてみたいと思います。

同じバーニングライフの僕のキャンプには、
星をイメージしたパーティクルが飛び交っていて
これが一定時間が経つと色がランダムに変化するような
そんな仕掛けにしてありました。

ランダムと言えば、乱数を発生させる関数を持って来ればできそうですが、
ここで扱うのは色というベクトル型の変数であるし、
何よりランダムと言っても、とんでもない色ばかり出て来ても困るので、
出来れば指定した色の中でランダムに変わるのが望ましいのです。
そんな欲張りなことができるのか?
そう、出来れば好きな色のリストみたいのがあって、
その中で順番がメチャクチャに入れ替われば……。

と思ってはたと思いつきました。
そうです。リストです。
整数型や文字列型のように頻繁に出て来るわけではないので、
目立たない、ジミ〜な存在ですが、
リンデン・スクリプトにはリスト型という変数があるのです。
これはいろんなものをまとめて放り込んでおける
なかなか便利な変数なのです。

昨日と同じく、青、赤、黄に白を加えた4色の間で
ランダムに色を変化させるということにして、
この4色のリストを作りましょう。
宣言の方法も簡単です。
要素をブラケット(四角い括弧)で囲んで
カンマで区切って並べるだけです。

list lstColors = [ <0.0, 0.0, 1.0>, <1.0, 0.0, 0.0>, <1.0, 1.0, 1.0>,
  <1.0, 1.0, 1.0>];

今、lstColors というリスト変数の中は、青、赤、黄、白という色が
順番に並んでいます。
ここで関数の登場。その名もズバリ!

llListRandomize()

文字通り、リストをランダムにする関数です。w
ランダムにした後どうするか?
出来たリストから1番目の要素を取り出してあげればいいのです。
そして、その要素を取り出すのが、変数によって異なりますが、

llList2〜()

という関数で、今回はベクトル型なので、

llList2Vector()

を使います。
昨日のスクリプトを参考にして、
20秒毎に色をランダムに変化させるには次のようにします。

default {
  state_entry(){
  }

  touch_start(integer total_number){
    llSetTimerEvent(20);
  }

  timer(){
    llSetColor(llList2Vector(llListRandmize(lstColors), 0),
      ALL_SIDES);
  }
}

llList2Vector() の2番目の引数が
リストの何番目の値を取ってくるかを示すもので、
1番目は「0」になります。
関数が入れ子入れ子になっててややこしそうですが、
何ともシンプル、1行で終わってしまいました。w

ん? ということは?
昨日の順番に色が変わるスクリプトも
このリストを使えばすっきりするのでは?

i = 0;

default {
  state_entry(){
  }

  touch_start(integer total_number){
    llSetTimerEvent(20);
  }

  timer(){
    llSetColor(llList2Vector(lstColors, i), ALL_SIDES);
    i++;
    if (i >= llGetListLength(lstColors) - 1) {
      i = 0;
    }
  }
}

llGetListLength() は、リストの要素の個数を返す関数です。
例えば今回の場合、青、赤、黄、白の4個になります。
但し、リストの順番も、カウンター変数 i の値も
「0」からスタートしているので、1を引いているわけですが、
昨日の「if 文」がずらずらっと並んだものに比べると
何ともシンプルになりましたね。
カウンターの値を増やしながら、
そのカウンターの値と同じ順番の色を持って来い、
と言っているわけです。
そしてカウンターが要素の数だけ増えると
また0に戻してあげているのですね。

リストはこのように順番に処理させる時にも使えますし、
それから、先に書いたようにいろんな要素を入れられるので、
データベースのような使い方もできます。
例えば、昨日ご紹介した、仲間のブログを表示する
メッセージボードですが、
あれは実はセカンドライフの中から僕のRLのサイトにアクセスして、
次のようなCSVファイルを作らせています。

記事1のURL, 記事1のタイトル, 記事1の更新日
記事2のURL, 記事2のタイトル, 記事2の更新日
記事3のURL, 記事3のタイトル, 記事3の更新日……

もうお分かりですね?
タイマーでこのファイルを1行ずつ取ってくるのですが、
その時に、1行の3つの要素、
記事のURLとタイトルと更新日とをリストに入れるのです。
そしてそのリストからタイトルと更新日を取り出して表示に使い、
URLは取り出したらそれをタッチスクリプトに入れて、
メッセージボードをタッチするとその記事がブラウザで開くように
設定してあるわけです。



今のところ、説明が飛ばしすぎで分からない、という方は
ごめんなさい、あまり気にしなくてもいいです。
とにかく、リストを使うといろんな複雑な処理も
簡単に行えるようになるのだ、
というくらいお分かり頂ければ幸いです。

あまり馴染みのないリスト型ですが、
このように複雑な「if 文」を使わずに済んだりと
いろいろ便利な使い方ができるので、
皆さんもいろいろ研究してみられてはいかがでしょう?

それでは今日はこの辺で。

2008年11月25日火曜日

スクリプトの話(18)〜3つ以上の状態判定

いやぁ、この連載も随分間が空いてしまいました。
今回含めて残りあと3回なんですけどね、
一気に行けそうなのに、なかなか時間がとれないでいます。
まぁ、のんびり最後までお付き合い下さい。

     *   *   *

さて、前回は状態の判定をするのに
「1」と「0」を使う話をしました。
人間が物事を判断する基準は
大抵が「OK」か「NG」
「Yes」か「No」
「いい」か「悪い」
つまりは「真」か「偽」かに還元できるもので、
それだからこそ、コンピュータはその人間の真似をして
「1」と「0」との組み合わせだけで複雑な処理をするわけですね。
「1」と「0」の間で旗を上げ下げして処理を分岐するのは
いかにもコンピュータ・プログラムらしいとも言えますし、
同時に人間的と言えるのかもしれません。

ところで、物事の判断というのは
必ずしも二者択一であるとは限りません。
楽しいお昼休み、今日の昼食はどこにするか
ラーメンか牛丼かカレーか
はたまたイタリアンかフレンチか……?
結局は毎日のように行っていると飽きてしまうので、
これらの店に順繰りに行くかもしれません。w

今年のバーニングライフの
僕のキャンプにあった巨大なメッセージボードは、
実は20秒おきに色が変わる設定ができます。
確か7色くらいを設定して
順番に変わるようにしてあったのですが、
そこでどんな処理をしているかと言うと。。。



話を簡単にするために
色を青、赤、黄の3色に限定します。
そして、タッチするとタイマーがスタートするとしましょうか。

integer i = 0;

default {
  state_entry(){
  }

  touch_start(integer total_number){
    llSetTimerEvent(20);
  }

  timer(){
    if (i=0){
      llSetColor(<0.0, 0.0, 1.0>, ALL_SIDES);
    } else if (i = 1){
      llSetColor(<1.0, 0.0, 0.0>, ALL_SIDES);
    } else if (i = 2){
      llSetColor(<1.0, 1.0, 0.0>, ALL_SIDES);
    }
    i++;
    if (i = 3) {
      i = 0;
    }
  }
}

実際にはもっと複雑ですが、
大体こんなイメージです。
大事なのは、変えて行きたい色の順番に数字をふっておいて、
変更するごとに1を足しているところです。
(そう。i++ は i = i + 1 のことですね。
こういう略した書き方をするとプログラムも
シンプルにすっきりとするので
じゃんじゃん使いましょう。w)
そして、順番の最後のところで
数字を振り出しの「0」に戻してあげてるところですね。
これでまた1...2...と数え上げて行き、
またまた最後の所で0に戻り、、、と繰り返していくわけです。

先に書いたお昼に何を食べるか、という件も、
これをカレンダーに仕込んでおけば、
昨日はカレーを食べたから今日はイタリアン、
なんて教えてくれるかもしれません。w

あ、実際にはこれの応用で、
僕の Lifebound Records 本店のメッセージボードが稼働しています。
仲間のブログの最新記事を順繰りに表示していますが、
記事と合わせてその方のアイコンに変わるようになっているのも
この仕掛けが使ってあるのです。



それでは今日はこの辺で。

2008年11月24日月曜日

ありがとうございます。

昨晩のリハビリライブは無事終了しましたのでご報告。
(本当に「無事」だったのか?w)
急なお知らせだったにも拘わらず
タイガーカフェの仲間を中心にたくさんの方々に来て頂き
感謝感謝のヒロシです。

本当はね、やると決めて日記で宣言するまでは
体もふにゃふにゃで、とても楽器なんか演奏するパワーも
人を相手にするエネルギーすら残っていなかったのですが、
いざやると決めて練習を始めたら
だんだん元気になってきて
そして皆さんにお会いして、演奏を進めていくうちに
どんどん元気を取り戻して来たのです。

やはり因果なミュージシャンですからねー、
楽器を弾いてこそ自分の表現ができるし
表現できたところで先へ向かえるというのがありますね。
それより何より、やはり気の合う仲間と一緒に時を過ごすことほど
元気になるものはないですね。
人の存在の力ってすごい、と思います。

そんなわけで、
本当に充実したひとときとなりました。
改めて、ありがとうございます。

2008年11月23日日曜日

今晩23時よりリハビリライブw

久しぶりに休日のヒロシです。
と言っても、疲れすぎていたのか
午後4時くらいまでグワぁ〜と寝ておりました。^^;

naturalway Flow さんとのコラボ以来
SLにも殆どインしておりませんでしたので
今日はリハビリを兼ねてひさびさに土曜日定例の
ライフバウンド・カフェでのライブを23時より行います。
お時間ある方は遊びに来て下さいね。

「ひさびさ」と書いたのだけれど、
11月8日のナチュさんとのコラボからは
まだ2週間しか経っていないのですね。
それがひと月に感じられるほどに
SL時間は早く流れていくようです。
それほどに濃く、深く、尊い、みなさんと過ごす一瞬一瞬。
そんなひとときをこれからも過ごせることを楽しみにしています。

それでは、また。

■Hireoshi Kumki Saturday Night Live
・日時:2008年11月22日(土)
・会場:Lifebound Cafe
http://slurl.com/secondlife/Fanghammer/23/73/22/

2008年11月10日月曜日

チャリティ・ライブ&コラボ無事終了!

今日は朝早くから仕事で、
日記書くのがメチャメチャ遅くなりました。
で、昨日のご報告です。w



昨晩は自分のライブの前に、同じ趣旨で演奏をされている
フォンタナ・オーケストラとGA-GOさんのライブを
ちょこっとだけ見に行きました。
フォンタナは知り合いの Ami Nicholls さんや taiji Lorefield さんが出てましたねー。
曲は僕が、多分一番大好きなベートーヴェンの五番。
その第一楽章が終わったところで僕自身も募金をして
GA-GOさんの会場へ移動。



GA-GOさんのステージは相変わらずかっこいいですねー。
見ててホントにおもしろい。
曲もいかにもライブ、って感じでいいしね。
ただ、自分のライブの準備があるので
こちらは2、3曲だけ聴いていよいよ会場へ。

僕らのライブはまずナチュさんの Music StarMine で始まり、
休憩を挟んで僕自身のライブとなります。
実を言うと、ナチュさんとのコラボのことで一杯一杯だったので、
自分のライブでやる曲は「Requiem」をやる以外には
全く考えてなかったんですね。^^;
というのも、これ、8分近いので、
30分の枠となると、、、他に何をやるか、難しいんです。w
でもね、みんなの前に出ると、
そしていろいろMCでしゃべったり時計見てるうちに
何やるか、決まってくるんですよ、これが。w

そして!
僕のライブが終わった後、太鼓を叩いてナチュさんを呼び出します。
ここからが本日のメイン・イベント。w
ナチュさんと僕と、お互いに相手の出してきたものに反応して
音やパーティクルを返していきます。
ちょっといたずらっ気を出してシンセで雷の音出したら、
ナチュさん、火で応えてくるし。w
おおー、さすがー、と思いつつも、
いつまでも雷やってるのはつまんないので、
きれいな曲に切り替えたら
これまたナチュさん、幻想的な絵を出してきます。
うーん、素晴らしい。
と、気持ちよくその世界に浸っていると
ナチュさん、飽きたのか、派手なものを出し始めました。
OK、OK、わかったわかった、というわけで、
僕も今度は元気なリズムの曲に切り替えます。。。

どこで始まる、というのは決めてましたが、
どこで終わる、というのは決めてなかったのです。w
RLのライブだったら目くばせしたり、
SLならIMしたいところですが、
いかんせん、両手が塞がってます。w
二人とも画面と音だけで合わせていったのでした。w

いやー、皆さんにも大変喜んで頂きましたが、
僕ら自身、やってて楽しかった。
ので、またどっかでやるかもです。
お楽しみに。w

喜んで頂けた、と言えば、
MCを通じて声かけした甲斐あって、
昨晩のライブで1万リンデン以上募金を頂きました。
募金下さった方、本当にありがとうございました。
1万リンデンと言えば、ポリオのワクチンで250人分、
結核のワクチンで500人分にも匹敵します。
これでたくさんの子供たちの命が助かるといいですね。
このチャリティー・イベント、僕はもう出ませんが、
11月15日までやっていますので、
ご関心がある方、好きなアーティストの方が出られる時は
是非是非ご参加下さいね。

それでは、今日はこの辺で。
ありがとうございました。

2008年11月9日日曜日

ネットからライブを聴けるようにしました。

ソラマメのページをちょこっとだけ変更しました。
サイドバーのビデオとCDの紹介の下に
ちいちゃーく「ネットライブはこちら」というリンクがあります。
クリックするとiTunesかWindows Media Playerが立ち上がるはずです。
これで、セカンドライフにインできない場合でも
僕のライブ演奏を聴くことができるというわけです。

勿論、演奏していない時にはソフトが立ち上がっても
何も聞こえてきません。^^;
なので、本当は放送中かどうか、表示したいのですが、
今のところまだいいアイデアが浮かばないので、
それでちょっと遠慮がちにちいちゃーく書いてます。w

というわけで、今晩は23:00よりライブです。
既にご案内した通りですが、
ナチュさんとのコラボがありますのでお楽しみに。
是非是非いらして下さいね。w

■Music StarMine with Hiroshi Kumaki
・日時:2008年11月8日(土)23:00〜24:30
・会場:SGLand2
 http://slurl.com/secondlife/SGLand/245/120/31

またまたリンデンへ一言(環境SIMについて)

さて、週末となり、ちょっと時間が出来たので、
例の環境SIMの件で、フォーラムで一言発言してきました。
例によって既に2,000件近くになっていましたし、
特に目立ったところがある発言でもないので、
果たしてどのくらい真剣にリンデンの人々に見て頂けるか
怪しいところではありますが。
以下、その内容を翻訳、転載しておきます。
恐らくは多くの方々が同様に感じておられるのではないでしょうか。
原文はこちらです。ログインが必要です。
http://forums.secondlife.com/showthread.php?p=2213691#post2213691

     *   *   *

確かに、現在の過負荷状態を解消するのに、商品のラインナップと価格設定を改訂するというのは解決策のひとつではあります。私はこの考えを基本的に支持するものですが、以下のナレッジベースにて公表された仕様は、大多数のセカンドライフ住人にとって、到底受け入れられるものではないのではないでしょうか。

http://forums.secondlife.com/showthread.php?p=2208520#post2208520

環境SIMの価格が通常SIMの4分の1に設定されているのであれば、誰もが通常SIMに対して4分の1の性能を期待するのではないでしょうか。しかしながら、上記のページに載っている環境SIMの仕様では、プリムは通常SIMの20分の1、アバターは10分の1となっています。これでは、結局のところリンデン・ラボが考えているのはこれまでと同じ1/4の費用を受け取りながら、実際には1つのCPUで10個の環境SIMを稼働させることではないかと疑わざるを得ません。これは「ホームステッド」についても同じです。通常SIMの1/3の価格に対して、プリムは1/4、アバターは1/5です。現在、きっとリンデン・ラボのスタッフはスクリプトやストリーミングといった事象がネットワークに与える影響について調査、計算をしており、それに時間がかかることはわかっていますが、スクリプトの制限について発表される時、それもまた私たちをがっかりさせるような数字なのではないかと恐れています。

このような程度の仕様で、一体私たちに何をしろと言うのでしょう? 私たちにできるのはせいぜい、リンデン・ラボが期待しているそのままに、海や森林を作って置いておくことくらいでしょう。現在環境SIMを規定通りに軽く使用し、必要であれば制限もやむなしとしたオーナーの方々が今回の改訂に満足して喜ぶと、本当にMさんやジャックさんやその他のリンデン・ラボのみなさんは思っていらっしゃるのでしょうか? いえ、これは改訂ではありません。改悪です。

そう、今回の変更はサービスの低下または値上げというように私には思えます。もしリンデン・ラボが環境SIMに対しUS$75.00を設定するのであれば、環境SIMには1/4の性能を持たせるべきですし、ホームステッドがUS$125.00なら1/3は当然でしょう。でなければ、みんな環境SIMなんか捨ててしまって、セカンドライフから去っていくでしょう。

今年の初めに環境SIMの価格改定が行われた時に、リンデン・ラボはセカンドライフの世界がより拡大していくことを望んでいたはずです。が、今回の価格改定を見ていると、どうも同社は今やセカンドライフを小さなものに縮小したいと考えているとしか思えません。

この投稿の冒頭で書いたように、SIMを3つのレベルにするという考え自体はいいと考えています。しかし、環境SIMとホームステッドの価格はその機能に見合っていません。リンデン・ラボが価格と機能レベルを見直し、全ての住人が納得する決断を最終的に下されることを期待します。

ありがとうございます。

     *   *   *

因みに、この投稿についてはレスがつきました。
一体こんな仕様の環境SIMで何をしろと言うの? という所を引用し、
「そうおっしゃる方はメインランドにお越し下さい。きっと羊のように大切に飼ってくれますよ。」
というコメントでした。^^;
更にそのコメントにもレスがつき、
「うん、だんだん僕もこの『飼われている』という状態に
もういい加減嫌気がさしてきたよ。
そろそろ群れから飛び出て、囲い(つまりグリッド)から
逃げ出すかな。」
という始末。
更に元の人がレスして。
「そうやってやめる人がいるから
リンデンは都合の悪い歴史を消すことができるんだよ。
で、また何も知らない新しい人がやって来る。。。」

まぁ、本当にみんなイラついているようですね。

例によってあまりに数が多いので
投稿全部を読んだわけではないですが、
全体としては、私と同じく、
使用レベルに応じてSIMの価格、機能を分けること自体はいいが、
よくよく見ると今回の提案の内容は前のものよりひどい、
どうしても現在の使用レベルの環境SIMはUS$125.00でなければならず、
現在の価格を維持したい人は機能がメチャメチャ制限されます、
という内容ではないか! と不満に思っている方が多いようです。

私も、フルに機能を使いたいなら通常SIMで、という考えは
よくわかるのですが、そしてそれは当然と思いますが、
今回の発表による価格と機能はあまりにもバランスが悪いので
一言言わせて頂いた次第でした。
コメントではなく、みんなと会話がしたいとおっしゃっいたM社長、
なかなかフォーラムに登場しませんが、
こうしたみんなの意見を聴いてどうされるおつもりなのでしょう?

2008年11月8日土曜日

【緊急告知】今晩もチャリティ・ライブ!〜そして新しい試み

ヒロシです。
今晩は、23:00から naturalway Flow さんとのコラボで
チャリティ・イベントに参加します。



これはあいおい生命保険株式会社が主催している
「Heart-Lifeチャリティ・イベント」の一環で、
10月11日〜11月15日まで行われる一連のイベントで集まった寄付金に
同額の寄付金をあいおい生命がプラス、
これを日本円にして
認定NPO「世界の子どもにワクチンを 日本委員会(JCV)」に
寄附するという趣旨のものです。
合計9つのSIMで36日間にわたって開催されるという
何とも規模の大きなイベントですね。

今晩は何とですねー、
次のように豪華なライブが3つもあるのですよ。w

■GA-GOチャリティ・ライブ
・日時:2008年11月8日(土)22:00〜23:00
・会場:IOIisland at 特設ライブステージ
 http://slurl.com/secondlife/IOIisland/26/41/32

■フォンタナ・オーケストラ・クラシック・コンサート
・日時:2008年11月8日(土)22:00〜23:00
・会場:waseda at waseda講堂
 http://slurl.com/secondlife/waseda/161/116/27

■Music StarMine with Hiroshi Kumaki
・日時:2008年11月8日(土)23:00〜24:30
・会場:SGLand2
 http://slurl.com/secondlife/SGLand/245/120/31

そう!
あの GAGO さんに、フォンタナ・オーケストラも登場!
どっちも見たいですねー。
ガーゴさんのステージは盛り上がるだろうし、
オーケストラにはタイガーカフェでおなじみの
Nada Dryke さんも出演されるし。。。
そう言えばなださんはこのイベントのチャリティ・モールに
Tabby Cat として服のお店も出店されているので
こちらも必見です。

そして!
ガーゴさんやフォンタナさんが終わった後に、
SLでしか見られないナチュさんの幻想的な
Music StarMine のショーが行われます。
みんなが花火に見とれ、音楽にうっとりしているところへ
のこのことヒロシが登場。w
しばらくソロで演奏した後、
終盤、ナチュさんの花火と僕の演奏のコラボになります。

このコラボレーションは完全に即興で行われるもので、
僕はナチュさんの花火を見て感じたことを音にしていきますが、
ナチュさんも僕の音を聴いて次々に出してくることになっていて、
お互いがお互いに影響し合いながら
恐らくは本日限りの、二度と再現できない
スペシャルなショーになると思います。
これは絶対に見逃せませんよ。^^
お楽しみに!

スクリプトの話(17)〜「旗を立てる」・状態の判定

さて、私のSL内の(一応)会社である Lifebound Records には
写真に見られるように左右にスライドして開く自動ドアがあります。
この自動ドアは私が豊島区で初めてお店を作った時に
初めて取り組んだスクリプトものでもあります。
豊島区からスタトラ、メインランドと移ってきて
再びこのお店に設置することにしたのです。



ところで、この自動ドア、
よくよく考えると不思議ですよね。
左右に開く、右側の方に焦点を当てて考えると、
開く時には元の位置から右方向に移動してしまうわけです。
そして閉まる時には開いた場所から今度は左方向に移動して
元の位置に戻ってくることになります。
左側のドアはこの逆の動きになりますね。

ということは、このドアは、右のも左のも、
今自分がどこにいて、次のイベント
(人が近づくとか遠のくとかーーセンサー・イベントですね)
が起こると、右に動いたらいいのか、左に動いたらいいのか
知っていることになります。
言い換えれば、今ドアが開いた状態なのか、閉じている状態なのかを
それぞれのドアは知っている、ということになりますね。

どうやったらこれら左右のドア・オブジェクトに
開いているとか閉じているということを教えられるでしょう?

こういう時、オブジェクトの状態を表す変数を用意してあげます。
integer(整数)型で、普通の状態、つまり閉じている時は0,
変化があった時、つまり開いた時の状態を1として、
名前は例えば isOpen、つまり「開いている」という名前にしましょう。
開いていれば isOpen = 1、
閉じていれば isOpen = 0
というわけです。

ここでドアを開くようにオブジェクトを動かす関数を openDoor() ,
閉じるように動かす関数を closeDoor() とすると、

integer isOpen = 0

if (isOpen = 0) {
  openDoor();
  isOpen = 1;
} else if (isOpen = 1) {
  closeDoor();
  isOpen = 0;
}

実際にはもっと複雑な処理になりますが、
イメージはこんな感じです。
初期状態としては、ドアは閉まっているわけですから、
isOpen には「0」が代入されています。
そして、「if文」では、
isOpen が「0」、つまり閉じている時は
ドアが開く処理をして、ここが大事なのですが、
処理した後に、isOpen に「1」を代入、
つまり、ドアが開いているという状態に変えています。
この状態で再びイベントが発生すると、
今度は isOpen = 1 となっているので、
ドアを閉じる処理が走り、
そしてその処理が終わると今度は isOpen に「0」を代入、
ドアが閉じている状態に変化させるわけです。

このように何かの状態を判断させなければならないような時、
integer型の変数を用意して「1」と「0」を代入して、
現在のその変数の値を見て処理を分岐させるのはよくあるやり方です。
ちょうどスイッチの「ON/OFF」のような働きをしているわけですね。
こういうはたらきの変数をプログラムの世界で何と言っているのか
私はよく知らないのですが、
元々データベースの世界から入った私にとっては
「フラグ」という表現がぴったりしているように感じます。

「フラグ」というのは勿論英語の「flag」、つまり「旗」のことです。
変化があった時にパッと旗を上げて注意を促すような感じで、
実際にデータベース用のブラウザでデータベースの状態を見ていると、
注意すべき項目のところに、ピコンと真っ直ぐに旗を立てたように
「1」とデータが入っているのです。

プログラムの世界でも同じで、
何か変化があった時、状態が変わった時は
この旗をピコンと上げる変数を用意してあげればいいというわけです。
状態の違いで処理を変えたい場合は
是非この旗を上げるような変数を使ってみて下さい。
きっといろんな場面で便利ですよ。w

2008年11月7日金曜日

SIMのラインナップ比較表

先のM・リンデン社長の記事にあったナレッジベースから
今提案されている商品のラインナップについて
比較表を翻訳、転載しておきます。
ご参考まで。



【翻訳】セカンドライフ住民の皆様への手紙(長文)

RLの仕事の関係で大変遅くなりました。
既にいろんな方々が書いていらっしゃるでしょうから
情報としては古くなってしまったかと思いますが、
これまで環境SIMの問題についてはずっと訳して参りましたので、
改めてここに本日のM・リンデンさんの発表の全文を
翻訳しておきたいと思います。
例によって非公式な翻訳であり、
誤訳等の文責は全てHiroshi Kumakiに帰するものです。
原文はこちら。
http://blog.secondlife.com/2008/11/05/a-letter-to-second-life-residents/#more-2778

     *   *   *

M・リンデンです。私共の環境SIMについての発表について、ご心配や建設的なご提案を頂いた皆様に深く感謝したいと思います。私共は皆様のご意見に対して慎重に耳を傾け、最初に発表した計画に修正を加えることと致しました。

ここで、方針の修正内容に入る前に、私共がどのような決断をしたかについて述べ、そして皆様からのご意見を要約してお伝えしたいと思います。環境SIMが導入された当初は、リンデン・ラボはプライベートSIMのオーナーに対して、オープンな場所である環境SIMをご自身のSIMに追加する機会を提供しましたが、これは海や公園といった、軽い使用法に限ってのことでした。が、この時私共は環境SIMをガチガチに作り込んで、細かい、量的な制限を設けることは致しませんでした。何故でしょう? それは単に次の2つの理由によります。

1. 皆さんもよくご存知のように、あるSIMのパフォーマンス(性能)というものは多くの要因によって影響を受けていて、それもそれぞれーーつまり、スクリプト、プリム、アバター、メディアといったそれぞれーーが互いに複雑に関係しながら影響を受けているのです。これらSIMのパフォーマンスに影響するあらゆる変数に対して制限を加えることで、皆さんのセカンドライフでの経験や創造性までもが制限されてしまうようなことはしたくなかったのです。それはリンデン・ラボは常に自由な形態をとってきており、セカンドライフの住民の皆さんが本来お持ちの善意というものを信じているからであり、また、制限を加え、それが確実に実行されるようにするにはそのための要員を雇わなければならないからです。

2. この環境SIMという商品を、私共は早く世に出したいと思っておりました。環境SIMはあっという間に広がりました。海を追加したプライベートSIMのオーナーもいらっしゃいますし、公園を作った方もいらっしゃいます。それは私共が意図した通りの使い方でした。が、多くの方々が環境SIMに作ったのは巨大な帝国でした。豪華壮麗な建物、美しいレンタル用の土地や建物、その他大きな建造物などを作ったのです。環境SIMのオーナーは他のオーナーの方々と同じCPUに同居している状態ですので、もしあるオーナーが海として使っている一方で別のオーナーが遊園地のような場所として使うとしたら、共同で使用しているこのCPUは過負荷状態となってしまいます。本来意図された通りの方法で使用している海を愛するオーナーがその影響を被ってしまうことになるのです。ここにおいて私共はこうした問題を解決するために今回この問題に立ち入ることにしたのです。しかし、セカンドライフはこうした問題一つ一つに対応するには、あまりにも大きくなり過ぎていたのです。

それは多くの皆様との会話、皆様からのご意見、ノートカード、メール、お電話を通して、その良い点悪い点を整理していく過程の中で、皆さんが発信しておられるご意見の内容は多岐にわたるものの、その中には私共が実際に対応可能な3つの一貫したテーマを見出すことができました。

1. 海や公園といった、本来意図された通りに環境SIMをご利用になられている方々は現在の価格の維持を求めており、その使用法について明示的に制限が加えられることに対しては同意しても構わないと感じていらっしゃるということ。

2. 環境SIMを使用して商業行為をされている方、レンタル用に貸し出していらっしゃる方、グループ活動をそこでされていらっしゃる方々については、確かに本来環境SIMに想定されている以上の作り込みをしていることは認めるものの、大きな、しかも急激な価格の上昇に対応することは不可能であり、経営的に打撃を受けてしまうということ。

3. 中には海のように何もないところではなく、しかし遊園地のように重い所でもなく、その中間のような場所を作っていらっしゃる方は、「通常SIMのライト版」のようなものを求めていらっしゃいます。通常のSIMよりは安い価格帯で、しかもある程度のものがビルドできるようなSIMをです。

リンデン・ラボの歴史の中で、私共は3種類の土地をリリースしてきました。メインランド、プライベートSIM、そして環境SIMです。セカンドライフの他の要因がやたらと複雑であるため、価格設定に関しては複雑なシステムにすることを私共はしたくありませんでした。しかし、今や、よりフレキシブルに需要に対応するために、商品のラインナップと価格体系を見直さなければならないことは明白となりました。

1. 「環境SIM」は現在の価格のまま提供することと致します。但し、森や海といった、本来想定された用途に限ってのものとします。適正にご使用頂くために、これには技術的な制限を加えさせて頂くこととします。まず最初にアバター数、プリム数の制限から始めて、最終的にはそこで行われるイベントや広告、スクリプトなどを制限していきます。引き続き「環境SIM」をご利用になられたい方は、現行のUS$75.00/月の料金となります。但し、そのようになさりたい旨、コンシエルジュ・チームにご連絡頂く必要があります。

2. このような「環境SIM」以上のものを求める皆さんには「ホームステッド」と呼ばれる新しいラインナップのSIMに移行して頂くことをお勧めしたいと思います。これは、少ない人数に対して土地をレンタルすることが可能な程度の軽い使用目的のためのSIMです。現在「環境SIM」をお持ちのオーナーの方々に対し、半年の移行期間を設けてこの新しいSIMの価格を適用したいと考えています。この新しい「ホームステッド」もまた、技術的な制限が、まずアバター数とプリム数に、最終的にスクリプトに対して加えられます。

※2009年1月5日ーー規定に沿わない使用法をされている「環境SIM」はこの日を以て「ホームステッド」へと移行し、毎月の維持費もUS$75.00からUS$95.00に引き上げられます。この新しい「ホームステッド」については、資格を持つ教育者の方々には割引価格での提供を致します。割引率は通常のSIMと同じく約30%です。

※2009年7月ーー「ホームステッド」の維持費は月US$95.00からUS$125.00に引き上げられます。

これらの変更についての詳しい情報は、以下のナリッジベースをご覧下さい。
http://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=5650

私共はこれが一番公正な方法だと考えています。ジャックと私は、今日は一日中フォーラムにログインして皆さんとこのことについて話し合ってきました。このブログの記事については、コメントの書き込みは一切受け付けません。それは、皆さんとの対話を制限したり、皆さんの自由な表現を制限したりするためでは勿論ありません。私共は住民の皆さんと会話したいと思っているのであり、フォーラムにはログインが必要だからです。これは大きな発表を行い、その事を先に進めるのに私共がとっている方針なのです。まずブログで案内する。そしてフォーラムで意見を言い、互いに話し合う、ということです。

こうした物事の進め方で私が学んだ、そして他のスタッフが改めて気づかされたことがひとつあります。それは、私共の今があるのは、いつも気持ちをひとつにし、熱心に取り組んで下さる住民の皆さんのおかげだということです。であればこそ、私共は皆さんを、できるだけ早い段階で対話に参加して頂きたい、最終的に結論を下すのはそれからにしたいと思うのです。ジャックが本件について発表を行ってから頂いたご意見はどれも実り多きものであり、そしてその殆どが、本当に、本当に建設的なものでした。セカンドライフは1対1の会話が困難な規模となっており、フォーラムも完全に対話が成立する場としては不十分なものではあるでしょう。また、私共の営業時間が不十分であるということもあるでしょう。皆さんに早い段階で対話に参加して頂ける方法についていくつか考えがあり、近々このブログとフォーラムでの会話の中でお伝えすることになると思います。

この考えについて、簡単にまとめておきたいと思います。この1年、住民の皆さんの関心事は専らセカンドライフ・プラットフォームの安定性でした。それは多くの人々の、スタッフだけではなく住民の皆さんも含めた多くの人々の努力の結果、私共は大きな躍進を遂げることができ、このことは多くの資料で裏付けることができます。クラッシュ率も低下しました。それも劇的に。これ以上何を言うことがあるでしょう? 今回の価格改定の件が出るまで、私共は顧客満足の点で好調であり、皆さんは私共がこれまで行ってきた改善についてよくわかって下さり、評価して頂いていると思っておりました。安定性の改善に関しての飛躍的成果は特筆すべきものであり、そのことは今年に入ってからセカンドライフ内の土地が大いに増加したことからもわかります。そして、その土地の増加の大部分は環境SIMによってもたらされたものなのです。初期の想定では土地は大きく広げていくものの、それに対する負荷はより低い比率で、と考えられていたのです。が、環境SIMは多くの場合、スクリプトやアバターによって過負荷状態となり、これまで成し遂げた飛躍的な安定性と同じくらいの予期せぬ過負荷状態を抱え込んでしまうこととなってしまいました。私共はセカンドライフを世界一の、最も優れた仮想世界のプラットフォームとすることにその使命を賭けております。そして事実私共は日々大きく躍進しているのです。継続的な安定性の向上というお約束を私共はこれまで実現し、証明して参りました。どんな予期せぬ拡大に直面しても、です。

フォーラムにて、皆さんからのご意見を伺えるのを楽しみにしています。
http://forums.secondlife.com/showthread.php?p=2208520#post2208520

皆さんの率直なご意見、辛抱強さ、抑制のきいた態度、そしてリンデン・ラボ、セカンドライフ全般に対して喜んで協力されようとする姿勢に感謝しております。セカンドライフは驚くべき存在です。それは、リンデン・ラボが時に不完全ながらも、常にその住民の皆さんと一緒になって、みんなが心から愛して病まない現実の世界以上に大きな、素晴らしい世界を作り上げているからなのです。

ありがとうございます。

2008年11月5日
M・リンデン


2008年11月6日木曜日

スクリプトの話(16)〜宿題の答え=発想の転換を

さて、既に15回を越えましたこの稿も、
今回からはスクリプトを書く時のヒントのようなものについて
触れていってみたいと思います。
そのまずは一回目。。。

前回変数の初期化について書いた時に、
僕自身が作った「世界時計HUD」の例を挙げました。
これは写真にあるように、画面右上に世界の時間を表示するもの。
時間の下にあるバーをクリックして文字色を変えたり、
時間の計算をしたりすることができます。



前回話題にしたのは、
折角お好みの色に変更しても、
次にログインした時に文字色が初期化されてしまうので、
最後に設定された色を覚えさせることはできないか、
というものでした。
さて、どうするか?

実は、前回これについては別の機会に、と書いたのは
記事自体が長くなったからというのもありますが、
実は、私自身、どういう処理をしたのか
全く覚えていなかったからです。^^;
そこで実際にスクリプトを見てみましたが、
それでも暫くは意味不明でした。w
そして、あっ、と思い出しました。

最後にどんな色に設定したか、
それをどうやって覚えさせるか、
そしてそれを起動時に取得するか。
ノートカードを利用することは考えられますが、
あんまり複雑は処理はしたくありません。
そこで、僕はじーっとこのHUDとにらめっこしたのです。

もう一度このHUDの写真をよく見て下さい。
実は、こうやって時間を並べるのに使っているのは
何のことはない、例の llSetText() なのです。
そう、フローティング・テキスト、
で、何の上にフロートしているかというと、
設定用のボタンとなっている下のバーですね。
ということは、そう、
このバーは HUD なので平面ですが、
実際にはブロック・オブジェクトなんです。

と、ここまで書けばおわかりでしょうか。
文字色の設定をする時に、このブロックも
同じ色に設定しているのです。
そして、このブロックの色は一旦設定されたら
起動時もその色のままのはずです。
私が state_entry() で書いている処理は次の1行でした。

  llGetColor(4);

これはそのオブジェクトのかっこ内の番号で示された面の
色を取得する関数です。
ここで4番というのがこのHUDのバーとなっている面の番号です。
文字の色そのものは保存できないので、
このオブジェクトの色をまず取得し、
その色を今度は文字の色として
設定し直すということをやっていました。
これであれば、敢えて色を保存したり
それを呼び出したりなんて複雑な処理はいらなくなりますね。
自動的に残ってしまっている値を
そのまま使えばよかったわけです。
ただ、ここで、
文字そのものに拘らず、同じ色を使っているオブジェクトに
視点を移したのが解決の鍵となりました。

リンデンのスクリプトに用意された関数は、
例えばエクセルの関数などに比べると随分少ない気がします。
例えば llSet〜 (値設定用の関数)はあるのに
セットとなるべき llGet〜(値取得用の関数)がないとか、その逆とか、
えー、何でこれないの〜? と驚くこともしばしばです。
基本的にはなかったらできません。
が、そこでないからできない、と諦めるかどうか。
何か他の方法はないか、
処理したい対象(今回の場合文字の色)を直接扱うのが無理なら、
他のもの(今回の場合バーのオブジェクト)を処理することで
回り道しながらでも実現できるかもしれません。
場合によっては、SLの中から抜け出して、
自分のWebサーバで処理させてもう一度SLに返すといったような
荒技まで考える必要があるかもしれません。

明らかに直球ではムリ!
そんな時こそ苦しみながらも
何か手はないかと考えるのが楽しみになってきますね。
そして、自分でも信じられないような解決を見いだした時の
嬉しさといったら!

。。。なんだけど、
自分がやったことを完全に忘れていたヒロシでした。w
今回はこの辺で。

     *   *   *

P.S. オブジェクトに色をつけたり、
テクスチャを貼ったりする時に、
面を指定したい時がありますね。
関数としては、

  llGetColor()/llSetColor()
  llGetTexture()/llSetTexture()
  llGetPrimitiveParams()/llSetPrimitiveParams()

などがあります。
が、自分が設定したい面が何番になるのか、
LSL Portal の「Face」の項を見てもよくわかりません。
こんな時は編集モードで、「テクスチャを選択」の状態で、
指定したい面を選択、丸に十字が出ているのを確認します。
そして、メニューから
Advance > Rendering > Selected Texture Info を選ぶか
ctrl + alt + shift + T(Macの方は cmd + option + shift + T)
と操作すると、画面左下に2行の情報が表示されます。
その最後の「face X」の「X」が面の番号ということになります。




大抵のスクリプトの入門書などでは
面の値に ALL_SIDES つまり全ての面を設定しているものが多く、
私自身面番号の指定で苦労したので
ここに補足として書いておきます。

【翻訳】明日、環境SIMについての発表を致します。

環境SIMの件について
本日ジャック・リンデンさんから新しい記事がアップされました。
この件について気を揉んでいらっしゃる方も多いと思いますので、
ここに全文を翻訳しておきます。
例によって非公式の翻訳ですので
誤訳等の文責は全てHiroshi Kumakiにあります。
また、原文はこちらです。
http://blog.secondlife.com/2008/11/04/openspace-announcement-due-tomorrow/

     *   *   *

先週の間ずっと、私共は皆さんのご意見に耳を傾け、最初に発表した内容について何度も検討を加えました。今回のこの記事は、私共の考えが皆さんのそれとより近づけることができるようなタイミングになってきたということをお伝えするだけのものです。

明日、M・リンデンがこのブログに記事を投稿するでしょう。この記事は皆さんから頂いた本当にたくさんのご意見に対するお返事であると同時に、環境SIMの件に関して私共がどのように事を進めようとしているか、詳しくお伝えするものになるはずです。

このMの記事が発表された直後に、私共はフォーラムにて新しいスレッドを立て、そこで皆さんからのご質問に出来うる限りお答えしていくつもりです。この件に関し、皆さんが今か今かと新しい情報を待っていらっしゃるということを承知しております。その待ちももうすぐ終わりですと、皆さんにお伝えしたいのが今の私の気持ちです。

2008年11月4日
ジャック・リンデン


2008年11月5日水曜日

【技術情報】惜しい! Chrome Mac版!

以前この日記でも絶賛したGoogle Chromeですが、
そのMac版とも言えるものが日本語版でリリースされましたね!
「とも言える」と書いたのは
本家Googleからのリリースではないからです。

これはCodeWeaverという会社が
WindowsアプリをLinuxやMacで動かすための
Wineという技術を発表していて、
その技術を使ってGoogle ChromeをLinuxやMacで動くように
パッケージ化したもの。
それを更に日本のネットジャパンという会社が
日本語化してのリリースとなったものです。
パッケージとしての名称は CorssOver Chromium。

実は日本語版はダウンロードページに
ブックマークの保存ができない旨書いてあったので、
えー、っとか思って英語版も併せてダウンロードして
機能比較してみました。

確かに、日本語版はブックマークが保存できないですね。^^;
登録はできるんだけれども、再起動すると消えてます。><
更に、Google Chrome の最大の売りと僕が考えている、
新しいタブを開いた時に表示されるはずの
最近開いたサイトのサムネールも何故か表示されません。><
フラッシュ・プラグインもインストールできないし、><
そうそう、パスワードで保護されているページへのログインも失敗!
うーん、これじゃぁダメダメだぁ。

一方、英語版はこれらの問題は全てクリアーされてます。
おー、おー、なかなか良いではないか。。。
と思いきや!
最大の欠陥が!
それは日本語の入力ができないのでした!><
これでは日本語の検索できないじゃん!w

というわけで、そもそもWinアプリがMacでも使えるよ、
という製品の副産物としての要素が大きいですね。
もうちょっと基本性能をアップしてからのリリースを
期待したいところです。
というよりも、やはりGoogle本家からのMac版のリリースを
待ちたいところですね。
期待してますよー、Googleさん。w

と、厳しい評価を下してしまった
Macで動くCrossOver Chromiumですが、
試してみたいという方はこちらからどうぞ。w

■CrossOver Chromium 日本語Mac版
http://www.netjapan.co.jp/r/product_mac/com_chr/dl.php

■CrossOver Chromium Mac版(英語版)
http://www.codeweavers.com/services/ports/chromium/

2008年11月4日火曜日

スクリプトの話(15)〜変数の初期化

前回は変数の値が有効に使える範囲
「スコープ」について説明しました。
これと関連して知っておかなければならないのが
変数の初期化のことですね。

例えばグローバル変数を使う時、
いくつかの処理で値を変えて使いたい場合は
その都度、その処理に都合のよい値に変えてあげる、
代入し直してあげなければなりません。

例えば、タッチした時だけ "I love you!" と言わせたいのであれば、

string strMessage = "Hello, Avatar!";

default {
  state_entry(){
    llSay(0, strMessage);
  }

  touch_start(total_number){
    strMessage = "I love you!";
    llSay(0, strMessage);
  }
}

のように、定義し直してあげる必要がありますね。
特にグローバル変数を使う時は、
現在その変数の値(中身)がどうなっているか、
これからやろうとする処理で変更しておく必要がないか
確認しておくことが必要です。

ところで、上の例では一番最初に
敢えて「=」で具体的な値を代入していますが、
これがなかったらどうなるでしょう?
例えば次の例で、

string strText;
vector vecTextColor;
float fltAlpha;

default {
  state_entry() {
    llSetText(strMessage, vecTextColor, fltAlpha);
  }
]

よくあるフローティング・テキストのスクリプトですが、
果たしてこのテキストは表示されるでしょうか?
されるとしたら何色で、どんなメッセージでしょうか?

そう。
メッセージは何も見えません。
何故なら、定義された3つの変数は
何れも初期値が指定されていないので、
文字列は何もない文字列 ""、
ヴェクトル型の色は <0.0, 0.0, 0.0>、つまり「白」、
フロート型の不透明度は 0.0、つまり「完全に透明」、
となっているからです。

こんなこと、わかり切ったことのようですが、
何故敢えて書いているかというと自分でも失敗したからです。w
普通のオブジェクトならいいのですが、HUDの場合、
ログインするごとに default / state_entry() が走ります。
ということは!
以前、世界時計HUDを作った時に、そのプロトタイプでは、
折角文字色を好みの色に変更できるのに、
ログインし直すとまた白に戻ってしまう、という現象が起きたのです。
何も手を打たなければ、上のフローティング・テキストと
同じようなことになってしまい、
必ず色は白になりますね。^^;

これを回避するには、最後に変更した色を覚えさせておいて、
その色を state_entry() の時に読ませるようにする工夫がいりますが、
まぁ、これは別の機会にお話することに致しましょう。
今日は、変数を使う場合には初期化する必要がないか、
逆に初期化されていないか、
スクリプトの結果が違ったり動かない場合は、
そこをチェックする必要があることだけ覚えておいて下さい。

     *   *   *

今回までのところで、
スクリプトが動かないという状況を避ける為の方法、
また、動かない場合のチェックの仕方についての話は終わりにします。
当初は6回くらいで終わらせるつもりでしたが、
書き出したら結構長くなっちゃいましたね。^^;

次回からは、これまでの話を元に、
複雑な処理をする場合などの Tips を
いくつかご紹介していきたいと思います。
それでは、また!

     *   *   *

P.S. llSetText() について補足説明しておきます。

一度フローティング・テキストを設定したけれども
やっぱり消したい、という場合、
llSetText() そのものをスクリプトから削除しても
フローティング・テキストは消えません。
これ、すごい不思議なんだけど。w

と、ここまで書けば、上の記事を読んだ方はおわかりですね?
一度セットしたフローティング・テキストを消すには
llSetText() を生かして次のようにします。

  llSetText("Hello, Avatar!", <0.0, 0.0, 0.0>, 1.0);
       ↓ 下のように変更!
  llSetText("", <0.0, 0.0, 0.0>, 1.0);

そう! 表示していた文字列だけを消せばいいのです!
ご存知の方には何でもないことでしょうけど、
これもまた僕が失敗したことなので、
敢えて説明しておきますね。。。^^;

FPSって何?

先日の Linkさんの講義で
パフォーマンス・モニターの見方を教えて頂いたのは
本当に参考になりました。

この時気になっていたのが、
自分のPCのパフォーマンスであるFPSなんですが、
一体、これってどういう値で
どの位が理想的な値なんだろうと。
NekoさんはドスパラのSL仕様のもので30位、
とおっしゃっていましたが。。。

リンデンのナレッジベースで
このパフォーマンスモニタの見方をチェックしてみました。
正確にFPSが何の略語かは書いていませんでしたが、
その説明からわかったのは
Frame Per Second、つまり1秒あたりのフレーム数、
ということのようですね。
フレームというのは「コマ」のことです。
映画が1秒に24コマ、テレビが同じく1秒に約30コマの
画像を見せていることはご存知でしょう?
いわゆる「パラパラ漫画」の原理で
動く映像として私たちは認識しているわけですね。
SLのFPSも同じで、ワールド内の風景がそのPCで
1秒に何回更新されているか、を示しているものです。

とすれば、Nekoさんおっしゃるように
FPS=30であれば、テレビと同じ品質で見られていることになります。
私はQuickTimeに動画を変換する時に
大体フレーム・レートを半分の15まで落としますが、
これでも十分に、割と普通の動画として見ることができます。
なので、FPS=15というのもそこそこということでしょう。
が、FPS=3となると、これは厳しいですね。
かなりいろんなものが見えていないのかもしれません。><
或いは遅れて見えているのか。。。

あと、もう一つ気になっていたのがSIMの状態を示す
AdvancedのところにあるChild Avatarsという項目。
最初タイニーのことかと思いましたがそうではなく、
このSIMにはいないけれども、
周りのSIMにいて、このSIMが視界に入っている人たちですね。
当然この人たちも視界内にあるこのSIMのテクス全てを
ダウンロードしているわけですよね。
SIMが重くなった時に、
今このSIMにいる人たちだけでなく、
周りのSIMにいる人たちも影響を与えていることを
この数字は表しているようです。

以上、ご参考まで!w

2008年11月3日月曜日

「100人入っても落ちないSIMの作り方」行って来ました

昨晩は、標題の、Neko Linkさんの講義を聴きに行って来ました。
例の環境SIM問題のこともあり、
そして僕自身がミュージシャンとして重い運用をしていることもあり、
どういうことがSIMなりクライアントなりを重くしたり
落としたりするのか、正確に知りたいと思って聴いて来ました。

講義の詳しい内容について触れるのはご遠慮させて頂いて……。

今回初めて知ったのは、
一番SIMを重くするのに貢献しているのはテクスチャであるということ。
いや、それ自体は薄々気づいていましたが、
何と、SLのビューワーは、
ミニマップの三角形で表現される視界の範囲にある
全てのテクスチャを一気に読み込むのだそうです。
「視界の範囲」という変な表現をしたのは、
つまりものの陰になって実際には見えていないものでも、
全部読み込むのだそうです。

ある地点にテレポートすると
アバターは必ず同じ方向=東を向くようになっているので、
イベント会場などの着地点の東側に
テクスをたくさん使ったオブジェクトなどがあると
次々に来るお客さんがそれらのテクスを皆一気に読み込むので、
つまりみんなで一斉にものすごい量のデータをダウンロードするので
SIM=サーバが重くなったり、落ちたりするのだそうです。
(って僕のお店は必ずSIMの西側にあって
東側がにぎやかだなぁ。w)

あと、ctrl+Shift+1(Macの方はcmd+Shift+1)で起動する
パフォーマンスモニタの見方も勉強になりました。
自分のマシンのパフォーマンスは
Basicの一番上にあるFPSで確認できるということ、
SIMのパフォーマンスは、Advancedのところにある
Time Dilationでラグを(最大値1)
Sim FPSでいわゆるSIM全体のパフォーマンスを見ることができあす。
Sim FPSは45が最大値、
これが0になると住民が動けなくなる状態なのだそうです。

因みに、いろんな場所で自分のFPSを計ってみてわかったこと。
最高が16くらいで、ひどい時は3.xという感じです。
これはやはり読み込んでいるテクスチャの量によるようで、
視界を128mから256mにすると一挙に落ちました。
なるほどー、って感じですね。

最近、どうもPCが不調、という方、
一度調べてみるといいかもしれませんよ。
視界の調整で少しはパフォーマンス上がるかも!