Editing Module:Test/data/doc

== Transformation rules ==

=== RimWorld vesion ===
Vesion is added to the beginning of each generated data file.

<pre>
return {

  version = "1.2.2753",
  ...
</pre>

=== Elements with attributes ===
Create a new subelement and move all of the attributes to their own subelements within it.

=== *Def elements ===
<defName> is used as part of the index for the main Def table.

Additional attribute added: "DLC".

<pre>
<ThingDef ParentName="BaseHare">
  <defName>Snowhare</defName>
  <label>snowhare</label>
  ...
</pre>

becomes

<pre>
["ThingDef:Hare"] = {
  ["_attrib_"] = {
    ["ParentName"] = "BaseHare",
    ["FileName"] = "Races_Animal_Hares.xml",
    ["DLC"] = "Core",
  },
  ["defName"] = "Snowhare",
  ["label"] = "snowhare",
  ...
</pre>

Parent (absctact) Def that gets inherited:

<pre>
<ThingDef Abstract="True" ParentName="AnimalThingBase" Name="BaseHare">
  <statBases>
    <MoveSpeed>6.0</MoveSpeed>
    <MarketValue>50</MarketValue>
    ...
</pre>

becomes

<pre>
["ThingDef:BaseHare"] = {
  ["_attrib_"] = {
    ["Abstract"] = "True",
    ["ParentName"] = "AnimalThingBase",
    ["Name"] = "BaseHare",
    ["FileName"] = "Races_Animal_Hares.xml",
    ["DLC"] = "Core",
  },
    ["statBases"] = {
      ["MoveSpeed"] = 6.0,
      ["MarketValue"] = 50,
  ...
</pre>

=== Descriptions ===

Because of some exceptions in Royalty Defs, <description> content has to be wrapped in double square brackets (Lua multiline syntax).

=== <nowiki><li></nowiki> elements without children ===
Get transformed into ordered lists (numerically indexed Lua tables).

<pre>
<tradeTags>
  <li>AnimalUncommon</li>
  <li>AnimalFighter</li>
</tradeTags>
</pre>

becomes

<pre>
["tradeTags"] = {
  "AnimalUncommon",
  "AnimalFighter",
},
</pre>

Note: a comma after the last item in a list is not flagged as an error in Lua.

=== <nowiki><li></nowiki> elements with children ===

<pre>
<lifeStageAges>
  <li>
    <def>AnimalBaby</def>
    <minAge>0</minAge>
  </li>
  <li>
    <def>AnimalJuvenile</def>
    <minAge>0.25</minAge>
  </li>
  <li>
    <def>AnimalAdult</def>
    <minAge>0.5</minAge>
  </li>
</lifeStageAges>
</pre>

becomes

<pre>
["lifeStageAges"] = {
  {
    ["def"] = "AnimalBaby",
    ["minAge"] = 0,
  },
  {
    ["def"] = "AnimalJuvenile",
    ["minAge"] = 0.25,
  },
  {
    ["def"] = "AnimalAdult",
    ["minAge"] = 0.5,
  },
},
</pre>

=== <nowiki><li></nowiki> elements with a single attribute "Class" ===
The value of the "Class" attribute is used to rename the <nowiki><li></nowiki>.

<pre>
comps = {
  {
    _ = {
      Class = "CompProperties_Glower",
    },
    glowRadius = 10,
...
</pre>

becomes

<pre>
comps = {
  CompProperties_Glower = {
    glowRadius = 10,
...
</pre>

NOTE: The first sample already underwent the transformation of attributes to a subelement.

=== Ranges (1~2) ===
: TODO

=== Curve points ===

Curves pop up in a lot of places so additional support functions for those might be in order.

Min, max, maybe average... things like that. Some (like litterSizeCurve) have a fixed amount of points (correction: even for litterSizeCurve this is not true) so you could just retrieve the first one or last (fourth), but this is not the case for all of them and is a bit ugly. Whatever the case, additional processing with wiki syntax would have to be used. This is bad (and to be avoided if possible).

<pre>
<litterSizeCurve>
  <points>
    <li>(1.0, 0)</li>
    <li>(1.5, 1)</li>
    <li>(2.0, 1)</li>
    <li>(2.5, 0)</li>
</points>
</pre>

becomes

<pre>
["litterSizeCurve"] = {
  ["points"] = {
    {0.5, 0},
    {1, 1},
    {1.5, 1},
    {2.0, 0},
  },
},
</pre>

=== Components ===

It would be useful to have some of the more used components. They can then be queried for additional functionality that some game objects have.

They can be numbered tables or, as in some of the examples above, string indexed. String indexes, in general, are simpler to use. Numeric tables I have to search through.

See 

'''TODO:''' implement filtering

== Issues ==

=== One (data) file to rule them all ===
One data file or smaller ones split by categories (buildings, races, items, etc.).

Single:
* simplicity
** versioning
** uploading

Split:
* dynamic loading

=== Inheritance (interaction with parser) ===
Inheritance can be handled by the parser or the module. If the parser handles it, then for any change the dataset needs to be recreated so I'm leaning towards letting the module take care of that. In this case the only purpose of the parser is to filter data and transform it into something Lua can use.
@@ Line 1: / Line 1: @@
 == Transformation rules ==
-=== RimWorld version ===
+=== RimWorld vesion ===
-Version is added to the beginning of each generated Lua table.
+Vesion is added to the beginning of each generated data file.
 <pre>
@@ Line 17: / Line 17: @@
 <defName> is used as part of the index for the main Def table.
-Additional attributes added: "DLC", "FileName".
+Additional attribute added: "DLC".
 <pre>
@@ Line 26: / Line 26: @@
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 40: / Line 40: @@
 </pre>
-Parent (abstract) Def:
+Parent (absctact) Def that gets inherited:
 <pre>
@@ Line 50: / Line 50: @@
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 67: / Line 67: @@
 </pre>
-=== List elements without children ===
+=== Descriptions ===
+Because of some exceptions in Royalty Defs, <description> content has to be wrapped in double square brackets (Lua multiline syntax).
+=== <nowiki><li></nowiki> elements without children ===
 Get transformed into ordered lists (numerically indexed Lua tables).
@@ Line 77: / Line 81: @@
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 88: / Line 92: @@
 Note: a comma after the last item in a list is not flagged as an error in Lua.
-=== List elements with children ===
+=== <nowiki><li></nowiki> elements with children ===
 <pre>
@@ Line 107: / Line 111: @@
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 126: / Line 130: @@
 </pre>
-=== List elements with a single attribute Class ===
+=== <nowiki><li></nowiki> elements with a single attribute "Class" ===
 The value of the "Class" attribute is used to rename the <nowiki><li></nowiki>.
 <pre>
-<comps>
+comps = {
-   <li Class="CompProperties_Glower">
+   {
-     <glowRadius>10</glowRadius>
+    _ = {
+      Class = "CompProperties_Glower",
+    },
+     glowRadius = 10,
 ...
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 145: / Line 152: @@
 </pre>
-=== Components ===
+NOTE: The first sample already underwent the transformation of attributes to a subelement.
-It would be useful to have some of the more used components. They can then be queried for additional functionality that some game objects have.
-They can be numbered tables or, as in some of the examples above, string indexed. String indexes, in general, are simpler to use. Numeric tables I have to search through.
-See [[#List elements with a single attribute Class]]
 === Ranges (1~2) ===
-<pre><overdoseSeverityOffset>0.18~0.35</overdoseSeverityOffset></pre>
+: TODO
-transforms to:
-<pre>overdoseSeverityOffset = { ["<"]=0.18, [">"]=0.35 },</pre>
 === Curve points ===
@@ Line 174: / Line 173: @@
 </pre>
-transforms to:
+becomes
 <pre>
@@ Line 187: / Line 186: @@
 </pre>
-=== Descriptions ===
+=== Components ===
+It would be useful to have some of the more used components. They can then be queried for additional functionality that some game objects have.
+They can be numbered tables or, as in some of the examples above, string indexed. String indexes, in general, are simpler to use. Numeric tables I have to search through.
-Because of some exceptions in Royalty Defs, <description> content has to be wrapped in double square brackets (Lua multiline syntax).
+See
-=== MayRequire attribute ===
+'''TODO:''' implement filtering
-Removed.
 == Issues ==
@@ Line 209: / Line 211: @@
 === Inheritance (interaction with parser) ===
 Inheritance can be handled by the parser or the module. If the parser handles it, then for any change the dataset needs to be recreated so I'm leaning towards letting the module take care of that. In this case the only purpose of the parser is to filter data and transform it into something Lua can use.
-== TODO ==
-* Implement filtering for components (any list item that follows the same pattern)
-<includeonly>[[Category:Module]]</includeonly>
-<noinclude>[[Category:Module documentation]]</noinclude>