Before I get started, is this the same project that the Starter Pack folks mentioned about using diffs for mods? Either way, my thoughts on what's here so far:
You lost me there. Is that object info encoded in the @@ line at the top? I'd much rather specify the object by type and token, just in case some other mod has left things untidy. [BODY_DETAIL_PLAN:STANDARD_MATERIALS] is enough to tell the program to look in body detail plan files. Just need some pseudo-objects to handle init files and such. Ideally, an entire mod could be contained in a single file.
...
Again, it'd be best not to assume you're starting from vanilla, especially since I've seen graphics packs that re-arrange the raws for internal consistency.
I got this idea from github, I don't know what other projects people are working on, Fricy mentioned something in a MW poll about the direction new modding should head in, I had this idea from back when I used to fail using mod manager, but recently learned the concept of cherry picking patch methods.
I don't know why your confused. The patch file was a LITERAL unified patch file, I was just supplying it as an example, WHAT IT IS MISSING is the object identifiers such as
[OBJECT:BODY_DETAIL_PLAN]
[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
that I would PREPEND to the front of the patch file.
I never said I'd start with vanilla [okay, maybe I said I'd use vanilla as a base]. What the goal is... is to identify differences FROM vanilla. That way a patch can be applied to "vanilla" dwarf fortress and turn it into a mod.
However, it doesn't have to be based on vanilla, but if one wants the exact patch differences between say a mod and vanilla. that would be what needs to be extracted to be applied to another mod.
Say I compare civforge to vanilla.
then I want to extract just what civforge changes from vanilla
and then import it over another mod
but... I think the same concept could be applied from the differences between civforge and say genesis... it's just that's what the patch is going to be based on... so if one applies it to vanilla, it's going to get you weird results I think.
The way I have github setup, is I handle all mod changes from a base, and I set the base as vanilla so I can see what that mod did differently. However, I'm not sure what I would base it on otherwise.
I had a different idea with comments, I don't want to assume they need to be on their own line.
I want to just position them where they were before in relation to tags/tokens.
If it was inbetween two tags, then put it back inbetween two tags.
If it was on it's own line, put it back on it's own line.
TBH, i'm such a newb with this, I'm still trying to get the hang of outputting to a new window before I start talking too much indepth of parsing methods.