Second Lifeで気に入ったアイテムの記録です あ、ウソです。スクリプトとか他のことも書いてます

2009/08/01

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

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

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

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

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


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

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

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

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

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

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

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

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

という感じ。

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

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

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

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

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

効果的に

G121 Black And White - ZERO
結局、7月は全く更新せず
何を書こうとしても、黒くなるので困ったもんです。

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

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

1.体験型
 これはものすごく初心者向けの内容です。
まず、見せる。
そして、「こういうものができますよ」とか
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

2.講座型
 スクリプトを勉強するには、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もあります。

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

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

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

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

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

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

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

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

2009/06/20

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

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

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

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




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

■重複 Yes/Yes(その1)
[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(その2)
[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押す
メッセージでません
この結果は、その1から考えても想像できますよね

一応、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を実行したら、前のは無効ってことですじゃのう


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

えーと、あれだ
「2.無視して別の人の権限要求をする」でいいのかってことでしたね。
結論としては、
「最後の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)

Caroline Ivory Satin Ensemble by INSOLENCE
駐車場の隣の田んぼから
カエルの鳴き声がします。

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

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




※冗長かもしれませんが、毎回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)

Caroline Taupe Satin Ensemble by INSOLENCE
もう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を閉じてしまえばいいのですが
権限要求の場合、タイムアウトするにはどうすればいいのか
この場合のタイムアウトにはいくつかの処理が考えられます。

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

まず、1.ですが、結果的にいうと、スマートな方法はないようです。
  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するしかないようです。
何かいい方法をご存知の方はコメントでもください。

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

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

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

次に続く

2009/05/02

shadow test(snapshot)

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

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

shadow test(print screen)

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















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系の関数をもっと使ってみるの4

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

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

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

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

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

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

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

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

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

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

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

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

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

ルートから子を操作する関数は今のところ以下の通りです。
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の操作も
制限があるとはいえ、工夫次第で可能ですよね。

4に続く

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

さて、この名前とリンク番号ですが、
この対応は、リンク順を変えた時しか変わりません。
※当たり前のようですが、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にスクリプトを仕込まなくても
ルートに1つスクリプトがあれば、処理ができることがわかります。

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

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

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

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

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

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

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

3に続く

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

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

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

では。


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

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

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

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

一番単純な方法では、llDetectedLinkNumberだけを使います。
    touch_start(integer total_number)
{
llOwnerSay((string)llDetectedLinkNumber(0));
}


これで、どのprimがタッチされか区別できます。
試してみるとわかるのですが、
子primでは2~の番号
ルートprimでは、1が返ってきます。
(※リンクされていない場合、タッチすると、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に名前をつけておくと、それをルートから取得できるわけです。
これなら、リンク順に関わらず一定の結果を得られます。
これでかなり実用的になります。

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

2に続く

2009/04/18

プログラムについてのどーこーの3

なげー、なげえよ、もう完全についてこれないやつは置いていくメソッド
ということで、まだ続いてたり

仕事場での職人は、尊敬されるか、あるいは、便利に使われるだけか。
まあ、そのへんは置いておいて。

SLではどうなんでしょうか。
今回は温度差がテーマ

スクリプト初学者(※)は、日々増えているように思っていました。
 ※個人的には初学者という言葉は、ほとんど知りませんでした。
  単純に、学び始めの人という意味でとらえてたんですが
  今、改めてググってみると、こんなのが...ナニコレ?
  私は、学び始めの人という意味で使っています


ただ、スクリプトを書き始めた人を単純に「初学者」ととらえると
まずいんだなということも考えてます。

いろんなものを製作している関係上、必要に迫られて
単に書いただけという人がいるからです。
なので、できればコピペですませたいし、
めんどくさいことは避けたいというスタイルがあります。
これは否定はしませんし、当然、結果だけほしくなりますよね。

私が勘違いしやすいのがこの部分で
「スクリプトを書く人=スクリプトを書くのが楽しいと感じる人」
とは限らないということです。
  ※これ、仕事にしてる人であってもあり得ます

仕事じゃないスクリプトを書くなら
たっぷり時間をかけられるし、その過程もめいっぱい楽しめます。
結果だけとかもったいねぇよ!
とかいう思想が根底にあるので
何か聞かれても、ほとんど何も答えません。
あるいは、キーワード程度で、あとは調べたり実験したりして楽しんでくれたまえ!
と、なってしまうわけです。
 ※いま、リアルタイムで、LSL-BBSで楽しい展開になってます
  こういうのは楽しいなぁ
  BBSのメンバーリスト、50から全然増えねぇなぁと思ってたら
  次のページがあったのか...


というわけで、イヤガラセで答えないんじゃなくて
楽しみを奪わないように答えないわけです。
誤解なきように。


さっきテレビで見て感動したモノ


ところで、CafeScripters cafeというものがあります。
ここでは、スクリプトとかの話を楽しくしようということで
やってるわけですが、ここでの会話でも同様の課題があるようです。

質問しにきた人に、素直に答えないということではないんですが
その質問を考える過程を楽しむ人と
とっとと答えを聞いて帰りたい人みたいな。

なので「いやいやいや、そこまで知ろうとは思ってねーし」とか
「なかなか本題に戻らねー」とか思ってても
必要な結果がでてくるまで、耐えるという状態もあるんじゃないでしょうかね。
話してる方は「このことなら、当然、この内容も関連するよね」
「こういう視点でやった方が効率よくね?」みたいな感じで
その話してることそのものも楽しんでるので、ズレズレです。

Scripters cafeだけにスクリプトの達人が集まると思ってしまいますが
実際には
「スクリプター同士がLSLのネタを中心として、
 セカンドライフに関する技術的な話題、
 また時にはセカンドライフに限らないプログラミング・技術系ネタで
 盛り上がるカフェです」
なわけです

特に「教えるための場」ではなく
みんなで楽しもうっていうスタンスなんでしょう。
こんなの作ったんだけどーとか
こんなん知ってるー?とか話のネタとして持ち込む感じで
参加するのが推奨ってとこでしょうか。

まあ、とりあえず、温度差(意識の差)があるのは当然なので
楽しく共存する方法を模索したいところです。

って、やっぱりイキオイだけで書き始めるとオチないな

プログラムについてのどーこーの2

ということで、長くなった前回の続き
あまりにも長いのでいつもどおり動画で癒されてください

前回のhao_yayoiさんの「習熟はしてるのかどうかよくわからない」という部分。
この「習熟」というのをどういうレベルとするのか
また、「習熟」することは、求められているのかという話が、今回のテーマ。

個人的には「普通」に使えるようになれば「習熟」なんじゃねーの?と思うんですが
この「普通」というアイマイな言葉がクセモノです。

マスタークラス(※)を目指すべきなのか
 ※「職人」っすかね。今風に言えばGeekな。
  Wiz的にいうなら、単独で最下層を楽々に歩けるくらい
  Diabloなら、Hell/Hell踏破
  あるいは...

実際、仕事で目にするコードは、ベタベタなものが多いです。
これはメンテナンスを大事にしてという理由よりも
さらに大きな理由があります。

誰でも書ける事

テンプレというかスケルトンとなるコードがあって
それに改造を加え作られることが非常に多いようです。
一から書けるほど習熟してる人が少ないそうで。
(また、人が一から書いたものを理解できる人も少ない)

このやり方は
「世界に冠たる日本の製造業のノウハウを
 適用することで生産性を上げることができるに違いないという発想」(※)に
基づいているんだろうなぁ。
(他にも「使えないやつ」が多すぎて
彼らに「そこまで」求められない現状に対する苦肉の策って面もあるかも)


 ※Rubyの人の「ソフトウェアは工業製品ではない」は
  私としては、ものすごく納得できるし、同意もします。

  完全に余談ですが、
  私の大好きなホーガンの作品に「創世記機械」というのがあるんですが
  この中にも似たような描写があります。


このテンプレ化は、それなりの効果があって
新人さんでも、マシンと化して、次々とコードを生産していけます。
かつ、計画も立てやすく、銀の弾丸も夢じゃないという状態になります
 ※正直「つまんね」と思ったことは隠しません。

ただ、落とし穴もあります。

仕事で、あるチームのお手伝いをすることになり
「郷に入りては」で、そこのお作法に従って、シェルを書いてました。
で、あるエラー処理と思われる箇所がエラー処理になっていない(※)ように思えたので
 ※「ひとつ前の処理の成否が、ある変数に格納される」というシェルの機能で
  それをifで判断しようとしてるんだけど、チェックしたい処理と
  ifの間に別の処理(必ず成功する)があって、肝心の処理の戻り値が上書きされている
それを署名の人に聞きにいくと
「ああ、そこは元からそうなんでわかりません」
隣の席の人に聞いても同じ答。
そのテンプレを提供したその人の先輩に聞いても「前からあるやつなんで(略」

ここで注目したいのは、この質問は、「~だからエラーが拾えてないんじゃないですか」と
理由をつけて聞いてるんですが、その仕組そのものを理解している人がいないことです。
完全に伝言ゲーム状態になってるんですね。
 ※最終的に、責任者に聞くことになり、そのフロアはかなりざわざわする事態まで。
  さすがにその責任者は理解していて「なにー!」となったんですが。
  じゃりんこチエのテツを思い出しましたよ
「次の分から、直したものを使おう」となったというのがオチです

私の思う「普通」ってのは、たとえテンプレを使ってても
こんなことに気づくレベルなんですけどね。
「習熟」って、単に知ってるだけじゃなくて
自分のものとして使えるかどうかってところが大事ですね。

プログラムについてのどーこー

hao_yaoiの人(※)が、プログラミングなことについて述べていたので
あー、そういえば...と最近思ってることを書きます。
※就職おめでとうございます

投稿の主題を拡大解釈・脳内補完・整理してみると
「プログラマってのは、単にコード化するだけでなく
 その仕組が動く全体を把握して、要求される内容を十分に満たすことはもちろん
 発生する問題点を見抜き、フォローしていくことや
 さらにこちらから提案していくことが大事なんじゃないか」
ということを、彼の人が書いているんだと理解しております。
このあたりは、2年目くらいからポツポツと求められてくるようなレベルで
この壁を乗り越えられるかどうかで、「むむ、使えないやつ」と思われるかどうかの分かれ道になったり。
なんかこのへんになってくると、SEなんでないっすかミタイナ。

さて、今回、何が気になったかというと、この主題以前の部分
"一応今の肩書きは「プログラマ」なんだけど、
 昔に制定されたプロトコルに従って作りたいものを実装してるだけであって、
 習熟はしてるのかどうかよくわからない。
 もちろん言語仕様とかはそれなりに踏まえてる。"
この部分が妙にひっかかった。
と言っても、イライラするんだようとかじゃなくて
ちょいと前から思ってることに妙にかぶるからでした。

実際のところ、今のコード書きは、
1つの言語だけできればいーやってわけにはいきません。
   というか、1つ言語ができれば、あとはリファレンス片手に
  そこそこ書けたりする。
  これは、プログラムが動く仕組がわかってたり
  機能から名前を類推できるようになったり
   なんかそのへんの共通するようなことが把握できてるからで。

なので、「習熟はしてるのかどうかよくわからない」という不安を覚えるのは当然だったりします。

で、私がちょいと前から思ってることっていうのが
「各言語仕様をどこまで理解することが必要なのか」なんてことです。

太古、1つの言語に対して完全に理解してる人というのはゴロゴロしてて
もう、自分でその言語を再現できますよみたいな感じ。
なので、その言語の癖にあわせて、最適な書き方をできるのは当然
これは、省メモリだったり、最速だったり。
「こんな仕様をこんなにコンパクトに!?」
これはDOS時代には、必須な技能でした。
コンパクトにできなかった場合は、メモリの切り替え(※)が必要で
「おっそ!」と非難轟々
 ※正式な名前は忘れてしまったんだけど
  マシンのメモリに収まりきらないので
  実行中に、この処理の時はこの機能は使わないので
  必要なものをそのメモリ空間に上書きして実行みたいなやつ
  なんかエクステンダとかもあったなぁ

LSLなんかでは16k(64k)に収めるために
i++と++iのどっちを使うかとか
同じ機能でも意識的に書き方を変えたりしています。
これは「リファレンスペラペラ」レベルにしか知らない言語ではムリな感じです。

「ムリ」とかちょっと否定的に書いているわけなんですが
今の時代は、ソレはソレでいいのかなぁというのが
気になるところなのです。

私は言語仕様とか読むのがわりと好き(※1)なので
ヒマとお金と体力(※2)があれば、言語仕様本とか買ってパラパラ読んだり(※3)しています。
でも、今のコンパイラの性能とか、マシンで使えるメモリやCPUを考えると
コード化時点で、そこまでの理解は不要なのかもしれないと。
 ※1:言語の理解というよりは、その実装の思想とか背景とかを知るのが好きです
  その副産物として、仕様の理解というものがついてくる感じ
 ※2:高くてデカいんだよ、持ち歩いて読みやすいサイズにしてくれ...
 ※3:がっつり読み込むというよりは、
  気になる部分だけ点として読んで、それが重なっていつのまにか
  全体を知るという読み方

いや、実際には「不要かもしれない」なんてことは思ってませんよ。
 ※「UNIXという考え方―その設計思想と哲学」という本は、一読の価値ありだと思ってます。
  一読どころか、何度も何度も読んでます。

いくらメモリを大量に積んでいて、CPUのスペックも上がり
ハードディスクの速度があがっても、
サーバで実行されるプログラムの数は増える一方なのです。
1つ1つのプログラムをコンパクトかつハイパワーにすることは
大きな意味があります。

なんだか妙に長いので次回に続きます

2009/04/04

やあ、春です

といっても、別に新しい文房具を揃える必要とかはないわけで
新鮮さは全くないのですが。

革新的でも美的でもなく、有用にもできず、わかりやすくも
一貫もしていない
感じで苦労しているyouです。


さて、日々、本を読みつつ暮らしているわけですが
久々に「ダメだこれは」って本に遭遇しました。
さすがにタイトルや著者名は出せませんが。
(朝日ノベルズだとだけ書きます)
何かのつながりで見つけて、amazonでポチった感じです。
(先月発売だったので、レビューが一件もないのも気にせず)
届いて箱をあけた瞬間、その妙な薄さにイヤな予感がし
通勤中に読み始めて、なんかダメな感じが濃厚になり
帰りの電車で「やっぱりダメだった...」と憂鬱になりました。

とりあえず、ダメポイントをつらつらと。
・主人公に魅力がない(プラスがないだけでなく、マイナス面が多い)
・全く成長がない
・読んで発見や感動がない
・敵役が気持ち悪くて、イヤなだけで魅力がない
・タイトルにもなっている主人公の役職に全く意味がない
・脇役にも魅力がなく、思わぬところに出番があるくせに
 全く本編にからんでこない
・降ってわいたようなラッキーに助けられ
 それを成り行きで受け取るだけで、解決につながる
 (活用してどうこうするというレベルでもない)
なんというか、ダメすぎて、
もしかすると大事な部分が落丁してるんじゃないかと
思ったくらいで。

「自称小説家志望の中学生が、
 取材もせず、特に詳しい分野もないままで
 ふとんに入って寝るまでにする妄想を活字にしただけ」
みたいな印象の本でした。
読み終わって「なんなんだこれは」とボーゼンとしつつ
あとがきを読んでみると、全く同じコンセプトの姉妹作があるとのこと。
...ってことは、これは世間(出版社)に認められてるのか。
いま、amazonで、この作者でリンクをたどると、他にも本がでてました。
とりあえず、ブラックリスト入りだ。

ダメポイントだけではアレなので
ナイスポイントもあげておきます。
・日本語になっていた(文章は普通に読めます)
・完結している


まあ、それはそれとして
いつもの通り、金曜日はいつのまにかイスで寝てしまい
5時頃から起きて、だらだらしています。
っていうか、今週はふとんで寝た日はなかったです。

さて、ここんところの習慣になってるエロ探索の旅をしつつ
ぼやぼやしていると、突然、Mr.ボールドを見たいなぁと思ったり。
この人って、関西以外でも知られてるんだろうか...


このおっさんを初めて見た時から
私の生活に「今、目ぇおうとったやんか」(今、目が合ってたでしょう)とか
「しまいには、感情的になるで」とか、妙なセリフが導入されました。
声がいいんだよなぁ
あと、なんかダルさ。キビキビと一輪車で動くくせに
口調は、超ダルい感じ。
ああ、芸になってるなぁ。

この人、残念ながらすでに故人なのです。

http://www.youtube.com/watch?v=tkeShx_9Afo
http://www.youtube.com/watch?v=RKBKsnvrvTA

結構前に亡くなったので、お正月とかのテレビがさびしくなりました。
一度、生で見たいなぁと思った時にはすでになくなってて、
かなりのショックだったことを覚えています。

しかし、wikipediaの
一輪車パフォーマンスを行うこととなったのは、
道端に置いてあった一輪車を盗んで
芸に取り入れようとしたのがきっかけである。
ってマジなんだろうか

2009/03/29

3月の更新は、多分、これだけ

さすがに死亡説は、流れていませんが
一応、元気だとお伝えします
あと、つらつら近況など

ということで、昨日の夜からスクリプト書いてました
例のコレですね
2~3月にかけて、持ち歩くノートにメモしながら
うまいやり方を考えてました
かなり考えまくったおかげで、
基本機能の8割程度まで、いっきに組めました
後は、インターフェイス部分のデザインと
内部処理の効率をあげるのみって感じですね
「のみ」か...


さて、それはさておき
wassrWizチャンネルで紹介されている
エルミナージュやってます

今は、プレイ時間31時間ってところです
普段、この手の携帯ゲームをやることもあまりないので
かなりのんびりやってます
※今はオートマッピングって当たり前なのかもしれませんけど
ダークゾーンとか回転床とか意味ねーじゃんって感じです


こないだ、wassrで教えてもらったんですが
今、こんなのあるみたいですね

これは楽しそうだ!
もちろん、ハード持ってませんけど
環境が変わると、昔のゲームでも新たな発展を見せますね

2009/02/22

久々に寝込んでました


Waist and sHip
なんというか、この一週間はインフルってました。
月曜日の朝、出勤直後から、なんかオカシイ、ナニコレ?みたいになり
時とともにどんどん変調
煙草を吸いながら
「黒井さん風邪っすか?」
「んー、セキがでてハナタレて、ちょっと熱いだけ」
「風邪ですやん!」
いいえ、インフルエンザでした。

夕方くらいになると、
周りからも「"明日は休み"の前言い訳っすかー」という声も聞こえ始め
どうみても、ハンパない状態の模様です。
いつもは、巧みなフットワークで乗り換えて
最速で帰るところ、そんな元気もなく鈍行で座って帰宅。
まわりへの被害を抑えるため、ハンカチで口を覆い、まるで火災の避難民。
八幡とかで止まってる時間がなげーんだよ!
もうぶるぶるにでもとりつかれたかのような状態。
ああ、電車から降りたら、車の運転しないとダメなのかーとクラクラ。

帰る道々、これは明日は休みだよなーと
ポカリスウェットとか、ゼリーとか大量に買い込み
(※コメまで買ったバカ)
帰宅すると、なぜかいつもの習慣でPCの電源を入れ
適当に挨拶して眠りました。
翌日が地獄で、朝から休むという電話を仕事場に入れ
病院にいこうとしても、起きるパワーがなくて
熱を計ると39.5度まで到達
うう、でも午前中に行かないと医者が閉まる。でも、動けない...
とりあえず、正午くらいにどうにか動けるようになって
いろいろ知恵をもらいつつ、午後からもあいている診療所にいってきました
今回はインフルエンザのA型ということで、タミフルもらってきました。
4日分の処方で、熱が二日間でなかったら、
インフルエンザが死んだよということらしいです。
※わさにも書きましたが、
 一人暮らしでは、凍らせるタイプの氷枕が
 メンテフリーでいいんですが、1つでは交互に使えなくて
 意味がありません。帰りに1つ買い足しました。

診療所で計った時点で熱は37.5
帰って計ると、38.5、こんな感じで37~39をうろうろしてます。
今回、なぜだか汗がほとんどでなくて
・ポカリスウェットをコップ2杯飲む
・2時間後、トイレで全部出る
これの繰り返しです。
このトイレに行くために起きるのがものすごく億劫です。
もうベランダでしてやろうかと思ったりもしましたが
今後の近所づきあいに差し障るので思いとどまりました。

常時熱が出ているわけでもないので
37度ちょいくらいの時は、本を読んだりしていましたよ。
仰向きで読んでたので、文庫から飛び出したハガキがデコに刺さったりして
一人むなしくなったり、テレビと角度の悪い布団の位置だったので
DVD見れなくていらいらしたり
トイレに行くたびに、reblogったりしていました。
SLは、ほとんどやらず(りぞーむの支払い期日だったので、撤収処理だけしました)。
木曜日からは熱が完全に下がったので
やっとお風呂に入ったりしてました。

月曜日からは仕事にも行けそうです。
というか、行きます。
私が休んだところで世界は回るんですけど
どうも休んでいると、それをいいわけにサボる人がいるようなので
マスク越しの凶眼で睨むために出勤します。
(ちなみに、まだセキは出ます)

さて、金曜日は、ここんところ見ているvwbcを見てました
その流れでNSKのコレにも参加してきたり
普段、イベントとかに参加せず、引きこもってるんですが
こういうしょんぼり状態に時には、なんだか参加したりします。
その流れで、翌日のラジオの収録も見てきました。
(バックナンバーは全てDLしました)
おもしろいことしてる人いるなー
一周年おめでとうございました。

さて、例の15パズルですが
参加者絶賛増加中ということで、現在二名の猛者がエントリー
次の金曜日が締め切りです。
しばらくの間、早寝の生活をしますので
SLのin率も下がりますが
ネットにはつないでいますので、質問などは
コメントなどにあげておいていただけると
そちらでお返事します。
よろしくお願いします。

2009/02/15

昨日だったかおとついだったか

screen_last_20090214
例のごとくパンツ写真を撮りまくってたわけですが
なんだかいつにもまして、不調だったのですよ。

なんだか肌のハリ悪ー!ってな悲鳴をあげつつ
でも、イキオイのあるときに撮影しておかないと
また、Inventoryの日付フォルダ行き(※)だと...
※私は撮影した服とかは、アルファベット-ブランド名のフォルダにいれてますが
 記録をつけてないのは、日付フォルダにいれているのです

で、お蔵入りを覚悟でバシバシ撮影してました。
それで撮影したのが、ココの2/14分のやつです。

で、撮影疲れで寝てしまい、
ふっと起きて、HUDでもつくろうかとログインしてみると
Last Loginの画像が妙にかっこいい。
肩のあたりのラインとか、なんだこれ...
というのが、今回貼ってる画像です。
慌てふためいて、保存されてるディレクトリにいって
Flickrっておきました。
あの苦労はなんだったのかと...
(Last Login画像は意外とおもしろいのがあるので
 保存しておいてもいいですね)


ということで、ふてくされつつ
この週末は、イッキ買いしたもやしもんをイッキ読みしたり
通販で買ったエビを喰らったり、DVDにどっぷり浸かったり
ぐーたらぐーたらしてました。

skinがきれいに見えたり、shapeのラインがやわらかく見える設定とかあるのかなぁ
同じ設定でも、ログインしたタイミングによって
ほどの差があります。なんなんだろう。

さっき、耳なしさんのyoutubeを見てたら
ふっと、私のトラウマ的にこわい話を思い出しました。
一応、貼っておきます

デザインはむずかしい

Agnes Black Outfit by INSOLENCE Lingerie
朝の喫茶店で、HUDのデザインを落書きしまくり。
機能を形にすることはできても、デザインにはなってない。
なんていうか、図画工作はできても美術になってないというか。
どう見ても紙版画みたいな感じ。

特に今回のは、アイコン部分をどうするかが重要
見た瞬間に「コレを指してる!」っていうのがわからないと
使いものにならない。
いっそ、文字にしちゃうかなぁ。
XyzzyTextも10文字対応になったし。
でも、アイコンだと1マスで収まるのが文字だと...
(漢字って偉大だ...)

とかいいながら、今日は大草原の小さな家のDVDでつぶれました。

デザインがうまくいくと
本来の機能の2割増くらいに見えるんじゃないかと最近思ってます。
かっこいい→よく見えるってことなんですが
これ、事実上、デザインが洗練されてると
配置とかも、UI的に優れたものになったりして
事実として機能がアップするってのもあるかも。

アイコンっていうのは、わかりやすいようでわかりにくいのです
というのは、国によって意味が全く通じなかったり
逆のマークになってたり...
(copy/mod/transとかのチェックのつけ方も違うしね)
文字を使いながらも、すっきりしたデザインになるといいですね
文字にした場合、今回のHUDは
耳なし芳一みたいになります。

ああ、悩ましい
どなたかーどなたか、デザイン力養成ギブスとか
ミルミルセンスヨクナールA錠とか、そーいうのをください!

2009/02/11

距離をおいてみたり

The Great Fissure1

だいぶ前に実験してたLM管理用のツール
ちょっと煮詰まって逃避してたんですが
その間に、別のことをやってると、なんとなく光明が見えてきました
よし!ばりばりつくるぞー!とか思いつつ
今日はダラダラ過ごしてました。

ちまちまとセコいものを作ろうとするんですが
実用として考えると
・負荷高すぎ!
・操作ややこしすぎ!
・動作遅すぎ!
・デザイン悪すぎ!(これは操作性にも通じるかも)
・似た物ありすぎ!
とかいろんな面で、作っただけで放置することになったりします

これ、いきおいよくダーっと作ってる間は
気づかなかったり(あるいは目を背けてたり)します
そういう意味では、ちょっと冷却期間をおくのはいいことかもしれません。
「ちょっと距離をおきたいの...」とかいうやつですね
しばらくして、再びさわってみると
自分でも、わかりにくーとかアラが見えてきます。
こうして、じわじわと改善していくと
結果として、いいものにな(ることもあ)ります。

ということで、いろいろ作りかけで飽きては放置していますが、
いつかきっとリリースする日がくるでしょう。
あたたかく見守ってください。

※イキオイだけで出すと、某Cafeの人達に
ボロクソいじられて、いじめられますので。

2009/02/08

15パズルその後

League Vintage Futura- Faded Blue4
さて、例の15パズルですが全く応募がありません!
ロジックを考えてくれてる人達の気配は感じるのですが
とっとと申し込みやがれ、ふぁっきゅー!とかは
全く思っておらず、規模が読めず、びびりまくってメソメソしてます。

ということで、インターフェイスを若干増強しました。
複数スクリプトを使う方には、ちょっと便利かもしれません。
配布オブジェクトも、バージョンアップ(Ver0.63)してます。
参加予定の方はチェックしておいてください。

http://lsl-users.jp/nsfw/

2009/02/07

CARNET

CARNET
先週、山科のヒカリヤ内の志津屋に行くと、お店が閉店な感じだった。
スゴスゴと引き返してきたんだけど、今日、サイトみたら
サイトの店舗情報からもなくなってた。

六地蔵店がなくなった時も「これからどこでカルネ買えばいいんだー!」とか
思ったものですが、今回も結構しょんぼりです。
山科にもう一店あるんだけど、ホームセンター内にあって
なんか行きにくいなぁ。

伏見方面に行ってみるか、あるいは大津まで行ってみるか。
そこまでしてもカルネは食べたいのです。

2009/02/06

もう痕跡もないことですし

PIXELFASHION Melissa Purple
PIXELFASHION Melissa Purple,
originally uploaded by you_xiao.
便利な世の中になったなぁというものに
Yahoo Pipesというものがあります。
検索してみると、いろんな解説がありますので
ごにょごにょといじってみると楽しいです。

YoutubeのプレイヤーなんかもPipes使ってるものが多くて
その便利さがわかります。
Jvnさんとこを見ると、LSLからの利用方法も見えてきます。


さて、このPipes、いろんなフィルターをGUIで!ってところもいいんですが
外部サーバーを自前で用意しなくていいってのが大きいと思います。

某Fakeな人がllName2Key的なものを公開しています。
目的がわかっているので、中を見るとPipesの使い方が見えてくるんじゃないでしょうか。
自分のAV名をいれてみてKeyになるか試してみましょう。

「LSLだけでやる!」というのもパズル的でいいんですが
こういうものを使うと、作れるものの世界が広がって楽しいんじゃないでしょうか。

※公開されているものには、何の保証もありません
 自分で中を見て理解して、自己責任で使いましょう
 唐突に削除されることもありますのでCloneって使うといいかもです
※もちろん画像は無関係
※タイトルは、わかる人だけわかればいいんじゃないでしょうか
 ええ、黒いです

2009/02/02

Iris Green Lingerie Outfit by INSOLENCE1

パンツ撮影について書いたところ
IMとかちらほらもらえて、嬉しいことです。

MatureなSIMでも、それは「大人なSIM」なだけで
パンツいっちょで歩いていいってことではないので
普通はパンツ禁止だと思ってたんですが
意外とパンツOK(黙認)なところもあるようです。
 ※「パンツ禁止」は、「パンツをはいてちゃダメ!」ではありません

「パンツ写真の後ろに、うちの建物があああ!」とかの
トラブルもコワイので、友達にもらった絵とかの前で
撮影するときでも「エロパンツ写真の背景につかっていい?」とか聞いてます。
「okok」と快く許可もらえるんで、もしかすると気にしすぎなのかなぁ。

前に
『「タバコ吸っていいですか?」って聞くのが紳士だと思うなよ
 それに対して「ダメ」って答えられるやつなんかいるかよ』
とか言うのを聞いたことがあって、激しく納得してしまったので
 ※タバコOKなのが確実な人としか会わなくなってしまいました。
それ以来、「NO」といいにくい質問は、あまりしなくなりました。
でも、これだと、わざわざ「タバコ吸っていいよ」と言ってくれる人は
ほとんどいないんですけどね。
ましてや、こっちが何も言ってないのに
「うちでパンツ写真撮っていいよ」とか言ってくれる人なんか
いるわけもなく。

お前はそこまでしてパンツ写真撮りたいんかと言われると
困るんですけどね

2009/02/01

Iris Purple Lingerie Outfit by INSOLENCE1

最近、SIM内で撮るにも場所に飽きがでてきました。
よそに行くにしても、パンツでフラフラできません。
 (うちでパンツ撮影してもいいよーって人は御一報を)

Back Yardがきてから、いつのまにか一年過ぎてます。
結局、個人サンドボックスみたいな使い方のまま
時間だけが過ぎてます。

ということで、3月をめどに
Back Yardをどう使うかの方向性を決めたいと思います。
とりあえず、Public化も含めて検討しますので
知恵貸すよー、腕貸すよーって人は、またよろしく

あ、それとどうでもいいんですが、カルピスソーダのジンジャーは
結構よかったです。

2009/01/31

NSFWな大会

PIXELFASHION Melissa Black(blog)

といっても、Not safe for workではなく
Numberpuzzle Solution Finding Winter prizeです

LSLで15パズルを解いてみようという大会です
15パズルそのものは、作りましたので
それとうまく通信して解くスクリプトを作ろうって感じ

興味のある人は、こちらにどうぞ
「LSLによる15パズル解法大会」


これ、メインの「解くロジック」も大事なんですが
こんな難点があります
 ・多次元配列使えれば楽なのに、Listしかない
 ・一手の時間制限が30秒
 ・他人の作ったスクリプトと協調しないとダメ

さっきのサイトに、ルールとかいろいろ書いてあるので
チェックしてみてくださいね

あ、これ、地味に賞金ありますんで
優勝して、NSFWなパンツでも買ってください

Cマガ電脳クラブが懐かしい...

2009/01/27

あ、生きてます

ZERO NUMBER Wo Boots Gomi2
ZERO NUMBER Wo Boots Gomi2,
originally uploaded by you_xiao.
そして、たくらんでます。

最近、投稿はFlickrばっかりです。
気楽だしw

RL仕事でも、ちょっと新しいこと始めたので
公私共に楽しく生きております

2009/01/03

スクリプトでサイズ変更を(trial)

あけましておめでとうございます

年末から作っているのがこれです。
これはいろんなオブジェクトに組み込んで
スクリプトから、サイズやテクスチャの変更をします。

某モジャモジャSIMの大将の依頼で作り始めて
さらなる人柱を募集しています。

興味ある人はよろしくです。




■■使い方---組み込み
1.このスクリプトセットが入ったオブジェクトをRezします。
 ※名前は"XCG Ver0.93"です・・・バージョンは変わります

2.各primにスクリプトに入れる
 XCGにタッチしてダイアログを表示し
 <Get Script>を選びます。
 この操作で"!!Scale"というスクリプトがInventoryに入ります。
 このスクリプトを対象となるオブジェクトの全てのprimに入れます
 ※できあがったオブジェクトにいれるよりは
  最初にprimにいれておいて
  コピーしながらオブジェクトを作る方が楽だと思います。

3.コントロール用のスクリプトを入れる
 2でスクリプトをいれたオブジェクトにタッチすると
 "For Load"という文字が出ます。
 この状態で、XCGのダイアログを出し<Load>を選びます。
 これでしばらく待つと、スクリプトが対象となるオブジェクトに入ります。
 ※この方法以外でスクリプトをいれても正しく動きません。

これで組み込みは完了です。

※なんらかの理由で、再度3を実行する場合は
 オブジェクトのルートprimから3で入ったスクリプト"!!!Ctrl"を削除します
 同じように"!!Scale"も削除して、2からやり直します。
 このとき、全primのスクリプトを入れ替える必要はなく
 ルートのみに入れてください。



■■使い方---サイズ変更/テクスチャ変更

1.ダイアログの出し方
 対象となるオブジェクトを長押しするとダイアログが出ます
 そのダイアログから必要な処理を選んでください。

2.ダイアログの説明

 【メインダイアログ】
 <SIZE>     サイズ変更モード
 <TEXTURE> テクスチャ変更モード
 <HELP>    説明ノートのGive
   ※!!Usageというノートを入れておくと、このボタンが出ます

 ※テクスチャ設定がない場合
  メインダイアログを飛ばしてサイズ変更ダイアログになります

【サイズ変更ダイアログ】
 <UNLOAD> 子primからScriptを除去する
 <LOAD>   子primにScriptを再loadする
 <INIT>    初期位置セット
            基準となる位置とサイズを設定します
            primをeditで変更した場合は、INITしてください
            ※スクリプトをいれた時点の位置やサイズを記録します
             edit後の位置を記録するためにこのボタンを使います
            ※このボタンは、購入者には表示しません
 <RETRY>  同じ比率でもう一度処理する
            ※なんらかの理由でサイズが変わらなかった場合に使います
              拡大の結果、Linkの上限あたりになると発生するようです
 <UNDO>   変更を戻す(※3手まで)
 <DEFAULT> defaultの位置に戻す

【テクスチャ変更ダイアログ】
<-PREVNEXT-> ページ切り替え



■■設定
"!!Ini"という名前のnoteを
対象となるオブジェクトに入れると設定ができます。
※note内では、#から始まる行はコメント扱いになります

==========noteの例==========
#設定ノート
# ダイアログのタイムアウト(秒)
DIALOG_TIMEOUT:10.0
# 長押しの閾値(秒)
TOUCH_HOLDTIME:0.5

#サイズ変更の比率
# 1~200%の6つまでの比率を指定可能
PER:105%,110%,115%,95%,90%,85%

#メッセージ
# 複数行書くと改行でつなぎます
MESSAGE_1:サイズ変更後は、Unloadしてください
MESSAGE_1:よろしく

# 色変更用テクスチャ指定
color1:d5d7d4d7-c77a-40fa-95d4-d81043b46a6a,a57b6488-bf09-b976-1002-c83ef259e6fe
color2:96654779-dc5b-7ad4-c1a0-bad3f64844dc,81fa866f-4789-7867-87bf-cf105b30dbc5
color3:8766e70b-15a6-2582-706e-a39d26e2822b,78662dee-0c7b-7c5f-f20a-6d2d50369a7e

==============================

色変更用テクスチャ指定
 子primの名前に番号をつけておくと、その番号に応じてテクスチャをセットできます
 ※1つのprimの全ての面のテクスチャを変更します
 ※この例では、1という名前のprimとルートprimのテクスチャを変更します

 設定は以下のようにします。
 [名前]:ROOT用テクスチャUUID,1番用テクスチャUUID,2番用テクスチャUUID,3番用テクスチャUUID・・・
 ※名前はダイアログのボタンになります
  ・名前は12文字までです
  ・同じ名前は指定できません
 ※noteは1行255byteまでが有効です
  おおよそ、UUIDは7種類が限度でしょう
 ※読み込める行数はメモリの上限で決まります

メッセージについて
 これはUNLOADを促すメッセージです
 全てのprimにスクリプトが詰まった状態では、SIMに与える負荷が大きくなります
 使用者にサイズ調整後、スクリプトを除去してもらうためのメッセージです
 ことあるごとに出力します



■■注意
・このスクリプトをいれたオブジェクトは、シフト+ドラッグのコピーはできません
・配布・販売時は設定noteを削除してください
 ※削除しないとUUIDが丸見えです



ということで、リリース前にモニターをしてくれる人を募集中です。
新店で、牛が眺めてるオブジェクトをタッチすると、セットを送るようになっています。
※これを組み込んだオブジェクトは、リリース版と同様に、trans okになります。
※これはTrial Versionですので、Descriptionに特定の文字がセットされます
※オブジェクトは必ずバックアップをとってください
もし、何かご意見ご感想、不具合報告をしてもらえる場合は、
この投稿にコメントしてもらえると助かります

2009/01/01

Happy New Year

Happy New Year
Happy New Year,
originally uploaded by you_xiao.
あけましておめでとうございます。

今回も、元気にだらだらと年越しできました。

また、今年もよろしくお願いします。