Module:Test/data/doc

Transformation rules

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 strings

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

<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

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

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