リフト３種（計７個）を乗り比べ

ちょっと前にオーダーした？スクリプトが動作しないと相談を受けて（それはリフトじゃなくてタッチで装着するスクリプト）解析した結果、動作しない原因は当人の勘違いもあったけれど明らかにLSLでの実装方法が間違っていたのでサラっと直してコードの見た目も別物に書き換えたというのがありました。そのように正解が１つしか無いというような内容だといいのですが、実現手段が色々とあると間違いじゃない・・・けれど、しかし・・・といった感じで、なんともスッキリしないのです。でも別の実装方法を知らなければどちらがよいかなど検討することもないのですから当然ですよね。そんな実装方法が色々とあるものの１つにリフト（昇降機）のスクリプトがあります。色々と題材はあるのになんでリフト？なのかは、先日にお友達から「リフトが欲しくて今、お願いしている最中です」と聞かされて、リフトはねぇ・・・色々あるなぁと頭をよぎってその場は以前に作ったものを２つほど動作見本を見せたのだけど、せっかく依頼してるんだからどんなのが出てくるのか見てみようってスルーしてたんです。しばらくして完成したのを見に行きましたが、それがまぁ一番アカンやつ(やってはいけない)だったので、どうしてそうなるのかと考えたところ、やはりちゃんと見本を誰も示さないからでは？と思うようになって、これがリフトだ！と見比べることが出来るものを用意してみました。

乗り比べセットはジャンクコーナーにあります。教材目的ですからFullPermissionですよ～
(箱に入れずに一括取得なので展開は20m × 20m の広さがあるところでRezしてね)

なお一般的な現実世界での普通の昇降機の移動速度は30m毎分らしいので
分かりやすいように30m上下移動する設定にしています。

■物理のリフト
物理モデルの移動完了判定について
◎at_target 最適
○moving_end 不向き　→　いつまでも微妙に動く場合がある
△Timer 無理だと思う　→　定速度なら逆ベクトルかけて止めるというのも出来そうだけど

●リフト①－１　
仕様：物理モデル

利点
   ・動きがスムーズ
   ・実装が簡単
欠点
    ・何かが乗っていると対象の質量が抵抗となる(衝突による衰退)
    ・乗っている質量の方が大きいと動かなくなる
    　(速度をを上げれば解決しますが速すぎるとコリジョン抜け)
    ・初動と終端付近での移動速度の差が大きい
注意
    ・変に回転しないようにSTATUS_ROTATE XYZを固定設定すること
    ・SIM負荷になるので動いている時だけ物理属性に変えること
    　(風でも物理は動きます、摩擦も計算します、浮いていても空気との摩擦があります)

●リフト①－２　
仕様：物理モデル(改)
    移動動作を一発指定ではなく
    細かく区切って連続的に継続させるようにしたもの。
    乗り物や武器のスクリプトの経験のある人なら
    applyimpulseで叩くようなイメージです。

利点
    ・初動と終端付近での移動速度の差が殆ど無く一定速度
    ・一発指定の物理よりはパワーがある
欠点
    ・何かが乗っていると対象の質量が抵抗となる(衝突による衰退)
    ・乗っている質量の方が大きいと動かなくなる
    　(速度をを上げれば解決しますが速すぎるとコリジョン抜け)
    ・動きが小刻みに揺れて見え綺麗ではない

何れも物理モデルの場合、上に乗っている物理の
質量によって速度が変わってしまう。
重すぎると動かない。
白いリフトの場合２名までが限界

まぁ他にもPushObjectで押し上げるとかApplyImpulseで上下に叩くとか
風変わりな方法もできそうですが試す意味が無さそうなので割愛します
（叩く系は土地の設定で禁止となっている場合があります）

■非物理のリフト
非物理モデルの移動完了判定について
※移動先の指定地点へ移動＝移動完了なので判定する必要がない

●リフト②
仕様：非物理モデル(標準プリム)

利点
    ・移動位置を直接指定なので位置ズレが発生しない
    ・何かが乗っていても対象の質量に左右されない
欠点
    ・単純LOOP処理の場合に動作中は他の処理が割込めない
   (Timer割込で回すなら問題なし)
    ・コマ送り動作であるので見た目がカクカクした感じになる
    ・一度に大きく移動させるとコリジョン抜けになりやすい

その他：llSetPosだとやはりディレイ0.2秒のペナルティがあるのでllSetLinkPrimitiveParamsFastを使って無理矢理に動かすというのも試してみたいですねぇ(未確認)

■キーフレーム（非物理）のリフト
キーフレーム（非物理）の移動完了判定について
◎Timer 最適　→　複数キーフレームであっても合計値で判断できる
○at_target まぁまぁ最適　→　ズレがあるのでターゲット検出範囲を広く取った方がいい。現物調整。リフトのように単調な移動なら問題ないが複雑な軌道をとるもの(同じ地点を通過する物)には不向き
△moving_end 可 →　キーフレーム内に停止状態を入れたり最初の０キーフレームでラグがあると終了条件が発生してしまう

キーフレーム仕様の主な利点
    ・何かが乗っていても対象の質量に左右されない
    ・終端までのフレーム数を変えることで一定速度や可変速度など自在に定義できる
    　例えば５m上昇させるという場合に１キーフレームで
    　[< 0, 0, 5 >,15]
    　と定義すると一定速度で移動するが複数キーフレームで
    　[< 0, 0, 0 >,3,< 0, 0, 0.5 >,3,< 0, 0, 1 >,3,< 0, 0, 1.5 >,3,< 0, 0, 2 >,3]
    　と定義すると、少し待機→0.5m上昇→1.0m上昇→2.0m上昇と次第に加速する感じが表現できる
キーフレーム仕様の主な欠点
    ・標準状態のプリムでは使えない(MESHオブジェクト(物理がCONVEXの指定のあるもの)が対象)
    ・衝突やラグ、端数処理の都合などで位置ズレ、時間ズレが微妙に発生する
    ・オブジェクトの編集権を持つアバターが選択状態の時は動作が停止する(軽くタッチ、またはタッチ長押しするとよく分かります)