Kerbal Space Program 2 Wiki:Manual of Style/GameData: Difference between revisions

From Kerbal Space Program 2 Wiki
Jump to navigation Jump to search
Added layout for parts data
Tag: 2017 source edit
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
The following are guidelines for various aspects of writing data pages in the Data: namespace, established by consensus among KSP 2 Wiki editors. Please discuss them on the talk page if you have ideas or questions. Editors should also be familiar with the main [[Kerbal Space Program 2 Wiki:Manual of Style|Manual of Style]].
The following are guidelines for various aspects of writing data pages in the <code>GameData:</code> namespace, established by consensus among KSP 2 Wiki editors. Please discuss them on the talk page if you have ideas or questions. Editors should also be familiar with the main [[Kerbal Space Program 2 Wiki:Manual of Style|Manual of Style]].


== Function ==
== Function ==
Line 5: Line 5:


== Naming conventions ==
== Naming conventions ==
Data articles are to be titled explicitly per their respective subject, e.g. [[Data:IX-6315 "Dawn"]], [[Data:PPD-20 "Wayfarer"]], [[Data:Kerbin]], [[Data:Laythe]], et cetera.
Data articles are to be titled explicitly per their respective subject, e.g. [[GameData:IX-6315 "Dawn"]], [[GameData:PPD-20 "Wayfarer"]], [[GameData:Kerbin]], [[GameData:Laythe]], et cetera.


== Layout ==
== Layout ==
=== Parts ===
=== Parts ===
The proper layout of part data is as follows:
The proper JSON-formatted layout can be found at [[GameData:Example]]. Take note of the following:
* Name
* Comments are not supported by JSON formatting. A dummy <code>_comment </code>parameter can be added if necessary but should not contain any information that would need to be passed or handled outside of the data page.
* Caption
* Any numerical parameters are only to be given numerical values. Units are handled separately. For <code>mass</code>, <code>max_temp</code>, and <code>imp_tol </code>the units are implicitly <code>t</code>, <code>K</code>, and <code>m/s</code>, respectively. Units for values in part type and part module parameters are implicitly handled as present in-game unless a <code>units </code>param exists which is then used instead.
* Mass
* All parameters are to be implemented as strings except for where a boolean is appropriate. Numerical data should be implemented as a string, not as a number, since the data page is used for primarily presenting text and not performing calculations.
* Size
* Maximum temperature
* Impact tolerance
* Stores research
* Resources
* Manufacturer
* Part type
** Part type params
* Part modules
** Part module elements
*** Part module element params
 
An JSON-formatted example can be found at [[Data:Example]].

Latest revision as of 05:43, 16 March 2025

The following are guidelines for various aspects of writing data pages in the GameData: namespace, established by consensus among KSP 2 Wiki editors. Please discuss them on the talk page if you have ideas or questions. Editors should also be familiar with the main Manual of Style.

Function

Data pages contain JSON-formatted information on particular entities. The Page content model in the Basic information section of the page's Page information display must be set to JSON, which is enabled by default for the Data: namespace.

Naming conventions

Data articles are to be titled explicitly per their respective subject, e.g. GameData:IX-6315 "Dawn", GameData:PPD-20 "Wayfarer", GameData:Kerbin, GameData:Laythe, et cetera.

Layout

Parts

The proper JSON-formatted layout can be found at GameData:Example. Take note of the following:

  • Comments are not supported by JSON formatting. A dummy _comment parameter can be added if necessary but should not contain any information that would need to be passed or handled outside of the data page.
  • Any numerical parameters are only to be given numerical values. Units are handled separately. For mass, max_temp, and imp_tol the units are implicitly t, K, and m/s, respectively. Units for values in part type and part module parameters are implicitly handled as present in-game unless a units param exists which is then used instead.
  • All parameters are to be implemented as strings except for where a boolean is appropriate. Numerical data should be implemented as a string, not as a number, since the data page is used for primarily presenting text and not performing calculations.