Difference between revisions of "CFG File Documentation/ko"

From Kerbal Space Program Wiki
Jump to: navigation, search
m
m (INTERNAL)
 
(2 intermediate revisions by 2 users not shown)
Line 113: Line 113:
 
|}
 
|}
  
=== Node Definitions ===
+
=== 노드 정의 ===
 
So, node definitions are a little weird.  You don't have to use any, and you *can use a whole bunch.  Defines where parts attach to other parts.  Tricouplers have four: three bottom and one at the top, while most parts simply have two, and a few parts have only one.   
 
So, node definitions are a little weird.  You don't have to use any, and you *can use a whole bunch.  Defines where parts attach to other parts.  Tricouplers have four: three bottom and one at the top, while most parts simply have two, and a few parts have only one.   
  
Line 154: Line 154:
 
</pre>
 
</pre>
  
=== FX definitions ===
+
=== FX (효과) 정의 ===
 
FX definitions specify visual effects associated with this part, including engine exhausts, explosions, and coloration.  Each one is a unique effect, and the only parameters they take is the location/offset that the effect occurs at.   
 
FX definitions specify visual effects associated with this part, including engine exhausts, explosions, and coloration.  Each one is a unique effect, and the only parameters they take is the location/offset that the effect occurs at.   
 
The 'active' switch on the end is used to define ''when'' this effect will be visible. See the [[FX Groups]] listing to know which effect groups are available, and when they are used.
 
The 'active' switch on the end is used to define ''when'' this effect will be visible. See the [[FX Groups]] listing to know which effect groups are available, and when they are used.
Line 185: Line 185:
 
* fx_exhaustSparks_yellow
 
* fx_exhaustSparks_yellow
  
=== Sound FX definitions ===
+
=== 사운드 FX (효과) 정의 ===
 
Just like Visual effects, sound effects specify an effect to be used by the part.  Sound effects are coded using a two-sided equation, the left side specifies the sound or sound file to be used, whereas the right side specifies when to use that particular sound.  Known Sound Effects definitions are:
 
Just like Visual effects, sound effects specify an effect to be used by the part.  Sound effects are coded using a two-sided equation, the left side specifies the sound or sound file to be used, whereas the right side specifies when to use that particular sound.  Known Sound Effects definitions are:
  
Line 240: Line 240:
 
|}  
 
|}  
  
=== Editor Parameters ===
+
=== 에디터 수치 ===
 
{|class="wikitable"
 
{|class="wikitable"
 
|-
 
|-
Line 330: Line 330:
 
|}
 
|}
  
=== Attachment rules ===
+
=== 부착 규칙 ===
 
attachRules defines how this part attaches to or allows attachments from other parts.  Though documented in some part files, the documentation is minimalist and difficult to understand, so here's a little clean-up and expansion.  
 
attachRules defines how this part attaches to or allows attachments from other parts.  Though documented in some part files, the documentation is minimalist and difficult to understand, so here's a little clean-up and expansion.  
  
Line 357: Line 357:
  
  
=== Standard Part Parameters ===
+
=== 일반적인 부품의 수치들 ===
 
This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them.  Standard part parameters indicate how the part interacts with the environment in flight mode.  From mounting on the launch platform or the runway through take-off and atmospheric interactions to landing and blowing up, this is where physics enters the game
 
This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them.  Standard part parameters indicate how the part interacts with the environment in flight mode.  From mounting on the launch platform or the runway through take-off and atmospheric interactions to landing and blowing up, this is where physics enters the game
  
Line 610: Line 610:
  
 
=== INTERNAL ===
 
=== INTERNAL ===
Internal specifies the internal files used to construct views from the IVA or internal vehicular activity, and are referenced out to the \Spaces\ directory of the relevant part mod. (Squad's internals are in \GameData\Squad\Spaces). INTERNALs have their own .cfg files with their own calls and methods that will not be discussed here. For details of these cfgs, please refer to #REDIRECT [[INTERNAL cfgs]].  Squad provides 9 INTERNALs as part of Stock KSP:
+
INTERNAl 구문은 IVA 상태에서 보이는 내부를 지정하는데 사용되고, 모드 내의 \Spaces\ 폴더 안에 있는 것들과 관련이 있습니다. (스쿼드 기본 내부 화면은 \GameData\Squad\Spaces 경로에 있습니다). INTERNAL 파일은 독자적인 .cfg 파일과 호출 함수들이 있지만 여기서 다루진 않습니다. 이에 관해선 항목을 참고하시길 바랍니다. 스쿼드는 9개의 기본 INTERNAL 을 제공합니다:
  
 
* crewCabinInternals
 
* crewCabinInternals
Line 623: Line 623:
  
 
=== RESOURCE ===
 
=== RESOURCE ===
In parts files, [RESOURCE] refers to a resource that is stored by a part. Each stored resource must be separately defined by a [RESOURCE] call. Any resource may be stored, including those not defined.
+
부품 파일 내에서 [RESOURCE] 부분은 부품이 가지게 되는 자원과 관련이 있습니다. 각각의 자원은 각각의 [RESOURCE] 호출을 사용해야 합니다. 정의되지 않은 자원을 포함, 어떤 자원이라도 가질 수 있습니다.
 
{|class="wikitable"
 
{|class="wikitable"
 
|-
 
|-
! variable !! example !! explanation
+
! 변수 !! !! 설명
 
|-
 
|-
| name || || name of the resource being stored
+
| name || || 저장돼 있는 자원의 이름을 지정
 
|-
 
|-
| amount || || amount of the resource initially provided. When dragged from the parts list to your vessel, this is the amount of the resource that it attaches with
+
| amount || || 자원의 저장량의 지정. 부품을 탭에서 꺼내서 부착했을때 가지고 있는 기본 자원량을 지정합니다.
 
|-
 
|-
| maxAmount || || This is the maximum amount of the resource that this part can store. I haven't tried it myself, but I wouldn't recommend setting amount higher than this.
+
| maxAmount || || 저장할 수 있는 자원의 최대량을 지정합니다. 해보진 않았지만, amount 값보다 더 큰 값을 하는걸 추천하지 않습니다.
 
|-
 
|-
| isTweakable || || In the parts file, I believe this is what prevents you from filling the part prior to launch
+
| isTweakable || || 부품 파일 내에선, 쏘아올리기 전에 연료 량을 변경할 수 있도록 해주는 구문인것 같습니다.
 
|-
 
|-
| hideFlow || || Prevents display of motion of resource transfer. Not sure why this would be important.
+
| hideFlow || || 자원을 전송할때 그 이동을 표시하지 않습니다. 이게 뭐가 중요한지 모르겠군요.
 
|}
 
|}
  
Line 646: Line 646:
 
| Thrust ||  AUDIO  ||  ||  
 
| Thrust ||  AUDIO  ||  ||  
 
|-
 
|-
| || || clip || specifies the location of an audio clip to play during the specified thrust effect.
+
| || || clip || 특정 엔진의 추진 효과에 사용될 오디오 파일의 위치를 지정합니다.
 
|-
 
|-
 
| || || volume ||  
 
| || || volume ||  
??  2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings
+
??  2개의 수치, 하나는 최소 볼륨을, 하나는 최대 볼륨을 지정하고 게임의 볼륨 설정과 관련이 있습니다.
 
|-
 
|-
 
| || || pitch ||  
 
| || || pitch ||  
?? 2-part array, used twice, once to specify a minimum volume, once to specify a maximum volume, relative to the game's volume settings
+
?? 2개의 수치, 하나는 최소 볼륨을, 하나는 최대 볼륨을 지정하고 게임의 볼륨 설정과 관련이 있습니다.
 
|-
 
|-
 
| || || loop ||  
 
| || || loop ||  
boolean, true or false, specifies whether to play the sound once, or to keep playing the sound as long as the specified effect is in operation
+
2진수 값을 가짐, true 혹은 false, 효과음이 한번 재생될 것인지, 특정 동작을 하는 동안 반복적으로 재생될 것인지 지정함.
 
|}
 
|}
  
Line 1,177: Line 1,177:
  
 
== ==
 
== ==
[[Category:Tutorials]][[Category:Documentation]]
+
[[Category:Tutorials/ko]]
 +
[[Category:Documentation/ko]]

Latest revision as of 15:44, 7 March 2020

이 글이 유용하다고 생각되거나 이 정보를 잘 이용했다면, 상단의 Discussion(토론)섹션을 클릭해서 댓글을 남겨주시면 감사하겠습니다. 작은 댓글이지만 이 일을 하는 데에 약간의 보람을 느낄 수 있게 해주고, 솔직히 말하자면, 아무도 그렇게 안해준다면 여기서 멈추고 그냥 혼자만 알고 있겠습니다. 그래요, 이런 정보들을 혼자서 알아내야 하겠죠. 하지만 하나 말해주자면, 이걸 하기 위해 정보를 모우는건 진짜 힘든 일이였습니다.

중요한 안내: CFG 파일에는 여러가지 종류가 있습니다. 가장 보편적인 형태의, 그리고 사람들이 가장 자주 관심을 가지는 것은 부품 CFG 파일입니다. 하지만 연료와 같은 자원들에 대한(것 뿐만 아니라 그 이외에도 다른) CFG 파일들이 존재합니다. 우선 부품 CFG 파일에 대해 설명하고, 다음에 자원에 대한 것들을 설명하겠습니다.

부품을 만드는 기본적인 설명서

모든 부품들은 CFG 파일을 포함해, 3D 모델이나 텍스쳐와 같은 여러개의 파일로 구성되어져 있습니다. 0.25 기준으론, 모델 및 충돌 판정 메쉬는 게임에서 사용하기 위해 출력하기 이전에 모델링 소프트웨어에서 둘다 텍스쳐를 할당해주어야 합니다. 저는 모델러가 아니라, 이부분에 대해선 좀더 적당한 사람에게 맡기겠습니다.

새로운 부품을 만들때, 각각의 파일은 (만약 필요하다면, 추가적인 모델과 메쉬 포함) 부품의 이름 혹은 적절한 설명을 이름으로 가진 단 하나의 폴더에 들어있어야 합니다. 스쿼드 조차 새 부품을 만들때 매우 불규칙적이긴 하지만, 폴더의 이름과 각각의 텍스쳐와 모델 파일은 CFG 파일안에 있는 부품명과 일치하는것이 가장 낫습니다 (게임내 VAB나 SPH에서 보는 이름 말고요! 이에 관해선 좀 있다가 추가로 설명하겠습니다.)

만약 많은 부품을 만들 계획을 가지고 있다면, 각각의 부품의 특징에 따라 분류용 폴더를 만드는 것이 가능합니다. 이 방법은 사용 가능하며, 스쿼드도 이렇게 사용하고 있습니다. 예를들어 /Engines/ 폴더에 엔진 관련 부품을 정리하면 됩니다.

만약 그냥 부품 뿐만 아니라 그 이상 게임 시스템에 무언가를 추가하는 모드를 만들거라면, 하나는 부품용, 하나는 회사용, 하나는 계약 시스템용 으로 하위폴더를 몇개 더 만드는 등의 응용이 가능합니다/

아무리 많은 하위폴더를 만들더라도, 그 폴더들은 /Gamedata 폴더 안에 들어가 있어야 모드로 인식이 됩니다. 이 폴더 안에 포럼 등에 모드를 알릴떄 사용하고자 하는 모드의 이름과 똑같은 이름의 폴더를 만들어 정리하는게 나을겁니다. (예: GameData/Modular Kolonization System/ 폴더안에 부품을 넣어논 모드는 Modular Kolonization System이라는 이름의 모드로 알려져있고, GameData/MechJeb/ 폴더 안에 부품을 넣어논 모드는 MechJeb 이라는 이르므이 모드로 알려져있지요.)

그렇다면 제가 새로운 연료와, 몇몇 회사, 그리고 엄청나게 많은 엔진과 연료통, 과학기구 및 전기기구를 추가하는 ShadowSplat 이라는 모드를 만든다고 칩시다. 제 모드의 폴더 구조는 이렇겠지요.


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

부품 CFG 파일

적어도 0.24.2 에서는 CFG 파일을 어디에 정리하든 별로 상관없는것 같습니다. 적어도 제생각에는, 뭘 어떻게 하든 특별히 상관 없는것 같아요. 하지만, 호환성 문제나 에러 수정과 같은 이유를 위해선, 기본 부품의 구조를 따르는게 낫습니다. 많은 기본 부품들이 뭘 어떻게 해야하는지 별도로 주석이 내부에 달려있긴 하지만, 설명을 위해 DoesItAll 이라는 가상의 부품을 하나 만들겠습니다. 이 부품은 이 폴더안에 있고:

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll

이 파일들로 구성된 부품입니다.

KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm


일반적인 구문

실제 구문 설명
PART - 이 CFG 파일이 부품에 관한 것이라는 정의를 내립니다.
{
name = DoesItAll 이 부품의 숨겨진 이름을 지정합니다. 띄워쓰기는 허용되지 않습니다. _ 를 포함한 다른 특수문자들은 사용 불가하거나 추천하지 않습니다. 이 이름은 게임 뒤편에서 부품을 정의하고 호출하는데에 사용되지만, F3을 누르면 나오는 창에서도 확인 가능한 이름딥니다. 이 이름은 최소한 부품에 관해 조금이나마 연관성이 있거나/있고 제작자와 연관이 있는 이름을 택하는게 낫습니다. fuelTankSmallFlat 이름이라는 부품 (실제로 존재합니다!)은 그닥 좋은 이름이 아닙니다. 부품을 효과적으로 잘 표현하고 있긴 하지만 T-100 연료탱크와 로코맥스사 X200-8 연료탱크 중 어느게 fuelTankSmallFlat 로 간주될지 헷갈릴 수 있기 때문입니다.
module = Part 이 구문은 더이상 사용되지 않습니다. 이전 버전의 KSP 에서는 하나의 부품은 하나의 모듈만 사용할 수 있도록 되있었지만, 새로운 버전은 하나의 부품이 여러개의 모듈을 사용할 수 있도록 변경되었습니다. Tail Fin 부품을 포함해 총 5개의 부품은 아직 이 구문을 사용하는 걸로 알려져 있습니다.
  • FuelLine 모듈은 추가적으로 maxLength 라는 함수가 있는데, 이는 연료관의 최대 길이를 제한하기 위해 사용하는 함수입니다. 이 방법은 기본 연료관 부품에서 사용되고 있습니다.
  • StrutConnector 모듈은 추가적으로 linearStrength, angularStrength 및 maxLength 값을 가집니다. 이 방법은 기본 스트럿 부품에서 사용됩니다 * 윙릿 모듈은 dragCoeff 값을 deflectionLiftCoeff 추가적으로 가집니다. ModuleControlSurface 값과 같은 역활을 합니다. 이 방법은 Tail Fin, wingletAV-T1, sweptWing 부품에서 사용되고 있고, 이 부품들이 없어지면 사라질 것으로 예상됩니다.
author 단순히 제작/업데이트 의 공로를 표기하기 위해 사용합니다. 이 부분은 게임내에서 표시되지는 않습니다. 이 부분은 그냥 하나의 팀명으로 적어놓는것이 낫습니다. 예를 들어, MKS부품의 이 부분은 모두 MKS 팀이라고 적어놓고 OKS 모드의 부품에는 그냥 OKS 팀이라고 적어놓으면 됩니다.

모델 관련 수치

이 부분은 지금은 점점 사용빈도가 줄어들고 있지만 메쉬를 직접 정의하는 방법도 있고, 아니면 MODEL 이라는 새로운 하위 명령어를 호출할 수 있습니다. 권장되는 방법은 MODEL 을 사용하는 방법입니다:

실제 구문 설명
MODEL { MODEL 하위 명령어를 호출합니다.
model 메시의 이름을 지정합니다. 이 이름을 가진 메시 파일을 부품 파일과 같은 폴더 안에 넣어두어야 합니다.
scale 모델의 크기를 지정합니다 - 사용하고 있는 3D 모델링 프로그램에 따라 단위 길이를 지정합니다. 만약 단위 길이 1 = 1 미터 로 작업했다면 이 값을 1로 두면 됩니다. 만약 단위 길이 1 = 0.1 미터로 작업했다면, 이 값을 0.1로 두면 됩니다. 단위 길이를 0.1 미터로 두고 모델의 크기를 조정하는 것이 scale 값을 조정해가면서 맞는 값을 찾는 것 보다 낫습니다. 이 크기는 노드의 배치에만 영향을 주고, 실제 모델의 크기를 바꾸지는 않습니다.
texture

만약 MODEL 구문을 사용하지 않는다면, 충돌 매쉬는 이렇게 지정해야 합니다.


실제 구문 설명
mesh 게임 내에서 실제로 보여지는 메쉬 파일과 텍스쳐를 지정합니다. .mu 확장자의 메쉬 파일도 사용가능합니다.

값을 지정하는 부분

실제 구문 설명
mesh = DoesItAll.mu 게임 내에서 실제로 보여지는 메쉬 파일과 텍스쳐를 지정합니다. .mu 확장자의 메쉬 파일도 사용가능합니다.
scale scale 값은 부품의 크기를 결정합니다. 이값을 바꾸면 정확히 어떤 일이 일어날지는 모르겠습니다.
specPower Specific Power 의 약자? fuelLine 부품용
rimFalloff 3 의값 fuelLine 부품용
alphaCutoff 값: 0.0 fuelLine 부품용
rescaleFactor

많은 부품에서 실제로 사용되지 않는 부가적인 값이긴 하지만, 개인적으로 부품의 크기를 변경하고 싶을때 사용하면 됩니다. 노드의 배치도 적절하게 같이 변경하기 위해서는 rescaleFactor 값 뿐만 아니라 scale 값도 바꾸어 주어야 합니다. 기본 값은 1.25이긴 하지만, 어떤 값으로든 변경할 수 잆습니다.

iconCenter 0,3,0 정수 값만 가질 수 있는걸까요? (advSasModuleLarge, fuelLine 부품)

노드 정의

So, node definitions are a little weird. You don't have to use any, and you *can use a whole bunch. Defines where parts attach to other parts. Tricouplers have four: three bottom and one at the top, while most parts simply have two, and a few parts have only one.

Node stack defines where the part vertically stacks with other parts, and node attach defines where on a part's surface other parts attach - in other words, horizontal attachment.

The attachment values relate to an object's origin, and their values correspond to a model's units and scaling factors. A node_stack_bottom with x, y, and z values of (2.5, 5.0, 3.0) will have an attachment node 2.5 units to the right, 5.0 units up, and 3.0 units forward. The next three values refer to the orientation that a particular node will accept other attachments, on a scale of -1.0 to 1.0. These represent the vector that a part will orient itself on when attaching to the node. For example, a fuel tank with a node_stack_bottom will have angx, angy, and angz values of (0.0, -1.0, 0.0). This represents a vector downward relative to the part model, in the negative y direction. A value of (0.0, -1.0, 1.0) would represent a diagonal vector downward and forward, while a value of (1.0, 1.0, 1.0) would represent a vector to the right, up, and forward.

Generally, most parts will have angx, angy, and angz values of either (0.0, -1.0, 0.0) for a node_stack_bottom and (0.0, 1.0, 0.0) for a node_stack_top.

The last value indicates the visual size of an attachment node. Values may be either 0 (small half-meter node), 1 (normal), or 2 (large). This parameter is optional and will default to 1 if nothing is specified.

Keep in mind, naming conventions (_stack_bottom, _stack_top) for nodes only apply to node_attach; they are only helpful in identifying a node's position.

Known node definitions are listed below:

  • node_stack_top
  • node_stack_bottom
  • node_stack_connect01
  • node_stack_connect02
  • node_stack_connect03
  • node_attach
  • node_stack_bottom01
  • node_stack_bottom02
  • node_stack_bottom03
  • node_stack_bottom04

Each one follows this example, and specifies where other parts can connect to this part:

Actual Part Explanation
node_attach = 0.00, 0.147, 0.00, 0.0, 1.0, 0.0, 1 specifies the location of the nodes of this part (the green circles).
node_stack_bottom = x, y, z, angx, angy, angz, size
node_stack_top = x, y, z, angx, angy, angz, size
node_attach = x, y, z, angx, angy, angz, size

FX (효과) 정의

FX definitions specify visual effects associated with this part, including engine exhausts, explosions, and coloration. Each one is a unique effect, and the only parameters they take is the location/offset that the effect occurs at. The 'active' switch on the end is used to define when this effect will be visible. See the FX Groups listing to know which effect groups are available, and when they are used. It's also possible to assign an effect to more than just one FX Group. If for instance, you want a smoke effect to be visible both when the part activates and also when it deactivates itself, you can do this:

fx_gasBurst_white = x, y, z, angx, angy, angz, activate, deactivate

This is particularly useful if you're defining a lot of effects, like the gas discharges on an RCS module.


 fx_exhaustFlame_yellow = x, y, z, angx, angy, angz, active
 fx_exhaustLight_yellow = x, y, z, angx, angy, angz, active
 fx_smokeTrail_medium = x, y, z, angx, angy, angz, active

Known FX calls are listed below:

  • 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

사운드 FX (효과) 정의

Just like Visual effects, sound effects specify an effect to be used by the part. Sound effects are coded using a two-sided equation, the left side specifies the sound or sound file to be used, whereas the right side specifies when to use that particular sound. Known Sound Effects definitions are:

This is pretty easy to use in a basic way, which will suit our needs just fine.

Under this section, comes:

sound_vent_medium = activate
sound_rocket_hard = active
sound_vent_soft = deactivate

Sounds are added to FX Groups, in much the same way smoke and flame effects are. Of course, sounds do not need to be positioned in space, nor do they have rotations, so all you need is to indicate in which FX Group the sound will be executed. As with effects, you can assign multiple groups to a sound.


Since 0.20 GameData structure there are 2 ways to add a sound to a part:

  • KSP has an internal sound library, which contains a few sound effects. By defining a sound as in the example above, KSP will search for that sound in its internal library.
  • The second way is to add new sound files which is ONLY possible if adding the sound file to the GameData/modName/parts/partName/part/sounds/ folder. Note that all the sounds are therefore "private", only accessed by that part. For now, the legacy folder or a shared mod folder method doesn't work, devs are probably going to fix this problem in the future.


REMEMBER: If you add a custom sound, the file name must start with sound_ (e.g., sound_myNewSoundEffect.wav).

To use a sound from the KSP internal library or the part/sounds folder, you must not include the extension in the sound name (e.g., sound_vent_medium = activate), otherwise the sound will not work.

Supported files are 48000 Hz .wav files and .ogg

Paired sound types and part status left side specifies sound, right side specifies engine status.

Left Side options Right Side options
sound_jet_low decouple
sound_jet_deep engage
sound_vent_soft running
sound_vent_large power
sound_vent_medium disengage
sound_rocket_hard flameout
sound_rocket_mini activate
sound_decoupler_fire deploy
sound_explosion_low
sound_parachute_open
sound_parachute_single

에디터 수치

Actual Part Definition
CrewCapacity The number of Kerbals that can be seated in this part. Mk1 Command Pod seats 1. Jebediah is so awesome, he only takes up .7 seats. Chuck Norris takes as many seats as he wants. Use 0 to specify a probe.
TechRequired

This is the technology tree node that must be activated in order to have access to this part. Any single word can go here, but if you use a word that is not in the tech tree definition, you may never be able to access your part. Currently, stock KSP comes with the following Technology_tree nodes:

  • start
  • basicRocketry
  • generalRocketry
  • stability
  • survivability
  • advRocketry
  • generalConstruction
  • flightControl
  • scienceTech
  • heavyRocketry
  • fuelSystems
  • advConstruction
  • aerodynamicSystems
  • advFlightControl
  • electrics
  • spaceExploration
  • landing
  • heavierRocketry
  • specializedConstruction
  • actuators
  • supersonicFlight
  • specializedControl
  • precisionEngineering
  • advElectrics
  • advExploration
  • advLanding
  • nuclearPropulsion
  • advMetalworks
  • composites
  • advAerodynamics
  • highAltitudeFlight
  • largeControl
  • unmannedTech
  • ionPropulsion
  • largeElectrics
  • electronics
  • fieldScience
  • veryHeavyRocketry
  • metaMaterials
  • heavyAerodynamics
  • hypersonicFlight
  • advUnmanned
  • specializedElectrics
  • advScienceTech
  • advancedMotors

The following Tech Tree nodes are present in stock, but not used unless called for by a mod

  • experimentalRocketry
  • nanolathing
  • experimentalAerodynamics
  • aerospaceTech
  • experimentalElectrics
  • experimentalScience
  • automation (used by MechJeb)
  • experimentalsMotors
entryCost entryCost represents the amount Kerbits required to unlock this particular part. As such, it could be considered an 'investment' cost in the development. First you have to have the brains to make the thing, then someone has to develop it (that's this cost), then you can get it into production (that's cost, coming later). You can set this to any value you like. Bear in mind that this value has no meaning in Sandbox or Science Modes. It is only used in Career Mode.
cost cost represents the cost in Kerbits to attach a single instance of this part to your craft. It does not include resources available on your part (fuel tanks' costs are this cost plus the cost of the appropriate resource). cost has no use in Sandbox or Science modes, it is only used in Career mode
category Contrary to some opinions, parts are not organized in-game according to the folder that they are in in the Squad\parts\ directory. Rather, they are organized according to the category value assigned here. Mods are organized alphabetically according to their sub-directory in parts, and then according to this value. This is why, when you add a mod that is contained in folder "000_NewMod", it's parts appear first and when you add a mod that is contained in "ZZZ_NewMod", it's parts appear last. Currently there are nine useable categories:
  • Command
  • Propulsion (deprecated, but still useable)
  • FuelTank
  • Engine
  • Aero
  • Electrical
  • Structural
  • Utility
  • Wheel
subcategory subcategory is not currently in use as of [0.90]. It is expected that this control will later be linked to [category] to provide a further subdivision of searchable parts in-game, possibly to cut down on clutter when the parts list gets exceptionally high. With certain mods installed, the Propulsion category already spans several pages. [subcategory] can help control this by provided variants such as [liquidEngine], [LOXfueltank], [SRB], etc
title title is the in-game name for your part and features such iconic names as 'Command Pod Mk1'. The title of your part can be as long or short as you want, and there are no known limitations on what can be used in the title. This is how your part will be known in-game, on in-game contextual menus and referred to on message boards and forums (hopefully) so take that into consideration.
manufacturer manufacturer is flavor text (possibly useful in future iterations as a filter for parts) that defines who built or created the part for use (or pulled out of the junk-pile and sold at 10000% mark-up for you to use). Just as with the title of your part, there are no known restrictions on the flavor text, including length. This is KSP, though, so try to be humorous
description description is the flavor text that describes your parts purpose, motivation, direction, life aspirations, goals, favor colors, and (hopefully) what it can (is supposed to) do. As with other flavor text, there are no known limitations on what can go here, including length. In fact, this flavor text is treated special in-game by being given a text box that automatically scrolls based on the length of the description used. If your part does something unusual, it's probably a good idea to (at least partially) document it here, so people know how to use your part in-game. Many are the parts that have failed their popularity exams because of bad descriptions.

부착 규칙

attachRules defines how this part attaches to or allows attachments from other parts. Though documented in some part files, the documentation is minimalist and difficult to understand, so here's a little clean-up and expansion.

  • // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
  • attachRules = 1,1,1,1,1

The rules correspond to the numbers below - 1 is allow, 0 is prevent. The tags are:

stack - Can your part be stacked on others?

SrfAttach - Can your part be placed onto a surface?

allowStack - Will you allow other parts to be stacked on your part?

allowSrfAttach Can other parts be placed on the surface of yours?

allowCollision - A special one: Can your part be placed if part of it is intersecting another part?


Note that you can also force parts attached to this part to attach in a specific symmetry.

  • // symmetry rules: 0=1x, 1=2x, 2=3x, 3=4x and so on...
  • stackSymmetry = 3



일반적인 부품의 수치들

This defines how your part performs in the air and its limits. Note that not all of these parameters need to be defined. If they're left out of the cfg file, KSP will use a default value for them. Standard part parameters indicate how the part interacts with the environment in flight mode. From mounting on the launch platform or the runway through take-off and atmospheric interactions to landing and blowing up, this is where physics enters the game

Actual Part Definition
mass = 1 mass measured in Kerbal tons, describes the 'weight' of your part and is used in calculations involving roll, pitch, yaw, and thrust. The higher the mass, the more energy will be needed to change any of those four parameters. It is also used in making center-of-mass, center-of-lift and center-of-drag calculations, some of which are critical for aerodynamic flight. This is a numerical value, and you can use any positive value. Bear in mind that extremely high positive values for [mass] may make the part unusable in-game or require additional special parts to make usable. This is generally considered poor design.
dragModelType [dragModelType] describes how your part interacts with drag forces. At present, the known [dragModelType]s include:
  • default
maximum_drag
minimum_drag
angularDrag
crashTolerance crashTolerance describes the maximum velocity (in m/s) at which your part can interact with another part without suffering damage (read: blowing up). The higher you set this value, the faster an impact your part can survive. 12 is fairly high, and is the de facto standard for most pods. 14 is useful for landing legs, and 50 is used on some wheels, which are basically indestructible.
BreakingForce

optional [breakingForce] specifies an amount of Force exerted between this part and another part that it is attached to. When exceeded, the two parts will separate (usually catastrophically). Higher values indicate stronger connections.

BreakingTorque optional. Like [breakingForce], [breakingTorque] defines an amount of Force between two parts, but rather than direct force towards or against, [breakingTorque] refers to rotational forces between the two objects.. It assigns a value that, again, when exceeded, will cause the two parts to separate, with the expected results
maxTemp Stock KSP uses the [maxTemp] value to determine at what temperature parts will blow up due to overheating. Since Stock KSP doesn't use environmental heating, the only Stock heat sources are engine exhaust, and we will talk about how much heat engines produce later on. Once this value (expressed in degree Celsius {or degrees Kerbius, if you prefer}) is exceeded, your part will spontaneously explode. Managing heat with engines is a critical function of launching higher-powered engines, and design considerations mean that you shouldn't place parts with low [maxTemp] values directly in the path of engine exhaust. Unless you want them to blow up, that is. ~1800 is a good value for most engine assemblies.
ActivatesEvenIfDisconnected true or false, assumed to specify whether the part will operate when not connected to a vessel (remote control?) Must test. Currently, only know part is the Sepratron I
stagingIcon Sets the icon in the staging system
  • DECOUPLER_HOR (Horizontal Decoupler Icon)
  • LIQUID_ENGINE (Liquid Engines, or engines that have controllable thrust)
  • SOLID_BOOSTER (Solid Rocket Boosters, or engines without controllable thrust)
  • (Pods)
  • (Vertical Decoupler)
  • (
stageOffset Can be 0, 1, etc. defines whether this part will create a new stage before itself. This only applies for the automatically generated staging sequence. -1 is used in parachutes...signals that activation of this object does not cause a staging effect?
childStageOffset Can be 0, 1, etc. defines whether this part will create a new stage after itself. This only applies for the automatically generated staging sequence.
explosionPotential unknown purpose. Possibly for future use for random failures. Known values are numerical.
  • 0.1
  • 0 (BSLsnakprobe)
fuelCrossFeed Will the part crossfeed fuel between parts attached to it? allows or restricts fuel moving through this part. Boolean argument: True or False
NoCrossFeedNodeKey = bottom if set to bottom will keep fuel from flowing FROM bottom nodes (avoiding some stack imbalances). Used with parts with multiple bottom nodes, such as the TVR-1180C Mk1 Stack Tri-Coupler. keeps resources from flowing FROM the named nodes (prevents stack imbalances and such) Use with fuelCrossFeed true to to allow resources to flow into these parts, but not back out. Known parameters: bottom
linearStrength The amount of stress the given part can sustain without breaking, in a straight back-and-forth direction. Used for fuel lines and strut connectors.
angularStrength The amount of stress the given part can sustain without breaking, laterally. Used for fuel lines and strut connectors
maxLength The maximum possible length of this stretchy part, expressed in meters. Used for fuel lines and strut connectors, as they have repeating meshes
vesselType unknown. May automatically set the Ship Type variable when including parts with a defined [vesselType]. Known [vesselTypes] include:
  • Ship
  • Probe
  • Lander
  • Rover
  • SpaceObject (refers only to PotatoRoids)
PhysicsSignificance optional. unknown purpose. assumed to default to zero. Appears to be a numerical value. Many parts are 'physicsless' Known parts:
  • radialFlatSolarPanel
  • ladderRadial
  • z-400Battery
  • z-100Battery

Known Values: 1

MODULES

Each Configuration file is comprised of several sections. Some of these sections are standardized across all parts, others are specific to specific part types. To build or modify a successful part, it is necessary to have an understanding of what each section does, and within those sections what each line of configuration actually does, and what the options are for those lines. This Definitions file will attempt to address each of those questions in turn and is current as of [0.25.0]


Notes: It appears that, with a few exceptions, all definitions can occur in any order in the PART file. Free arrangement is valid for MODEL {}, INTERNAL {}, MODULE {},



MODULEs define what specific parts can do. They are generally calls to C-coded or hard-coded functions that define what functionality these parts have in-game.

name names define the module in use and are a general indication of what the module subtype does. Specific variables are associated with each MODULE.[name]. For example, the Clamp-O-Tron Docking Port Sr. has the MODULE.name ModuleDockingNode and its' associates variables are [referenceAttachNode] and [nodeType]. Some MODULEs share variables with other MODULEs, which can make deciphering their purpose difficult.

known MODULEs, their associated variables, and the meanings of those variables will be explained below.

MODULE Name MODULE Function From Modification
ModuleParachute Parachute Operations Stock
ModuleSAS Control System Stock
KerbalSeat Internal Seating? Stock
ModuleLandingGear One type of Wheel Stock
ModuleSteering For Wheel Operations Stock
FXModuleConstraingPosition Unsure Stock
ModuleLandingLeg For Landing Legs Stock
RetractableLadder For Collapsible Ladders Stock
ModuleReactionWheel Controls Force of Reaction wheels Stock
ModuleScienceContainer Place to store Science Stock
FlagDecal Flag Decorations on Parts Stock
ModuleScienceLab For Science generators Stock
ModuleJettison Fairing removal Stock
ModuleAlternator For producing resources based on thrust Stock
ModuleCommand For Control Stock
ModuleEnviroSensor Unmanned Science Stock
ModuleControlSurface Control Surfaces, aelirons Stock
ModuleAnimateHeat Unsure Stock
Module Engines Engines and Thrust Stock
FXModuleAnimateThrottle Unsure Stock
ModuleEnginesFX Unsure Stock
ModuleGimbal Engine Directionality Stock
ModuleTestSubject Contract System Stock
LaunchClamp Launch Clamps Stock
ModuleDockingNode Docking Ports Stock
ModuleRCS Reaction Control Systems Stock
ModuleResourceIntake Intakes that produce resources Stock
ModuleScienceExperiment Controlling Experiments Stock
ModuleGrappleNode For the Claw Stock
ModuleLight For external lighting Stock
ModuleAnimateGeneric Generic Animation Calls Stock
ModuleDataTransmitter For transmitting antennas Stock
FXModuleLockAtConstraint Uncertain Stock
ModuleAsteroid Unsure Stock
ModuleDeployableSolarPanel For Unfoldable Solar panels Stock
ModuleWheel For wheels, powered or unpowered Stock
FXModuleLookAtConstraint Unknown Stock
FXModuleConstrainPosition Unknown Stock
ModuleAnchoredDecoupler Decouplers1 Stock
ModuleDecouple Decoupling Operations Stock
KASModuleContainer Containers KAS / Kerbal Assembly System
KASModuleGrab KAS / Kerbal Assembly System
KASModuleStrut KAS / Kerbal Assembly System
SCANset SCANsat
TweakScale Changing the size of parts TweakScale
MechJebCore Automated ship controls and advanced information systems 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

INTERNAL

INTERNAl 구문은 IVA 상태에서 보이는 내부를 지정하는데 사용되고, 모드 내의 \Spaces\ 폴더 안에 있는 것들과 관련이 있습니다. (스쿼드 기본 내부 화면은 \GameData\Squad\Spaces 경로에 있습니다). INTERNAL 파일은 독자적인 .cfg 파일과 호출 함수들이 있지만 여기서 다루진 않습니다. 이에 관해선 항목을 참고하시길 바랍니다. 스쿼드는 9개의 기본 INTERNAL 을 제공합니다:

  • crewCabinInternals
  • cupolaInternal
  • GenericSpace1
  • GenericSpace3
  • landerCabinInternals
  • landerCabinSmallInternal
  • mk1CockpitInternal
  • mk1PodCockpit
  • PodCockpit

RESOURCE

부품 파일 내에서 [RESOURCE] 부분은 부품이 가지게 되는 자원과 관련이 있습니다. 각각의 자원은 각각의 [RESOURCE] 호출을 사용해야 합니다. 정의되지 않은 자원을 포함, 어떤 자원이라도 가질 수 있습니다.

변수 설명
name 저장돼 있는 자원의 이름을 지정
amount 자원의 저장량의 지정. 부품을 탭에서 꺼내서 부착했을때 가지고 있는 기본 자원량을 지정합니다.
maxAmount 저장할 수 있는 자원의 최대량을 지정합니다. 해보진 않았지만, amount 값보다 더 큰 값을 하는걸 추천하지 않습니다.
isTweakable 부품 파일 내에선, 쏘아올리기 전에 연료 량을 변경할 수 있도록 해주는 구문인것 같습니다.
hideFlow 자원을 전송할때 그 이동을 표시하지 않습니다. 이게 뭐가 중요한지 모르겠군요.

EFFECTS

Thrust AUDIO
clip 특정 엔진의 추진 효과에 사용될 오디오 파일의 위치를 지정합니다.
volume

?? 2개의 수치, 하나는 최소 볼륨을, 하나는 최대 볼륨을 지정하고 게임의 볼륨 설정과 관련이 있습니다.

pitch

?? 2개의 수치, 하나는 최소 볼륨을, 하나는 최대 볼륨을 지정하고 게임의 볼륨 설정과 관련이 있습니다.

loop

2진수 값을 가짐, true 혹은 false, 효과음이 한번 재생될 것인지, 특정 동작을 하는 동안 반복적으로 재생될 것인지 지정함.

Resource Configuration Files

Resources are massively modifiable, but Stock KSP only comes with a few, and these are contained in squad/resources/ResourcesGeneric.cfg. Be extremely careful when modifying ResourcesGeneric.cfg, as it could have unintended side effects for your rockets. Resource definitions follow these conventions:

variable example explanation
name
Resource Mod
LiquidFuel Stock
Oxidizer Stock
SolidFuel Stock
MonoPropellant Stock
XenonGas Stock
ElectricCharge Stock
IntakeAir Stock
EVA Propellant Stock
MechanicalParts MKS/OKS
Recyclables MKS/OKS
ElectronicParts MKS/OKS
PlasticParts MKS/OKS
ModularParts MKS/OKS
ReplacementParts MKS/OKS
RepairKits MKS/OKS
PatchKits MKS/OKS
Computers MKS/OKS
Robotics MKS/OKS
ExoticMinerals MKS/OKS
RareMetals MKS/OKS
Chemicals MKS/OKS
Polymers MKS/OKS
SpecMachinery MKS/OKS
AdvMachinery MKS/OKS
BasicMachinery MKS/OKS
PunchCards MKS/OKS
Compost MKS/OKS
MEP-Manufacturing MKS/OKS
MEP-Laboratory MKS/OKS
MEP-Refining MKS/OKS
MEP-Mining MKS/OKS
MEP-Environmental MKS/OKS
MEP-Computing MKS/OKS
This is the name of the resource. Like the name of your part, it is restricted to one word with no spaces or underscores. This is how the resource is referred to in-game.
density 0.005 [density] is a numerical value between 0 and 1 used in calculations involving mass, storage capacity and units. Lower values mean lower densities, meaning you can get more units in a smaller space.
unitCost 0.8 [unitCost] defines the amount of Kerbits of value for each unit of the specified resource. Any number will do. Positive values indicate that you pay for the resource. Negative values have not been tested (yet), but it is assumed that negative values mean others will pay you to get rid of this resource. (Nuclear waste disposal, anyone?)
flowMode
  • STACK_PRIORITY_SEARCH
  • NO_FLOW
  • STAGE_PRIORITY_FLOW
  • ALL_VESSEL
[flowMode] defines how the resource moves throughout your vessel whenever the resource is requested by a particular part. There are 4 known methods of flow mode:
transfer
  • PUMP
  • NONE
[transfer] is an optional method which specifies how and whether or not a resource may be manually transferred from one location on a vessel to another. There are two known methods of [transfer]:
isTweakable
  • true
  • false
[isTweakable] is an optional, boolean method which specifies whether or not a resource may be assigned during construction. Defaults to true. The only accepted arguments are true and false.

Science Definitions Configuration Files

variable example explanation
id crewReport internal name of the experiment in question
title Crew Report Flavor text of the experiment
baseValue 5 Base science value of the experiment
scienceCap 5 Max? value of the experiment, before multipliers
dataScale 1 Multiplier used in calculations
requireAtmosphere
  • True
  • False
specifies whether this experiment must be conducted inside an atmosphere
situationMask 63 uses the sum of the situation bits to determine where the experiment can be conducted:
  • SrfLanded = 1,
  • SrfSplashed = 2,
  • FlyingLow = 4,
  • FlyingHigh = 8,
  • InSpaceLow = 16,
  • InSpaceHigh = 32
biomeMask 7 uses the biome number to determine if the experiment has already been conducted
requiredExperimentLevel 0.5 specifies the level of research facility required before the experiment can be conducted
RESULTS
name example definition
Too many to list!
  • default
  • MohoSrf
You ran an Atmosphere Analysis, recording various measurements like temperature, pressure and atmosphere composition Flavor text for the science popup window and science archives that describes what happened when the experiment was conducted.
an array of data that provides flavor text for each scenario that the experiment is conducted in. Left side is a combination of the planet name and the situation bit. No spaces. Right side is the flavor text provided to the GUI.

Contracts Definitions Configuration Files

Contains a single call to STORY_DEF, which then allows for subsets
variable example explanation

Contracts Configuration Files

Agent Configuration Files

Agent configuration files specify specific Agents that may have an impact on the performance (read science, money, and prestige) awarded to your Kerbals for completion of specific tasks. Also specifies agency relations to one another. Many of these configurations are not implemented as of [0.90]

// Agency mentalities
// * Commercial   [Increased financial stakes, both for success and failure]
// * Competitive  [competes with companies which we have a negative standing towards, auto-added if any standings set][not impl]
// * Conglomerate  []
// * Startup   []
// * Cooperative  [not impl]
// * Ecomental   [not impl]
// * Economic   []
// * Hasty    [-deadlines -expiry +rep]
// * Patient   [] 
// * Industrial   [not impl] 
// * Perfectionist  [not impl]
// * Pioneer   [Makes agency more likely to offer a contract to something that's never been done before]
// * Record    [Flags agency as a record-keeping organization, focuses on contracts about breaking existing records and doing new things]
// * Scientific   [Agency is more likely to offer science data gathering contracts][not impl]
// * Stern     [Higher Reputation Stakes for both success and failure]
// * EasyGoing   [Lower Reputation Stakes for both success and failure]
// * Kerbalminded  [not impl][Sets up conditions against losing Kerbals]
// * Moral          [not impl]
// syntax guidelines
//
// standings = agent name string, float
// mentality = MentalityClass [float]


Kerbal Configuration Files

Defines what your Kerbals can do. Contained in the Traits.cfg file.

variable example definition in code
name
  • Pilot
  • Engineer
  • Scientist
describes the Kerbal's job
name = Pilot
title Any text Flavor text of the job
 title = Engineer 
desc Any text Flavor text of job description
desc = Pilots provide assistance in flying the vessel.
EFFECT { Array of skills describes benefits to vessel for having a Kerbal with this job aboard
 EFFECT
 {
  name = VesselScienceReturn
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 }
 EFFECT
 {
  name = PartScienceReturn
  modifiers = 1.05, 1.1, 1.15, 1.2, 1.25
 }

Prop Configuration Files

Contained in several different files, usually labeled prop.cfg, in the /Props/ directory. Describes aspects of parts used on IVAs, included buttons, switches, dials, and screens.

PROP
{
  name = directionalKnob
  MODULE
  {
    name = internalGeneric
  }
}
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0

PROP
{
  name = RadarAltimeter
  MODULE
  {
    name = InternalRadarAltitude
    indicatorName = indicator
    increments
    {
       inc = 0, 0
       inc = 34, 100
       inc = 70, 200
       inc = 110, 300
       inc = 145, 400
       inc = 180, 500
       inc = 215, 1000
       inc = 232, 2000
       inc = 250, 3000
    }
  }
}
proxy = 0, 0, 0,  0.06, 0.01, 0.06,  1.0, 0.5, 0
PROP
{
  name = NavBall
  MODULE
  {
    name = InternalNavBall
    navBallName = NavSphere
    iconUp = 0, 1, 0
    progradeVectorName = progradeVector
    retrogradeVectorName = retrogradeVector
    progradeWaypointName = progradeWaypoint
    retrogradeWaypointName = retrogradeWaypoint
 normalVectorName = NormalVector
 antiNormalVectorName = antiNormalVector
 radialInVectorName = RadialInVector
 radialOutVectorName = RadialOutVector
 maneuverArrowName = ManeuverArrow
 anchorName = Anchor
  }
}
proxy = 0, 0, 0,  0.075, 0.01, 0.09,  1.0, 0.5, 0
PROP
{
  name = switch
  MODULE
  {
    name = internalGeneric
  }
}
proxy = 0, 0, 0,  0.0225, 0.0075, 0.0225,  0, 1, 0

Internals Configuration Files

Strategies Configuration Files

Contained in Strategies.cfg, used to describe the variable strategies available. Each strategy opens with STRATEGY {

variable samples description in code
name
  • AppreciationCampaignCfg
  • FundraisingCampaignCfg
  • OpenSourceTechProgramCfg
  • UnpaidResearchProgramCfg
  • OutsourcedResearchCfg
  • PatentsLicensingCfg
  • AgressiveNegotiations
  • RecoveryTransponders
Internal Description of Campaign Name. No spaces or special characters
name = AppreciationCampaignCfg
title Recovery Transponder Fitting Flavor text for the campaign name
title = Appreciation Campaign
desc Recovering parts landed far away from the Space Center can be very costly, but I reckon we can reduce those costs by installing better transponders on the parts we launch. These units are not cheap, but they should make it much easier to find parts, improving the recovery value even if they're half-way around Kerbin. What do you say? Flavor text for the description of the campaign
desc = We could definitely improve our 
image by putting some effort into reminding Kerbals 
everywhere of just how great the Space Program is. 
Advertisement space isn't free, however.
department
  • Operations
  • Finances
  • Science
  • Public Relations
Specifies the Department that the strategy belongs to. Can only be a department that already exists (as of [0.90]
department = Public Relations
icon specifies the icon image to be used in conjunction with the campaign. In the campaign selection.
icon = Squad/Strategies/Icons/AppreciationCampaign
groupTag
  • Basic,A
  • Basic,B
  • Basic,C
  • Misc,D
  • Misc,Recovery
Uncertain, clearly has something to do with grouping
groupTag = Basic,A
minLeastDuration positive Integers the minimum shortest amount of time (in days) that the campaign may have (campaigns must run at least this long)
minLeastDuration = 60
maxLeastDuration positive Integers the maximum shortest amount of time (in days) that the campaign may have. Using the sliders, campaigns may be adjusted to require at least this long to run
maxLeastDuration = 100
minLongestDuration positive Integers the minimum longest duration (in days) of the campaign. Using the sliders, campaigns may be adjusted to only run this long
minLongestDuration = 1200
maxLongestDuration positive Integers the maximum longest duration (in days) of the campaign (campaigns cannot run longer than this)
maxLongestDuration = 1600
requiredReputationMin Integers Minimum reputation required to purchase this campaign
requiredReputationMin = -500
requiredReputationMax Integers The most reputation you can be required to have in order to run this campaign
requiredReputationMax = 750
initialCostFundsMin Integers Minimum funds required to purchase this campaign
initialCostFundsMin = 8000.0
initialCostFundsMax Integers The largest amount of Kerbits that can be required to purchase this campaign
initialCostFundsMax = 160000.0
initialCostReputation Integers Minimum cost in reputation to run this campaign
initialCostReputation = 0.0
initialCostScience Integers Minimum cost is science points to run this campaign
initialCostScience = 0.0
hasFactorSlider
  • True
  • False
Can the campaign be adjusted by increasing inputs and getting greater outputs out of the campaign?
hasFactorSlider = True
factorSliderDefault Float multiplication factor for each step along the slider bar
factorSliderDefault = 0.05
factorSliderSteps Numbers number of steps/stages in the slider bar
factorSliderSteps = 20
EFFECT { see table below describes what the particular campaign actually does see table below

EFFECTS

There are currently three different EFFECT types available for use in Strategies: CurrencyOperation, ValueModifier, and CurrencyConverter. Each one has different variables and are detailed below.

CurrencyOperation
variable samples description in code
name
  • CurrencyOperation
internal reference name
name = CurrencyConverter
currency
  • Funds
input and output for campaign operations
currency = Funds
operation
  • Multiply
  • Add
operation to perform on currency
operation = Multiply
effectDescription "to Launch Costs" Flavor text for the operation to be performed
effectDescription = to Launch Costs
minValue Float factor to use in operations
minValue = 1.1
maxValue Float factor to use in operations
maxValue = 1.06
AffectReasons
  • VesselRollout
  • RnDPartPurchase
conditions that trigger the operation
AffectReasons = VesselRollout
ValueModifier
variable samples description in code
name
  • ValueModifier
internal reference name
name = CurrencyConverter
valueID VesselRecoveryFactor Value to be modified
valueId = VesselRecoveryFactor
minValue Float factor to use in operations
minValue = 1.1
maxValue Float factor to use in operations
maxValue = 1.06
CurrencyConverter
variable samples description in code
name
  • CurrencyConverter
internal reference name
name = CurrencyConverter
input
  • Funds
  • Reputation
  • Science
specifies the input for the campaign
input = Funds
output
  • Reputation
  • Funds
  • Science
specifies the outputs for the campaign
output = Reputation
minShare Float specifies the minimum
minShare = 0.0
maxShare Float specifies the maximum
maxShare = 1.0
minRate Float specifies the minimum rate of conversion, based on slider values
minRate = 0.041667
maxRate Float specifies the maximum rate of conversion, based on slider values
maxRate = 0.0520
AffectReasons
  • ContractReward
  • ScienceTransmission
  • ContractAdvance
  • VesselRecovery
  • VesselRollout
  • RnDPartPurchase
criteria for conversions
AffectReasons = ContractReward, ContractAdvance
effectDescription
  • gains
  • Income
describes the type of return
effectDescription = Income

Department Configuration Files

Used in the Strategies system, these specify the Departments available that provide different strategies for use.

variable samples description in code
name
  • Finances
  • Science
  • Public Relations
  • Operations
The department name
name = Public Relations
desc Flavor Text describes the department
desc = Linus is Wernher Von Kerman's Intern. 
Because Wernher himself is too important to be 
bothered with these boring strategy meetings. 
He sends his intern in his stead.
color array of 3 numbers between 0 and 255 specifies the color of the department
color = 149 254 135
avatar
  • Strategy_MechanicGuy
  • Strategy_PRGuy
  • Strategy_ScienceGuy
  • Strategy_Mortimer
Internal name of the Department Head
avatar = Strategy_PRGuy
headName
  • Mortimer Kerman
  • Linus Kerman
  • Walt Kerman
  • Gus Kerman
Flavor Text for the Department Head
headName = Walt Kerman
headImage
  • MORTIMER_KERMAN
  • SCIGUY_KERMAN
  • PRGUY_KERMAN
  • PRGUY_KERMAN
animation file name for the Head shot of the Department Head featured in the strategy selection screen
headImage = PRGUY_KERMAN