Difference between revisions of "CFG File Documentation/ko"

Revision as of 04:31, 23 December 2014

이 글이 유용하다고 생각되거나 이 정보를 잘 이용했다면, 상단의 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

일반적인 구문

Model Parameters

At this point, you can use the deprecated style of mesh on a line by itself, or open a new sub called MODEL. The preferred method is to use MODEL:

If you do not use MODEL, you must use mesh to define the parts collision mesh, like so:

Asset Parameters

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.

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:

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 definitions

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

Sound FX definitions

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.

Editor Parameters

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.

• // 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

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

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.

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:

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

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.

EFFECTS

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:

Science Definitions Configuration Files

Contracts Definitions Configuration Files

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.

name = Pilot

 title = Engineer 

desc = Pilots provide assistance in flying the vessel.

 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 {

name = AppreciationCampaignCfg

title = Appreciation 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 = Public Relations

icon = Squad/Strategies/Icons/AppreciationCampaign

groupTag = Basic,A

minLeastDuration = 60

maxLeastDuration = 100

minLongestDuration = 1200

maxLongestDuration = 1600

requiredReputationMin = -500

requiredReputationMax = 750

initialCostFundsMin = 8000.0

initialCostFundsMax = 160000.0

initialCostReputation = 0.0

initialCostScience = 0.0

hasFactorSlider = True

factorSliderDefault = 0.05

factorSliderSteps = 20

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.

name = CurrencyConverter

currency = Funds

operation = Multiply

effectDescription = to Launch Costs

minValue = 1.1

maxValue = 1.06

AffectReasons = VesselRollout

name = CurrencyConverter

valueId = VesselRecoveryFactor

minValue = 1.1

maxValue = 1.06

name = CurrencyConverter

input = Funds

output = Reputation

minShare = 0.0

maxShare = 1.0

minRate = 0.041667

maxRate = 0.0520

AffectReasons = ContractReward, ContractAdvance

effectDescription = Income

Department Configuration Files

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

name = Public Relations

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 = 149 254 135

avatar = Strategy_PRGuy

headName = Walt Kerman

headImage = PRGUY_KERMAN