llGet/Set/ResetAnimationOverrideっす

G+でいろいろ書いてたりするっす。
ここで宣伝してもフォロワーが増えるわけじゃないっすけどね。
どうもぺんぎんっす( ◎v◎)


3月の終わりに新関数の情報が入ったっす。
メイングリッドへの適用はまだされてないみたいっすね。
13日、いつもの会で試した時はコンパイルが通らなかったっす。

まずはLSL Portalの新関数ページへのリンクを貼っておくっす。
翻訳作業はメイングリッドへ適用されてからやるっす。
llGetAnimationOverride
http://wiki.secondlife.com/wiki/LlGetAnimationOverride
llSetAnimationOverride
http://wiki.secondlife.com/wiki/LlSetAnimationOverride
llResetAnimationOverride
http://wiki.secondlife.com/wiki/LlResetAnimationOverride

関数名からだいたい想像できるっすね。
アニメーション・オーバーライドの関数っす。
組み込み関数になることで簡単に作れるようになるっす。
こういうタイプの新関数は「お手軽関数」と自分では呼んでるっす。
いや、別に流行らせなくても良いっすよ。

これまでのアニメーション・オーバーライドの作り方は、
llGetAgentInfoでアバターの状態を取得して、そこから
指定しておいたアニメーションをllStartAnimationさせてたっす。
短い間隔のタイマーでぐるぐる回すのが一般的っすかね。
でも、新関数を使えばタイマーで回す必要が無くなるっす。
各状態で実行するアニメーションを上書きしちゃうっすからね。

他のヒトと同じモノを作っても面白くないっすよね。
個性をアピールしたいなら、入力周りで差を付けると良いっす。
どの状態のときに、どのアニメーションを実行させるか、
事前に決めておく必要があるのは従来通りっす。
自分ならHUDにMOAPでフォームを作らせるっすかね。
URIリソースを1つ消費するっすけど、アバター割り当てのを
使うので、枯渇する心配は必要無いんじゃないかと思うっす。


リログすると再指定する必要があるのが注意点っすかね。
on_rezイベントでリログを感知してやれば問題無いっす。

ピン設定よりうっかりしやすいっすよね

PrimToTextは近いうちに出せると思うっす。
全ての形状はサポート出来てないんっすけどね。
どうもぺんぎんっす( ◎v◎ )


完全じゃないので、後でスクリプトを入れ替える必要があるっす。
今回はリモートアクセスを採用することにしたっす。

ピンの設定よりも忘れやすいのが権限のチェックっす。
スクリプトにコピー権限を付け忘れるんっすよね。
自分だけかもしれないっすけど。

そこで、事故防止のために確認ステップを入れておいたっす。
llGetInventoryPermMaskを使うわけっすね。
オブジェクトの方は確認いらないっすよ。


リモートアクセス周りはたぶん大丈夫だと思うんっすけど、
念には念を入れてテストするっす。

もうひとつのZERO_ROTATIONっす

今週のいつもの会は「ドア」がテーマっす。
気が向いたらソースを載せるっすね。
どうもぺんぎんっす( ◎v◎ )


回転軸が任意で回転角が0のrotationはZERO_ROTATIONっす。
でも、回転角が2πの場合はZERO_ROTATIONじゃないっす。

ZERO_ROTATIONっていうのは＜0.0, 0.0, 0.0, 1.0＞っす。
回転角は実部だけ見ればいいので、1.0に注目っす。
回転角をθとすると、cos(θ/2)が1.0なので
θは4nπになるっす。
2πの場合は違うことが分かるっすね。

回転角が2πのとき、実部はcos(2π/2)で-1っす。
ノルムが1っすから、虚部は全部ゼロっす。
つまり＜0.0, 0.0, 0.0, -1.0＞っす。

くるっと1回転したら違う姿勢になると大事件っすから、
同じ事だということを示さないといけないっす。
「逆の逆で元に戻る」とやるのが簡単っすかね。

あるrotation、rの逆回転qを求めるっす。
2通りあるっすね。
　・回転角の符号をひっくり返す
　・回転軸を原点を対称にしてひっくり返す
まず、回転角の符号をひっくり返して
　＜r.x, r.y, r.z, -r.s＞

これの回転軸をひっくり返して

　＜-r.x, -r.y, -r.z, -r.s＞

逆の逆で元に戻ったので、元のrと同じになるっす。

符号を全部入れ替えたら同じになるっすから、、

＜0.0, 0.0, 0.0, 1.0＞と＜0.0, 0.0, 0.0, -1.0＞も同じっす。

ま、どうでもいい知識っすね。

3364バイトっす

ブログは久しぶりになるっすね。
他のところでいろいろ書いてたっす。
これまで通り、何か作ってるっすよ。
どうもぺんぎんっす( ◎v◎ )


誰も来ない「いつもの会」っすけど、活動はしてるっす。
今日はllGetSPMaxMemoryとかllGetUsedMemoryをいじったっす。
メモリ消費量を取得する関数っすね。

予想はしてたっすけど、きっちりした値を返すわけではないっす。
ほとんどは12バイト刻みの値を返してくるっす。
急に飛んだりして一律12バイト刻みではなかったっすね。
他にもいろいろ検証してみたっす。

一番簡単なコードを書いておくっす。

default
{
    state_entry()
    {
        llOwnerSay((string)llGetUsedMemory());
    }
}

やってもらえば分かるっすけど3364って出るっす。
ここから最小のスクリプトにおけるメモリ消費量を出すっす。
default stateにイベント1個が最小っすよ。

やり方は上のスクリプトが3364を返してきてるので、
　llOwnerSay((string)llGetUsedMemory());
の分を引いてやるっす。
　llOwnerSay((string)llGetUsedMemory());
　llOwnerSay((string)llGetUsedMemory());
っていう風に何個か重ねて、3364との差を見て行くっす。
OwnerSayで出てきた値は全部出しておくっすね。

1個: 3364
2個: 3364, 3364
3個: 3364, 3364, 3388
4個: 3364, 3364, 3388, 3388
5個: 3876, 3876, 3900, 3900, 3900

6-10個: 3876, 3876, 3900, 3900, …
20個: 4900, 4900, 4924, 4924, …


意味ありげに512バイトすっ飛んでたりするので、
この方法だと全然分からないっす。
4つで24バイト増えたから6バイト!ってやるのは危ないっす。
とりあえず、今日の結論っす。
最小のスクリプトは3364バイトくらいなんじゃないっすかね?

4:2:4のイメージっす

ポリゴン数が多すぎる場合にはCOLLADAが良いかもしれないっす。
不要な部分を取り除くために一旦、HTMLで出してるんっすけど、
XML形式になってるので、コメントアウトが使えるんっすよね。
ちょっと考えてみるっす。
どうもぺんぎんっす( ◎v◎ )


設計:実装:テストにかかる時間の比率が4:2:4になってたっす。
ちょっと作って動かす、ちょっと作って動かす…とやってるので、
4:4:2くらいの感覚なんっすけどね。
自分が「とりあえず完成」って言ってる場合には、
全体の8割くらいが出来た状態と思ってくださいっす。

もうちょっと細分化すると、
大雑把にどんなものを作るのかを決めるのに全体の10%、
機能面とかを煮詰めるのに全体の15%、
外側をどうするのかに5%、
どう作っていくのかの作戦を決めるのに10%、
これで40%っす。
設計が終わったら実装にかかるっす。これが全体の20%っす。
残りはテストっす。
ちょっと作ったら動かしてみるのに15%、
部品をくっつけて動かしてみるのに5%、
全体を通しで動かしてみて、評価するのに20%っす。


SLの世界だと設計ナシでいきなり書き始める人も多いと思うので
まったく参考にならない数字だとは思うんっすけどね。

時間当たりのテキスト出力量っす

llGetMassMKSっていう関数が来てたっす。
体積に比重を掛けた値を返すっす。
物理周りはそろそろやらないとっす。
どうもぺんぎんっす( ◎v◎ )


SimToTextでは1回のOwnerSayは100バイト程度のテキストで、
Sleepなしで一気に必要ポリゴン数分出してるっす。
このことがパケットロスを引き起こしちゃうっす。

Sleepを0.1秒ずつかけて毎秒1KB程度の出力にしたところ、
影響が感じられなくなったっす。
ギリギリを攻めるのか、それとも余裕を持たせるのか、
悩ましいところではあるっす。
良い感じのところを探らないといけないっすね。


毎秒10ポリゴン分の出力になるので、13万ポリゴンでは3時間半。
出力し終わると変な達成感があるかもっす。

SimToTextの利用制限っす

自分は制作じゃなくて製作してるっす。
クリエーターじゃなくてメーカーっすね。
何か作ってることには変わりないんっすけどね。
どうもぺんぎんっす( ◎v◎ )


SimToTextはSIM形状データの二次的著作物にあたるっす。
じゃあ、原著作者は誰？となるんっすけど、場合によるっす。
SIMオーナーかもしれないし、土地の所有者かもしれないっす。
土地がグループでの所有の場合もあるっすね。
とにかく権利関係がややこしいことになってるっす。

誰が作ったか分からないので、スクリプトから
チェックして弾くことができないっす。
せいぜい許諾を取ることを促すメッセージを流すくらいっす。
でも、これじゃあ対策として不十分っすよね。

llGetParcelDetailsのPARCEL_DETAIL_OWNERフラグで
返ってくるkeyと一致しないと使えないとやってしまうと、
ほとんどの人が使えない状況になるっす。
正式に許諾を得たのに使えないということになっちゃうっすね。


今のところは
・他の住人に許諾を取ることを促すメッセージを出す
・出力したデータを利用できる範囲を制限する
という対応にしようと考えてるっす。
イマイチなんっすけどね。

SimToTextのGUIっす

SIMの地形データをテキストとして出力するやつっす。
PrimToTextと併せて「Toシリーズ」っす。
「Forシリーズ」も今後作って行くんっすけどね。
どうもぺんぎんっす( ◎v◎ )


操作周りは全然作ってないっす。
SimToTextの詳細度は0から5の6段階なので、
全部パイメニューにしちゃうのはダサいと感じるわけっす。
収まるんっすけど、しっくり来ないっす。

最有力はパイメニューの隣に0から5の数字を描いたボタンを
設置する併用型っす。
プリム数は多くなるっすけど、一度に2つを見て、操作できるっす。
↑↓ボタンの方法は表示のさせ方に凝らないといけないので、
今回は採用しないっす。
モノによってはプリム数のメリットが無くなっちゃうっすからね。


オブジェクトの色・カタチも考えないとっすね。

SIM画像のURLっす

13万ポリゴンのSIM地形は近いうちにやってみるっす。
コピペは何回かに分けないといけないかもしれないっすね。
どうもぺんぎんっす( ◎v◎ )


SIMの画像はSIMの座標が分かっていれば取れるっす。
世界地図を眺めていても分からないかもしれないっすけどね。
Map APIのページにもサンプルスクリプトが載ってるんっすけど、
使いやすくURLを返す関数にしてみたっす。

string GetSimImageURL()
{
    string url = "http://map.secondlife.com/";
    vector pos = llGetRegionCorner();
    string x = (string)((integer)(pos.x / 256.0));
    string y = (string)((integer)(pos.y / 256.0));
    url += "map-1-" + x + "-" + y + "-objects.jpg";
    return url;
}

あとはSayさせるなりしてくださいっす。


SL自体の規約は読んだと思うっすけど、
APIのToSまで読んでる人は少ないんじゃないかと思うっす。
URLを貼り付けておくので、見ておくと良いっすよ。
http://wiki.secondlife.com/wiki/Linden_Lab_Official:API_Terms_of_Use

SIM画像の取得っす

いろいろあって、久しぶりの投稿っす。
ネタが無くなったわけじゃないんっすよ。
どうもぺんぎんっす( ◎v◎ )


SIMの形状(起伏だけっすけどね)を出力されてみたっす。
となると、テクスチャも貼り付けたくなるっすよね。
wikiの方で調べてみると、Map APIが用意されてたっす。
http://wiki.secondlife.com/wiki/Linden_Lab_Official:Map_API_Introduction

画像だけが欲しいので、単に画像のURLにアクセスすれば良いっす。
ご丁寧にLSLから取得するものも書いてくれてるっす。
まぁ、stringをreturnしたほうが使いやすいっすけどね。


PrimToTextもSimToTextも作らないといけないっす。
これからもかなり忙しくなるっすね。

256プリムからのlistenっす(3)

形状データのテキストサイズ削減はうまくいきそうっす。
200バイト程度まで減らせそうで、目標はクリアっす。
これも後で書くっすね。
どうもぺんぎんっす( ◎v◎ )


そもそも論として、256のsayはlistenできないっす。
待ち行列には64個までしか入らないという制約のためっす。
too muchなんたらーっていうエラーを吐いて、
溢れたsayは捨てられることになるっす。

でも256プリムからのsayを受けたいわけっす。
256プリムをリンクして1オブジェクトになっていると仮定して、
リンク番号×0.05秒ずつsayしているのが今の方法っす。
これはダメっすよね。
逆のパターン、1プリムオブジェクトが256個あった場合、
全然機能しなくなるっす。

プリムのkeyを種とするハッシュ関数を作って、
ハッシュ値からsayするタイミングを決定させるっていうのが
より確実そうなので、ちょっと組んでみるっす。



やることがたくさんあるので、計算部分が順調に遅れてるっす…

256プリムからのlistenっす(2)

LSLCONに出す作品群の調整をしてるっす。
PrimToTextはテキストとしてSayさせられないので、
ノートカードに出力結果をコピペして配布するっす。
大量のチャットログが流れるっすからね。
どうもぺんぎんっす( ◎v◎ )


今回は文字列の処理っす。
プリムの形状データをコンパクトにして送りたいわけっす。

圧縮・解凍じゃなくて、不要な部分を取り除いただけっす。
300バイトを250バイト以下に持っていければ書くっすけどね。
考えてるアルゴリズムはあるんっすけど、
圧縮率がどうなるか計算してみないと分からないっす。

「不要な部分」というのは小数点以下の末尾0と、
半角スペースの2種類っす。
vectorやrotationの中にも半角スペースがあったりと、
この2種類を除去するだけで10バイト単位でごっそり減るっす。
これでもまだダメなんっすけどね・・・


ヒープ枯渇でスクリプトが死んじゃったら、
通常のエラーメッセージの他に、何かもう一言、
出力しようと思うっす。

256プリムからのlistenっす(1)

PrimToTextの進行もそろそろ書かないとっすね。
もう12月っすか…
どうもぺんぎんっす( ◎v◎ )


計算もやらないといけないっすけど、
まずはSay/listenの部分を強化したっす。
送信テキストと、データの格納部分をパワーアップしたっす。

256プリムは余裕じゃないかと思われる方もいると思うっす。
でも考えてみると64KBしか使えないわけっすから、
1プリムあたり256Bytes未満にしないといけないんっすよね。

形状データはllGetPrimitiveParamsの値をCSVで送ってるっす。
つまりはテキスト(string型)なんっすよね。
なので、文字数+αがそのまま消費メモリ量になるっす。

考えるべきは一番文字数が多くなるときっす。
これはトーラス、チューブ、リングのとき最も多くなるっす。
integer 2
float 4
vector 8
rotation 1
これだけ入ってるっす。
floatは小数部が必ず6桁表示されることを考えると、
1(整数部)+1(小数点)+6(小数部)の8文字が最低でもあるっす。
vectorはfloatが3つと、"<"・">"それと内部区切りの", "があるので
30文字が少なくともあるっす。
もうすでに256文字はオーバーしちゃってるっすね。
このままじゃダメなわけっす。

で、やったのが
・送信テキストの無駄を省く
・できるだけ多く格納できるようなスクリプトを1本作る


具体的な話は長くなりそうなので明日にするっす

さくさくと新関数6つを見るっす

いつの間にか増えてた新関数の話っす。
まだメイングリッドに来てないのもあるので注意っす。
そこら辺はLSL Portalを見てくださいっす。
どうもぺんぎんっす( ◎v◎ )


6つあるので、ざざーっと見て行くっす。

http://wiki.secondlife.com/wiki/LlSetContentType
llSetContentTypeはhttp_requestイベントで受け取るメディアタイプを
text/plainとtext/htmlから選択できるようにするっす。
これ、使いようによっては革命が起きるんじゃないっすか？

http://wiki.secondlife.com/wiki/LlSetVelocity
http://wiki.secondlife.com/wiki/LlSetAngularVelocity
llSetVelocity/llSetAngularVelocityは物理オブジェクトに
等速直線運動/等加速度運動をさせるっす。
動き始めはllSetForceで、ある程度まで加速したらllSetVelocityで
等速に切り替えるとそれっぽい動きができるかもっす。

http://wiki.secondlife.com/wiki/LlSetKeyframedMotion
llSetKeyframedMotionは非物理オブジェクトの動きを
まとめて記述できるっす。この関数は昨日も書いたっすね。
llSetLinkPrimitiveParamsFastを何回も呼び出さなくても済むっす。
ただ、動きについてだけなので、色が変わったり、
形状が変わる場合には使えないっすね。

http://wiki.secondlife.com/wiki/LlSetMemoryLimit
llSetMemoryLimitは使用するメモリ量に自ら制限をかけられるっす。
なんというか「競技向き」っすよね。
通常は使う必要が無いんっすけど、アスリートだけが使う感じっす。
設定した制限値を超えたらDEBUG_CHUNNELでShoutされちゃうんっすかね？

http://wiki.secondlife.com/wiki/LlManageEstateAccess
llManageEstateAccessは土地へのアクセス権限をいじれるっす。
ライブイベントなんかだと、外からは見えるけど聞こえない、
聞きたければ「入場料」を払え！みたいなことが……。
Payが扱いやすくなったっすからね。


自分の中で注目度が高い順番に並べたっす。
とは言え、使い方次第っすけどね。
ちなみに、今年追加された関数の中では、
llRegionSayToが一番の衝撃だったっす。
皆さんはどうっすかね？

llSetKeyframedMotionっす

テンプレートをいじったので、次回からフォントが違うっす。

ちょっとは見やすくなるんじゃないっすかね?

どうもぺんぎんっす( ◎v◎ )

しばらくブログを書かないうちに、新関数がいくつか追加されたっす。

明日まとめて書くっすね。

今回はその新関数の1つ、llSetKeyFramedMotionの話っす。

llSetKeyFramedMotionについてはLSL Portalをどうぞっす。

http://wiki.secondlife.com/wiki/LlSetKeyframedMotion

非物理オブジェクトの動きをまとめて記述できる関数っす。

llSetLinkPrimitiveParamsFastを何回も呼び出さなくて済むっす。

色とかカタチが変わる場合には使えないっすけどね。

動きをループさせたりするオプションも付いてるっすよ。

この関数のwikiを見て、なるほどと思ったのが、

[座標]・[姿勢]・[秒数]の3つで「動き」というものが表現されるという点っす。

当たり前と言えば当たり前なんっすけどね。

一般的な動きの表現方法は、1コマあたりの再生時間を決めておいて、

そのコマでの座標・姿勢を記述していく方法っす。

1秒あたり何コマっていう「FPS(フレーム・パー・セカンド)」というのは

聞いたことないっすかね?

この方法だと、止まっているときは同じ数値が繰り返し出てきたり、

再生時間に対してデータ量が比例して増加したりと、ムダがあるっす。

[座標]・[姿勢]・[秒数]の3つで書く表現方法だと、中間の状態は

計算してやらないと出ないという問題があるっすけどね。

時間とメモリのトレードオフの関係にあるわけっす。

SLはメモリの制約が厳しいので、時間を犠牲にメモリの得を取った方が

良いケースが多いっす。

llSetKeyframedMotion以外に使える記述方法かもしれないので、

覚えておくと良いかもっすね。

d/dt が一定なのか変化するのか、っていうイメージっす。

HUD型汎用リモコンっす

PrimToTextは来週あたりに機能限定版を出すっす。

UIをもうちょっといじるっす。

どうもぺんぎんっす( ◎v◎ )

LSLCON向けのネタっす。

アイデアだけ先に出しちゃうっす。

作る時間があるか微妙なもんっすからね。

入力用HUDを付け替えるのが面倒なんっすよね。

なので、全部1つにまとめられないかと思ったわけっす。

HUDとオブジェクトに必要な機能はそれぞれ2つっす。

HUD

　1.送信に使うチャンネルを設定する。

　2.アバターが入力した情報を送信する。

オブジェクト

　1.受信に使うチャンネルを指定する

　2.HUDからメッセージを受け取る

簡単な話、「チャンネル」と「メッセージ」を取り決めれば良いっす。

チャンネルに関してはHUDに入力機能を持たせれば良いだけなので、

問題になるのはメッセージの方っすかね。

ざっと並べてみると

　・数値(0-9、小数点、+/-)

　・方向(8方向+真ん中)

　・Yes/No

　・Prev/Next

最低限これだけあれば良いんっすかね。

あとはこれを規格化すれば良いっす。

メッセージを受けるlistenイベントを作っておけば使い回せるっす。

オブジェクトを作る側にもメリットはあるっすね。

流行ってくれないとダメなんっすけどね。

llCastRayのページが更新されてたっす

PrimToTextの効果音を作ってたっす。

あっても無くても、さほど変わらないんっすけどね。

要望があったので、一応作ったっす。

どうもぺんぎんっす( ◎v◎ )

http://wiki.secondlife.com/wiki/LlCastRay

このページっす。

日本語のページはまだできてないっすね。

始点と終点を指定して、その間に引っかかったモノを返すっす。

イメージは「赤外線センサー」っすかね。

スパイものでお馴染みのやつっす。

この関数はより強力で、貫通するっす。

しかも、「誰が」「どこで」引っかかったのかまでも分かっちゃうっす。

llSensorとの大きな違いは、結果がlistとして返ってくるところっす。

イベント間を行き来しないので、組み立てしやすくなるかもっす。

あと、最大で256個まで引っかけれるのも大きいっすね。

sensorイベントに上がって来る最大数より、ずっと多いっす。

接触のcollision、投げ網のsensor、そして赤外線のllCastRay。

お店にある自動ドアに変化が出てくるっすかね？

ボックス大工事開始っす

大きな山場を迎えたっす。

ここを乗り切れば、他のは問題無くできるはずっす。

正念場っすね。

どうもぺんぎんっす( ◎v◎ )

ボックスのパスカットを作ってたところ、テキストが64KBになったっす。

1,450行くらいあるっすから、そろそろとは思ってたんっすけどね。

このままでは書き足せない状態なので、大工事を行うっす。

まずは関数化っす。

四角形ABCDの頂点はfor文の中で計算してるので、

A = f(i, j)

B = f(i, j+1)

C = f(i+1, j+1)

D = f(i+1, j)

と表す事が出来て、関数fを作ってやればテキスト量を減らせるっす。

ただ、プリムのサイズや姿勢の情報もfに持って行かないといけないっす。

引数として渡しても良いんっすけど、A・B・C・Dの4つで同じことを

書くことになっちゃうっす。

ここはプリムの形状データをグローバル変数に格納しておくことにするっす。

関数fからグローバル変数を参照してもらうっす。

この作戦でテキスト量が3割くらい減ると見てるっす。

そのために加筆・修正・削除しないといけないのは全体の6割っす。

軽いハックで済めば良いんっすけど、これ以上は犠牲も大きいっすね。

ボックスの完成が近いっす

この週末でケリを付けるっす。

ここからスピードアップしてやるっす。

どうもぺんぎんっす( ◎v◎ )

ボックスの中空で残っていた「三角形」が書けたっす。

あとはパスカットでボックスは完成っす。

次は球を作る予定っす。

ボックスと球は使用頻度が高いと思うので、かなり便利になるはずっす。

あ、あと、rotationの講座を準備し始めたっす。

算数をできるだけ使わないようにはしたいっすね。

具体的には「軸」と「回転角」にフォーカスするっす。

vectorとは違う、行列の感じも伝えられたらと考えてるっす。

いつやるか、どこでやるかは全くの未定っす。

準備だけ始めたというところっす。

期待せずに待ってると良いっすよ。

0.25 alpha → 0.30 alphaの更新

・ボックス　1,382行(0.25 alphaは931行 +451行)

コンフィグメニュー追加っす

外側はこれでほぼ出来上がったっす。

あとは内側、算数の部分っす。

メモリは足りるみたいっす。

どうもぺんぎんっす( ◎v◎ )

設定を変更できるようになったっす。

変更できるのは「出力形式」「詳細度」「出力スピード」「レイヤー」

の4点っす。

出力スピードはスリープを使って調整してるっす。

チャットの順番が前後したり、飛んだりしないようにもできたり

するんじゃないっすかね？たぶん・・・

コンフィグもパイメニューっす。

現在の設定値を示すために、半透明なプリムを使ってるっす。

設定を変えるたびにプリムが動くっす。

OwnerSayでも出るので不要だったかもしれないっすけど、

第三者から見て分かるようにしたかったもんっすから、

プリムによる表示も付けたっす。

というわけで、算数がんばるっす。

現在の行数

・リング　377行

・スフィア　272行

・シリンダー　323行

・プリズム　461行

・トーラス　304行

・チューブ　525行

・ボックス　931行

・メインの制御スクリプト　1,216行

・サブの制御スクリプト　32行

・設定の保存と再起動スクリプト　149行

・プリム側　63行