FTD研ログ置き場

Last-modified: 2018-12-14 (金) 22:15:10

概要

現在Discordチャットルームに設置されている各種ログ倉庫。
とりあえず貴重な検証データなどを喪うよりはずっといい、ということで此方になんとか移していく。
ある程度有用そうだと判断したらごった煮でおk!
(編集済)等はDiscordでの発言の修正時に付く文章の為気にしなくて良い。

 

ログが長くなりすぎた場合はログ1ログ2の様な形で増やして対応していくのが無難と思われる。

砲弾の速度について

公式wikiのレールガンによる加速値が非常に分かりにくい&ちょっと間違ってるので、日本語訳兼修正をば(ver2.16)
参考:公式wikiページ https://fromthedepths.gamepedia.com/Advanced_Cannon#Muzzle_velocity

 

Vr=(8*q*(1+5*(1-0.9^nr)))^0.5/(ns^0.25*(5*d)^0.75)*s

 

Vr:レールガンによる加速値(m/s)
q:速度に消費される電力量
nr:レールガンケーシングの数
ns:砲弾長相当モジュール数 (例えば砲弾の飛翔体の長さが1200mmで口径500mmなら1200/500で2.4)
d:砲弾の口径(単位はm。例えば500mmなら0.5)
s:弾のspeedmodifierによる係数

 

ついでに、ガンパウダーによる加速の計算式は
V=700*np/(np+ns)*s*Vs^0.03

 

V:ガンパウダーによる加速値(m/s)
np:ガンパウダーの数
Vs:砲弾の飛翔する部分の体積(単位はm3 計算式は3.1415/4*d^3*ns)

 

何個レールガンケーシングを入れるべきか便利ツール化したもの↓
https://wikiwiki.jp/ftdjp/%E4%BE%BF%E5%88%A9%E3%83%84%E3%83%BC%E3%83%AB#bc59b15a

 

以下Discordでの話

 

BiAM(定数, 項数, 初項, 公比)
=定数+等比数列の和
=定数+初項×(1ー公比^項数)/(1ー公比)
なので

 

レールガンケーシングによるレールドローの増幅率は
BiAM(1,レールガンケーシング数,0.5,0.9)

 

レールガンケーシング数をnとすると
n=0のとき
増幅率=1
n=1のとき
増幅率=1+0.5=1.5
n=2のとき
増幅率=1+0.5+0.5x0.9=1.95
n=3のとき
増幅率=1+0.5+0.5x0.9+0.5x0.9^2=2.355
と増えていく。

 

レールガンケーシング数がnのとき増幅率は
1+0.5(1-0.9^n)/(1-0.9)
=1+5(1-0.9^n)
となるから、公式wikiの記述と一致する。

 

なお、速度に対する影響はこれの平方根に比例するので
n=0のとき1
n=1のとき1.225
n=2のとき1.396
n=3のとき1.536
と、非常に伸びにくい関数となる。

 

以上が超エネルギーをつぎこんだレールガンでない限り、
レールガンケーシングはかなり少ない方が弾速が伸びる理由の一つである。

 

公式wikiだとその等比級数の和に比例して速度が増加するとあるんだけど、(編集済)
実際の計算式を見る限りそれを0.5乗してるっぽい_?(編集済)
あ~、それだった・・・あいました・・・

 

んだね、上にも書いたけどレールドローにかける割合だね

 

公式wikiの記述はレールガンケーシングによる係数をチャージ量にかけると書いてないから間違うんだな…

 

あー確かに そこはよくない書き方になってますね

スクリューの判定如何について(陳腐化の恐れあり

https://twitter.com/i/moments/871077709752836097
モーメントにてまとめてもらってます。

フラグ起爆方法による起爆位置の違い

DCフラグ:装甲に着弾する1フレーム前の位置 or シールドに着弾する1フレーム前の位置
慣性信管フラグ:装甲に着弾する1フレーム前の位置 or シールドが張られている位置

着弾時間による誤差と等速円運動

砲の精度と索敵精度が高ければ砲撃は当たりやすくなる。
だがその2つだけではどうしても当たらない場合がある。
例えば船の上空に戦闘機が旋回している場合、砲撃が常に一定の差ずれ続けるのを見たことはないだろうか。
今回は着弾までの時間による誤差を考えていくことにしよう。

FtDのAIによる照準は、相手がそのままの速度でまっすぐ進む(等速直線運動)と予想して射撃を行う。
実はAIは相手ビークルの加速度を考慮できないのだ。

加速といっても、速度が増える(または減る)ことだけを指すのではない。
力学では運動方向の変化のことも総じて加速という。

[画像]

ビークルは、直進しているときは等速直線運動、旋回しているときはほぼ等速円運動を行うので、
直進しているときはどんなに速度があっても照準が大きくずれることはない。
問題となるのは旋回時、つまり等速円運動の場合である。

等速円運動では、常にビークル進行方向の力はつり合っている。
力は回転の中心方向にかかっているので、加速度も円の中心方向に向いている。
5円玉にヒモを結んで振り回してみてほしい。
常にヒモはピンと張って5円玉を中心側に引っ張っている(張力がかかっている)ことが分かるだろう。

[画像]

だから、等速円運動をするビークルをAIが射撃すると常に外側に照準がずれる。
ビークルが円の内側方向に曲がって進むことがAIには予想できないのだ。

ここからはどの程度のズレなのかを定量的に評価していこう。
数式が苦手な人は読み飛ばして結論を読んでほしい。

ビークルが等速円運動をしているとき、
ビークル初期位置をx、速度をv、加速度をaとする。
ビークルの位置をX、AIによるビークルの位置予想をX'とすると、
AIの予想は等速直線運動になるから時間tが十分に小さいとき、

X=x+vt+1/2・at^2
X'=x+vt

より、着弾時間による誤差は

X-X'=1/2・at^2

つまり加速度に比例し、着弾までの時間の2乗に比例する。

加速度は計測しにくいので、角速度をω(rad/s)とおく。
角速度の計測方法は上の方にピン止めしてある。
等速円運動の運動方程式より

ma=mvωだから

X-X'=1/2 ・vωt^2

となり、速度にも角速度にも比例し、着弾までの時間の2乗に比例することが分かる。
回避を考える場合は速度だけでなく、常に旋回し続けることがいかに重要であるかが分かる。

着弾までの時間は、弾速に反比例し距離に比例するから、
当てたい場合は弾速を上げ、避けたい場合は距離を取ることで劇的に命中率が変わることも分かる。

最後にもう一点、相手のAIの照準を避けるのに重要な点を述べておく。
相手と同じ高度で等速円運動をしても無意味だ。

[画像]

加速度の方向は常に回転面上にあるから、
回転中心が相手のビークルと一致していると、
照準の位置はずれても照準の角度が全くずれないので相手の狙いを外せない。

[画像]

逆に効果的な円運動は、回転面が相手ビークルと離れているとき。
つまり相手の上空をグルグルと回ることが最も相手ビークルの狙いを効果的に外すことができる。

ホイールの衝突判定

ホイールは
Wheel Colliderという地面との当たり判定をもっていて、
通常のブロックよりも地面と接触しやすく、摩擦も持っているみたいですね

ホイール設置数が20個を超えるとビークルで上や真ん中に配置してあるものからこのWheel Collider判定を失うようになってます
Wheel Colliderを失ったホイールは推力を発生するけれども、地面との当たり判定は小さくなるようです
また、サブオブジェクト上に設置したホイールは全てWheel Colliderを持たないようです

https://docs.unity3d.com/ja/current/Manual/class-WheelCollider.html

索敵メモ

◆各センサーの平均化の重みづけについて
2倍の精度を確保するには、4倍の索敵回数が必要である。
だから、各センサーの情報の重みは "誤差の2乗に反比例した比で設定" しなければならない。

例えばCamera 90 (Range error:10% Bearing error:0.2)と
Retroreflection Sensor 360 (Range error:0.1% Bearing error:1)を使っているならば、

Camera 90 
→Range(relative):0.01 Bearing(relative):2.00
Retroreflection Sensor 360
→Range(relative):2.00 Bearing(relative):0.04
と設定するとよい。(編集済)

◆平均化時間について
過去さかのぼって平均値を取る秒数のことである。

基本はできるだけ短くするとよい。
ただし、必ず "平均化時間内に索敵回数が1回以上含まれるように" すること。

Retroreflection Sensorは索敵回数が5回/秒なので、0.2秒に1回しか索敵しない。
ここで、Range averaging timeを0.2より小さくすると、
レトロリフレクションの索敵情報が含まれていないタイミングが生まれてしまう。
夜間や悪天候などで索敵回数が減ることを考慮すると、ここでは0.4秒程度にしておくのが無難だろう。

同様にBearing averaging timeは方位角センサーの秒間索敵回数に合わせて設定するとよい。
大抵の場合0.1秒で済む。
Speed Calculation timeも0.1秒でよい。

▽方位角センサーのおすすめ
・IR Camera Gimbal Tracker
索敵回数驚異の40回/秒。
対高速機では毎フレーム検知できることが最も重要だ。

IRの欠点であるコストの高さも抑えめで、水中も見通せる。
ただしスモークには阻害される。

・Camera 90
コストが安く、探知回数も多め。
トラッカー扱いではないのでスモークの中を見通せる。
タレットに乗せて運用しよう。

・IR Camera 90
2ブロックのためコストがやや高いが、水中をも見通せる謎の能力を持つ。
カメラ90と同じく、タレットに乗せればほぼ万能センサーと化す。

▽距離センサーのおすすめ
・Retroreflection Sensor 360
レーザートラッカーと同じ精度を持ち、
GPPC負荷が少なく、水中でも使用できて、スモークの中も見通せる。

探知回数が5回/秒と少ないので距離平均化時間は0.2秒~0.4秒にしておくとよい。
Neterの敵のほとんどは光学系センサーを装備しているが、
稀に装備していないビークルもあることに注意。

・Laser Range Finder Tracker
コストが異様に安く、GPPC負荷も小さい。
トラッカー制限に引っかからないならとりあえず付けておいて損はない。
水中でも使えるが、スモークに阻害されることは覚えておこう。(編集済)

索敵誤差の2乗に反比例した比で設定する理由

1次元のランダムウォークの考え方にならって、
1次元での索敵誤差の集計を考える。

数直線上の原点に敵ビークルがあり、
センサーの索敵誤差は1/2の確率で+1、残り1/2の確率で-1をとるとする。
n回の索敵のうちk回、索敵誤差が+1になるとすると、

n回の索敵誤差の合計を確率変数xとおくと、
x=k-(n-k)=2k-nより、
k=(n+x)/2

n回の試行のうち、1/2の確率の事象がk回起こるので、
kは二項分布B(n,1/2)に従う。

n回の索敵におけるkの平均と分散は
E(k)=np=n/2
V(k)=np(1-p)=n/4

よって、n回の索敵におけるx=2k-nの平均・分散・標準偏差は
E(x)=E(2k-n)=2E(k)-n=0
V(x)=V(2k-n)=4E(k)=n
δ(x)=√V(x)=√n

平均すると0になるが、分散はnになる。
標準偏差は√nである。

何回も索敵すると平均はもちろん0であるが、
標準偏差すなわち索敵誤差の合計はおよそ√nであるから、索敵回数に応じて少しずつ増えていき、
例えば4回の索敵であればおよそ2、9回の索敵であればおよそ3、16回の索敵であればおよそ4だけ
原点からずれていることがわかる。

索敵誤差の集計は
これをn回で割って平均すればよいので、1/√nとなる。
集計した索敵誤差は索敵回数に応じて少しずつ減っていき、
例えば4回の索敵であればおよそ1/2、9回の索敵であればおよそ1/3、16回の索敵であればおよそ1/4だけ
原点からずれていることがわかる。

集計した索敵誤差は索敵回数の平方根に反比例して減っていく。


センサーの索敵誤差がD(m)であり、Dは完全にランダムな値を取る場合を考えよう。
Dはxに対して独立であるので、Dの平均をdとおくと、
X=dxと置き換えることができて、

Xの平均・分散・標準偏差は
E(X)=E(dx)=d・E(x)=0
V(X)=V(dx)=d^2・V(x)=nd^2
δ(X)=√V(X)=d√n

索敵誤差の合計は索敵回数の平方根に比例するので、
集計した索敵誤差はやはり索敵回数の平方根に反比例して減っていく。


次に、センサー同士の重みづけについて考えよう。
d=1の索敵誤差をもつセンサーとd=2の索敵誤差を持つセンサーを考える。
1の索敵誤差のセンサーの確率変数がX、2の索敵誤差のセンサーの確率変数は2X。

これらを(1-t):tの比で重みづけした場合の確率変数Yは、
Y=(1-t)X+t・2Xで与えられるから、

分散は、
V(Y)=(1-t)^2・V(X)+4t^2・V(X)
={5(t-1/5)^2-4/5)}n

分散は、t=1/5のとき最小値4/5・nをとる。
センサーの索敵誤差の比が1:2に対し、重みづけの比は4:1になっている。
これは索敵誤差の2乗に反比例する比である。

索敵誤差の比が1:2でなくとも、
同様に考え、センサーの索敵誤差の2乗に反比例する比で重みづけすると、分散は最小になる。
すなわち集計した索敵誤差も最小になる。

フィーダーの稼働タイミング・ワイヤレストランスミッタ&レシーバの更新タイミング

アドキャのフィーダーの稼働は0.2秒ごと、全フィーダ同時に行われる
給弾時間0.214秒の砲弾ならば、0.4秒ごとにしか給弾されない

ワイヤレストランスミッタ&レシーバの接続は、1秒ごとにしか更新されない

オートキャノンとシンプルレーザー雑感

AutoCannon
コストは、
本体 25 Cost
弾薬消費 3.3 Ammo/s → 3.3 Ammo box
Ammo boxが 10 Costなので実質 58.3 Cost

ダメージは、
500 damage 3 AP
3 round/s
だから 1500 damage/s

よって1コストあたりのDPSは
1500 damage/s ÷ 58.3 Cost = 25.7 damage/s・cost

Simple Laser
コストは
本体 100 Cost
弾薬消費 4 Ammo/s → 4 Ammo box
なので実質 140 Cost

ダメージは、
400 damage/s 30 AP
10秒間のうち5秒射撃するので 200 damage/s

よって1コストあたりのDPSは
200 damage/s ÷ 140 Cost = 1.4 damage/s・cost

この18倍のDPS差をレーザーのAP・命中率の優位で埋めるのはほとんど不可能で、
Neter機相手だと実測で2倍~3倍程度AutoCannonの方が強い

※上記はあくまで計算上の解でしかなく、実戦ではまた違う結果が出る。
メタル以上の装甲材のAC値や弾速と相対速度やターゲットの機動による命中率補正、
「実弾は入射角が浅いと跳弾しやすい」という性質、
更に「実弾は傾斜反射シールドで無効化されやすい」という性質も踏まえると、
相手次第ではこの解は容易くひっくり返ってしまう。

スラスターのオーバークロックバグ(旧ACB)

ACB開いて

1.Inputsは適当にActivate every secondsあたりにしておく

2.AffectedはまずAerial AI CardsでMinimum altitude~を選択し、Affectの値を2600に変更する

3.次が重要で、AffectedでPropolution Componentsを選択してから、Set drive fraction~のラジオボタンを押さないでおく

4.時空の彼方へ飛び去る

※このバグは新ACBで修正されたが、旧ACBで超出力に設定されたスラスターは依然使えてしまう。

リアクションホイールの参照する重量

v2.15のうちにリアクションホイールのテストをしておく(編集済)
左右のリアクションホイールを逆回転させ、ヨーを釣り合わせることで発生するモーメントが何に依存するかをはかる(編集済)
スピンブロック単体で回転させてもヨーが発生することから、スピンブロック自身の重量も含めて計算することが分かる
回転軸上に置いても半径1mに置いてもヨーが変わらないことから、回転半径は(現実と違い)反作用トルクに影響を及ぼさないことが分かる
サブオブジェクトとメインオブジェクトを重ねて回転を止めてもヨーが発生することから、実際の回転速度ではなく設定した回転速度を参照することがわかる
ここまでは以前実験済み
スピンブロックのWeightは10、WoodのWeightは10なので、スピンブロックにWood4つ乗せるとWeightが50として反作用トルクが計算される
ここで、スピンブロックにスピンブロックを乗せ、さらにWood1個乗せた状態で両方のスピンブロックを回転させると、ちょうどヨーが釣り合う
下のスピンブロックがWeight30分のトルクを発生、上のスピンブロックがWeight20分のトルクを発生していると考えられる
つまり、v2.15においては反作用トルクは孫オブジェクトの重量も含めて計算するが、親オブジェクトの回転速度は参照しないことがわかる

砲弾の速度にサブオブジェクトの移動速度は乗らない

クランク式移動をしながらオートキャノンを垂直な方向に撃つ 見えにくいがオレンジの軌跡がオートキャノン(編集済)

仮にサブコンストラクトの速度が射撃した弾に乗るなら、オートキャノンは斜めに飛んでいかなければならない
しかし垂直に飛んで行っていることから、サブコンストラクトの速度が乗っていないことが分かる
全ての砲弾は、メインコンストラクトの速度のみが加算されて射出される

推進技術あれこれ

▼スピンウイング推進
ウイングは、ウイングが乗っているオブジェクト基部の速度に比例した推力(揚力)を発生する。
だからウイングをスピンブロックに乗せ、そのスピンブロックを高速で回転することで
推進装置として利用できる。

ゲームスピードが1倍(40frame/s)のとき、
ウイングが乗っているスピンブロックを、2重スピンブロックで回すとする。
回転半径をr(m)、回転速度を30rad/sに設定すると実際の角速度は43°/frameになるから、
ウイング1個が発生する推力は
0.8(kN・s/m)×r(m)×sin(43°×2)(/frame)×40(frame/s)≒31.9r(kN)

主に高高度~宇宙用。
水中で利用する場合はオブジェクト1つに置くウイングを99個以下にすると推力が5倍になる。
その場合はウイング1個が発生する推力はおよそ159.6r(kN)。

▼エルロン推進
エルロンは、エルロンとビークル進行方向のなす角に関係なく
ビークル速度に比例した推力(揚力)を発生する。

よってビークル速度をv(m/s)とすると
エルロン1個あたりの推力は、0.4v(kN)となる。

主に高高度~宇宙用。
初動にヘリブレードか何かが必要。
細かな注意点が更にいくつかあるので今度書く。

▼ハイドロフォイル推進
ハイドロフォイルは、
ビークル速度のハイドロフォイルの正の向きに平行な成分に比例した推力(揚力)を発生する。

ビークルに対しハイドロフォイルのブロックとしての設置方向を45°に傾けたとき推力は最大になり、
ビークル速度をv(m/s)とすると
ハイドロフォイル1個あたりの推力は
10(kN・s/m)×v(m/s)×sin45°×cos45°=5v(kN)となる。

水中専用。
ヘリブレードやスピンウイングなどで初速を確保しないと正しい方向に推力が出ないので注意。

▼固定ウイング推進
どうあがいても上記2種よりも推力が上がらない。悲しみ。

◆比較
エルロン推進・ハイドロフォイル推進は速度に比例した推力なので
ビークル速度が速いほど有利。
高速で小型のビークル向け。

スピンウイング推進は回転半径に比例した推力なので
中型以上のビークルに向く。
また、エルロン推進やハイドロフォイル推進の初速用に使うのもよい。

ジェット・イオン系航空機がまっすぐ飛ばないときの解決策

そそ、だいたいそんな感じ

細かい解説は省くけど、
重心より前に水平方向の抵抗中心があるのが問題なので
①重心を前にする(TEST11)
②ビークル前方の水平方向の抵抗を減らし、抵抗中心を後ろにする(TEST12)
のどちらかで解決できます

TEST13はエルロン推進の左右の推力の差を利用してロール収束させる方法ですね
これも細かい解説は省きますが、現実の垂直尾翼のようなはたらきを持たせています(編集済)

サブオブジェクトをピストンでつくるメリット

スピンブロックが1面接続なのに対して、ピストン1mは5面接続なのでサブオブジェクトを守る力が単純に5倍高い
ピストンはちょっと重いのと、スピンブロックに比べコストが70→105になるけど・・・

また、ピストンブロックには先端部にしか攻撃の当たり判定が存在しない

高速ビークル上でのACBによる障害物検知

高速ビークル上ではACB障害物検知はサブオブジェクト上のブロックをしばしば認識しない
この速度のビークルでは実際の位置よりも2m先にブロックを置くと検知してくれる

80m/s * 1/40 s = 2m だから、1フレーム前のブロックの位置を検知していると考えられる
ここ以降が問題で、
ブロックを1フレーム前の位置に置いて検知させると、判定が同フレームの位置を参照するようになる(編集済)

つまり2m先のブロックを撤去したのちも、正しい位置のブロックを検知するように変化する(編集済)

スラスタ・姿勢制御装置への入力の優先度

1.AI入力
Aerial AI, Naval AIによるスラスタへの直接入力

2.ACBによるComplex Key入力

3.プレイヤーによるComplex Controller入力
あるいはVehicle Controller入力

の3つがあって、
AI入力とACB入力は同時に推力発生
プレイヤー入力とACB入力は同時に推力発生
プレイヤー入力とAI入力はプレイヤー入力優先 ですね

近接信管によるシールド破壊

近接信管でHESHを起爆すると、シールドプロジェクタに直接Thumpダメージを与えられる。

 

近接信管でEMPを起爆しても、シールドプロジェクタに直接EMPダメージを与えられる。
この場合シールドプロジェクタのEMP感度は0.6なので、
125x0.6=75ダメージだから
EMPダメージは125必要。

 

ただし、シールドプロジェクタに隣接して
MetalブロックやスピンブロックなどのEMPダメージを素通しするブロックがある場合、
EMPダメージが97.86ダメージあれば一撃破壊できる。
実はEMP伝播は同じ点を何度も通ることができる。

 

後日の研究で、最初に伝わったブロックのみ2度通ることができるらしい

スピンブロックのcontinuousモードの回転速度

スピンブロックの速度設定(30)はdeg/sと表記してあることもあるが実はrad/s

 

それと continuous の向きは 1deg 刻みの 360 通りになるっぽい
だから角速度 ω [rad/s] = ω/40 [rad/frame] = (ω/40)*(180/π) [deg/frame] = 4.5ω/π [deg/frame]
なんだけどこれを整数値に丸めてると思われる

 

・ continuous モードのスピンブロックの向きは 1° (deg) 刻みの 360 通り
・ rotation モードのスピンブロックはそういった制限は無い

ミサイルのHP

ミサイルのHPは6モジュールにつきHP100。1モジュールにつき約HP17。
サンパーヘッドを持つときはモジュール数にさらに8を加えてHPを計算する。
つまりサンパーヘッドは通常のモジュール9個分のHPを持つ。

ミサイルがサンパーを含まないn個のモジュールをもつとき、
ミサイルHP=100/6×n

ミサイルがサンパーを含むn個のモジュールをもつとき、
ミサイルHP=100/6×(n+8)

スモークの減衰力とウェーブフロントの貫通力

レーザーの経路上のいずれかにスモークがあれば減衰される。
発射地点と着弾地点以外の中間地点にスモークがあっても減衰される。

減衰割合は、1枚で0.01倍、2枚で0.001倍、3枚で0.0001倍...
おそらくバグであるが、1枚で2枚分、2枚で3枚分、3枚で4枚分...の減衰力になっている。

Wavefront ダメージ50%・25%貫通だと
スモークなしでは997ダメージ
スモーク1枚(実際の処理はバグで2重になっている)で105ダメージ

1-sqrt(105/997)≒0.675
0.9*(1-0.25)=0.675より

実際のスモーク軽減率=もとのスモーク軽減率×(1-ウェーブフロント貫通力)
となっていることが予想される。

レーザーのAPの確保

frequency doubler が m 個、ポンプが n 個あるレーザーを考える。
AP は 400m / n, 平衡時の基礎ダメージはポンプ数に比例: an
AP-AC によるダメージ倍率は min(1, AP/2AC) = min(1, 200m / (AC*n))
AP-AC を考慮した平衡時のダメージは

(基礎ダメージ)*(AP-AC 倍率)
= an * min(1, 200m / (AC*n))
= min(an, 200am / AC)

min で後者が選ばれるとき (AP が AC の 2 倍より少ないとき) ダメージはポンプ数に依存せず frequency doubler の個数だけで決まる。(編集済)
レーザーの AP が足りていないとき frequency doubler を増やすとエネルギー消費を増やすことなくダメージを増やせる
レーザーの AP が足りていないときポンプを増やすとダメージが増えることなくエネルギー消費が増える

旧爆発ダメージと新爆発ダメージの違い

旧仕様
・ダメージは球状に広がる(ユークリッド距離)
・ダメージ伝達の最大半径は10m

旧仕様のダメージ減衰
1.Armour Classによる減衰
1/AC

2.距離による減衰
もとの爆発半径の半分以上を超えると
ダメージは反比例的に減少し、爆発半径の端では1/2になる。

3.与えたダメージによる減衰
もとの爆発ダメージは、球状に伝達していくときブロックにダメージを与えるごとに減っていくが、
例えばブロックに100ダメージを与えても残りダメージが100減るわけではない。

ブロックに与えたダメージ x √AC ÷10 の分ずつ減っていく。
この仕様のため、しばしば爆発ダメージは表記より大きい合計ダメージを与える。

新仕様
・ダメージは正八面体状に広がる(マンハッタン距離)
・ダメージ伝達の最大距離は30m
・起爆地点からもとの爆発半径以内にビークルがあれば、
30m以上離れていても爆発起点をそのビークルの端に移し爆発ダメージを伝達する。
その際AirBleed減衰を適用する。

新仕様のダメージ減衰
1.ACによる減衰
1/AC
FLAKなら1/AC^1.5

2.伝達による減衰(AirBleed)
もとの爆発ダメージをD、元の爆発半径をRとすると
1.3 x D^0.35 / R^2 (%)ずつ減衰する。

http://www.fromthedepthsgame.com/forum/showthread.php?tid=35076&pid=370410#pid370410
で、ブロック1個ずつダメージが伝わっていくたびにこの減衰計算が行われる。

3.ブロックに与えるダメージ割合による減衰
与えられるダメージが
ブロックの現在HPの5%未満であるとノーダメージになる。
ブロックの現在HPの40%以上であると与えられるダメージを全て与える。
5%以上40%未満であればその間の割合のダメージを与える。

https://www.desmos.com/calculator/ckj9pmnth7

4.与えたダメージによる減衰
例えばブロックに100ダメージを与えると基本的には残りダメージが100減る。
よって、大抵の場合爆発ダメージは表記より小さい合計ダメージしか与えない。

ただし、爆発ダメージがブロックを破壊しなかった場合は残りダメージを100まるまる消費しないこともある。


で、ここでAirBleedの設定値おかしいと思うんですよね。
ダメージが大きいほど減衰しやすく、半径が大きいほど減衰しにくい設定なのは分かるんですが、

500mm HE warheadモジュール1つならダメージ2985、半径17.3mなので
1.3x2985^0.35/17.2^2= 0.072% ずつしか減衰しない。
これではAirBleedがないに等しい。

ダメージ80000、半径50mの核なら、
1.3x80000^0.35/50^2≒ 0.027% ずつなのでやはり効果がない。
Power to explotion radiusを2→1.8前後まで下げてもほとんど壊せるブロック数が変わらないことからも
AirBleedが機能していないことが分かります。

ダメージ100000、半径5mの粒子砲なら、
1.3x100000^0.35/5^1.5≒ 6.5% ずつなので効果がかなりあります。
実質的にExplosive粒子砲にしか効果がないといってもいい。

Shaped charge secondary モジュールを複数付けた場合の挙動

結論から言うと付ける意味はない。

Shaped charge secondaryモジュールを2個以上付けると、
後ろのShaped charge secondaryもHE0.1個分 HEAT特殊効果0.5個分として扱われる。
Penetration factorは一番後ろにつけたセカンダリHEATの設定値のみを参照する。

サブオブジェクト上ACBの優先度

http://www.fromthedepthsgame.com/forum/showthread.php?tid=31941&pid=356897#pid356897
ACBの仕様は次のようになっている
・範囲が無限であるとき、ACBと同じオブジェクト上のすべてのブロックと、ACBのあるオブジェクトの直系の子・孫サブオブジェクト上の全てのブロックを制御する
・範囲が無限でないとき、ACBと同じオブジェクト上の範囲内のすべてのブロックと、基部ブロック(タレット・ピストン・スピンブロック)が範囲内にあるサブオブジェクト上のすべてのブロックを制御する

 

つまり
・ACBは自分自身が乗っているスピンブロックやピストンを制御することはできない
・ACBの範囲指定が無限でない限り、ACBのあるサブオブジェクトの孫にあたるサブオブジェクトを制御することはできない

 

ACBの範囲指定3mの例↓

acb1.jpg
 

ACBの範囲指定50mの例↓

acb2.jpg

ACBの範囲指定無限の例↓

acb3.jpg

Sail(帆)の仕様

sail1.jpg

帆の配置方向は24通り考えられるが、推力が安定して出るのはそのうち8通りだけである。
帆には縦軸と横軸があり、三角帆を配置したとき、筋が出る方向を横軸、筋に垂直な方向を縦軸とする。
縦軸を水平面に対して垂直に立てなければ帆に推力は生まれない。(編集済)
正確には水平面と帆の縦軸のなす角の正弦に比例する。飛行機の翼状に配置しても無駄である。つらい。
風の強さだけでなく、帆の横軸と風向のなす角によっても推力は変わる。黄が三角帆。青が四角帆。(編集済)
https://www.desmos.com/calculator/n0agila8bi
三角帆は向かい風のとき推力が半減するような設定になっている。
四角帆のデメリットはというと赤ベクトルで表示される横風を三角帆の3倍強く受けること。表示上は3倍には見えないのだが3倍らしい。(編集済)

sail2.jpg

帆はあまりイリーガルな配置はできないが、帆面に当たり判定がないためこのような重ね方ができる。(編集済)
また、右端のように接続面さえ守っていれば見た目は繋がっていなくても回転して配置することもできる。

アドキャ混成弾の強み

mix.png

アドキャAP弾のダメージ最大値

shell.png

RTGの建造コスト

RTGの建造コストを実際にキャンペで検証してみた。
検証に使ったのはコスト5628の偵察機、うちRTGは1125。
建造をすると実際に使った資源は4560でその差は1068、これは1125の5%とほぼ等しい。よってRTGは建造時もコストが安くなっていると言える。

初回建造時もS/R分数が適応されるということか~!
考えてみれば建造と修理って同じ処理ですもんね。これは設定ミスですよね…

推力とMassと重力加速度

Heliblade_lift_test_spec.png
無動力ヘリブレード100枚を付けたこのようなビークルを用意し、
MassとWeightと重力やその他の力の関係を調べる。
惑星はNeter。ゲームオプションの推力倍率の設定は1.00。浮力倍率の設定は1.25。
高度は0m以上275m未満で行う。

1.MassとWeightの関係

全てのブロックにおいて、1 Mass = 100 Weightである。
この2つの値は両方とも質量を表す。
片方が重量を表すということはない。

2.力とDragの関係

各種スラスタに表記されているForceとDragの単位は等しい。
イオンスラスタを用いて直進するビークルを作ればわかる。(編集済)

3.Massと重力の関係

無動力ヘリブレード100枚は1500の力を発生する。
バランスを崩さないよう、Always Upオプションを1.0(100%)にしておく。

 

ビークル重量を次第に重くしていき、上昇と下降の境目を見極める。
慣性の影響を受けないように、
いったんビークル固定してから固定を離し、V画面で高度の値を見る。

 

結果152.9 Massでは上昇し、152.91 Massでは下降した。

 

重力係数をg、質量をm、力をFとすると、
mg=Fより、g=m/Fだから
1500/152.91<g<1500/152.9
9.8097<g<9.8103

 

であることが分かる。
gはまず間違いなくUnityのデフォルト重力加速度9.81m/s^2であろう。

 

ここから、力Fの単位を公式Wikiに記載されているkNとすると、
単位の計算は
kg x m/s^2 = Nより
t x m/s^2 = kN
つまりMassの単位がトンであることが分かる。

 

鉛 1m^3がわずか2トン、Metal 1m^3 がわずか400kgという事実が判明する。
言い換えると鉛の密度が2.0g/cm^3、Metalの密度が0.4g/cm^3である。
Neterヤバイ。

 

以下にブループリントを添付しておく。(編集済)
fileHeliblade_lift_test.blueprint

4.重力と浮力の関係

lead_block.png
鉛のインベントリ画面を見てほしい。
empty spaceというのは鉛ブロックが押しのける水の体積であるから、
empty space has +37.5 というのは鉛ブロックが押しのける水が生み出す浮力を表す。

 

a relative buoyancy ... -158.7 というのは浮力を差し引いた鉛が沈む力を表す。
つまり、鉛にかかる重力は
37.5 - (-158.7) = 196.2

 

この重力の単位は何だろうか。
3.Massと重力の関係から、鉛1ブロックにかかる重力が
2t x 9.81m/s^2 = 19.62kN であることが分かっている。

 

値がちょうど10倍になっていることから、
浮力の表示単位はhN(ヘクトニュートン:ニュートンの100倍を表す単位)であることが分かる。

 

1m^3の水は、浮力係数が1.25であるとき37.5hNすなわち3.75kNの浮力を生み出す。
言い換えると、1m^3の水にかかる重力は3.75kNである。

 

このとき水の密度は約0.382g/cm^3である。
やはりNeterヤバイ。

5.自然浮力としてのヘリブレードとWoodの比較

無動力ヘリブレードは約15kNの浮力を発生させるスラスタである。
Woodは水面下で約2.8kNの浮力を発生させるスラスタともとらえることができる。(編集済)
AARパーツ考察/スラスタについての調査/推力と重量の関係

 

この調査となぜ重力加速度の値が食い違うかというと、
wikiの方の考察ではオプションの推力倍率が1.25の状態で調査を行っているからである。

 

スラスタ推力109350、
Mass 13933.49で浮くことから
109350/13933.49x1.25≒9.81より
重力加速度は9.81m/s^2であることがここでも裏付けられる。

 

実際VehicleBuoyancyクラスと、StaticPhysicsクラスに重力係数は9.81という記述がある。

FtDのオブジェクト個数上限と挙動

FtDのオブジェクトプール数まとめ(生成現回数)
fragment:400(フラグ弾)
projectile:500(シンプル系武器、ピストルの砲弾)
LaserPulsePool:20(パルスレーザー)
cramProjectile:500(CRAM砲弾)
advprojectile:500(アドキャ砲弾)
flash:50(爆発)

 

というわけで500発の砲弾を撃ち続ければ砲弾は止められるってことですね!!

 

(CRAMの場合は)
まさかCycleIndexをオーバーライドしてわけわかんない処理にしているとは。。。
最後の1個が上書きされる、じゃな?
常に499個出し続ければってことか。。。

 

(APSの場合は)
アドキャはオーバーライドしてにゃい
ってことはアドキャは消せるのか…
→500個出すと古いものから消える

 

(レーザーは)
しかしパルスレーザー少なすぎない…?
あそもそも多分これダメージ判定してねーや>パルスレーザーオブジェクト

 

レーザーとかPACはエフェクトとダメージ判定が別枠だからね!
さっきも書いたけど描画上限ってだけで発射上限じゃないから、別に100門のパルスレーザーを撃っても判定が消えるとかは ないぞ

フレアもアクティブレーダーシーカーを少し引き寄せる

スティッキーフレア、100(どれくらいかは謎)のアクティブレーダー誘因力持ってますね
ソナーとビジブルは0、IRは自信の何か熱量みたいなの*1000
たまにレーダーミサイルが引っ張られてたのはこの100が原因すな

RTGの建造コストと資源の無限増殖

http://www.fromthedepthsgame.com/forum/showthread.php?tid=23970
①RTGのブループリントを呼びます。
②修理します。(消費500)
③ビークルを消去します。(1万マテリアルゲット)

 

ちょっとまった
ビークルの消去時に得られるマテリアルも5%判定ですぞ!

 

ビークルごと解体なら本来のコストで解体できる
つまり触手でRTG作ってまるごと解体すれば夢の無限リソース…!

 

流石に不味いということで修正されました。
世の中そんなに甘くはない。

ERA発動条件

FtDのERAは,1.ダメージを食らう,2.HESH・HEAT・Fragを食らう,3.破壊される,4.体力が半分以下でダメージを食らうの条件で発動してるっぽい
発動の処理は多分,CRAM,アドキャ,Fragでそれぞれ用意されてて,無効化する対象になる範囲は正面30°...かな?(

リペアボットの修復について

1.bounding box(※)の外にリペアボットを出すように配置すると修復が早い
2.本体に接続可能なブロックから修復していく
3.修復可能な箇所が複数あり、リペアボットも複数ある場合、同時に修復する
4.サブオブジェクト上の修復は後回しにされるが2,3の条件によりリペアボットの数がメインオブジェクトの修復可能箇所を上回っている場合、メインと同時並行で修理する
5.3m or 5mタレットの直下が接続できないブロック(Transceiver等)または何もない場合はそのタレット及びサブオブジェクト上のブロックは修復されない
(※)メインオブジェクトを囲う長方体。非実体化時の緑枠。

各種装甲防御まとめ

https://twitter.com/i/moments/979936055401984000

索敵判定はセンサーから相手の重心に向かって伸びる

索敵線がスモークに当たっているとトラッカー系は機能を失う
画像では灰色のレトロリフレクションと、
デフォルト索敵の白色のマーカーしか表示されていない

 

が、鉛を追加し重心をスモーク外に出して
索敵線がスモークに当たらないようにしてやると
トラッカー系も正常にはたらく
緑の太字マーカーがカメラトラッカー、黒の太字がレーザーレンジファインダー

地形衝突ダメージの例外

メインオブジェクトのブロックが8個以下なら、地形ダメージを受けない

粒子砲の貫通モードは11個以上のブロックを壊すこともある

粒子砲の光線は曲線のように見えますが、実は100本の線分がつながってできています。

 

Damage and attenuationの値が1.0のとき粒子砲の射程は3912mですから、
このとき1本の線分は3912m÷100≒39mの長さを持ちます。
39mの線分が99回屈折してつながることによって、3912mの曲線を描いているんですね。

 

粒子砲の命中とダメージの判定は、これら39mの線分ごとに行われるので
1本の線分ごとに最大10ブロックを破壊できます。

 

画像では砲口から39m離れた部分から新たに10ブロックの破壊が起こっています。
実験のため屈折量は最小限になるようにしていますが、
39mごとに新たな線分になり、そのたびに上限10ブロックまで破壊できることが分かります。

スラスタの推力設定の不具合は修正された

スラスタの推力を50%にしたとき、推力が0.5 x 0.5 = 0.25倍になっていたバグの修正を確認

アドキャのオートローダセットの組み合わせ比較

連射速度倍率/コストのグラフ
https://www.desmos.com/calculator/r1ebxdmxol

 

こっちが連射速度倍率/体積のグラフ
https://www.desmos.com/calculator/1ccmkdi6em
このグラフのいいところは
左上の l = 1 って書いてあるところのスライダを弄ると
1m以外のローダの速さも比較できるところなんすよ

 

それぞれのセットのクリップ数とフィーダ数は c1 = 1 とか f1 = 1 ってところのスライダで弄れる
ベルトローダのグラフは1m以外では非表示にしておくと吉

 

砲弾長1mでは
体積あたりの連射速度ならベルトが圧倒的だけど、
コストあたりの連射速度はクリップ多めと大差ないですね。

 

ベルトはセルフスモークや曳光弾みたいに、一定間隔で撃たなければいけない弾にも不向きだし、
サブオブジェクトを重ねる前提ならクリップ多めの構成もありかもしれません。

 

同様に2m以上では
体積あたりの連射速度はクリップレスローダーの構成がだいたい速いけど、
コストあたりの連射速度はクリップレスローダーは低く、
クリップ多めの構成が強いですね。

 

クリップレスローダーは配置が簡単で敷き詰めやすいのが利点ですが、
多クリップの構成は配置が難しくなったりスキマができてしまうことがあるので
イジェクタ入れてみたり、配置を工夫してうまく直方体にするといいかも

FtDのブロック浮力は中心1mが浸水したときだけ発生

多分このグラフなんだけど、ちょっとソースのどこなのか特定するのに時間かかってます
中央1m分だけ比例になってるはず・・・
https://www.desmos.com/calculator/hq41shda72

電気エンジンの消費電力効率は実際の消費量に依存する

私も少し触りましたけど、4mバッテリー、4mRTG、ヒートデコイ、イオスラ小2で、充電100消費100のはずが、徐々に充電量が増えてました。
量的には5分で1000ぐらい。電気エンジン出力比での変動は目に見えては見受けられませんでした。(出力が0/100でも220/320でも差はなさげ)
ただ、精密に検査はしていません。(目視で充電量と出力を追っていたぐらい)

 

ヒートデコイ5基で
80 x 5 = 400 power
RTG4m を4基で
25 x 4 x 4 = 400 energy/s

 

電気エンジンの効率は100%に設定してるから
10000 x 0.04 = 400 energy/s なので
バッテリーが10000 energyになったところで平衡するはずがそうはならない

 

実際は10000 energy に近づくほどバッテリーの充電上昇速度は鈍くなるが、
10000 energyを超えるとまた充電上昇速度が上がっていき、12000energyまで充電されてしまう

 

電気エンジンの出力が消費エネルギーを上回っている場合に電気エンジンの効率設定が自動的にアジャストされている?

 

それがひとつ考えられるよね

 

あっソース見たらこれ効率が自動的に適用されてるな・・・

 

電気エンジンの効率は
出力/消費電力 = 2/(1+出力の割合) で決まる。

 

出力が低いと消費電力の2倍近い出力が出るし、
出力が100%のときは消費電力と等しい出力を発揮する。

 

ここで、出力の割合は電気エンジンのQ画面で見るPower outputの値と思われがちだがそうではない。
出力の割合はPower outputの値ではなく、実際に発揮する出力で決まる。
Power outputは実際に発揮する最大出力を制限するだけである。

 

例えば、充電量が10000 energyのとき、電気エンジンの最大出力は10000 x 0.04 = 400 power。
ここでPower outputを60%に制限すると、効率は 2/(1+0.6) = 1.25。
パワーは400 x 0.6 = 240 power。

 

しかし、Power outputを100%に設定していても
電気エンジンが240 powerを発揮しているときは
効率は 2/(1+0.6) = 1.25となり、Power outputを60%に制限したときと同じ効果が得られる。

レーザートランシーバの接続判定

laserconnection0.jpg

サブ→(メインを横切り)→サブ
これもつながる

 

タレットは、レーザートランシーバの接続レーザーをオブジェクト間で中継できる

 

ルール1. タレット側トランシーバはタレットの真上にある必要がある
ルール2. メイン側トランシーバのレーザーはタレットに当たっている必要がある
ルール3. タレットでレーザーを受け取って折り曲げることができるが、その角度は60度未満でなければならない

laserconnection2.jpg

だから2軸タレットならこんな繋げ方もできる

laserconnection1.jpg

以上のテクニックをあまりふまえないで提案する
2軸レーザータレットモデル

laserconnection3.jpg

新HEATの計算式

HEAT貫通距離やっべえな・・・体積の0.1乗ってなんなんだ

 

v2.2.21でのHEAT
https://www.desmos.com/calculator/nbu9mpoafb

GridCastingのバグが修正され、メイン⇔サブ間でも複合装甲効果が乗るように

まっすぐ置いてるメタルブロックがメインオブジェクト
45回して置いてるメタルブロックがサブオブジェクト

 

9000/((15+15x1)x2)=150より、積層ACボーナスが適用されていることが分かる

 

サブオブジェクトが前でも有効やんけこれ

新パドル(Articular Paddle)の仕様

関節パドルは、従来のパドルの発生する力のビークル進行方向(後退方向)の成分のみを発生する
パドルによる無駄な揚力を抑えることができる

HEAT用空間装甲とAPに対する複合装甲

一応知らない人もいるだろうから
HEATの仕様をおさらいしておく

 

メインに着弾した場合、貫通線はサブオブジェクトを通り抜ける
HEAT破片はサブの後ろに発生する
右上には砲弾のKD3ダメージだけが表示されている

 

サブに着弾した場合、貫通線はメインを通らない
HEAT破片はサブを抜けたところで発生し、右上にはHEAT破片がメインに当たって合計43ダメージとなる

 

サブとサブを並べたときも、
着弾したサブオブジェクトを通った貫通線は別のサブオブジェクトを通らない

 

これは、サブオブジェクトの設置順によらない
着弾する側を入れ替えても同様にもう片方のサブオブジェクトを通らない

 

子サブオブジェクトと孫サブオブジェクトを並べた場合は
子を通った貫通線は孫を通って孫の後ろに破片が発生

 

逆に、孫に着弾した場合は貫通線は子を通らず
子に破片が当たる

 

以上のことから分かるが、
HEAT貫通線は着弾したオブジェクトからの直系の子孫のみのオブジェクトを探査することが分かる
親や兄弟は気にしないことが分かる

 

GridCastingは、線とブロックの当たり判定全般を担う箇所であるが、
実はその判定方法には2種類ある。
1.GridCastAllConstructables
2.GridCastOneConstructable

 

1はそのビークルの全てのオブジェクトを探査するメソッド
2は線が初めて当たったオブジェクトの子孫のみを探査するメソッド
で、HEAT貫通は後者のGridCastOneConstructableを使用しているのだ。

 

2.GridCastOneConstructableを採用している判定で重要なものは
・フェイルセーフ
・索敵トラッカー
・HEAT
・HESH
であり、この4つは覚えておくとよい。

 

残りの判定はすべて1.GridCastAllConstructablesである
・ACBの障害物判定
・アバタースキル全般
・アドキャ砲弾
・レーザー
……
等無数にある。

 

つまり、サブオブジェクトに着弾させる装甲を使えば
サブ→メインではHEATやHESHに対しては空間装甲として認識され
キネティックダメージやHEダメージに対しては積層装甲として認識されるのだ。

フラグモジュールのフラグ数が繰り上がる砲直径

00.00mm 破片数1(設定不可)
15.22mm 破片数2(設定不可)
25.94mm 破片数3
35.43mm 破片数4
44.21mm 破片数5
52.48mm 破片数6
60.38mm 破片数7
67.99mm 破片数8
75.34mm 破片数9
82.48mm 破片数10
89.45mm 破片数11
96.25mm 破片数12
102.91mm 破片数13
109.45mm 破片数14
115.87mm 破片数15
122.18mm 破片数16
128.40mm 破片数17
134.53mm 破片数18
133.33mm×60モジュールで砲弾長8mなので、60モジュール弾を撃つなら128.40mmが限界か
しかし精度に必要な砲身長が跳ね上がったりフラグ保持プールの制限もあるのでほどほどの方がよいかも

 

60より少ないモジュールでフラグ弾を撃つときの参考にもどうぞ

 

コメント

  • VerUPがあるからいつごろ書かれたかが微妙にきになりますね。えっと、ある種普遍的な現象の説明なのか、何かブロック結合体の性能を加味した説明なのか、FTDの仕様を使用した方法なのか -- 2018-07-17 (火) 08:19:33