I like the principle of NO SPECIAL CASES. No special syntax, no different behaviour, just diffs derived from the full set of changed files in the raws. If that makes some advanced stuff impossible, simple is better. (I've been reading
this list)
As to detecting merge conflicts, there are two ways to do it - both of which work to combine files. The fast and simple way is the standard merge conflict test; if your diff returns an error show the problem in the live preview.
The slow way, which will return no false negatives, is to add and subtract combinations of diffs to check that changes don't overwrite. For example, we take vanilla DF and apply mods by diffs A, B, and C in that order. We can then check for problems by confirming that VABC-A == VBC, VABC-B == VAC, skip the case VABC-C == VAB as trivially true, and also check VABC-AB == VC for completeness. Given that this is N-1 factorial checks for N mods, it could be too slow for a live preview but if we only call it when the fast merge check returns OK that should be acceptable. If one passes and the other fails, I'd probably alert the user and allow them to decide.
Modbase, rubble, Thistleknot's project are all awesome but
that's not what new players need. They don't need amazing merge tools. They just need an easy way to try some mods, and the LNP provides the model I want for graphics and utilities already. If you can only use one mod at a time that's not a fatal flaw for these users!
@King Mir: good points;
0.2 - Files that are identical to vanilla should be detected and removed, though this might come later (not 0.9 though, you're right)
- Any test versions that overwrite files instead of using diffs would be pre-0.1
0.3 - No. No special formats in the mod. Not until 2.0 minimum, and even then it has to be backwards compatible
0.4 - As above, I foresee using diffs early. Could change if it's harder than I expect, but unlikely.