[XML Markers] Exportion of XML Marker Packs File Structure

[klingbolt]

The current exportation of xml files puts all marker packs into a singular file. In order to export specific packs, rules need to be added to separate the files.

The proposed solution is to use the type= field present in all POIs to identify nodes and, through checks, add all relevant MarkerCategories. The parent name would be the folder the file is in and the first child will be the file name. Example:

<POI type="a.b">
<POI type="a.c.d">
<POI type="a.c.e">

Would result in the following file structure

a\
     b.xml
     c.xml

[klingbolt]

In looking at different marker packs and TACO documentation (http://www.gw2taco.com/2016/01/how-to-create-your-own-marker-pack.html), it seems that the format TACO uses is to have one xml file that contains all of the category data. Often called categorydata.xml or aaa.xml.

[AsherGlick]

categorydata.xml is theoretically loaded first, then they are loaded alphabetically aaa.xml is usually the first in the list of alphabeticals. We dont need to replicate this functionality but we might want to replicate part of it. EG: the shared elements are stored there so that we dont have any confusion on attributes being defined for a specific category in multiple places. But any category unique to a different xml file is only stored in that file.

[klingbolt]

That makes sense why it does that. I figured I would put that note here since we would want our exported files to be usable by Blish or Taco.

[dlamkins]

Not something that should necessarily influence your plans, but perhaps worth knowing:

In Blish HUD we have a slightly different structure we're using to allow us to load markers and trails faster. We call it our optimized format. The format is still fully readable by TacO but is exported in the following way:

• All categories for the pack are exported into a single file called _markerCategories.xml. If this file is found in a pack, we assume the pack has been optimized.
• Markers and trails are split into files called map{id}.xml where {id} is the map those markers and trails are found on. This lets us skip parsing all of the XML files to find relevant markers and instead just load the one for the map we're on. This also means we don't have to open any of the trl files to determine the map they're associated with.

Packaged in this way, the packs remain compatible with TacO while providing advantages to load times, etc.

We don't currently have maker pack developers producing packs in this way. Instead, during download, we parse and optimize them before saving.

[AsherGlick]

@dlamkins This sounds pretty similar to how we ended up storing our internal binary formats (#114), except we dont yet have an overarching file of "all categories". But we probably will end up adding that as the xml loading project gets user tested.

In my head this XML marker pack exporter is meant for compatibility with existing systems, which to me falls into 3 requirements. 1) Can be loaded in TacO. 2) Can be loaded in BlishHUD. 3) Can be loaded by a human with a text editor.

We dont have any plans to make a protocol buffer editor so right now if someone wanted to tweak a value in the marker pack manually they would either need to hope that we made a UI to edit that element, or edit the binary protobin, which would be hard. The plan is that the xml export would allow them to export the pack as XML, tweak something the same way the current marker pack creators do, and then re-import it.

Do you see any performance benefits with your optimized format beyond only needing to load a single map's markers at a time?

[dlamkins]

None that come to mind for your specific implementation. It did allow us to cut back on unnecessary textures, invalid attributes, etc., but that I presume is a similar benefit in your binary format. It seems you've gone in a very similar direction now that I see that other work. 👍