◆ - Sugar Snow - ◆

  

プリム間のリンクメッセージの速度を測ってみました。

ルートプリム ⇒ 子プリム ⇒ ルートプリム
のようにメッセージを送り時間を計測してみました。
つまり、およそllMessageLinked２回分です。

結果は、約0.022秒でした。
１回分だとその半分になるのでしょうか。

子プリムを増やしてすべてに送信するとこのようになります。（リンク９個でそれぞれの受信までに掛かった時間）

0.021606
0.043945
0.066467
0.088379
0.111389
0.132996
0.155029
0.177368

予想とは違い、時間は単純に加算されました。

LINK_ALL_CHILDRENを使用してすべてのプリムに送っているので
送信に0.01秒、受信に0.01×8の時間が掛かるかと思っていました。

この結果だと、１つ１つ送っても同じみたいですね。

遅くはないけど、意外と時間掛かるみたいです。
  

LSLで最近これに気付きました。

jump文です。

C言語などであるような break や continue が無くて不便だなぁとは思っていたのですが、
特に困ることもなかったので全然気付きませんでした。

プログラミング言語を知っているが為に構文に関わるところは
適当に読み飛ばしていました。
リファレンスも元々自分用として書いていましたので
その部分は飛ばしてしまっています。

そんな訳で今更気付きました。

jump はC言語に無いですからね(笑)
C言語風にいうと goto と同じですね。
ラベルの書き方も : ではなく @ という違いがあります。

javaでgotoみたいなことができると知ったときと同じくらい新鮮でした。
わかる人だけわかって下さい。(笑)

でも、多用は厳禁ですね。

まあ使う機会なんてそんなにありませんが。

  

ひさしぶりにスクリプトでも書いていたらこんなエラーが出ました。


Parser stack depth exceeded; SL will throw a syntax error here.

これは？

とりあえず調べてみると、スタックが150を超えると駄目みたいです。

んんっ？
いくらなんでもそんなにネストしている場所は無いのですが？？

スタックの数え方がよくわからないのですが、（英語だったので適当にしか読んでいないだけなのですが）
処理がネストする以外に変数や関数を定義するだけで１つ消費するみたいです。
制限されている理由も書いてあった気がします。

私のソースは定義値用に無駄な変数作りまくっているのが原因でしょうね。
回避方法を参考に
関数を先に定義してから変数を定義するように変えてみました。

それだけで無事エラーが出なくなりました。

グローバル変数を使用している関数が、
変数定義より前に定義されているのが気持ち悪いのですが、
エラーは出ないのでひとまず良しとしておきましょう。

どうやらこのエラー lslint.exe を使用している場合だけに起きるようです。
InWorldでは問題なくコンパイルが通りました。

何はともあれ解決しました。


それにしても定数どうしましょうね。
無駄に思えて仕方がないのですが、即値はもっと嫌です。
しかも複数のソースで同じ物を使用する場合、両方に同じものを書かないといけないですし。

まあ、あまりにも増えすぎたら奥の手使うしかないですね。