XML Concatenate for FE

External Link

I had an idea for an xml concatenate utility to assist with updating mods to new versions of Fallen Enchantress as well as making mods compatible with other mods. Is this something that would be helpful?

The idea is when you mod an XML file, you make a new XML file of the same name (in a different directory) that only contains your changes (as well as the hierarchical nodes above those changes). The Concatenate utility will combine this change file with the main file from the Fallen Enchantress directory. So if FE had a file that looked like:

Code: xml
<?xml version="1.0" encoding="utf-8"?>
<ElementalDefinitions>
 <ElementalDefs>
 <RandomPlacementRequirementDef InternalName="ResourceHoard_Rediculous">
 <ObjectType>ResourceHoard</ObjectType>
 <DisplayName>Rediculous</DisplayName>
 <ObjectsPerLandTile>0.14</ObjectsPerLandTile>
 <DistanceBetweenObjects>2</DistanceBetweenObjects>
 <DistanceBetweenObjectTypes>2</DistanceBetweenObjectTypes>
 <MaxObjectsPerSector>0</MaxObjectsPerSector>
 </RandomPlacementRequirementDef>
 </ElementalDefs>
</ElementalDefinitions>

... and you wanted to turn down the ObjectsPerLandTile, you would create a file that looks like:

Code: xml
<?xml version="1.0" encoding="utf-8"?>
<ElementalDefinitions>
 <ElementalDefs>
 <RandomPlacementRequirementDef InternalName="ResourceHoard_Rediculous">
 <ObjectsPerLandTile>0.10</ObjectsPerLandTile>
 </RandomPlacementRequirementDef>
 </ElementalDefs>
</ElementalDefinitions>

Then whenever a new version of FE is released, you would run the concatenate utility and it would generate a new XML file with all the information from the original but the changes from the change file. This also works with integrating changes from multiple change files, or you can set the FE base directory to point to the xml files from another mod and try to make your mod compatible with the other (no guarantees).

It works on the following principles:

For each XML file in the FE directory, it will check to see if a matching filename exists in the change file directories. It will run the concatenate on any files with matching names.
It uses the original XML file as the base. At a minimum it will contain all the fields from the original file.
A unique node is identified by its position in the hierarchy, its name, and its attribute.
For each node in the change file, it will try to find the same node in the xml file based on the above criteria. If that node has no child nodes, it will replace the innertext (0.14 in the above example) with the innertext from the change file (0.10).
If the node is not found in original file, it will create a new node.
Resultant files are saved in the selected target directory.

At this point, I thought it would be a good excercise to learn how to use the XML classes in .NET (it requires .NET Framework 4.0 to be installed, btw), so I went ahead and built it. But I didn't do any real testing, so there are probably bugs. I thought I'd go ahead and make it available, and if this ends up being useful to people I might come back sometime and work out whatever kinks are found.

In case it isn't obvious, I have no affiliation with Stardock, and this application is "Use at own risk," meaning by using this you agree not to hold me responsible for any damages caused by this application.

*Edit*

It occurs to me that it's easy to miss the "External Link" link at the top of this post, so here's the link again: https://dl.dropbox.com/u/35106869/XMLConcatenate.zip

This was created safe, but one should always run a virus scan on any files downloaded anyway.

Locked Post

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

Nice idea in theory. How will it handle nodes or tags that don't exist in the original? Will it comment out any replaced tags? Does it actually change the original or create a merged copy?

Successfully updated karma reason!

Quoting Aerion Istari,

reply 1

How will it handle nodes or tags that don't exist in the original?

If a node exists in the change file that doesn't exist in the original, a new node will be created in the merge file. Remember that a unique node in this case is defined by its name, place in the hierarchy, and any attributes it might possess.

Quoting Aerion Istari,

reply 1

Will it comment out any replaced tags?

Not in this version, but if I come back to it I'll look into how difficult it would be to add a comment to changed tag values. I was also thinking about making it possible to mark a node for deletion.

Quoting Aerion Istari,

reply 1

Does it actually change the original or create a merged copy?

Create a merged copy in the specified target directory.

Successfully updated karma reason!

Quoting sirmathmansir,

reply 2

Quoting Aerion Istari, reply 1How will it handle nodes or tags that don't exist in the original?

If a node exists in the change file that doesn't exist in the original, a new node will be created in the merge file. Remember that a unique node in this case is defined by its name, place in the hierarchy, and any attributes it might possess.

Quoting Aerion Istari, reply 1Will it comment out any replaced tags?

Not in this version, but if I come back to it I'll look into how difficult it would be to add a comment to changed tag values. I was also thinking about making it possible to mark a node for deletion.

Quoting Aerion Istari, reply 1Does it actually change the original or create a merged copy?

Create a merged copy in the specified target directory.

This is exactly what I would like to see...but how hard would it be to add an 'un-merge' or 'un-build' command to restore the main (core) files back to original? If we had a tool to do what you designed it would be easier than managing our own zip file of the install\english\data directory to replace before patching.

Successfully updated karma reason!