思い出せないのか、それとも…っす

bitboardに直した方が頭の体操になるっすね。

32bitの符号付き整数2つをつなげてるっすから、

妙なテクニックが必要になってるっす。

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

HUDでアバターを指定位置へ移動させるにはllMoveToTargetを

使えば簡単にできるっす。

でも、指定のrotationに回転させるってどうやるんっすかね?

座ってないっすからllSetLinkPrimitiveParams(Fast)は使えないっす。

llRotLookAtはHUD自体が回転したっす。

他の物理関係の関数を使用した場合、指定したrotationに到達したか

どうかのチェックが必要で、かつ細かく連発することになるっす。

アバターが気持ち悪い動きをするので、この方法は使いたくないっす。

llMoveToTargetみたいに簡単にできる関数を見逃してるんっすかねぇ。

それとも、そもそもそんな関数が無いんっすかねぇ?

7割書き換えるっす

出来ることならやりたくなかったんっすけどね。

奥の手っす。

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

リバーシを引き続き作ってるっす。

実は探索して結果を返すところまでは出来てるっす。

でも問題は速度なんっすよねぇ。

石が4つ置かれた初期盤面から4手読みさせたところ、

平均して5.6秒かかってたっす。

中盤では同じ4手でもノードの展開数は跳ね上がるっすから

これじゃあ遅すぎるわけっす。

そこで、現在64要素のlist1つで表現している盤面を

2要素のlist2つで表現する方法に変えるっす。

bitboardってやつっすね。

わざわざlistでやるので気持ち悪いんっすけど、

LSLのinteger型が32bitなので仕方ないっす。

目標は初期盤面から4手読みで1秒以内っす。

ということは速度を5倍以上向上させないといけないっすね。

もしあらゆる手段を使ってもダメなら、深さを4から2に変えるっす。

これは最後の手段っすね。

動摩擦係数(Havok 7)っす

1.40.4が全域適用されたので実験したっす。

Havok4のときの結果は前に書いたっす。

比べてみると良いっすね。(あんまり変わってないっすけど)

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

方法はHavok4のときと全く同じなのでコピペっす。

[方法]

1.llSetForceでとりあえず動かす

2.llSetForce(ZERO_VECTOR, FALSE)を実行

3.現在位置と速度を取得

4.止まるまで待つ

5.止まったら位置を確認

「運動エネルギーが摩擦力による仕事に全て変わった」として、

1/2mv² = μ'mgL

整理して

μ' = v² / 2gL

(μ':動摩擦係数, v:最初の速度, g:重力加速度(=9.8), L:移動距離)

という計算から求める。

・1セット7回の試行

・7回の試行のうち最大値をそのセットの値とする

で、10セット行ってみた結果が↓っす。

10セット分の集計

箱-土台	最小値	最大値	平均	標準偏差	中央値
S-S	0.558389	0.625028	0.591373	0.026299	0.588103
M-S	0.403648	0.435557	0.416047	0.011017	0.415439
G-S	0.358687	0.368062	0.361732	0.004303	0.359595
W-S	0.510505	0.565133	0.539083	0.018935	0.544879
F-S	0.532399	0.635523	0.600847	0.032738	0.601467
P-S	0.339902	0.402113	0.373375	0.019872	0.373200
R-S	0.334738	0.468658	0.416322	0.043050	0.424146
S-M	0.376186	0.443406	0.414127	0.020795	0.416319
M-M	0.256901	0.267467	0.261841	0.003190	0.262087
G-M	0.215483	0.227015	0.221312	0.003751	0.222878
W-M	0.347730	0.369481	0.356886	0.007541	0.353187
F-M	0.400925	0.445923	0.423707	0.017372	0.422570
P-M	0.313242	0.329052	0.323484	0.006252	0.325682
R-M	0.397827	0.471527	0.426896	0.026352	0.429242
S-G	0.342789	0.364226	0.353114	0.007470	0.354795
M-G	0.218975	0.226897	0.221807	0.002749	0.220832
G-G	0.178997	0.186264	0.182606	0.002791	0.181759
W-G	0.305589	0.320378	0.315749	0.005759	0.319785
F-G	0.369080	0.399671	0.381964	0.011072	0.378474
P-G	0.252126	0.270482	0.262287	0.005889	0.262184
R-G	0.363569	0.389073	0.377633	0.009121	0.378585
S-W	0.523125	0.565399	0.537925	0.015813	0.541454
M-W	0.319756	0.370439	0.350097	0.016855	0.351838
G-W	0.306236	0.327062	0.317252	0.007308	0.319103
W-W	0.452460	0.504664	0.471510	0.018114	0.464441
F-W	0.488737	0.567489	0.528534	0.025983	0.525334
P-W	0.416600	0.446154	0.428300	0.012415	0.424277
R-W	0.469199	0.536698	0.511458	0.024257	0.514511
S-F	0.572372	0.632154	0.599994	0.019148	0.600879
M-F	0.400892	0.437555	0.422820	0.012406	0.428644
G-F	0.358422	0.394345	0.371395	0.012178	0.374071
W-F	0.505438	0.550946	0.525378	0.015940	0.525057
F-F	0.603197	0.675531	0.628161	0.023074	0.623332
P-F	0.451103	0.509668	0.478783	0.022862	0.471104
R-F	0.589573	0.655833	0.611079	0.023804	0.616158
S-P	0.372899	0.402781	0.387664	0.009097	0.389129
M-P	0.310546	0.331952	0.319970	0.006468	0.319418
G-P	0.259572	0.268057	0.264639	0.002960	0.264829
W-P	0.406565	0.447081	0.424840	0.013214	0.427467
F-P	0.435581	0.489691	0.475577	0.019960	0.481683
P-P	0.346188	0.366909	0.359167	0.007030	0.359720
R-P	0.477034	0.518234	0.498277	0.012790	0.500961
S-R	0.401700	0.458935	0.426180	0.022779	0.414204
M-R	0.407225	0.429482	0.421081	0.007993	0.422630
G-R	0.346984	0.364003	0.355765	0.006245	0.353202
W-R	0.490846	0.566586	0.529422	0.025313	0.530752
F-R	0.591343	0.642965	0.611081	0.021990	0.603284
P-R	0.482538	0.509736	0.497900	0.011063	0.500562
R-R	0.612431	0.647615	0.631416	0.013400	0.630602

llDeleteSubListとllList2Listっす

listを扱う関数に同じようなのがあるっすね。

今回のタイトルの通りっす。

正解かどうかは別にして、自分なりの使い分けを書いておくっす。

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

"Delete"と付いてるので渡したlistも変わっちゃいそうなんっすけど、

実際にはコピーを渡してるので元のlistには変化がないっす。

というわけで、2つの関数は同じことをしてるわけっす。

自分の使い分けは

別のlistに代入するときはllList2Listを

元のlistの要素を削除するときにはllDeleteSubListを

という風にしてるっす。

2種類とも使ってるっすよ。

例えば、ギザギザリストを番兵を使って作ったとするっす。

list a = [1, 2, 3, -1, 4, 5, -1, 6, -1, 7, 8, 9, -1];

みたいな感じっす。これは-1を番兵としてるっす。

これを区分けして処理していくことを考えるっす。

　[1, 2, 3]

　[4, 5]

　[6]

　[7, 8, 9]

としたlistを取りたいわけっす。

ここで自分ならどうするかというと、

integer sentinel; // 番兵のインデックス
while(a) // while(llGetListLength(a) != 0) と同義
{
   sentinel = llListFindList(a, [-1]);
   処理(llList2List(a, 0, sentinel - 1));
   a = llDeleteSubList(a, 0, sentinel);
}

こうやるわけっす。

(色付けはhttp://lsl-users.jp/codehighlight/を利用したっす)

なんとなく雰囲気は伝わったと思うんっすけど、どうっすかね？

無事帰還っす

帰ってきてくれると信じてたっす。

むしろ帰ってくるのは分かってた、という感じっす。

分かっていたとしても帰ってきてくれると嬉しいもんっすね。

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

リバーシのAIの話っすよ。

何か別なことを想像したりしてないっすか？

再帰呼び出しで探索をしてたんっすけど、returnされてこなかったっす。

予想通り無限ループが発生してたっす。

簡単に説明すると、盤面を走査してるときに同じ場所ばっかり調べてたっす。

iとjでそれぞれタテとヨコを調べてるっす。

ループで回してるっすから、これでナナメも走査できるっす。

for(i = -1; i <= 1; i++)

{

　　for(j = -1; j <= 1; j++)

　　{

　　　　その方向にひっくり返る石があるか判定(石の位置, i, j);

　　}

}

とまぁ、ざっくりこんな感じのことをやってたっす。

判定関数の作り方がマズくて、i=0,j=0のときに無限ループっす。

対処として、i=0,j=0を除いてループを全部書き下したっす。

8方向についてだけっすからラクに書き換えられたっす。

ループじゃない分、ちょっとだけ速くもなるっすからね。

さらに今日はもうちょっと進んだっす。

初期盤面からの探索で、正しい着手可能点を返してきたっす。

盤面評価がいい加減でも、とりあえず探索できたっす。

あとのチェック項目は

　・パスの処理

　・終局の処理

　・評価関数の強さ

　・全体の実行速度

とりあえず大きいのはこんなところっす。

今日はかなり進んだ気がするっす。

行ったまま帰ってこないっす…

デジアカの生徒募集が開始されたっすね。

募集は来月19日までなので、お早めにどうぞっす。

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

帰ってこないのはヒトじゃないっすよ。

ネガアルファ法で探索させようとしてたんっすけど、

怪しげなループに陥っていて、抜け出せないまま帰ってこないっす。

これくらいのバグは想定内っすけどね。

作成中のリバーシのAIの話っす。

考えられる可能性はたくさんあるんっすけどね。

一番下のノードに到達したのに判定を誤ってるとか、

途中の処理で無限ループが起きてるとか、いろいろっす。

要は凡ミスしてる可能性が大っす。

ちょこっとずつ直していくっす。

土日で仕上げるっす

viewer2.1.0 (207030)を入れてみたっす。

今のところ不都合は無いっす。

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

一気にリバーシの探索部分を書き上げたっす。

書いただけなのでバグ取りはまだっす。

一発OKなんてのは期待してないっす。

地道に潰していくっす。

LSLでネガアルファ法を実装したことのあるヒトは

世界でも10人いないんじゃないっすかね？

そもそも再帰なんて使わないっすからね。

入力用のテストデータを作って休みのうちにカタチにしたいんっすけど、

たぶん無理っすね。

評価関数の手直しもしたいっすからね。

プリム数は減らさないっす

Viewer 2.0.1からベータが外れてたっすね。

ビューワについてはあんまり書く気はないっす。

たぶん他の方が書いてるっすからね。

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

リバーシのAIを書いてるっす。

大体想像できると思うっすけど、一般的なスクリプトに比べて、

とんでもなく容量を食ってるっす。

合計すると全体で100KBを余裕で超えるっす。

もちろんMonoコンパイルでの話っす。

数値計算が主なので重い処理はほとんど無いんっすけどね。

でも、これだけ容量を食ってると何か対策が必要かもっすね。

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_10_21

メモリ消費量について話が出てたので紹介するっす。

ポイントを書き出してみるっす。

・1つのFull Regionには800MBが割り当てられている

・Regeion内のアバターもオブジェクトも、このリソースを使う

・アバターのメモリ使用量の99パーセント点(※)は10MB

　(※ パーセント点(percentile)は百分位数のことで、

　　パーセンテージとは別物なので注意っすよ。

　　ざっくり言えば上位1%は10MB以上使っていて、

　　その他の99%の使用量は10MB以下ってことっす)

公平にリソースが分配されたとき、その範囲内であれば文句無いっすよね？

ということで、「プリム数あたりのメモリ消費量」を指標としてみるっす。

リバーシは装着型じゃないっすから、これを使うっす。

装着型のオブジェクトには別の指標が必要っすね。

先のリンクの内容から許容範囲を出してみるっす。

Full Regeionの場合、まず、800MBのうち400MBをアバターに、

残りの400MBを土地のオブジェクトに割り当てるっす。

400MBは99パーセント点上のアバター40人分になるっす。

その残った400MBを平等に分配するっす。

つまり15,000で割れば良いっすね。

400MB / 15,000prims ≒ 27KB/prim

っていう値が出るっす。

HomesteadはFull Regionの1/4のプリム数っすから、

メモリリソースを4つのHomesteadで共有してると仮定すると

Full Regionと同じ27KB/primっていう値が出るっす。

(800MB / 4 = 200MB

200MB / 2 = 100MB

100MB / 3,500prims ≒ 27KB/prim)

これはギリギリの値なので、もっと下げないといけないっす。

どのくらいからパフォーマンスに影響するのか分かんないんっすけど、

とりあえず半分くらいにして、キリの良い値を指標には使いたいっす。

というわけで、自分の指標は

上限は16KB/primで、可能な限り8KB/primに抑える

にしたっす。

プリム数を増やして、割合としてのメモリ使用量を下げるっす。

リバーシが全体で130KBとすると65primsで2KB/primっすね。

これくらいなら大丈夫…なんっすかねぇ？

リムーブの活用法っす

やる気が出ないのは暑いからっすね。

でも別な理由があるような気もするっす。

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

ここら辺においてある、テクスチャ・チェンジャーで販売もしたいっす。

Pay/moneyイベントを使えば出来るんっすけど、

ちょっと違った方法も考えてみたっす。

現状、SLPPFとかのリンク周りの関数で作ってあるっす。

そこのところを変えて、リンクじゃなくてSay/listenでやり取りするっす。

こうすると商品部分と切り替え部分が分割されて、

Payじゃなく、Buyで購入できるようになるっす。

テクスチャ・チェンジャーをまるごと販売するわけじゃないっすから、

Buyでやるときはこうなるっす。

注意が必要なのは「コピー」を販売するようにすることっす。

「コンテンツ」じゃ中に入ってるスクリプトを販売することになっちゃうっす。

でもこうすると、商品の中にスクリプト(listenして形状を変える)が

残っちゃうっす。

そこで登場するのがリムーブっす。

リムーブが便利なのは自身を対象にできて、自爆できるっす。

llRemoveInventory(llGetScriptName());

と出来るわけっす。

llDieと並んで地味に使えるっすよ。

リムーブするタイミングなんっすけど、購入後初めてRezした時に

やることになるっす。

on_rezイベント中で記述するわけっすね。

「オーナーとクリエーターが異なるならリムーブ」

としておけば良いっす。

この方法の長所と短所をまとめると

長所:

　・Buyの安心感・安定感

　・切り替え部分は使い回しが可能

短所:

　・スクリプトの本数が増える

　・Say/listenを利用するので混線対策も必要

　・購入時には商品中にスクリプトが残っている状態

　　→一度もRezしないまま、別のオブジェクトのコンテンツに入れると

　　　　on_rezイベントは起きず、スクリプトも残ったままになるっす。

　　　　でも、どうせ使うときにはRezするっすから問題ないっすよね?

　　　　ただ単に気持ち悪いだけっす。

結論:なんだか面倒なので、普通にPay/moneyでやるべし

CAっす

デジアカの受け付けが間もなく始まるみたいっす。

でも実際に講座が始まるのは9月からなんっすよね…

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

CAはセルオートマトンの略っす。

何なのかは調べてくださいっす。

モデル化したのを実際に動かして、さらに可視化するのには

SLのオブジェクトはなかなか使えそうっす。

あんまり複雑なのが出来ないのが難点っすけどね。

まず手始めにECAのルール224を作ってみようと思うっす。

モチベーションが上がらないので、いつ完成するかは分かんないっす…

if文に直接ぶち込むっす

サーバー1.40.4のアナウンスがあったっすね。

20日にいつも通り20%適用、28日に全域適用らしいっす。

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

面白そうなネタを見つけたっす。

http://wiki.secondlife.com/wiki/If

単なるif文の説明なんっすけどね。

日本語での説明もあるっすよ。

if文の条件式のところにはstring型とかも直接ぶち込めるっす。

とっても気持ち悪いんっすけど、使い道もありそうっす。

例えば以下は同じ結果を返すっす。

[A: string型のパターン]

　if(llStringLength(str_test) != 0)

　if(str_test)

[B: list型のパターン]

　if(llGetListLength(lst_test) != 0)

　if(lst_test)

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

にも書いてあるんっすけど、key型の使い道もあるっす。

直接ぶち込むif文も慣れた方が良いんっすかねぇ。

また作り始めたっす

ここ2週間ほど更新のペースが遅かったっすね。

それでも週3ペースなんっすけどね。

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

作りかけのを完成させるべく、コツコツ作ってるっす。

モノはリバーシのAI部分っす。

ヒトvsヒトのは既にたくさんあるっすけど、vsオブジェクトは無いっす。

強いのは64kb制限とか速度の問題で作れないっす。

でも弱いのなら作れなくもないっす。

ただ超面倒なだけっす。

進展があったのは「評価関数」の部分っす。

無理をして2種類の評価関数を組み込んだっす。

LSLで作るものとしては豪華仕様っす。

速度は低下するんっすけど、ちょっとでも強くしたいっす。

予定としては中盤までは4手読み、最終盤6手完全読みっす。

置ける場所を考えるとどちらも1,000パターンまではないっす。

これがギリギリの線じゃないかと思ってるっす。

10月のアレまでには完成させたいっすねぇ。

連絡が来たっす

まだ詳細について煮詰まってないみたいっすけど、

判明してるところまで書いておくっす。

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

デジアカの件っす。

スケジュールについて、ちょっと進展があったっす。

8月中旬に入校式

9月から講座開始

ということらしいっす。

7月中に講師の方で一度集まることも予定されてるっす。

もうすぐ募集も開始されるみたいっすよ。

まだ時間に余裕があるので、作りかけのを作っちゃうっす。

SLマーケットプレイスっす

メールが来てたっすね。

でもマーチャント(出品してるヒト)にしか届いてないかもっす。

知らないヒトも多いんじゃないっすかねぇ。

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

マーチャント、つまり売り手の方から見てみるっす。

買いやすいかどうかは、いろんなところで書かれてるっすからね。

https://marketplace.secondlife.com/

これが新しいSL Marketplaceのページっす。

商品などの設定を変更したい場合は、ログインしたあと、

マーケットプレイス→マーチャントのホームページ

と進めば変えられるっす。

ここはXStreetSLとほぼ同じ感じっすね。

自分が一番の違いを感じたのは「マイストア」の存在っす。

XStreetは自分の[名前]で販売することになってたんっすけど、

それとは別に、[ストアの名前]を付けることができるっす。

[ストアの名前]の他にも[プロフィール][ポリシー][ブログへのリンク]

なんかも、ストア情報として書けるっす。

[プロフィール]は2,100文字、[ポリシー]は450文字っていう

制限はあるんっすけどね。

少なくとも8週間はXStreetは無くならないとメールに書いてあったっす。

でも早いうちにSLMarketplaceに慣れた方が良いっすね。

(というのもメールに書いてあったっす)

なんと、今月14日まではコミッション・フィー(販売されたときに

支払う手数料)が無料になるということなので、

商品を買われる方もSLMarketplaceで買うと、

制作・販売者が喜ぶかもっす。

サーバー安定化についてのごにょごにょっす

そろそろ今年のLSLCONについて動き出さないとっすね。

去年は一応「成功」なので、去年と同じ感じになると思うっす。

いや、まだ分かんないっすよ?

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

近頃、予定が狂いまくってるっす。

ぽっかりと予定に穴が空いて、暇っす。

モノはいろいろ作ってるんっすけどまだ余裕があるので、

オフィスアワーのログを漁ってみたっす。

あんまりチェックしてないBeta Server Office Hoursのログを

久しぶりに見てみたっす。

ナナメ読みしたので「いつ」に関する記述は見つけられなかったんっすけど、

サーバー1.42と1.44について書いてあったっす。

http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2010-04-15

サーバー1.42: TCMalloc

サーバー1.44: Mono 2.6

これがキーワードっす。

新機能というよりは安定化・高速化に関するアップデートっぽいっす。

しばらくは見た目が地味なアップデートが続きそうっすね。

今日は書くこともないっすね

wikiを漁ってたら、llGetAgentInfoにAGENT_AUTOPILOT

なんてのが増えてたみたいっす。

オートパイロット状態を検出して、何するんっすかね?

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

今日は「書くことがない」ことをネタにして、無理やり書いてるっす。

無いもんは無いっす。

ロールバックされなければ動摩擦係数のこともあったんっすけどね。

次、いつ1.40が戻ってくるのかのアナウンスも出てないっす。

実験は中断っすね。

Havok 7といえば、FJ Lindenさんがblog書いてたっすね。

http://blogs.secondlife.com/community/features/blog/2010/07/01/upgrade-of-second-life-to-havok-7

Havok7になってフレームレートが増加した、って書いてあるっすね。

ぬるぬる動くようになったわけっす。

デフォルトの箱を物理にして、ドラッグで移動させても体感できたっす。

今はロールバックされて…

なんか皆さんビューワの変化に一喜一憂してるみたいっすけど、

サーバー側の変化には鈍いみたいっすね。

静止摩擦係数(in Havok7)っす

現在はロールバックが行われて1.38に戻ってるっすね。

日本時間午前5時前に5セット分届いてたもんっすから、

その分のデータをまとめてみるっす。

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

llSetForce(<friction, 0.0, 0.0> * llGetMass() * 9.8, FALSE)
っていうのを0.5m*0.5m*0.5mの様々な材質のボックスに与えて、
frictionの値を変えながら、動いたときの値を出したっす。
f = μmg　の式をそのまま使ってるわけっす。

ここは前回と同じっすね。

・1セット5回の試行
・5回の試行での最大値をそのセットでの結果とする
・これを5セット行い、最頻値(mode)を出す

材質は頭を取って
　Stone → S
　Metal → M
　Glass → G
　Wood → W
　Flesh → F
　Plastic → P
　Rubber → R

と表記するっす。

では結果っす。

右側のカッコに入ってる数値は、havok4の頃に測定した値っす。

---

S-S　0.816501 (0.816001)

S-M　0.528501 (0.527001)

S-G　0.461000 (0.460999)

S-W　0.715001 (0.715001)

S-F　0.872001 (0.872001)

S-P　0.595503 (0.594919)

S-R　0.872003 (0.872170)

M-M　0.353499 (0.344583)

M-G　0.294999 (0.287083)

M-W　0.476499 (0.476500)

M-F　0.563502 (0.562501)

M-P　0.400500 (0.410500)

M-R　0.563502 (0.562001)

G-G　0.244999 (0.242000)

G-W　0.419999 (0.410500)

G-F　0.476500 (0.476500)

G-P　0.353499 (0.345000)

G-R　0.476500 (0.476499)

W-W　0.628001 (0.627501)

W-F　0.764002 (0.764001)

W-P　0.528500 (0.527000)

W-R　0.764002 (0.764001)

F-F　0.932001 (0.916001)

F-P　0.628001 (0.627500)

F-R　0.932001 (0.931501)

P-P　0.461000 (0.461000)

P-R　0.628000 (0.627501)

R-R　0.932001 (0.916001)

---

Havok7になったからといって、書き換える必要は無さそうっす。

動摩擦係数を見てみないとはっきり言えないっすけどね。

動摩擦係数は1.40が再び来たらやるっすよ。

静止摩擦係数の小さい順に並べると

　Glass

　Metal

　Plastic

　Wood

　Stone

　Flesh / Rubber

になるっす。

どうもFleshとRubberの値は同じっぽいっす。

今回はきっちり合ってるっすね。

乗り物を作るには良くなったみたいっす

C#導入が凍結されちゃったっすねぇ。

時期尚早ではあったんっすけど、やってほしかったっすね。

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

Havok7での静止・動摩擦係数の測定実験は進行中っす。

来週火曜日くらいに結果は出せそうっす。

Havok4の頃とそんなに変わってないんっすけどね。

実はサーバー1.40.2で、密かにある変更があったっす。

自分も偶然見つけたんっすけどね。

物理オブジェクトって、座っているアバターも1プリムとしてカウントして、

合計32プリムまでっていう制限があったっすよね。

1人乗りのビークルなら31プリム以下で作る必要があったっす。

これが1.40.2からはアバターはプリム数に含めないことになったっす。

つまり乗り物だけで32プリムが可能で、しかも何人でも乗れるっす。

自分は乗り物にはノータッチなので実感が湧かないんっすけど、

実際に作ってるヒトにとっては大きい変化かもっすね。