Thinking about ...

まず、ＬＳＬ（いわゆるリンデンスクリプト）についてあまり詳しく知らない人のための説明をします。

　１、ＬＳＬはテキストで記述され、そのテキストを元にＬＳＬシミュレータが「どのような処理をするか」
　　　を解釈し、ＳＬ内に反映させます。

　２、よく「スクリプトが壊れた」という言葉を使いますが、一度保存されたスクリプトのテキストが
　　　製作者の意図に反して勝手に変化することはありません。
　　　つまり、壊れたという状況は、製作者が予測していなかった処理が実行されたことによって
　　　「変な動作になったり、エラーがでたり」という想定外の結果になってしまったことを意味します。

つまり、今回のＳＰＳの不具合は、製作時のＬＳＬシミュレータの仕様では特に問題が発生して
いなかったが、ＭＯＮＯの導入に先駆けて行われた仕様の変更によって問題が発生するように
なってしまった、ということになりそうです。

ちなみに、現時点で把握できているＳＰＳの問題点ですが、サイズ変更のために各パーツに
埋め込まれているプリム変形用スクリプトを動作させるために使用していたllMessageLinked
という関数が正常に処理されなくなってしまうケースがあるようです。
正常に処理できるケースとそうでないケースの違いがまだいまいち掴みきれてません＾＾；

※パーツを一個一個順番に変形させていく方法のほうが確実のように思われますが、従来の
　ＬＳＬシミュレータではＳＩＭが重くラグが発生している場合は逆効果になることが多かったため
　上記のように各パーツに「変形しろ」という命令を一斉に飛ばす方法を採用していました。

前記事にも書きましたが、MONOは従来のＬＳＬシミュレータよりも処理速度が最大２２０倍も速い
ということなので、処理速度を重視すべき製品は、ＭＯＮＯへの対応が不可欠となりますが、
まだＭＯＮＯそのものに未知数の部分があり、さらなる仕様変更（微調整）の可能性もあります。

以上のことを踏まえて、私の製作したスクリプト入りの製品に関して、次の方針をとりたい
と思います。

　１、ＳＰＳは、llMessageLinkedに関する修正をおこなう。
　　　※ただし、完全に解決できるかどうかは現時点では断言できません。
　　　※既ユーザーには修正版を自動アップデートにて配布します。

　２、ＭＯＮＯがＳＬ全体に導入されたと思われる時点（ＲＣヴューア1.21のリリース）にあわせて
　　　処理速度を重視すべきだと私が判断した製品をMONOに対応させ、
　　　※既ユーザーにMONO版を自動アップデートにて配布します。

Ｐ．Ｓ．
ＭＯＮＯ導入は将来を見越して必要だと理解できますが、それにあわせて既存のＬＳＬにまで
こういう仕様変更をするのは、マジで勘弁してください＾＾；＞リンデン