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

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.

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.