Module:Test/data/doc

Herein lie the (current) ad hoc rules for getting from an XML to a Lua table

Elements with attributes

Move into key with exact name. Attributes become subkeys. A bit ugly but simple.

Def keys

defName is used as an index for the main Def table. defName remains as a subkey to the table.

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

becomes

["Hare"] = {
  ["ParentName"] = "BaseHare",
  ["defName"] = "Hare",
  ["label"] = "hare",
  ...

Parent Def that gets inherited (Name becomes the key, no defName):

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

becomes

["BaseHare"] = {
  ["Abstract"] = true,
  ["ParentName"] = "AnimalThingBase",
  ["statBases"] = {
    ["MoveSpeed"] = 6.0,
    ["MarketValue"] = 50,
    ...

<li> elements enclosing simple values

Get transformed into ordered lists (numerically indexed Lua tables).

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

becomes

["tradeTags"] = {
  "AnimalUncommon",
  "AnimalFighter",
},

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

<li> elements enclosing multiple items

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

becomes

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

Ranges (1~2)

TODO

Curve points

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

becomes

["litterSizeCurve"] = {
  ["points"] = {
    {0.5, 0},
    {1, 1},
    {1.5, 1},
    {2.0, 0},
  },
},

Issues

• One data file or smaller ones split by categories (buildings, races, items, etc.).
• A pro for separation might be that not everything has to be loaded to get relevant data (load only relevant files).
• Until a more final version of the data is seen, the size of the whole thing is a bit unknown but shouldn't be too big to prevent the "one file" option. A definite pro for the one file option is the simplicity of updating - upload one file, done.
• Some pieces of the puzzle are in game code so until more files are processed, can't say what else will pop up.
• Can't keep semi-manually processing the xml files... it's lunacy.