ここに示す内容はCFG File Documentationの翻訳です。
ただし全文訳ではなく、必要に応じて省略・補足・改訂を加えています。
configフォーマット
KSPで利用されるconfigフォーマットはUnityクラスではなく、KSP特有のものです。
KSPは.cfgファイルをconfigノードに読み込みます。
configノードは(シリアル化されたすべてのデータ型の)値と子ノードを持つことができます。
より詳しくはC#クラス ドキュメンテーションを参照してください。
KSPでは、パーツ、燃料資源、UIなど様々なものを定義するためにconfigファイル(*.cfg)を利用しています。
v0.24.2までにおいては、configファイルの必須要素は微々たるものです。
また、順序は不動です。
ただし、互換性及びデバッグ上の理由から一般的な構造を踏襲することを勧めます。
多くのバニラパーツにはあなたが学習する際に助けとなるようなコメント文を含んでいます。
さて、ここでは例として"DoesItAll"というパーツを考えます。
このパーツは以下のフォルダにおかれています。
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll
そしてこのフォルダは以下の3つのファイルを含みます。
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm
注:これは一般例であり、追加の情報は各リンク先を参照してください。
moduleマネージャ
configデータはノード木もしくは文字列のみからなる単純なものです。
configの構文解析は.cfgファイルを利用する各moduleによって行われます。
詳しくはAPIのKSPFieldを参照してください。
MODモジュールマネージャは強力なフィルタリングと拡張機能をconfigノードフォーマットに与えます。
'@'、'[ ]'、その他プログラミングのような記号を見かけたとき、そのconfigはmoduleマネージャによって利用されています。
より詳しくはin the forum threadやon sarbian's Githubを参照してください。
CFGファイルの基本仕様
それぞれのCFGファイルは複数のセクションで構成されており、すべてのファイルに共通なものもあれば、特定のファイルのみに記述されるものもあります。
それらを理解することはMOD作成の上で必須となるでしょう。
CFGファイルでは改行が要素の区切りを表します。
そのため、1行に複数のフィールドを記述したり、逆に1つのフィールドを複数行にまたがって記述することはできません。
CFGファイルは構造体、フィールド、コメントからなります。
構造体は複数の子構造体とフィールドをまとめる構文です。
構造体の定義は以下のように、構造体名 + "{" + 構造体の内容 + "}"と記述します。
PART
{
~~~
}
フィールドは実際に値を設定するための構文です。
フィールドの定義は以下のように、フィールド名 + "=" + 値と記述します。
mass = 1.50
コメントはCFGファイルに補足説明を加えるためのものです。
コメント文はゲームに反映されることはありません。
以下のように、"//"からその行の終わりまでがコメント文となります。
mass = 1.50 // ここはコメント文です
標準的なパーツCFG作成ガイドライン
すべてのパーツはconfigファイル、モデル/コリジョンメッシュなど複数のファイルからなります。
バージョン0.25においては、モデル/コリジョンメッシュはモデリングソフトウェアで作成され、エクスポート時には材料が割り当てられている必要があります。
ここではモデリングについての導入は省きます。
新しいパーツを作るとき、すべてのファイル(必要ならば追加のモデルやメッシュを含む)を、そのパーツのフォルダにまとめておく必要があります。
この点においてはSquad自身が恐ろしく矛盾をしていますが、フォルダ名をパーツ名とし、なおかつcfgファイル中で参照するパーツ名と一致させることが望ましいです。
(ここで言うパーツ名とはビルド名ではありません。詳しくは後述)
複数のパーツを作る場合、パーツの種類ごとにフォルダ分けしたいと考えるかもしれません。
これは実際利にかなっており、Squadもそのようにしています。
例えば、エンジンを作ったならば"/Engines/"ディレクトリに配置するのがよいでしょう。
ただパーツを提供する以上のことをするMODをつくるなら、パーツフォルダや他の機能のフォルダといったように更なるサブフォルダを作りたい場合もあるでしょう。
MODフォルダはどれほど深くネストしても構いませんが、MOD固有のフォルダにまとめて/GameDataフォルダに配置しておくべきでしょう。
これは、MOD配布の際に非常に利便性を向上させます。
例えば、"ShadowSplat"というMODパッケージを作成した場合、そのディレクトリ構造を以下のようにするということが考えられます。
KSP_win\GameData\ShadowSplat\
KSP_win\GameData\ShadowSplat\Agencies
KSP_win\GameData\ShadowSplat\Resources
KSP_win\GameData\ShadowSplat\Parts
KSP_win\GameData\ShadowSplat\Parts\Engine
KSP_win\GameData\ShadowSplat\Parts\FuelTank
KSP_win\GameData\ShadowSplat\Parts\Science
KSP_win\GameData\ShadowSplat\Parts\Electrical
このように、"\GameData\[MODパッケージ名]\[グループ]\[カテゴリ名]\[パーツ名]\"などのようにするのが実用的でしょう。
パーツの定義は、すべてPART構造体の中に記述します。
基礎パラメータ
これらはPART構造体において基本的に必須であると考えられるフィールドです。
フィールド | 説明 |
name | パーツの内部名です。空白文字は許可されません。アンダースコアおよびその他の記号は許可されないか推奨されません。パーツ固有でなければなりません。この名前はほかのパーツがこのパーツを参照する際に利用されます。また、エラーメッセージにおいて利用されます。 |
module | この規則は現在のバージョンでは利用されなくなりました。基本的に常に"Part"を指定しておきます。 |
author | このパーツの作者です。ゲーム中参照されることはありません。あなた或いはあなたのプロジェクトチームを特定できる固有名であることが推奨されます。 |
Part
{
name = InternalUniqueModelName
module = Part
author = AuthorName
~~~
}
モデルパラメータ
レガシーバージョンではmeshフィールドにより定義していましたが、現在は以下のフィールドからなるMODEL構造体で定義することが推奨されます。
が、やはりレガシー構文を現在も利用しているMODも多いようです。
フィールド | 説明 |
model | メッシュファイルのファイル名です。同じフォルダに配置されているメッシュファイルを指定する必要があります。GameDataディレクトリ以下のパス名を指定します。拡張子不要。 |
scale | モデルの拡大率を表します。モデリングツールに依存します。モデリング単位がメートルである場合は1を、センチメートルである場合は0.01を指定します。 |
texture |
互換性のため以下の構文が残されています。
mesh | アセットパラメータに含まれます。メッシュとテクスチャのパッケージを指定します。一般に.muファイルを指定します。 |
Part
{
~~~
MODEL
{
model = Squad/Part/Utility/ModelFileDir/ModelFileName
scale = 1.0
texture = TextureFileName.png
}
~~~
}
アセットパラメータ
フィールド | 説明 |
mesh | メッシュとテクスチャのパッケージを指定します。一般に.muファイルを指定します。現行バージョンでは代わりにMODEL構造体を使用することが推奨されます。 |
scale | モデルの拡大率を表します。現行バージョンでは代わりにMODEL構造体を使用することが推奨されます。基本的に1以外の値は非推奨のようです。 |
specPower | 使途不明。 |
rimFalloff | 使途不明。 |
alphaCutoff | 使途不明。 |
rescaleFactor | オプショナルパラメータ。ゲーム中においてモデルをリサイズしたい場合に指定します。 |
iconCenter | アイコンの中心を示す。整数配列? |
Part
{
~~~
mesh = ModelFileName.mu
scale = 1.0
~~~
}
コネクタノードの定義
他パーツをアタッチできる/にアタッチするためのコネクタノードを定義します。
記述形式をいかに示します。
[ノード名] = x, y, z, angx, angy, angz, size
以下に示す複数のノード名が利用できることが知られていますが、node_attach以外は単にノードの位置をわかりやすくするために便宜的に名づけられているに過ぎないようです。
- node_attach
- node_stack_top
- node_stack_bottom
- node_stack_connect01
- node_stack_connect02
- node_stack_connect03
- node_stack_bottom01
- node_stack_bottom02
- node_stack_bottom03
- node_stack_bottom04
以下にコネクタノード定義の例を示します。
Part
{
~~~
node_stack_top=0.0, 1.65, 0.0, 0.0, 1.0, 0.0, 2 // ノード名"node_stack_top"として、位置(0.0, 1.65, 0.0)に向き(0.0, 1.0, 0.0)でサイズ2のコネクタを作る。
~~~
}
FX定義
視覚FX
比較的新しいパーツではこれらフィールドを設定する代わりにEFFECTS構造体を定義しているようです。
パーツに関連付けられた、エンジンの噴煙・爆発・着色などの視覚エフェクトを視覚FXとして定義します。
各々が固有のエフェクトを表し、エフェクトの配置のパラメータを持ちます。
末尾の'Active'スイッチはエフェクトがどのようなときに表示されるかを表します。
視覚FX定義は以下のように記述します。
[fxName] = x, y, z, angx, angy, angz, [scenes]
どのようなエフェクトが利用可能で、どのようなときに使用されているかを知りたいときはFXグループリストを参照してください。
複数のscenesをエフェクトに割り当てることも可能です。
例えば、activeでもdeactiveでも煙のエフェクトを表示させたいときには以下のように記述するといいでしょう。
fx_gasBurst_white = x, y, z, angx, angy, angz, activate, deactivate
これは、RCSのガス放出など多くのエフェクトを定義したい場合に便利です。
fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, activate
fx_exhaustLight_yellow = x, y, z, angx, angy, angz, activate
fx_smokeTrail_medium = x, y, z, angx, angy, angz, activate
以下のようなFXが知られています。
- fx_exhaustFlame_blue_small
- fx_exhaustFlame_yellow
- fx_exhaustFlame_yellow_tiny
- fx_exhaustFlame_blue
- fx_exhaustFlame_white_tiny
- fx_exhaustLight_yellow
- fx_exhaustLight_blue
- fx_smokeTrail_medium
- fx_smokeTrail_light
- fx_gasBurst_white
- fx_exhaustSparks_flameout
- fx_exhaustSparks_yellow
PART
{
~~~
fx_exhaustFlame_blue = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, running
~~~
}
効果音FXの定義
比較的新しいパーツではこれらフィールドを設定する代わりにEFFECTS構造体を定義しているようです。
視覚エフェクト同様に効果音も定義することができます。
効果音FX定義は以下のように記述します。
[soundName] = [scenes]
以下のような効果音FXが知られています。
- sound_jet_low
- sound_jet_deep
- sound_vent_soft
- sound_vent_large
- sound_vent_medium
- sound_rocket_hard
- sound_rocket_mini
- sound_decoupler_fire
- sound_explosion_low
- sound_parachute_open
- sound_parachute_single
PART
{
~~~
sound_rocket_hard = running
~~~
}
視覚FXおよび効果音FXでscenesに設定できる値は以下のようなものが知られています。
列挙子 | 主な利用シーン |
activate | 汎用:パーツの機能が有効になった |
deactivate | 汎用:パーツの機能が無効になった |
engage | エンジン:起動時 |
running | エンジン:起動中 |
disengage | エンジン:休止時 |
flameout | エンジン:停止時 |
decouple | デカプラ:起動時 |
deploy | パラシュート:展開時 |
エディタパラメータ
フィールド | 説明 |
CrewCapacity | 搭乗できるKerbalの人数。Mk1 Command Podなら1が、各種プローブなら1が設定されています。偉大な飛行士Jebは0.7人分の席しか消費しません。チャック・ノリスは彼のほしいがままに席を消費します。 |
TechRequired | キャリアモードにおいて、パーツが登録されるテックツリーのノード。あらゆるワードが設定可能ですが、テックツリーに存在しないワードを設定した場合そのパーツはどうやっても利用できなくなることに注意してください。バニラで利用できるワードはテックツリーノードを参照してください。 |
entryCost | パーツの解放に必要なFundsコスト。開発投資といえるでしょう。任意の値を設定できます。キャリアモードでのみ効果を発揮します。 |
cost | パーツを利用する際に1つ辺りに必要なFundsコスト。購入費といえるでしょう。ここで設定されるコストは満載時のコストであることに注意してください。キャリアモードでのみ効果を発揮します。 |
category | パーツのカテゴリ。各パーツはcfgファイルの配置されたディレクトリとこのフィールドの値によってソートされます。現在は以下のものが利用できます。 Pods Propulsion (非推奨) FuelTank Engine Aero Electrical Structural Utility Wheel |
subCategory | categoryフィールドによる分類を補足するために用意されていると思われますが、ver0.90時点では利用されていません。 |
title | ゲーム中でのパーツ名。例えば"Command Pod Mk1"など。プレイヤーが普段目にするパーツ名であり、ゲーム中メニューに表示されるパーツ名であり、各種コミュニティで情報交換される場合に恐らく使われるであろうパーツ名です。 |
manufacturer | ゲーム中でのパーツメーカ名。基本的にはフレーバーテキストですが、VAB/SPHではパーツメーカごとの分類も利用できるようになっています。 |
description | ゲーム中でのパーツの説明。VAB/SPHで表示されるフレーバーテキスト。パーツの目的や用途を説明したり、多くのバニラパーツ同様にジョークを含めたりできます。改行を利用できない他には特に制限はないようです。 |
PART
{
~~~
CrewCapacity = 1
TechRequired = start
entryCost = 0
cost = 600
category = Pods
subcategory = 0
title = Mk1 Command Pod
manufacturer = Kerlington Model Rockets and Paper Products Inc
description = Originally built as a placeholder for a demonstration mock-up of a rocket, the Mk1 Command Pod was heralded as a far safer and more reliable option than its predecessors by rocket scientists throughout the world. It is now commonly seen in active service.
~~~
}
アタッチメントルール
attachRules | このパーツを他パーツに取り付けたり、逆に他パーツをこのパーツに取り付ける際のルールを定義します。 |
stackSymmetry | パーツ対称配置において対称数を制限します。2~4分岐アダプタなどで利用します。対称扱いとなるコネクタの組は自動で判断されるようです。 |
attachRulesは以下のように5つの値(0または1)により定義されます。
attachRules = stack, SrfAttach, allowStack, allowSrfAttach, allowCollision
- stack
- このパーツを他パーツのコネクタに取り付けることができるか
- SrfAttach
- このパーツを他パーツの側面に取り付けることができるか
- allowStack
- 他パーツをこのパーツのコネクタに取り付けることができるか
- allowSrfAttach
- 他パーツをこのパーツの側面に取り付けることができるか
- allowCollision
- このパーツを他パーツと重なるように取り付けることができるか
0は不可を、1は許可を表します。
stackSymmetryは0:対称性なし、1:2回対称、2:3回対称、3:4回対称…という風になっています。
PART
{
~~~
attachRules = attachRules = 1,0,1,0,0 // 他パーツのコネクタに取付可、他パーツの側面に取付不可、他パーツをコネクタに取付可、他パーツを側面に取付不可、他パーツと重なる取付不可
stackSymmetry = 2 // このパーツのコネクタへの対称配置を3回対称に限定
~~~
}
標準パーツパラメータ
パーツの物理的ふるまいを定義します。
必ずしもすべてを定義する必要はありません。省略された値にはデフォルト値が適用されます。
ここで定義された値は、射点や滑走路に機体が配置されてから常に利用され続けます。
フィールド | 説明 |
mass | 設定推奨。トン単位(ただしKerbalトン)のパーツ質量。正の実数で定義します。極端に大きい数字を与えると、ゲーム中でパーツが正常に動作しなくなる可能性があります。乾燥重量であることに注意してください。 |
dragModelType | 設定推奨。空力計算モデル。現在のところ、default以外に設定できる値はありません。 |
maximum_drag | 最大空気抵抗係数。一般的に0.2~0.3、大きくとも1未満。 |
minimum_drag | 最少空気抵抗係数。一般的に0.2~0.3、大きくとも1未満。dragModelTypeがdefaultである場合は利用されていないようです。 |
angularDrag | 角空気抵抗係数。空気抵抗のうちモーメントにかかわる成分を決定すると思われます。一般的に1以下。 |
crashTolerance | 設定推奨。他のパーツや地表にぶつかったときに破壊されない上限の速度。ポッドには12、固定着陸脚には14、ランディングホイールには50などの値が設定されています。 |
breakingForce | 他のパーツとの接続強度。引張強度・圧縮強度を表していると考えられます。数字が大きいほど接続が強くなります。省略した場合デフォルトの200が設定されます。 |
breakingTorque | 他のパーツとの接続強度。曲げ強度を表していると考えられます。数字が大きいほど接続が強くなります。省略した場合デフォルトのデフォルトでは200が設定されます。 |
maxTemp | 設定推奨。パーツの破壊温度。バニラの場合、熱に弱いパーツで1200、強いパーツで2400~などの数字が設定されています。 |
ActivatesEvenIfDisconnected | trueまたはfalseを設定します。パーツが機体から分離された後でも起動できるかを表します。現在のところ、バニラにおいてはSepratron Iのみで利用されています。 |
stageingIcon | ステージに表示されるアイコンを表します。以下のものが利用できます。 DECOUPLER_VERT DECOUPLER_HOR LIQUID_ENGINE SOLID_BOOSTER RCS_MODULE FUEL_TANK COMMAND_POD |
stageOffset | 整数が利用できます。このパーツが新しいステージを作るかどうかを設定します。パラシュートなどには-1が設定されています。 |
childStageOffset | 整数が利用できます。このパーツの小パーツが新しいステージを作るかどうかを設定します。 |
explosionPotential | 使途不明。バニラではコマンドポッドに0が、制御翼に0.1などが設定されています。 |
fuelCrossFeed | TrueまたはFalseを設定します。Falseの場合、このパーツを介して燃料供給されなくなります。 |
NoCrossFeedNodeKey | bottomなどを設定します。ここで設定されたコネクタからは燃料供給されなくなります。 |
linearStrength | 2パーツ間に生じる強度。引張強度・圧縮強度を表していると考えられます。Fuel LineやStruct Connectorで利用されています。 |
angularStrength | 2パーツ間に生じる強度。曲げ強度を表していると考えられます。Fuel LineやStruct Connectorで利用されています。 |
maxLength | 接続距離の限界。メートル単位で指定。Fuel LineやStruct Connectorで利用されています。 |
vesselType | 機体の分類種別。以下のものが利用できます。 Ship Probe Lander Rover SpaceObject |
PhysicsSignificance | 0または1を設定します。1が設定されたパーツは物理演算が省略されます。 |
MODULE
MODULE構造体はパーツの挙動を定義するために使用します。
これら構造体はゲーム中においてKSP本体やMODのライブラリが実装するメソッドを呼び出し実行します。
nameフィールドでは呼び出したいMODULEの具体名を指定します。
例えばClamp-O-Tron Docking Port Sr.にはドッキングポートの機能を提供するModuleDockingNodeモジュールが定義されています。
PART
{
~~~
MODULE
{
name = ModuleDockingNode
~~~
}
~~~
}
既知のモジュールは以下の様なものがあります。
モジュール名 | 提供される機能 | モジュールの実装 |
ModuleCargoBay | カーゴベイ | バニラ |
ModuleParachute | パラシュート | バニラ |
ModuleSAS | SAS姿勢制御レベル | バニラ |
KerbalSeat | オープンシート | バニラ |
ModuleLandingGear | ランディングギア | バニラ |
ModuleSteering | ホイールのステアリング動作 | バニラ |
FXModuleConstraingPosition | 不明 | バニラ |
ModuleLandingLeg | 着陸脚 | バニラ |
RetractableLadder | 収納式梯子 | バニラ |
ModuleReactionWheel | SASリアクションホイール | バニラ |
ModuleScienceContainer | サイエンス記憶装置 | バニラ |
FlagDecal | 旗の貼り付け | バニラ |
ModuleScienceLab | サイエンス実験装置 | バニラ |
ModuleJettison | 投棄式フェアリング | バニラ |
ModuleAlternator | エンジン噴射を利用した発電機 | バニラ |
ModuleCommand | コマンドポッド | バニラ |
ModuleEnviroSensor | 環境センサ | バニラ |
ModuleControlSurface | 制御翼/エルロン | バニラ |
ModuleAnimateHeat | 加熱に伴うアニメーション | バニラ |
ModuleEngines | エンジンとその噴射(やや非推奨) | バニラ |
FXModuleAnimateThrottle | スロットル制御に伴うアニメーション | バニラ |
ModuleEnginesFX | エンジンとその噴射 (ModuleEnginesの代わりにこちらを推奨) | バニラ |
ModuleGimbal | エンジンのジンバル制御 | バニラ |
ModuleTestSubject | パーツテスト (一般にはキャリアミッションが動的生成する) | バニラ |
LaunchClamp | 発射装置 | バニラ |
ModuleDockingNode | ドッキングポート | バニラ |
ModuleRCS | RCSスラスタ | バニラ |
ModuleResourceIntake | エアインテーク | バニラ |
ModuleScienceExperiment | サイエンス実験装置 | バニラ |
ModuleGrappleNode | the Klaw | バニラ |
ModuleLight | 室外灯 | バニラ |
ModuleAnimateGeneric | 標準的なアニメーション | バニラ |
ModuleDataTransmitter | アンテナ | バニラ |
FXModuleLockAtConstraint | 不明 | バニラ |
ModuleAsteroid | 不明 | バニラ |
ModuleDeployableSolarPanel | 展開式ソーラーパネル | バニラ |
ModuleWheel | ホイール | バニラ |
FXModuleLookAtConstraint | 不明 | バニラ |
FXModuleConstrainPosition | 不明 | バニラ |
ModuleAnchoredDecoupler | デカプラ | バニラ |
ModuleDecouple | デカプラ | バニラ |
KASModuleContainer | コンテナ | KAS / Kerbal Assembly System |
KASModuleGrab | KAS / Kerbal Assembly System | |
KASModuleStrut | KAS / Kerbal Assembly System | |
SCANset | SCANsat | |
TweakScale | パーツサイズ変更 | TweakScale |
MechJebCore | MechJeb制御装置 | MechJeb |
ModuleConnectedLivingSpace | MKS/OKS / Modular Kolonization System | |
KolonyConverter | MKS/OKS / Modular Kolonization System | |
MKSModule | MKS/OKS / Modular Kolonization System | |
ExWorkshop | MKS/OKS / Modular Kolonization System | |
KarboniteAtmoExtractor | MKS/OKS / Modular Kolonization System | |
KarboniteDrill | MKS/OKS / Modular Kolonization System | |
KarboniteGenerator | MKS/OKS / Modular Kolonization System | |
KarboniteParticleExtractor | MKS/OKS / Modular Kolonization System | |
KarboniteConverter | MKS/OKS / Modular Kolonization System | |
USI_Converter | MKS/OKS / Modular Kolonization System | |
USIAnimation | MKS/OKS / Modular Kolonization System | |
USI_BaseAnchor | MKS/OKS / Modular Kolonization System | |
USI_InertialDampener | MKS/OKS / Modular Kolonization System | |
ProxyLogistics | MKS/OKS / Modular Kolonization System | |
FSanimateGeneric | Firespitter | |
FStextureSwitch2 | Firespitter | |
FSfuelSwitch | Firespitter | |
MKSLcentral | MKS/OKS / Modular Kolonization System | |
ORSModuleAirScoop | MKS/OKS / Modular Kolonization System | |
ORSModuleAirIntake | MKS/OKS / Modular Kolonization System | |
ORSResourceScanner | MKS/OKS / Modular Kolonization System | |
ORSModuleRailsExtraction | MKS/OKS / Modular Kolonization System | |
ORSModuleParticleCollector | MKS/OKS / Modular Kolonization System | |
ORSAnimatedScanner | MKS/OKS / Modular Kolonization System | |
ORSAnimatedExtractor | MKS/OKS / Modular Kolonization System | |
ModuleSPU | Remote Tech | |
ModuleRTAntennaPassive | Remote Tech | |
FSplanePropellerSpinner | Firespitter | |
FSengineSounds | FSengineSounds |
MODULEは1つのパーツにいくつでも持たせることができます。
基本的にはMODULE名が同一のものが複数含まれていても問題ありません。
INTERNAL
INTERNAL構造体は、IVAで見られる船の内装を作成するためのファイルを指定するために使用します。
一般的には、内装CFGはMOD中のSpacesディレクトリに配置されます。
KSPはパーツCFGのPART.INTERNAL.nameフィールドと内装CFGのINTERNAL.nameフィールドを比較し、一致するものをその有緑パーツの内装として呼び出すようです。
バニラでは以下の9つの内装が用意されています。
- crewCabinInternals
- cupolaInternal
- GenericSpace1
- GenericSpace3
- landerCabinInternals
- landerCabinSmallInternal
- mk1CockpitInternal
- mk1PodCockpit
- PodCockpit
PART
{
~~~
INTERNAL
{
name = mk1PodCockpit
}
~~~
}
RESOURCE
RESOURCE構造体は、そのパーツが燃料や電気などのリソースを備蓄できることを指定するために使用します。
リソース1つにつき1つのRESOURCE構造体が必要になります。
RESOURCEは1つのパーツにいくつでももたせることができます。
フィールド名 | 例 | 説明 |
name | ElectricCharge | 備蓄するリソースの名前。 |
amount | 100 | リソースの初期搭載量。 |
maxAmount | 100 | リソースの最大搭載量。 |
isTweakable | false | VAB/SPHでリソース搭載量を変更できるかどうか。 |
hideFlow | true | リソースの移動が可視であるかどうか。このフィールドが何故必要なのかは詳しくわかっていません。 |
バニラでは以下のリソース名が利用できます。
- LiquidFuel
- Oxidizer
- SolidFuel
- MonoPropellant
- XenonGas
- ElectricCharge
- IntakeAir
- EVA Propellant
- Ore
- Ablator
PART
{
~~~
RESOURCE
{
name = ElectricCharge
amount = 100
maxAmount = 100
isTweakable = false
hideFlow = true
}
~~~
}
リソースCFGファイル
KSPではゲーム中必要な燃料や電気などのリソースもCFGファイルで定義しており、好きな様に変更や追加が可能です。
バニラのリソースは\GameData\Squad\Resources\ResourcesGeneric.cfgで定義されています。
リソースの定義はRESOURCE_DEFINITION構造体で行います。
フィールド名 | 例 | 説明 |
name | LiquidFuel | リソースの名前。スペースやアンダーバーを利用することも可能です。 |
density | 0.005 | リソース1単位あたりの密度。 |
unitCost | 0.8 | リソース1単位あたりのFundsコスト。 |
hsp | 2010 | 比熱。リソース1トンあたりの熱容量。densityやunitCostと異なり、リソース1単位ごとの指定でないので注意。 |
flowMode | STACK_RIORITY_SEARCH | 宇宙機にこのリソースのタンクが複数装備されているとき、どのような順番で消費されるかを指定します。 |
transfer | PUMP NONE | フライトモードにおいてリソースをマニュアルで移動できるかどうかを指定します。PUMPが設定されているリソースはAlt+右クリックでパーツ間のリソース移動が可能となります。 |
isTweakable | true false | オプショナル。リソースが宇宙機建造時に割り当て可能かどうか。デフォルトではtrueです。 |
flowModeには以下の値を指定できます。
- STACK_PRIORITY_SEARCH
- 建造時の積み重ね順に消費されます。すなわち、VAB/SPHにおけるルートパーツに近い順に消費されます。FuelLineを利用すると消費順を変更することができます。
- STAGE_PRIORITY_FLOW
- 現在のステージに属するパーツから消費されます。ステージが異なるパーツからは消費されません。FuelLineを利用すると他のステージからも消費できるようになります。
- ALL_VESSEL
- 機体全体から一様に消費されます。
- NO_FLOW
- リソースは他のパーツに移動しません。リソースを備蓄しているパーツのみが消費できます。
RESOURCE_DEFINITION
{
name = LiquidFuel
density = 0.005
unitCost = 0.8
hsp = 2010
flowMode = STACK_PRIORITY_SEARCH
transfer = PUMP
isTweakable = true
}
Science CFG
サイエンス実験の種類を定義します。
(編集中・・・)
Contracts Definitions CFG
Mission Controlで受けられるミッションの説明文を自動生成するためのジェネレータを定義します。
(編集中・・・)
Contracts CFG
Mission Controlで受けられるミッションの内容を定義します。
(編集中・・・)
Agent CFG
Mission Controlで受けられるミッションの発注者を定義します。
(編集中・・・)
Kerbal CFG
ユニークKerbalを定義します。
(編集中・・・)
Props CFG
ゲーム中に利用されるUIなどを定義します。
(編集中・・・)
Internals CFG
有緑パーツの内装を定義します。
(編集中・・・)
Strategies CFG
Administration Buildingで実行できる戦略を定義します。
(編集中・・・)
Department CFG
Administration Buildingで実行できる戦略の分類を定義します。
(編集中・・・)
コメント
- やー、こういうの訳してくれると助かるわぁ -- 2015-11-27 (金) 18:16:07
- TechRequiredの項目注意。大文字小文字の間違えでも使えなくなります。サンドボックスで使えるのにキャリアやサイエンスモードで使えない場合、ここが間違えている可能性があります。 -- 2020-12-11 (金) 21:55:39
- 因みに、公開されてるMOD、DeepSky/ThorTech/razor_VTOL、WarpJetエンジンの設定で確認しました。使用するときは自分で設定してください。 -- 2020-12-11 (金) 23:51:16
- OPTとThorTechの修正MOD作成例を添付しときます。設定テキスト作成の参考にどうぞ。(https://spacedock.info/mod/2699/KSP%20Old%20Patch?ga=%3CGame+3102+%27Kerbal+Space+Program%27%3E) -- 2021-04-10 (土) 22:22:36
- TechRequiredの使用できるパラメータ記載WIKI(英語)のリンクはこちら:https://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation -- 2021-04-10 (土) 22:26:31