記憶粘土について検証したことと、不具合報告（制約含む）を書きます。
検証１．リンクした順番（リンクナンバー）と、形状が再生される（移動する）順番に法則性はあるか。
ドアノブとドアにllMessagedLinkのメッセージが届いた際に、リンクナンバーを表示するデバッグ文を入れてみました。
ケース１．ドアノブを先にリンク
Shape Memory Prim: DoorNob No=4
Shape Memory Prim: Door No=5
Shape Memory Prim: DoorNob No=4
Shape Memory Prim: Door No=5
ケース２．ドアノブを後にリンク
Shape Memory Prim: DoorNob No=5
Shape Memory Prim: Door No=3
Shape Memory Prim: DoorNob No=5
Shape Memory Prim: Door No=3
リンクナンバーに関係なく、ドアノブがなぜか先にメッセージを受け取っています。
ちなみに実際に動いているのはどちらもドアノブが先です。
ちなみに、Jakenさんと同じ事やったときは、どちらのケースでもドアが先にMessagedLinkを受け取りましたが、実際に動いているのはやっぱりドアノブが先ということで、もう意味がわかりません。。。
リンクする順番で動く順番を制御することは無理ということなんでしょうか。
検証２．１００個以上の記憶粘土をリンクさせてもちゃんと動くか。
ちょっとがちゃがちゃ変形時間がかかってるかなーという気はしますが、動きました。
質問１．
記憶させたオブジェクトをRezしてからコピーすると、コピー先で記憶がなくなっていることがある。（lantern Oyenさんから）
実際にやってみると、たしかに記憶がとんでます。
何回かやってみましたが、全部消えてました。 スクリプトリセットされるんでしょうか。
インベントリ（持ち物）内でコピー、もしくはインベントリから複数Rezした場合は問題なく、記憶されてます。
ちなみに、記憶しているかどうかは、editor-menuスクリプトでCHECKボタンを押すと何番目に記憶されているかが表示されます。
これは、色だけ違うものを作ったりするような場合に陥る可能性があるので、注意が必要とともに、
コピー可のものを配布する場合の注意事項とする必要がありそうです。
質問２．記憶した位置へ移動してくれない場合がある
（lanternさん、Wraithさん）
いくつかのパターンがあるようで、まだよく分かっていません。
小さいプリムを非常に大きなプリムへ変化させた時、一回の移動では足りず（？）、二回実行すると記憶した位置へ移動するケースがあることが分かりました。
対応として、play-menuのllMessagedLinkをコピペして、おまじないのように二回書けば問題なく動くということになりましたが、この辺りは検証が必要です。
他にも、まだ不明なケースがあるので、検証してみてまた報告します。
7 件のコメント:
○メッセージ順
プリム毎のUUID順かもしれません。
○rez/copy
スクリプトはリセットされます。copyによりスクリプトもcreate/rezされるからだと思います。
○位置
llSetPos()等で１度に移動できる(と保証されている)距離は10mまでです。
UUID順！ うすうすそうかなーという気はしていたんですが、やっぱそうですかね。
というか、UUIDって新しくコピーかなにかで作る度に文字列ソート的には後になるのでしょうか。その辺が分かれば多少はましなんですが。
SetPos（実際はSetParm使ってますが）で１０ｍ制限は知っています。
それは疑ったんですが、物を見せてもらったら、数ｍ程度しか離れてませんでした。
リンク可能距離が問題なのかなという話もあって、検証してます。
んーどうだろう。いっぱいrezして一個ずつUUID見てくしかないですねぇ。
順次大きくなっていくのだとすると、いつかはUUIDを使い切ってしまう日が来てしまうことに…。
でも、オープンチャットやIMですら発言順に応答が返ってこないことがある（しかも人によって違う）SLです。そういう技術なので、リンク順とかUUID順とかいう小手先の業で回避できるとは思えないです。
ある人からは正常に動作しても、別の人から見ると他の動きをしてるかもしれませんし。
10m制限内でもだめなんだ。んー。普通にリンクオブジェクトをeditして全体のテクスを一気に変えても戻っちゃう面が出てきたりするので、そういうもんなのかも(笑)
sleep入れて遅延させてもラグ状況によってまた違うしねぇ。確実なのは親子プリム間でひとつずつ要求・応答を繰り返すことしかないような…。
UUIDは、一般的な生成ロジックなら、おそらくランダムだと思います。
サスガにこれを独自実装・・・は、してないと思う・・・（汗）
詳しくはこのあたりを。＾＾；
http://ja.wikipedia.org/wiki/%E6%B1%8E%E7%94%A8%E4%B8%80%E6%84%8F%E8%AD%98%E5%88%A5%E5%AD%90
で、大きいプリムから小さくしたりする場合は、リンク可能距離の問題の可能性が大きいですね。
私が把握してるリンク可能距離は、xyzのどれか一辺でも長い部分があれば、３方面に対照的に広がるようです。
厳密に比較してませんが、<0.1,0.1,10.0>と<10.0,10.0,10.0>は、リンク可能距離が一緒っぽいです。
Taifrogさんと、ドアとノブのSayを見ていましたが、そもそも、Sayの出力順序が信用ならないという問題があります・・・ｗ
libsecondlifeをイジッてて気がついたのですが、Say自体は、別スレッドからのイベント処理に対して、同期を取らないと画面に出力出来ません。
なのでイベントの発生順序によって、Sayの出力が前後で入れ替わる可能性があります。
特にLSLでスクリプトが別になっていると、処理も非同期なスレッドで実行されていると思われるので、親プリムのLSLの連続Sayがずれる可能性がなくても、親プリムのLSLと子プリムのLSLの同時Sayは、前後入れ替わる可能性があると思います。
・・・言いたい事わかってもらえたかなー；
シフトコピーはスクリプトがリセットされるようですね。
対応としては注意書きで十分なんじゃないでしょうか。
(コピー元の記憶が消えるわけでもないので)
うちのやつは、一応、noteからの情報読込もやってますが、
正直、不要な機能な気もしてます。
kioさん、テクスが元に戻ることがある？？？ まじっすか。
Jakenさん、やっぱリンク可能距離で検証してみます。 Sayの順番が適当なのは、なんとなくｗ
noteは、200プリムでなんか作った人もいるので「書き出して」とは言えません・・・
ああ、もちろん、書き出し機能はあるんですよ
noteから読める1行の長さって決まってるんで
それにあわせて情報を分割しながら出力します。
とりあえず、こっちのは見切ったので
この系統はtaiさんにお任せしますｗ
がんばれー
コメントを投稿