What does it do?
Updating your mod for each release is a pain, right? Well hopefully not any more. I kept trying to solve the time problem with complex utilities, but this time I'm building something super simple. RawPatcher to the rescue. The utility goes through the DF raws and modifies the values that were changed in your Mod raws, and adds new entries where none previously existed.
The tool will attempt to intelligently merge raw objects according to this logic:
1. The first token in the tag is treated as the name of that "property".
2. If the property doesn't exist on the source object, it is added to the end.
3. If an exact match for the property is found in the source object, no changes are made.
4. If one instance of the property exists in the original and mod objects, the mod property replaces the original property.
5. If multiple instances of the property exist in either location, the mod property is added to the end of the object.
You can also force behaviour by using the following tag formats:
[ADD_TAG:METAL_ORE:IRON:100] will add the tag [METAL_ORE:IRON:100] to the end of the object, regardless of what is already there. If a tag is found which matches this exactly, it will not be added.
REMOVE_TAG removes a single property that best matches the provided tag. An error results if multiple tags ties for best match.
[REMOVE_TAG:METAL_ORE] will remove [METAL_ORE:IRON:100] if it is the only METAL_ORE on the object. There will be an error if it also has [METAL_ORE:LEAD:100]
[REMOVE_TAG:METAL_ORE:IRON] would remove [METAL_ORE:IRON:100] if both tags existed.
[REMOVE_ALL:METAL_ORE] will remove all METAL_ORE tags on the object. Only accepts a single parameter.
DFFD link: http://dffd.wimbli.com/file.php?id=3353
Installation
1. Install Adobe AIR (http://get.adobe.com/air/)
2. Double-click the AIR file
Should work on PC, Mac and Linux. Contact me if it doesn't, please
Usage
1. Create "mod raw" files containing ONLY your changes. (see below for example)
2. Point the utility to your mod files and a clean copy of the df raws
3. Point the utility to an output folder
4. Click "Do It"
Notes
- files in the source folder with no counterpart in the mod folder will be copied directly
- files in the mod folder with no counterpart in the source folder will be copied directly
- the order of objects in the raws don't matter. The tool is smart enough to match up tags to objects
- the tool is not smart enough to match things up well with hierarchical sub-tags at this point, so some of the more complex raws may not work well
- you can use this tool to combine several mods together by using the output from the first merge as the base for the next merge
- all comment text is completely stripped during this process
Roadmap
I'll eventually put up a poll to see what I should prioritize, but this is my personal order for now.
1. Eliminate the restrictions on sub-folders are raw file types
2. Save last selected folders
3. Generate a mod folder describing the difference between two sets of raws
4. Select multiple mods to apply at once, detect conflicts
5. Single file merge
6. Rule-based changes
7. Add support for init files
8. Retain comments
Example
In the DF Raw (inorganic_stone_mineral.txt)
inorganic_stone_mineral
[OBJECT:INORGANIC]
[INORGANIC:HEMATITE]
[USE_MATERIAL_TEMPLATE:STONE_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:hematite][DISPLAY_COLOR:4:7:0][TILE:156]
[ENVIRONMENT:SEDIMENTARY:VEIN:100]
[ENVIRONMENT:IGNEOUS_EXTRUSIVE:VEIN:100]
[ITEM_SYMBOL:'*']
[METAL_ORE:IRON:100]
[SOLID_DENSITY:5100]
[MATERIAL_VALUE:8]
[IS_STONE]
[MELTING_POINT:12736]
In the mod Raw (inorganic_stone_mineral.txt)
[INORGANIC:HEMATITE]
[TILE:'S']
[REMOVE_ALL:ENVIRONMENT]
[ENVIRONMENT:IGNEOUS_INTRUSIVE:VEIN:100]
[REMOVE_TAG:MATERIAL_VALUE]
In the merged Raw (inorganic_stone_mineral.txt)
inorganic_stone_mineral
[OBJECT:INORGANIC]
[INORGANIC:HEMATITE]
[USE_MATERIAL_TEMPLATE:STONE_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:hematite]
[DISPLAY_COLOR:4:7:0]
[TILE:'S']
[ENVIRONMENT:IGNEOUS_INTRUSIVE:VEIN:100]
[ITEM_SYMBOL:'*']
[METAL_ORE:IRON:100]
[SOLID_DENSITY:5100]
[IS_STONE]
[MELTING_POINT:12736]
Not to mention that if your mod is broken by the new version, you'll be left editing deltas against new raws to fix it. This may be exceptionally difficult--especially if the new version removed an object you were editing.
tl;dr: this idea will have you specifying transformations to raws, rather than changing the raws themselves, probably with few benefits.
I think it'd be better to just Diff the modded raws against the originals, which is what I assume most do now. With that, you have normal raw format files to work with before and after migrating to the new version, rather than deltas (which are managed on an as-needed basis by existing tools).
If I may, simply version controlling the DF install (with Git (http://en.wikipedia.org/wiki/Git_(software)), for example), would give you the ability to do just this rather easily (i.e.: no writing diffs manually). A sample flow would be to make a branch for the mod (vanilla install in the master branch, the mod in my-mods-name) and make all mod changes in my-mods-name. Then, when a new DF releases, you switch to master, wipe out the contents of the branch, unpack the new version into the repository and commit it into the master branch (you just replaced the master branch's version with the new version), and rebase the mod branch on master (replay the branch's changes on top of the updated master branch).