ASUKA の CLUB RAIZEEN (雷神) のダンス玉 Massive Link Dance Unit ですが、、、昨日から調子悪くなっちゃってます。
きっかけは、、、ダンスアニメーションを LIN ちゃんが増やしたところからなのですが、その前から Owner でさえコンテンツフォルダーからスクリプトを開いてリセットすることができず、、、なんて症状でした。
で、昨日はじめてみたエラーで "Bounds Check Error" というのが出ました。
lslwiki によると Message Queue のオーバーフローや、1度に 50 以上のプリムに対して link messages を送ったとき（う、、、1プリムだけど、、、link message を受け取る script は、、、50 は楽に越えているし、、でも、、、これまで動いていたけど・・・）とか、あまりに多くのアイテムをリストにいれて llGiveInventoryList() をやるようなとき（やってはいませんが、、）に発生するみたい。あとは、null を Say したときも出るみたいですね。（これ、、、脆弱だわ・・・）
やはり、全部のアニメーションを読み込んで、List にいれて、、、の限界なのかもしれませんね。
いまひとつ、、、原因がはっきりしていないのが気持ち悪いですが、ASUKA (というか LIN ちゃん（笑）) の使われ方・使い方をクリアすれば、、、どんなところでも問題なさそうなので、ここはひとつ、設計変更することにしてみました。
ちなみに・・・ LINZOO さんは、この MLDUnit に、、、37 ものダンスアニメいれてたり（笑 たぶん、まだ増やすつもりと見ています。。。（37 程度のダンスアニメの名前だと、、、LIST としてはそんな対したサイズじゃないんですけどね、、、やっぱり、スロット管理 LIST なのかな?）
アニメーションのセットを複数作って、それをひとつの Synchro Manager スクリプトが読み込んでいましたが、これを、複数の Synchro Manager に分けるやり方です。ひとつの Synchro Manager で 3 つまでのセット操作・切り替え実績のある script はできたのですが、10 (LIN ちゃんの要望、、、）セットにした場合は、コンパイルは通ったのですが、run time 時に " Stack Heap Collision" というエラーがでちゃいました、、、これも lslwiki によれば、、、、ran out of memory.... 要はメモリー不足、、、ということです。本家のほうには Windows の場合は 22 までの else-if はいいけど、23 からは拒否されるみたいなことも書かれています、、、、（そこまで使っていないような、、、）で、、、、Mac OS X だと、、、692 の else-if が accept される、、、はい?（笑
lslwiki ってすごいですね、、、本家 (Linden) のほうの LSL の wiki も見ますが、こちらの昔からあるほうの lslwiki にはほんと、助けられています。
でも、、いずれにせよ、1スクリプトあたり16KB で バイトコードと、スタックと、ヒープを扱わなきゃいけないのですから、なるべく、なるべくシンプルにしていくしかないのでしょうね。
で・・・作りました。
でも、まだエラー処理のルーチンを追加中です。
これ・・・いつになったらできるのかな（笑
とりあえず、、、土曜日納品は間に合わなかったけど、今日、、、渡す予定でｗ
基本は帰納法・・・っていうか、n & n+1 が真ならば、無限に、、、みたいなスクリプトにしてます。（メモリーの問題は無視ね、、、）
この、n & n+1 の考え方は面白いかもｗ（自画自賛ｗ）
大人数かつたくさんのアニメでのテストが楽しみですｗ
「Owner でさえコンテンツフォルダーからスクリプトを開いてリセットすることができず」なんだけど、リンクダンスしたままリセットさせようとしてないかな。
返信削除「リンクでがんばって動いているのにそんな動作の余裕ねーよ！」ということかもしれません。
ということで、編集するときはリンクダンス全ストップさせてからしましょう(笑)
ちょっと小難しい薀蓄を垂れますよ、と。
返信削除list型のヒープ領域の使い方の話です。
list型は各要素へのポインタのみ保持し、
要素本体は別個にヒープ上に保持されます。
listの各要素のヒープ構造は型で変わりますが、
今回使ってるのは多分integer型かstring型だと思うんでそれで。
list型のヒープ構造
ヘッダ[11byte] + (ポインタ[4byte] * 要素数[n])
string型のヒープ構造
ヘッダ[7byte] + (1文字[1byte] * 文字数[n]) + 終端文字[1byte]
integer型のヒープ構造
ヘッダ[7byte] + 値[4byte]
string型の場合は文字列自体のbyteと、さらに12byte/要素。
integer型の場合は15byte/要素ずつメモリを消費します。
あとlist操作系の関数は戻り値がlistなんで、
listA = llListSort(listA,1,TRUE);
みたいに引数と戻り値格納先が同じだったりしますわな。
これは内部的には次の書き方と同じような動きしてます。
listB = listA;
listA = llListSort(listB,1,TRUE);
listB = [];
要するに同じ内容のlistが2つヒープ領域上に存在する瞬間があります。
なので予想される空きヒープ領域の半分しか使ってないのに、
Stack-Heap Collisionが発生する場合があります。
まあ見た目以上にメモリ使いますよ～ってだけです…
小難しいだけで何の解決にもなってない orz
まあ一応参考までにってことで…
さらにどこか間違ってたらユルシテ m(_ _)m
さんきゅーｗ
返信削除論理的に限界がわかるのでとても参考になりましたｗ