[TNKworks]VardarV1.0

まぁ聞いたことがない方が多いメーカーでしょうな

ラインナップに ○ータス○リーゼ アル○ーヌ・○ノー ヨ○ハチ カ○ラGTとかある

ライトウェイトスポーツ系を多く出してるメーカーさんです

ただ実際の評価はといいますと

"バックさえしなけりゃ走りは一流"

(リバースのステアリングに致命的なバグがあるのです)

"デフォルト設定がもっとマイルドなら評価が変わっていた"

(何故かやたらピーキーなのですげー扱いづらい)

"やたら低LIだから置物としては割とまとも"

ってな感じの意見が多いメーカーです

んでまぁそこがSUVを出したわけですよ お値段3000L$

(元ネタはト○タのF○クルーザーってやつ)

見ての通り見た目はいいんですよ見た目は

ランドインパクトも停車状態で20とかですげー良好

しかもこのランドインパクトで

・ライト類全点灯

・全ハッチ開閉

・リフトアップ仕様に出来る

・複数のペイント有り

・5人乗り

等置物としての出来はかなりいい

ただし見た目がオフローダーなのにデフォルト設定での不整地走行が散々なのですよ

(後述する傾向と対策を実施すれば随分改善します)

このSSが撮れる場所までこいつで自走するのに最初は30分かかりましたｗ

何故か

まずこの傾斜をどれだけ頑張ってもまともには登れない
まぁこれウィリー機能があるって書いてあったわけですが
ウィリー機能だけONにしてもフラフラしやすくなるだけでさっぱり改善しない

んでまーSLヴィークルのセオリー通りにギア上げるとどうなるか

まぁ坂を抜けた瞬間に不安定な姿勢ですっ飛ぶからコケるわなぁ

しかし ご安心ください

信頼と伝統の飛行モード完備!
これでコケても安心!



とまぁこれで終わってもアレすぎんので
不整地走行での傾向と対策を

ウィリーモード
turn Angle 50
accel power 450位上
Roll allowed 45位上
ギアはロー固定

この設定でなら割とどこでもいけます

あとは無駄に段数が多いギアとかも余裕があったらどうにかするがよろし

ってなところかねぇ

以上

mesh関係のお話

３Dデータについて基本的なことがわかってる前提で

文書化されてなかったり解説が分散してたりするお話のまとめ



現状わかってる範囲でやるなって言われてる感じのこと


・llSetAlpha系命令によるオブジェクトアニメーション


 これはllSetTextureAnimとは別の話ね



 同じ場所に大量の面を重ねてアルファ切り替えで
 アニメーションしているように見せる処理のことらしい


・ものすごいハイポリゴンのオブジェクトを
 計算上低LIに見せかけるテクニック

 (ある程度方法がテンプレ化してんだけどそれはここで書かない そのうちどうせ潰される)

・ダミー面使ってセンターをずらしたObjectのアップロード
 当たり判定の処理的にかなりまずいらしく
 どうしてもセンターオフセット回転やりたいなら
 パペッター系のスクリプトでやれとのこと

・convex hullの多用
 物理シェイプ的には正四面体をアップロード時に指定が最軽量らしいとのこと





スクリプト連動周りのお話



・アニメーションではなく見た目切り替えの処理でなら

 (車だとエアロパーツとかホイールとかの辺り)

 setalphaで不可視状態にして最小化 が最善とのこと
 (レンダリング負荷周りのお話っぽい)

・これは推奨ってわけではなくそういう手もあるって話ですが

 furryさんとかでnフレームの口パクさせたい場合
 左端1/nのエリアを通常の絵
 残りを透明にしたテクスチャを用意して
てくすちゃあにめ でワンフレームづつずらしたものを指定して
 動いてるように見せかけるって手が使えます

 (ローカル動作なので40fpsとかでもSIMラグはほぼ無し)
 マテリアルでアルファマスクをワンビットアルファにしてやれば
 アルファ面が前後するバグも考えなくておｋです




んでその他のFAQみたいなもの


・スカルプもアニメーションさせるのにUUIDフリップがあるじゃないか


  あれも本来は多用するなって方針ですよ


・出来るようにしてあるならそれはやっていいってことだろ?


  ［お前がそう思うんならそうなんだろう お前ん中ではな］

  (テンプレらしいので使ってるだけですよ)


・ソースを出せ


  ソースが出せるんだったらURL羅列して終わってんだよ



・つまりどういうことだってばよ?


  meshはどうやったって重いんだから無駄にトラフィック圧迫するようなことすんなってことです









ってなところかね


以上

アウトSIMのお話

未だにmeshが全てを置き換えられない理由のひとつがこいつっすな

どーん

まーあれだ
SourceEngineで言うところの3D SKYBOXに近いものだ

実際に行動可能なエリアの外に視界遮蔽とかディテールアップを目的として
オブジェクトを配置する技術

これの木とか岩とか滝が全部SIM外にある

単SIMで大幅なディテールアップが望めるので

かなーり便利なしくみなんだけど

HUGEPRIMっちゅーってサイズとかがかなり限定されてるプリムを使うので

既存プリムに適用出来ないmeshオブジェクトだと不可能

スカルプはプリムパラメーターなので適用可能っちゅーわけなんだが

スカルプは頂点精度が256しかないので

このサイズ(1024*1024*100)だとかなーり大雑把なディテールしか作れない

けどまーないよりはマシなのでかなり重宝されてる感じっすな

オマケ

　HugePrimは重いって話について

　

　まー全く重くないって言うと嘘になるんだけど

　(実際リンデンも存在自体は容認しているが物理オブジェクト化すんなって言ってるし)

　実質LODが全くかからないので大量に使われると描画負荷になるとか

　描画距離短い人だと表示されてないのにコリジョンだけ出て

　見えない壁があるような状態になるとか

　１プリム辺りの同時コリジョン数がどうしても多くなるとか

　そういうのがあるので多用は禁物って程度やね

以上

SL用 モバイルビューワについて

とりあえずまー現存ビューワーで3D表示まで対応してるのはこいつしかありません

Android版のみです

Lumiya
https://play.google.com/store/apps/details?id=com.lumiyaviewer.lumiya


んでこいつですが
うちが使ってみた感じでは

・mesh対応
　riggedの表示も問題ない

・光源演算非対応
　ずーっとフルブライト状態なのでフェイスライト不要？ｗ

・タッチとか座るとかは一応出来るっぽい
　面指定のタッチが出来ないので一部HUDや設置物では動作に不安がある
　モバイルビューワーを全面的に想定ならマルチサーフェス以外に
　ダイアログ等での操作が出来る仕組みが必要かも

・TP以外でのSIM越えは不可能

・IMとかチャットはある程度可能
　ダイアログ操作も可能

・sit時にコントロールイベントが拾えないっぽい
　なので自分で運転するタイプのヴィークルは全部アウト




動作に関して

・IS11T(悪名高きレグザフォンｗ　もう会社無いからアップデートも絶望的)
　ログインしてチャットする程度ならギリギリ
　3D表示は重すぎて全く使い物にならん
　装着物等の変更はアキラメロン
　3G回線も使えるので停電時の緊急連絡等もいける

・MemoPadHD7(2013年夏発売のローエンド最新機種　通称廉価版Nexus7)
　3D表示で特にストレス無く歩ける
　服装の切り替え等も特に問題なし
　たくさん人がいる場所だとわかんないのでなんとも
　乗り物使っての移動とかはどっちにしろ無理
　外付けキーボードあればチャットとかも問題なくいけるのかねぇ　まぁATOK必須だが




動作スペック的に大丈夫なら300円払う価値はあるのかもしれん
スマホでのINは画面サイズと解像度的にチャットとIMのみっぽい


あとなんかあったらコメントでよろ

以上

ヴィークルスクリプトについて(下書きそのままぶちこみ版)

tipsというかメモ書きレベルのお話

うちのスクリプト組んだ時の内容だからこのセオリーがそのまま全部使えるわけではないので
そこだけ注意

・DTCARは機能だけを参考にする
　機能的にはあれがかなり優秀なので

　pgupとpgdnでギアコントロール
　左右キーにハンドル
　前加速　後は減速と後退

　同時押しで飛行モードとかは入れるなよｗ

・ベーススクリプトはAelonPerkinsのRealisticCarかTerraのDIY Planeを使う
　シンプルでロジック構造にそこまで癖がないのでおすすめ

　ちなみにArlonの基礎パラメーターそのまんま使ってもほぼ問題ない

　修正すべきバグはいくつか存在するが
　そのままだとタイヤ制御周りがステアリング反応速度のボトルネックになるのと
　後進中のステアリングがぶっ壊れてるのと
　コーナリング中にブレーキングしようとすると強制カウンターステアで死ぬので
　その辺は最優先で解決する必要がある

　一番確実なのは”前進中に後キー”押された時を検出して
　その時だけはブレーキングモードにする処理系と

　タイヤ制御をコントロールイベント内部では状態フラグだけ書き換えて
　タイマーイベントでフラグ書き換わり時のみ実際の処理を行うようにする

　どうせブレーキランプとかバックランプも連動させるんだから
　状態フラグはinteger型のビットマスクに全部ぶちこんて
　messagelinkedで一括送信する仕組みにしとけ捗るぞ

・もう全部のタイヤと座席にスクリプト入れるとかするな
　ただし完全シングルスクリプトなんてもんはタダの自己満足だ

　そこ気をつけるだけで普段使いのユーザビリティーが400%くらい向上する
　あえて完全シングルスクリプトにしない理由は
　複数タイマー制御する処理とかイベントスタックとかを考慮すると
　完全シングルにするより　ある程度処理系カテゴリーで分けたほうがトータルでは軽い

　といっても３~５枚程度に入るようにはしとけ

・やばいとおもった時に安全に停止出来る事が全てに優先する
　人間やばいと思った時ほど普段の癖で操作してしまう
　前後や左右の同時押しで特殊機能が発動するタイプのスクリプトは
　安全性が最優先の場合　問　題　外

　それでもそういう機能を入れたいってならデフォルトはONでも全くないから
　”オフ出来る”ようにしとけ　そんだけで随分評価が変わる

・フィーリングで迷ったら演出上はもっさりにしとけ
　イベントスタックしまくって入力反応がちょー遅いとかそういうのは問題外だが
　アクセルめいいっぱい踏み込んでももっさり加速しかしないとか
　ハンドル切れ角がMAXになるまでに時間がかかる　程度なら
　個々の車両の特性なのでドライバーがなんとかする



どうせ後で追記するだろうからとりあえずこの辺にしとく

以上

公式wikiのLSLライブラリーのお話

結構有用っぽい感じのコードがあったので適当に紹介

http://wiki.secondlife.com/wiki/LSL_Library

ただシンプルすぎて逆に使いにくいとか
コマンドのUIがあんまり親切じゃないとか
負荷コントロール周りでちょいきになるのがあったりするので

配布したり売ったりするならそこをなんとかしませう





個人的に気になったのはこれ

http://wiki.secondlife.com/wiki/Linkset_resizer_with_menu

メニュー付きのりサイズスクリプト
最大と最小の調整がソース内部で可能っぽいのと
初期に戻すって項目もあるのがいい

ただ微調整するときに毎回タッチしないといけないのがめんどいので
クローズ選択するまではダイアログがすぐに出る仕様の方が親切かも

http://wiki.secondlife.com/wiki/User:Daemonika_Nightfire/Scripts/*DS*_Resize_Script

ってかこいつが商用システムに一番近いやつか？
thisとallの選択とか位置とサイズの記録機能もあるっぽいし
説明欄使うっぽいから別スクリプトで利用してる場合は要注意





あと気になったのがあったら追記するかも

以上

SL車両 デモカーrezzer向けチェックリスト

デモカーのrezzerがある場合
最低でもここをチェックすればおｋってリスト

ちなみに特定メーカーをdisする目的ではなく
あくまで走行安全性のためのチェックリストであり
これが出来ていないから全く駄目ってわけでもありませんが
少なくとも同じ車種でまともな操作系のがありゃそっちにするわな的な

キー説明

前　カーソル↑ or W
後　カーソル↓ or S
右　カーソル→ or D
左　カーソル← or A
上　PageUp     or E
下　PageDown or C



・前進中に前キー押しながら後キーを押して離してアクセルが保持されるかどうか

　これでいきなりバックはじめたりアクセルがキャンセルされるのは非常に危険です

　何故かというとSIMラグでアクセルを離したつもりになってるのに離れてないことがあり
　そういう状態で減速しようとして後キー押すと暴走事故になるため


・前進中に左右キーどちらかを押した状態で後キーを押した際に
　きちんと左右キー押している方向で旋回を継続されるかどうか

　これは上記のとの複合ですがいきなり逆向いたり
　異常なスピンモードに入ったりするのは事故につながります



・停止状態から後キー押しながら左右キーできちんと押した方向に曲がるか
 (バックギア搭載車両を除く)

　万が一壁に刺さった際の脱出や
　普段の車庫入れ等でこの操作が逆になっていると
　集中力ががストレスでマッハです


・停止時　あるいは前進中に前後キーが同時に押される際に
　前進後退停止　以外の異常な挙動をするかどうか

　いきなりウィリー開始して壁にすっ飛んでったり
　飛行モードになったりすると
　積極的な加減速で挙動を制御するサーキットやワインディングでの走行ではかなり致命的
　随伴車両が居る場合多重クラッシュの大惨事になる可能性すらあります


・shift押しながら左右キーに特殊機能が割り当てられていないかどうか

　割り当てられてるとマウスルックでの運転が出来ません
　あとキーボードのマッピングによっては該当操作が走行中に出来ません


ってなところかなー
想定外の操作をしても動かない　のは仕様ですが
想定外の操作をすると暴走する　は不具合やバグです　事故ります

以上

スカルプテッドプリムについて

webを適当に見た感じ日本語でまともな解説やってるサイトがほぼ無いです
あっても情報が2008年代とかで
大規模な仕様変更が2009年以降におきてるんだけど
その後のまとめ解説が見つけられなかったですよ


というわけで軽く解説



どういうものかってのを3Dやってる人ならこれでわかるって表現だと

UV座標上のピクセルにオブジェクトの位置座標を
RGBで対応させたものがスカルプです




んじゃ実際のスカルプについて適当に

まずはデータ形式から

SLの画像データは32bitのbitmap(RGBA)なので
そこから頂点精度は8bitとなります

んで昔のドキュメントだと頂点数は32*32って解説されてたと思うんですが
実際の形状データは32*32"面"ですので
頂点は33*33です

これは最初のスカルプの仕様が球体のみで
全部のポリゴン終端が収束されてる前提での仕様でした

が

その後ご存知の通り仕様変更がおきました


データ上33*33ですがプリムパラメータにより

球体　        32*33
シリンダー　32*33
トータス　    32*32
平面　       33*33

とデータ解釈が行われます

其の関係でUVマップは格子状で数量固定にせざるをえないので

昔言われてた"スカルプは頂点の切り貼り厳禁"って話になるわけですな
仕様さえ理解してりゃ制限があるにはあるけど
実際にはいくらでも出来るんですけどね


昔のチュートリアルで自由形状をUV展開して配置して
アップロードしたものの見た目がいまいちよろしくないってのがあったと思いますが
あれはピクセルのデータリードのの解釈についてきちんとした情報がなかった時代に
試行錯誤で到達した話ですので
最初から仕様通りのUVと頂点配置のオブジェクトを作ってしまえば
綺麗なデータが作れるというお話です



次はビューワー上の実装でのお話

スカルプマップの画像は最低64*64でないと正常にリードされません
これは前記のとおり頂点解釈が33*33であるためです

んでリードされるピクセルですが
33ってことは基本一個おきリードですが片方の終端は連続リードされます
んで連続リードされる頂点ですが
SLビューワのデータリードは左下原点です

なので上端と右端が2ピクセル分連続リードされます

ってなところですな


次アス比スカルプ

現在ガチ勢が使ってるのは大抵アス比スカルプですな
LOD安定性ってことだと正方形アス比のスカルプはいまいち使いにくいので
アス比スカルプ使う場合がどうしても多くなります

アス比スカルプといっても奇数は配列に出来ないです
あとは四角面総数が1024にならないとあかんです

面数配置のリストはこんな感じ

4*256
8*128
16*64
32*32
64*16
8*128
256*4


んでもってLODについて

LODってのは要は遠距離オブジェクトのポリゴン省略して
レンダリング負荷を減らすための仕組みです

LODはちょいめんどくさい話になるんですが
アス比の場合長い方からLODがかかります

んでもって(シリンダーにした場合の)断面方向は
4頂点以下には絶対にならないようになってます
(テロとかで右クリック選択出来ないオブジェクトを使われないようにするため)
なので角材を組み合わせたオブジェクトとかは
極端なアス比スカルプのほうがいいってことになります




実際にモデリングする際のtips

テクスチャ解像度のコントロールのために
UVを調整するってのが"ほぼ"出来ません
(気合と根性で出来るっちゃ出来るけどツールと腕に依存する)
なので頂点配置数で解像度コントロールすることになります

あとはLODが弱い頂点は形状のアウトラインとしては使いものにならないので
実際に形状として使える頂点数は全体の50%から25%になります
それ以外の頂点は曲線表現の中間調点とかそんくらいの用途です

ってなところかな

あと細かい部分の質問はコメントにでも書いてもらえれば
わかる範囲で返答するかもしれません

以上

SIMオーナー向けスクリプト負荷管理のお話 Ver.0.5

まー参考データなので鵜呑みにしないこと
結局最終的には各自の判断による自己責任だ




想定はパブリックアクセスのSIM
(どうせ身内しか来ないってSIMでもアクセスコントロールしてないなら該当です
　負荷なんぞ知らんってのが本当に出来るのは
　プライベートな自宅まるまる１SIMの場合くらいです)


目標値はあくまで参考値なので
"これ以上になるとなんかあったときに色々ときつい"て数値であり
少ないなら少ないほどいいです
というか特に理由がなければギリギリまで削れってことですな


前置きとしまして
SIMのフレームタイム(遅延無しでの処理可能時間)は約22mSecです

つまりなんだかんだでこれの半分が平時負荷になってるのが理想
人が多い時でも75%程度になってりゃ不意のスパイク負荷で処理落ちとかもほぼない

　　機械っちゅーのはざっくりとした数値ですが
　　負荷が半分になれば寿命が４倍になります
　　逆に負荷が２倍になれば寿命は４分の１です


具体的なリミット数値に関しては
状況に合わせてかなりフレキシブルな対応が求められるため
実測データと経験からやってくだされ

とまぁ投げっぱなしにするのもアレなので代表的なリミット数値を挙げておきます
所謂BANラインってのは別でありますがまぁそこは各自の自由で


・常設物のアイドル時スクリプトタイム　1オブジェクト辺り0.05mSec以下(0.01mSec以下が理想)
・アバターのアイドル時スクリプトタイム　一名あたり0.05~0.2mSec
・アバターの装着スクリプト総数　　　　一名あたり20~100

大体このへんです
んでアバターの方がかなり大雑把な数値なのな理由がありまして

置物のみでなら平時のスクリプトタイムが合計で5mSec切ってりゃ十分です

アバターの方は服装によってかなり振れ幅があり
ガチの軽量化特化で服装を選べる上級者連中は大丈夫なのですが

そうでない人だと
"スキンヘッドor全裸になれというのかこのやろう"
って逆切れ型のクレームのほうが面倒なので
よっぽど多人数が集まることが想定される場合を除き
ある程度はスルーしてったほうが色々と平和です

ただしガチでSIM負荷がきついときはとっととTPHOMEしてしまいましょうｗ




・置物について

　ガチで全部コントロールしたいなら
　全部mod可品買い入れ&自作　が正道です
　んで不要なスクリプトは全除去してしまいませう

　カラーチェンジとかマルチアニメみたいな余計な機能満載してるような家具は
　ベンチスコア取る余裕も買い直す予算もない場合、nomod品は全部無視してしまいませう

　乗り物関係もnoscriptのディスプレイモデルが同梱されていない場合
　よっぽど軽いとかでないなら常設は諦めませう

　
　んでまぁ負荷関係で一番面倒なのはクラブ関係の設備でして
　ほんとに負荷考慮だと市販品はほぼ全部アウトです
　というか普通に売ってる奴はもう世代が古すぎるってのもあります

　かといってなんも知らん一般人が制御周り自作すりゃ軽くなるかってーと
　断言しますが100%市販品と同等か更に重くなります
　なのでもうここは有名クラブでの使用実績とかで判断するしかねーです




とりあえずの対策ってことならこんなもんかね
ユーザー側の話はガチで荒れる話なのでどうすっかねぇ

以上

ヴィークル基礎 Part.1

さて不定期連載のヴィークル制作講座でもやりますかね

第一回はいきなり地上ヴィークル開発のコア知識と業界の現状からいきませう

前提条件として
・ノーマルプリムの位置　回転　拡大縮小等の編集作業が出来
・親プリム　子プリム　リンクナンバーについて理解しており
・27プリム以内でタイヤ以外のオブジェクトが全て制作可能で
・なおかつXYZ軸の意味がわかることを前提とします

そこすら出来ないとドキュメント量が半端なくなりますのでｗ



さて今回の教材となるたった一枚の画像

まぁ選定車種や造形に対するツッコミはあえて無しの方向でｗ
(フルスカルプでやってもいいんだがそれやると別の問題が出る)



1.造形とリンクについて

大抵ヴィークルスクリプトで
最初に引っかかるハードルが

・27プリム以内でタイヤ以外のオブジェクトが全て制作可能で

この前提条件
物理スクリプト関係の知識がないと
まずこれを256プリム限界まで使い切ってしまうのですよ
んでそこから入れても動かないって相談がされるわけです

なのでまず27プリムで車体を作れるようなりませう




んでまぁここクリアすればもう完成したも同然でして
極端な例としましては

"既に走行可能状態になっているフルパーミッションの車両"
を入手してきてルートプリムとホイールだけの状態にして
向きと位置を合わせて車体をリンクするだけです


現在フルパーで流通してる世代の車両は
4年以上前に様式が既に完成しており
ホイールとルートプリムにスクリプトを入れるだけで動きます


・・・とまぁここまでが
"とりあえず走るようになるまで"のテンプレです
ここまで出来るようになってからこの先を読みませう





2.ヴィークルスクリプトについて

とりまwikiのURLを

http://wiki.secondlife.com/wiki/Category:LSL_Vehicle

まー色々と中間理論は端折りますが要点は以下に示す通りです


・SLヴィークルの基本的な計算式は
　速度÷加速時間＝パワー
たったこんだけです　車体重量は加速するだけなら一切関係ありません


つまり馬力を上げまくればとりあえずパワーが出るなんてヌルいもんではありませんが
物理仕様の限界以内ならどんな車体でも最大900km/hまで安定して加速できます


んでSLヴィークルはルートプリムの回転と軸が重要でして

・X+方向を正面
・Z+方向を上面

これを守らないとまっすぐ走れません


ってな部分が基礎です
正直これ以上はユーザーの好みが関係するファクターが多すぎるので
気になった箇所からwikiで関数見ながら調整していく方法が正道です





3.実走行に関係するパラメーターについて


こっから先は更に上級者向けというか

ある程度リアル車両あるいはドライビングシミューレタでの
運転やセッティング出しが出来る前提の話になります

・旋回力パラメーターについて
　大抵のスクリプトだと”わかりやすく”するために定数でヘッダ領域についてますが
　DTCARとかだと想定がせいぜい普通車の時速60キロくらいまでです


　ってのがデジタル入力だと40キロから120キロくらいまでの

　まっすぐ走るために必要な修正舵が入れづらいので

　速度が上がるほど反応が鈍くなる数式の方が扱いやすいのです
　"とりあえず減速すりゃ安全"ってわかりやすいですしね
　そして低速域ではステアリング切れ角がある程度大きくなり
　転回等の小回りも可能になります
　無闇に上げるとどうしようもなくなりますので注意

・トーとキャンバーについて
　トーを"アクセルON時の直進安定性"　キャンバーを"ステアリングの初期反応"とするならば
　それに相当するパラメータが一応存在します
　ただし調整のやり方はちょいと特殊で
　”減衰時間"をダイレクトに指定する感じになりますので

　ある程度走りながら出す感じになります

・車体重量と重心、当たり判定について
　SLヴィークルにはいわゆるショックアブソーバーやサスペンションがありませんので
　"パワーがかかって居ないとき”の挙動は重量や重心位置、当たり判定の形状で決まります

　まーいろんなパラメータから逆算でパワー与えてゴリ押ししてもいいのですが
　このへんもある程度経験から出せるようになりませう






※こっから下は碌なこと書いてないので　
　　読み飛ばしてもらって結構


・４実際のカースクリプト


　まーご存知の方は知っての通り
　いわゆるサーキットSIMでは300キロオーバー領域まである
　"レーシングカー"が人気で主流です

　で、

　　まぁそういうのは
　　DTのベースでギアと旋回力のパラメーター”だけ”アホみたいに上げた奴で
　　低速ぐるぐるしすぎの割には、高速域もそこまで曲がるわけでもなく
　　核パルスエンジンでも使ってんじゃねーかってレベルの鬼加速です


　んなもん乗ってられっかってなるのは自明の理なわけですが
　そんなもんがもう4年以上未だに”トップシェア”を守ってるのは
　"他のスクリプトが調達できないから"なわけです
　まぁ理由とかはその業界詳しい人にinworldで聞いてください
　二時間くらいかけてたっぷり聞かされます


・5ヴィークル業界の今後？

　正直まぁ今から新規でヴィークルメーカー立ち上げるのは
　あんまりオススメ出来ませんが

　ほんとに自分が欲しいヴィークルは自作するか作ってもらうしかありません

　んでもって地上ヴィークルのスクリプトは完全自作以外の方法がほぼありませんので
　そこだけは一応覚悟してもらう方向になるのかなと



ってなところかね

以上

マテリアル testビューワ

リリースされますた

結果としましては
快適に利用するためには
影モードONでアンビエントオクルージョンONにしないといけないので


最低ラインとしてGTX5xxシリーズのミッドレンジ以上のボードがおそらく必要です



とりあえずSSを載せときます

まず夕方

アンビエントオクルージョン　ON
左　リアビュー　右　フロントビュー

アンビエントオクルージョン　off

 左　リアビュー　右　フロントビュー

この通りアンビエントオクルージョンoffだと影の裏側が完全に潰れてしまうので
ONにしないとまともに表示されないかと


次　昼

アンビエントオクルージョン　off


アンビエントオクルージョンon
　　+ローカル光源

このへんからすると


法線マップをまともに動作可能にするためには
アンビエントオクルージョンは必須っぽいですな

ってなると快適に利用するのでしたら
最低でもGTX5xxシリーズ以降のミッドレンジが必要かと

9600GTでも一応表示自体は可能ですが
フレームレートが一桁台なので実質ムリポ


アンビエントオクルージョンoffでも補助光源を追加すれば
まともに表示されるようにはなりますが
まー重くなるのでトレードオフっすな


ちゅーわけで

現状だと

・ここ２世代くらいのミッドレンジ以上のボードが必要
・影モードをONにすることは必須


ってなところですな

以上

近況メモ

詳細書くとまずい部分適当にはぼかすので察してください


・3つの動作規格に合わせて　最終的に
　メインモジュールの定数だけ差し替えれば移植完了するスクリプト

・法線コントロールのために
　平面マップのリボンを組み上げてエッジを出すモデリング方式

・アニメヘッド＋ヘア＋furry系のボディー耳とアパレル規格について
　　(mod名称から勝手に命名　rikugou neko)
　

これのヘッドパーツ
　ヘッドパーツ用のヘア
　
　これのボディーとヘッドパーツの耳を使用
　　(タンクトップとショーツはmodで使うので捨てずに保持)
　ボディーと耳用のテクスチャキット(複数種有り　パーツにテクスチャはりつけ)
 　　(一応ヘアのカラーと合わせたほうがいいけどめんどいならどーでもおｋ)


　カーゴパンツはマケプレに無いので本店ベンダーから購入
　ジャケットもあるけどはえり周りがでかすぎるので
　調整しきれない前提で買うかどうか検討のこと

　全部そろえてmodをちょい追加で買うと3000l$前後かな

　ブルーギャラクシーのボディーキットと服は
　規格品で全ての服に差し替え用のテクスチャ(通称mod)があるので
　服のスタイル自体は変えられないが
　ベースの服さえ買ってしまえばバリエーションはそれなりにある

　デフォのブルーギャラクシー用シェイプだと
　furryのヘッドサイズに合わせてて明らかにごついので
　体格とヘッドのバランスは各自好みに合わせて調整のこと
　うちで調整した感じだと180センチ以下にしないと等身バランスがおかしい
　それ以上の慎重で等身のバランス取ろうとすると
　ヒーローショーの敵役みたいなゴツさになるので注意

　ちゃんと調整すりゃバイクとかもひととおり乗れる




ってなところかね
以上　

(メモ)Vプリカ

Vプリカについてわかりやすいサイト見つけたのでメモ

http://www.vpreca.com/



参考資料程度に

以上

(2013/08/05追記)
Vプリカでの公式サイトからの支払いは無理っぽい

サードパーティービューワのお話

まー前置きとしまして

特にこれといって理由がないなら
純正ビューワ使っとくのが一番マシです


一時期は純正のV3系より
１系サードパーティービューワの方が軽くて便利とか
そういう話が出てましたけど

ぶっちゃけ純正が重い環境だと
"サードパーティービューワの方が軽い”なんて
安易な理由でおすすめできるような状況じゃないです

まずインターフェースがまるっきり違いますし

ヘタするとグラフィック周りのバグで熱暴走して
物理的にぶっ壊れるとかあるし




とまぁここまでが前置き


んでビューワー選びの話になりますが
前提条件としまして
先日の”マテリアルが動作する最低スペックの話"のマシンスペックをクリアしてること
サードパーティービューワー一覧に載っていないビューワは除外とします


　V3系の純正が普通のコンテキストメニューでいまいちしっくりこないという方は
　NiransかFireStormが選択肢になります

　NiransViewer
　http://niranv-sl.blogspot.jp/

　2007年組にはあえて説明する必要もありませんな
　Kirstensビューワの正式な後続ビューワーです

　主な仕様

　　・64bitOSネイティブのバイナリ
　　　これの関係でWindows専用です
　　・中央の空白が大きい変形パイメニュー
　　・”既存のPCゲーム”に近いユーザーインターフェース
　　・シャドー周りのグラフィックが強化されている
　　　マテリアル対応できるマシンでも全部ONにすると地獄を見るレベルですので
　　　ほんとのハイエンドマシンをフルパワーで使いたいならおすすめかも

　FireStorm　Viewer
　http://www.firestormviewer.org/
　
　主な仕様
　　・Phoenixビューワーとほぼ同じインターフェース
　　　現状”昔ながらの”パイメニューが使える唯一のビューワです
　　　画面上の設定ウィンドーとかも大抵１系時代と同じ位置にあります
　　・スクリプト管理周りの強化
　　　パイメニューにスクリプトカウンタがついてます
　　・広域レーダー
　　　通常のレーダーより広範囲を見られるレーダーがついてます


現状パイメニューが使いたいローエンドの人はFireStorm
ハイスペマシンの本気を見たい人はNiransってところですかな

んでパイメニューが使えないけどそれなりに高機能なビューワーとしては
Exodosビューワーとなります

　ExodusViewer
　　http://exodusviewer.com/
　　
　主な仕様
　　・スクリプトエディタのカラーテーマが二種
　　・マウスルック時のクロスヘアが複数から選べる
　　・その他様々なUIカスタム機能

今のところメインストリームのサードパーティービューワはこの３つ
他のビューワーはどちらかというと”業界特化型”のが多いので

解説サイトとかでおすすめされてない限りはあえて入れる必要はあまりないかと






あとは参考までにうちの環境でのこの３つのビューワーについて

普段使ってるマシンのスペックはこんな感じ(viewerのHelpから引用)

CPU： Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3292.55 MHz)
メモリ： 8139 MB
OS バージョン： Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
グラフィックカード製造元： NVIDIA Corporation
グラフィックカード: GeForce 9600 GT/PCIe/SSE2

Windows グラフィックドライババージョン： 9.18.0013.1407
OpenGL バージョン： 3.3.0


・Nirans
　設定をかなり追い込まないと不安定で糞重くて落ちまくるという三重苦
　ただし一旦安定してしまえば影ON　描画距離256mで20fps前後で安定
　オブジェクトの編集ダイアロクの構成が先進的すぎて使いにくいｗ
　スペックに余裕のあるマシンで動画撮るならこいつ一択かねぇ

・FIrestorm
　影表示無しなら一番安定しててフレームレートも出るが(設定によっては45fps以上)
　スクリプトエディタのカラーリングが個人的に見づらくて仕方がないので　
　パイメニューと普段使い周りのUIが優秀でなかったら使ってないかも？
　イベント等で負荷監視任務につくときはこいつ安定やね

・Exodus
　グラフィック周りの挙動はFIrestormとあまり変わらず
　影モードoffにしてもfpsあんまり上がらない
　meshを右クリックしたときにクラッシュしやすい持病を抱えている
　スクリプトエディタのカラーテーマのダークが個人的に最強レベル


参考情報２

firestormのうちでの設定
とりあえずこれで20fps前後は出る

ってなところかね

以上

これからSL用にPC新調する場合の最低ライン

マシンスペック的な最低ラインのお話

これさえクリアしてれば
”とりあえずマテリアルONにすることは出来る”ってラインですので
快適にプレイ　ってなら自己判断でパーツをアップグレードしませう


まずCPUですが
ぶっちゃけi7までは必要無いです

かといってi3だと普通には問題ありませんが
動画エンコとか別作業しながらだとちょっときついです
なので　可能なら　i3の3240　あるいは3225　辺りが最低ラインかな
これ以下はやめときませう



んで、i3を選択する場合
ぶっちゃけ影とマテリアル要らないなら
このふたつのCPUならオンボで30fps出ます
3225はHD4000だからもーちょいマシかも？
(影onでは両方共10fps以下に下がります)


ただ一部ビューワのボタンが虹色になるバグ持ってるので
現行モデルでミッドレンジのボードを別で選びませう



んでグラボ

最低ラインはGTX650　640不可　安いからって240はもっと不可
650Tiはちょっとお高いけどチップが660と同じなので可能ならチョイスってところ

ただし上位GPUの660と670はでかいケースじゃないと入らない上に
電源容量も800Wクラス以上が無いとつらいです


ちゅわけで650と650TiからVRAM容量2G以上を目安に適当にピックアップ
予算とか宗教上の理由で選ぶがよろし










んで次　メモリとマザーボード
i7にする予定がない場合
B75系で好きなマザー選べばおｋ

鉄板はASUS　玄人さん向けはギガバイト
今回は最低ラインってことなのでMicroATXのお安いやつをチョイス
将来的にi5入れたりGTX660入れたりするならH77にしときませう


メモリはDDR3-1600(PC3-12800)を　最低でも8Gぶちこみましょう
予算が無いからって4Gを選ぶと泣きます
あとバルクは避けといた方がいいけど安いのを適当に　でおｋ
うちはこいつを3000円切ってる時に買いますた





次　ドライブと電源
前のマシンがPATAの人だと
HDDと光学ドライブは買い直しになるので注意
予算に余裕があるならSSDがいいけど
今回は最低ライン　のお話なのでなんでもおｋ

まぁコスパ的に2TB前後のSATAHDDがいいのかね

電源ですが

グラボぶちこむなら最低700Wで
最低ライン　はワット数クリアしてりゃとりあえずおｋ
ただ電源はぶっ壊れると怖いので
いいグラボにしたり巻き添え故障が怖い人は
80PLUS-SILVERを最低ライン

余裕がある人は80PLUS-GOLD認証のを選びませう




最後にケース
デュアルファンの長いグラボ使わない人ならどれでもあんまり変わらん

ただ旧マシンのケース流用する場合は干渉とかを入念にチェックしませう
・・・GTX670入れるのにケース買い換えた人知ってますのでｗ

ってなところかね

以上

スクリプト関係のビューワー改造メモ

現在V3系はスクリプトエディタの文字数制限がかかってます(65536文字)


で、
この制限って場合によってはかなり厄介で

コメント等をメンテナンス性向上のため満載していたり
インデントきっちりつけてる１系ビューワー時代のソースだと
文字数がオーバしてる場合が多いです

そういうソースをV3系ビューワーで開くと
まぁ下のほうが途切れて表示されるわけですが




絶対にその状態で

　編集したり

　外部エディターで開いたり

　外部エディターで開いても途切れてるのを確認した後にエディターを閉じたり

してはいけません

途切れた後のデータが消えます

（これでロストして泣いた人知ってます）

まぁこれ知らない人結構居るというか
そういう長さのソース書く人間って少ないからねー





んで、
これの解決策なんですが２つあります

・coolVL　Phoenix　Inprudence等の１系ビューワを使う
　この方法昔なら推奨してたんですが
　２系ビューワーが標準になってからSLはじめた人も結構いますので
　現状でわざわざ低機能な１系使わせるのはある意味拷問です

・Skinsのpanel_script_ed.xmlを改変してリミットを解除する
　多少リスクがありますが現状だとこの方法が一番確実ですな


後者のやり方を説明

XMLが開けるテキストエディタが入ってる前提で話を進めます
(メモ帳でもおｋ)

\ビューワーインストルフォルダ\skins\default\xui\en\ panel_script_ed.xml


これをデスクトップにコピーしてテキストエディタで開きます
で、

  max_length="65536"

この行を探してください
これを

  max_length="1048576"


これに変更します
これで文字数制限が16倍になります(4倍くらいでもいいですけど一応余裕を見ます)
んでこれをさっきのフォルダに上書きすればおｋ

これで途切れずに表示可能になるはずです

ね？簡単でしょ？


以上

バイクでのメインランドツーリングについて

さて

まーSLで一部のコアユーザーに人気のある趣味として

メインランドのバイクツーリングがあります

SS撮影のためのものがほとんどなので

ちょっと探せばこういうSSが色々出てきます

ただしまぁ実際のツーリングってかなりの高ハードルです

なにしろまずまともに走れるバイクがほぼ無い

”ツーリング”用として売られているバイクのほとんどが

加速が遅くて旋回ダルッダルで段差耐性がほぼなくて

しかも汎用スクリプトシステムのかなり旧いのを採用してるので

内包してるスクリプト量が下手な多機能HUDより多いとかザラ

そういうバイクだと

メインランドのような一分以内にSIMエッジを

四個や五個、下手すりゃ10個とか超えるような

超シビアコンディションでは

”どれだけ落ちずに走り続けられるか"というサバイバルレースになります

もちろんそんなもんを楽しめるのは一部のドMのみなので

軽くて見た目がそれなりの見た目のバイクを探すわけですが

"んなもんねーよ"

ってな本音言っちゃうと話が終わってしまうので

ある程度数値的に観測出来たり見た目にわかりやすい範囲で

バイク購入前のメインランドツーリング関係で

重要なチェックポイントをいくつか

・meshは特に理由がない限り避ける

　はいこれで現役でバイク作ってるメーカーの7割を敵に回しました(笑)

　実際のところはmeshの場合ランドインパクトで見る感じなんですけどね

　可能なら34以下　どれだけ多くても70以下のものにしませう

　それ以上になると総合で振り落とされたりロストするリスクが増えます

・KCP-ACS使用車種は9割9分9厘地雷

　これもほんとは言いたくないんですが

　実際問題としてあのスクリプトは現代ではレガシー過ぎます

　ただあれにも利点がありまして

　サイズとsittargetの調整機能が標準でついているので

　ポーズ固定タイプのチョッパーとかクルーザーだと

　大抵のアバターに対してフィッティングが取れてしまうのですよ

　あと加速とハンドリングをユーザーがある程度セッティング変えられる

　(変えられるだけで目的のセッティングが簡単に出せるって意味ではない)

・乗った状態での再物理化が可能かどうか

　メインランド走ってると進入禁止エリアに刺さることがよくあります

　んでそういう場合編集で安全な場所まで引っ張りだすわけですが

　刺さった時に大抵の場合物理がoffになってしまうわけです

　んでまぁ乗り直せば物理回復するんですよ

　・・・立ち上がった瞬間にオートリターンで消えますがねｗ

　なので乗った状態での再始動が可能かどうかは割と重要です

・試乗車がある場合は徹底的に試す

　試乗車で試すのはSIMエッジ耐性　というよりは

　まずまっすぐ走って縁石乗り越えて転落しにくいかどうか

　基本的に縁石はまっすぐ進入しないと越えられないくらいのセッティングがちょうどいいです

　ただしこれも別ファクターである程度許容可能で

　転落した場合のリカバリー機能があれば

　多少ハンドリングが悪くても大丈夫です

　(まぁこれがついてるとバカにするユーザーも多いですが飛行機能とかｗ)

　あとはメインランドの幅員(約12メートル)で安全にUターンが出来るかどうか

　結構これ無視されるんですけどかなり重要なんですよね

　ソロツー(単独でのツーリング)ならほぼ関係ないのですが

　複数人でいく場合　待ったり追いかけたり救助にいったりがよくあるので

　Uターンして迎えに行くとかができないと地味に不便です

バイク選びの基準は大体こんなもんかな

次に装備について

これはある意味ちょー簡単

服装全体での装着プリム数合計を1000以下を目安にする

服装全体でのスクリプト総数を10以下を目安にする

AOはoffではなく取り外す

ってな辺りを徹底すれば大抵の場合大丈夫

ってなところかな

以上

リンクナンバー管理のお話

ちょっと雑談で出てきたので適当に解説とまとめ


スクリプトでめんどくさいもんのいくつかの一つに

ボタンやエフェクト再生関係でのリンクナンバー管理があります


現代では
機能が必要なプリム全部にスクリプトを入れて
ｌMessageLinked();関数で通信させるなどという
リソースの異常占有はやたら嫌われていますね


なのでまぁllSetLinkPrimitiveParamsFast();
　などのリンクプリムに対する命令を使うことになるのですが

　リンクナンバーなんてもんは
　オブジェクトの保守管理中にしょっちゅー変わりますので

　特にスクリプトとオブジェクトの作者が違う時には
　"リンクを変えるな"を徹底することでそこの解決とする場合が多いです





ただし　どうせスクリプトを使うなら
　管理を自動にすることで解決出来るので
　これを利用しない手は有りません

　せいぜいリンクナンバーを覚えないといけないプリムが30以下程度の場合
　(メモリ容量的な話なので数値に根拠はありませんがｗ)
　覚えないといけないプリム全部に通しナンバーなりユニーク名をつけて

　それをスクリプト起動時にllGetLinkName();でクローリングして
　保持するという方法が使えます

HUDの場合もっと手抜きの方法があります
　llGetLinkName(lDetectedLinkNumber());を利用します

　もうお解りですね？
　ボタン全部に機能名つけてif文で分岐してやればええわけですｗ


アニメーション再生HUDならもっと手抜き実装が可能で
　リストのボタン名称を毎回全部書き換えてしまえば
　ボタンとのヒモ付が不要になるので
　かなりのメモリー節約になります
　(ボタンリストの書換が負荷になるので書換レートとかを工夫しませう)

ってなところかな

まとめ
”リンクナンバーは
　　プリム名とヒモ付して管理せよ”

以上

ノーマルプリムを使用した高架道路の工法について

さて

SL建築ににおいてめんどくさいもんナンバーワンに近いものして

道路の傾斜設計があります

馬鹿正直にプリムを斜めに回転させて配置してたら何年かかってもきっちり出ません

(自動計算で配置したところでテクスチャ汎用性で詰む)

　そこで道路の進行方向をZ軸にしたBOXを適当にパスカットして

　上部層　のパラメーターを使って傾斜を作る方法が割とメジャーです

　(ただし全体で整合性取ろうとすると事前計画と計算が必須なのは変わりませんが)

で、

　これを高架道路で実現しようとした場合

　転落防止の壁が必要になりますが

　これも同じ工法でやろうとすると

　必然的に中空開けた箱を重ねる工法になります

　その方式を下の画像に示します

　(黄色が路面プリム　緑と水色が壁プリム　グレー部分はパスカット前の元形状)

まぁ見りゃわかりますが

　プリム数優先の左の工法が大抵の場合最適解です

　歩道や一般コンバットフィールドレベルならこれですらオーバースペックで

　緑の部分にテクスチャをきっちり貼りつけた奴で十分です

２プリム構造にする場合は主に車両走行も想定する場合です

　まともな設計してあれば３０キロまでは割と大丈夫ですが

　70km/h程度の走行を想定するなら走行面を別プリムにすべきです

んで右側のやつですが

　この構造がガチで効いてくる速度域は120km/hオーバーです

　　(設計がまずい車体だと50km/h以下でも体感出来ますけどｗ)

　240キロでドリフト進入ミスった時の壁ヒットとかで被害が随分減ります

　だたし消費プリム数が1.5倍になるので　一般SIMではあんまりオススメ出来ませんが

　コリジョン性能の向上ってことだとやっておきたいプランですな

とまぁ

　フルSIMレベルのコース設計者ならある意味常識みたいなな内容ですが

　どうもあんまり広まってる気配がないのでメモ程度にまとめてみますた

以上

Rotation関係のお話

http://wiki.secondlife.com/wiki/Rotation/ja

オブジェクト連動のスクリプト組む人間はひととおり読んどけー

以上

SLのSIM負荷のお話 Ver.0.1

まぁ適当に箇条書き＋軽い解説
(細かいディテールは端折ったり言い換えたりしてるので
　ガチで知りたい人は実際にテストして確認してくだされ)



SLの要求スペック下限が地味に低い理由は
モデルデータ(meshを除く)のデータトラフィックが少ないのと
物理エンジン周りの演算を全部サーバーがやってるお陰ですが


車のホイールとかをサスペンション効かせつつちゃんと接地させるとか

ちゃんと銃口から弾を出すとかって話だと逆にこれがネックになります

　　普通のネトゲってその辺の物理演算をクライアントにある程度やらせて
　　サーバートラフィックと処理量を減らしてるのよね


けどSLの場合そこをリアルタイムでサーバーでやらすので
負荷対策かクライアントでの描画情報は一切サーバーに行きません
(チャット　キー入力　カメラの位置と回転　のみです)



なので複数アニメ再生してる状態での装着オブジェクトのSIM上の座標や回転は

当然のことながら取得出来ません



llGetAnimationとかはありますが
あれもサーバーからクライアントに送信している
”アニメーションデータのUUID”のみを観測する仕様です


なのでアニメーション自体の回転情報とかはSIMでは見ていません

なのでSIMでの物理演算が　”あの重さ”で済んでいるとも言う





んでまぁ



ここ最近スクリプトと物理を軽くすれば

たとえ50人以上集まってもSIM負荷は上昇しない

って定説が覆りつつあるというか


そこ軽くしても相変わらず重いSIMは瞬発的に重い時が出るってのが出て来まして
その次に注目されたのがアバターのトラフィック負荷なわけです


ちょー簡単に説明するなら

アバターがTPしてくると
SIMにいる人数*2のトラフィックが発生します

(TPしてきたアバターをSIMに居るアバター全員が読み込みリクエスト
　＋TPしてきたアバターがSIMに居るアバター全員読み込むリクエスト)

これもまぁ情報自体は4年前くらいに出てたんですが
ぶっちゃけ定量的に数値で計測する仕組み(アバターレンダリングコスト等)が
"数値"で指定しようとするとギリギリ設定にする人間が多くなり

ビュワーサイドでロード中も表示されるために途中でロードこけたり
ビューワバージョン違うと数値が変わったりで全く当てにならず
挙句の果てにオカルトチューン呼ばわりされる始末



とまぁそんな感じで
SLのSIMシステムは単純に
ネトゲのサーバーやwebサーバーと比較できるようなシロモノではなく
内部がやたら複雑怪奇なわけです

以上

実用スクリプトのお話(α版)

今回の内容はソースコードとか一切ありませんｗ

前置きとしてぶっちゃけてしまいますが
下手なリファレンス本買うよりwiki見たほうが情報量が多いです
んでもって更にナマの情報ってことなら
inworldでフルパーのスクリプト集める感じになります




ただそれにしても
インフラとして確立してるOSS(オープンソース・ソフトウェア)系のもの以外は
即商業製品や配布可能レベルになるようなもんはほぼありません

wikiに乗ってるコードですら
　機能不足等の理由からそのまま転用ってのは無理です

(なにせ売ることが出来るのでその辺の取り扱いはかなり厳しい)



SLで商業利用価値が高いスクリプトはいくつかありますが
そういうものは非公開になってしまっているものが多いです

ライセンス規定(配布はcopyのみ)付きでフルパー販売した場合に
　購入者のミスでフルパーで流出した場合
　回収する手段がありませんので
　それが高価値なものほどばらまかられた場合の被害が大きくなります



・物理乗り物のスクリプト

　例外は航空機の基本スクリプトくらいで
　売り物として成立するレベルのものは
　現状では一切表に出ていません　断言します

　KCP-ACS(メジャーなバイクスクリプト)ですら
　スクリプト負荷の問題がクローズアップされている現代では
　重すぎてお話になりません
　(かといって他の選択肢が無いので未だに採用メイカー多し)

　DTCARは流出事件後にフリービーのような扱いを受けてしまい
　開発停止してしまっているので現代ではまともに走らないです
　(マケプレで500L$以下で売ってるヴィークルはほぼ全部こいつ
　　EMHとProStreetは数少ない正規版を使ってるメーカーですが
　　DTCAR本体のアップデートが行われていないため出遅れ気味)


　俗にアーロン系と呼ばれているスクリプトもありますが
　音とかアニメとかエフェクト再生周りがあまりにもプアで
　使いこなせるようになる前に季節が一巡してしまいます
　(日本人の車屋で自前スクリプトのところは大抵こいつベース)

　Astaroというメーカーが制作しているスクリプトが
　複数メーカーの車両にOEM供給で組み込まれるようになって
　比較的まともなスクリプトということで一定量の評価を得ていますが
　非公開なので入手は無理かと



・武器スクリプト
　SLではコンバットSIM(現実でのサバゲとかペイントボールみたいなもんです)
　が一定数の人気を持っており
　そこで使える武器を作るためのスクリプトにはある程度の商業価値があります

　ただし実質フリービー扱いの武器スクリプトも結構ありまして
　そういうのベースで外装がしょぼい銃は売ってても相手にされません
　(外装が良くても内部がしょぼいと不正コピー品の疑いをかけられますし)

　要求される外装レベルは最低でも１００均の水鉄砲程度には
　外装再現が行われている必要があります
　(実際のところそれ以下のもんが大量にあるというお話)

　発射レートや銃口初速にも　まともなフィールドはかなり厳しい制限があり
　現実ではユーザースキルである程度はやくなるリロードに関しても
　ゲーム進行上の”隙”を作る目的からある程度の制限が行われています


　んでCS(コンバットシステム　ダメージ判定を行うための仕組み)
　には所謂API式とLLCS式というのがありまして

　LLCS式ってのはダメージエリアのことです
　API式はユーザー作成のスクリプトでやってるやつです


　LLCS式は基本部分がいくつかフルパー公開されているので
　タマが出るところまでは比較的簡単に到達出来るはずです

　しかし既存ガンメーカーが実現出来ているレベル
　(秒間８発以上　エフェクト連動で低負荷　スリング状態の実装)
　をやるには知識とスキルが必要です


　API式のCSは銃やタマによってダメージの通り方が違います
　強力な銃やタマほど通るダメージも大きいです
　しかし強力なタマの入手が新人にはほぼ不可能です
　(組み込み済みの銃を買うのには特に制限なし)

　API式のCSに対してLLCS銃のダメージは大抵の場合通りますが
　(VICEなどの例外は有り)
　通ったとしてもタマの威力は最低の判定をうけます
　かといって無許可でAPI弾製造するとペナルティーがでかいです


・クラブ関係のシステム
　正攻法ならここに手をだすのが一番楽かもしれません
　照明　クラブ内のモニター類　ダンスコントロールなどは
　小規模ならフリービースクリプトからの改変でどうにかなります

　ただし大人数集めるイベントで使うってなると話は別で
　負荷コントロールやロード負荷
　低SIMFPS環境下での動作確実性などが求められるので
　一気にハードルが高くなります


・所謂エロ方向
　なんだかんだでエロやってる人が短期的には一番カネ払いがいいです
　ただ普通のところでエロをやっていると公言すると
　ドン引きされやすい諸刃の剣なので
　よほどの覚悟がないとオススメ出来ません


ってなところかな

基礎からの勉強ってことだと
　VICEのデフォルト飛行機とか
　フリービーで出回ってるしょっぼい銃とかを
　改造して勉強するのが　
　なんだかんだではやいんじゃないかなぁ
　無料で手に入って中身それなりに単純だし

　(販売レベルに出来ない理由となってる
　　各種トラップも入ってるけど見つけるの簡単だし)


いきなり大規模なもん作ろうとすると確実にコケます
(ほんとのチャレンジャー向けですが
　VRCっちゅーOSSの鉄道スクリプトがあります
　あまりにソースが汚い上にスパゲッティーなので
　ゼロベースで作りなおしたほうがはやいと言われてるレベル)


身内数人だけの場所やsandboxのみで使う程度なら
ほぼ問題にならないような部分が
シビアに影響してくるのが実用スクリプトです

販売や配布目的でスクリプト入のものを作る場合
そこを十二分に考慮しませう

以上

SecondLifeの課金手段等について(20150825追記)

まーあえてこの書き方したほうがわかりやすいでしょう

SLには課金が必要なものが5つあります

・土地(サーバー上の区画)の維持費
　プレミアムアカウントなら512sqmまで無料です
　(ちなみに１SIMのサイズは65536sqm)

・SIM(サーバーまるまる一個)維持費と購入
　今のレートだと月額3万ちょいって辺りかな
　サーキットやゲームフィールドの運営をしない限りはほぼ不要です

・L$の購入
　(レートは1US$=240L$で多少前後する)

・プレミアムアカウントの料金
　(年間は確か72$だったっけかな)

・マーケットプレイスでのUS$決済
　(paypal決済のみだったかも？)

この5つが課金対象です

んでまぁ日本国内から課金の支払いに使えるのは

・VISA,Master,American Express の各クレジットカード
　(JCBも一応使えるらしいがエラー起こすことが多い)

・paypal
　登録に郵便での個人認証が必須になったので時間に余裕をもって登録しませう

・一部のVISAデビッドカート
　楽天銀行のカードは確認済み

あとは最近だとこいつが増えました

・Vプリカ
　コンビニ決済で作れてプリペイドなので
　VISAデビッドですら心配だという人におすすめ
　ただしL$購入とプレ垢の支払い以外には使わないほうが色々と楽かも

ごめんVプリカでのL$購入
paypal経由とかもやってみたけど公式サイトでは無理だったわ　(20130624追記)


一時期使えてたけどまたダメになったなVプリカ(20150825追記)



プレ垢一年分（72$）+ 初期装備を揃えるのに 30$(約7000L$)ほどL$を買っておけば
inworldでの買い物や活動にほぼ困らないでしょう
いきなりOmega(SL内のリアル系FPS)のフルセット揃えたりとかしない限りは余裕っすな

以上


※補足情報
なぜいきなりプレ垢取ることを勧めるかと言いますと
支払い情報とL$を持ってたほうがスムーズに事がはこぶ場合が多いのです
(最近は支払情報や年齢認証必須のエリアが結構多くなりましたので)

テスト投稿

てすてす