アバターとはSLユーザーが操作するキャラクターのことを指します。
広義にはSLユーザーやアカウントまでも含めて「アバター」という言葉を使うこともありますが、通常はSL画面に表示される人型(稀に人型ではないヤツもいますがw)のキャラクターのことを言います。
広義にはSLユーザーやアカウントまでも含めて「アバター」という言葉を使うこともありますが、通常はSL画面に表示される人型(稀に人型ではないヤツもいますがw)のキャラクターのことを言います。
アバターは固有の名前を持っていますが、通常の場合LSLではUUIDで識別されます。
名前についてはファーストネーム(名前)とセカンドネーム(苗字)があり、ファーストネームのほうはユーザーが自由につけることができます。
セカンドネームはリンデンが用意したものの中から一つを選ぶようになっています。
ファーストネームが同じアバターというのは存在しますが、ファーストネーム+セカンドネームとなると必ず固有の名前になります。
名前についてはファーストネーム(名前)とセカンドネーム(苗字)があり、ファーストネームのほうはユーザーが自由につけることができます。
セカンドネームはリンデンが用意したものの中から一つを選ぶようになっています。
ファーストネームが同じアバターというのは存在しますが、ファーストネーム+セカンドネームとなると必ず固有の名前になります。
UUID
UUIDとは (Universal Unique IDentifier)の略で、SL内のあらゆるものを識別するためのキーとして使われています。
日本語では「汎用一意識別子」という名前が付いていますが、何やら堅苦しいせいか使われているのを見たことがありません。
その名が示すとおり、UUIDとは本来SLに限ってのキーではなく、様々なものを識別するのに利用可能な汎用的な仕様です。
OSF(Open Software Foundation)というオープン仕様を色々策定している組織が定めています。
日本語では「汎用一意識別子」という名前が付いていますが、何やら堅苦しいせいか使われているのを見たことがありません。
その名が示すとおり、UUIDとは本来SLに限ってのキーではなく、様々なものを識別するのに利用可能な汎用的な仕様です。
OSF(Open Software Foundation)というオープン仕様を色々策定している組織が定めています。
UUIDは128bitの数値(=32Byte=18446744073709551615)であり、この天文学的な数値がかぶることはほぼあり得ません。
さらに言うなら、このUUIDの生成方法も仕様で決められており、ベースとして時間を元にしています。
つまり作成時間が異なれば、異なるUUIDが生成されます。
SLでは、そのオブジェクトやアバターが作られた時間・Rezされた時間を元にUUIDを作成しているようです。
仮にまったく同じ瞬間に作成されたとしても、時間+固有の番号を割り振りますので、UUIDは必ず各オブジェクト・アバターごとに固有のものとなることが保証されると言っていいでしょう。
さらに言うなら、このUUIDの生成方法も仕様で決められており、ベースとして時間を元にしています。
つまり作成時間が異なれば、異なるUUIDが生成されます。
SLでは、そのオブジェクトやアバターが作られた時間・Rezされた時間を元にUUIDを作成しているようです。
仮にまったく同じ瞬間に作成されたとしても、時間+固有の番号を割り振りますので、UUIDは必ず各オブジェクト・アバターごとに固有のものとなることが保証されると言っていいでしょう。
UUIDは以下のような値になっています。
3F2504E0-4F89-14D3-9A0C-0605E82C3301 66864E3E-E095-A9F8-058C-D6F75B6341F8
これをLSLではkey型データとして扱います。
Key型データは特殊な文字列型で、上記のようなUUIDを文字列として保持しています。
LSLの多くの関数でこのKey型データを使って、アバターやオブジェクト、テクスチャやアニメーション、はたまたグループなどを識別します。
まったく同じ名前のオブジェクトが複数あったとしても、UUIDが異なるので処理対象を間違わずに済みます。
Key型データは特殊な文字列型で、上記のようなUUIDを文字列として保持しています。
LSLの多くの関数でこのKey型データを使って、アバターやオブジェクト、テクスチャやアニメーション、はたまたグループなどを識別します。
まったく同じ名前のオブジェクトが複数あったとしても、UUIDが異なるので処理対象を間違わずに済みます。
また、LSLではアバターやオブジェクトのUUIDを取得する方法が様々に用意されていますので、UUIDの中身(具体的な32個の16進数)を意識する必要が極力ないようになっています。
例えばオブジェクトのオーナーのUUIDを取得するにはllGetOwner関数を実行するだけで良く、実際にオーナーのUUIDがどんな値なのかを知る必要はあまりありません。
例えばオブジェクトのオーナーのUUIDを取得するにはllGetOwner関数を実行するだけで良く、実際にオーナーのUUIDがどんな値なのかを知る必要はあまりありません。
UUIDの特殊な値として、定数NULL_KEYで定義されている"00000000-0000-0000-0000-000000000000"があります。
この値はkey型データの初期値として使われる他、リッスンやセンサーにおいては「全てのUUID」を意味します。
また、if文などの条件判定においては、NULL_KEYはFALSE、NULL_KEY以外はTRUEとして評価されます。
この値はkey型データの初期値として使われる他、リッスンやセンサーにおいては「全てのUUID」を意味します。
また、if文などの条件判定においては、NULL_KEYはFALSE、NULL_KEY以外はTRUEとして評価されます。
integer isNullKey(key id){ if (id) { return TRUE; }else{ return FALSE; } }
オブジェクトのUUIDは、そのオブジェクトがrezされたタイミングで生成されます。
つまりSLワールド上に存在するオブジェクトは、全て異なったUUIDを持っていると考えて支障ありません。
その一方、テクスチャやアニメーションなどのアイテム類はアップロードされた時点でUUIDが付与されているようです。
アイテムごとのUUID生成タイミングの一覧表があったら便利かもしれませんね(作った人、作ってくれる人など募集中w)。
つまりSLワールド上に存在するオブジェクトは、全て異なったUUIDを持っていると考えて支障ありません。
その一方、テクスチャやアニメーションなどのアイテム類はアップロードされた時点でUUIDが付与されているようです。
アイテムごとのUUID生成タイミングの一覧表があったら便利かもしれませんね(作った人、作ってくれる人など募集中w)。
UUIDがユニークなキーであることを利用し、乱数的に使うことも可能です。
default { touch_start(integer detected){ key id = llDetectedKey(0); // タッチしたアバターのUUID string s_rand = "0x" + llGetSubString((string)id,1,3); // UUIDの2~3文字目を抜き出す integer i_rand = (integer)s_rand % 3; // 抜き出した16進数を3で割った余りを求める(=必ず0~2の数値になる) llWhisper(0, "Your number is " + (string)i_rand); } }
UUIDの特定個所を抜き出し(ハイフン部分を避ける)、integer型にキャストした後、乱数の最大値+1でmod(%演算子)すると0~乱数の最大値の数値が取れます。
この方法ですとアバターごとに違った数値が取れるだけでなく、同じアバターは必ず同じ数値になることが保証されます。
通常の乱数(llFrand関数)だと同じアバターでも毎回違う数値になってしまいますが、アバターごとに決まった乱数にしたい場合には有用です。
この方法ですとアバターごとに違った数値が取れるだけでなく、同じアバターは必ず同じ数値になることが保証されます。
通常の乱数(llFrand関数)だと同じアバターでも毎回違う数値になってしまいますが、アバターごとに決まった乱数にしたい場合には有用です。
チャット?
シット?
パーミッション?
アタッチメント?
キーコントロール?
UI?
カメラ?
- UUIDは~固有のものとなることが「保証されると言っていいでしょう。」≒「保証される。」 厳密には保証されないんですか? -- 通りすがり (2008-04-24 07:25:32)
- UUIDを使い尽くした場合などに被ることもあるかもしれませんが、現実的には使い尽くすことがないため、ユニークと考えて問題ないです。 -- Miz (2008-05-01 10:33:00)