PlotinusRedux
Warlord
- Joined
- Jul 11, 2013
- Messages
- 196
[EDIT: I've got an experimental version of this ready at https://forums.civfanatics.com/resources/civ-6-mod-manager-experimental.25880/ ]
I'm just getting started on Civ modding--I never did any with the early Civ's, though I've been an avid player since Civ 1.
Apparently most UI mods require completely overriding existing .lua and .xml files under Base\Assets through <Import>. I'd have thought they'd make a system where you could override specific functions in .lua and tags in .xml, but apparently not.
I've already run into an incompatibility with another mod because we both modified DiplomaticActionView.lua and .xml--even though we modified different parts of both files and our mods would actually complement each other.
The differences are easily automatically resolved with any 3-way merge application, but most users won't even know what a "3-way merge" is much less how to do it. One user has already merged our mods and posted a link to it, but he'll have to update that any time either of us make a change and then if someone else posts a 3rd mod affecting the same files....
So I have a proposal I'd like feedback on.
I've used a an open-source 3-way merge library that handles merges fine as long as neither branch modified the same line. I've tested it on the mod conflict above and it produced a new mod combining both of them that works fine. Of course that won't always be be the case--if both branches modified the same line (by heuristics, not line #), it will fail, as it should, because that represents a true incompatibility. Also, since it doesn't understand the logic of the files it's merging, the merged file might not work--if one person deleted a global the other person refers to, etc. But 95% of the time, unless the mods really do conflict, it will work.
So my proposal is to write a ModManager application (sorry, mac users, in C#, I'm just not familiar enough with Java to do it in Java--Java is one of the few major languages I've never spent significant time with. I could do it in C++, but I'd end up making Windows calls for the UI anyway). It would read through the mods directory and list all mods installed, along with any that conflicted with each other (at least initially just on the basis of overriding the same files in the Import section of the .modinfo file). It could also list additional information such as version--maybe eventually linking to Civfanatics.com to indicate if a new version was available, though that would probably require Civfanatics.com to add a query page--or at least if the .modinfo included a custom <url> tag under Mod\Properties, provide a hot link to that, which could be the Civfanatics page for the mod.
Anyway, the main thing would be from there the user could check conflicting mods and it would attempt to build a new mod that included them all using 3-way merge to resolve differences, with a warning that the result might not work and a failure message if the merge found conflicts. That mod would automatically be added to the mods directory with a description listing all the mods (and their authors) included in it and a custom Mods/Properties value that would allow the ModManager to recognize it as a merged mod and offer to rebuild it if any of the included mods changed.
That's something I could write in 2-3 days--I wrote the base already to test merging my mod with the one it conflicts with. Of course I'd post the source to on GitHub.
Would something like this be useful and a good idea? Would a more limited tool for modders showing differences from the base files and letting them manually resolve any 3 way merge conflicts be better (the for-general-consumption one would just fail if there were any conflicts that couldn't be auto-resolved), though they'd then have to post the resulting combined mod for others to use and redo it when any of the underlying mods changed?
I'm just getting started on Civ modding--I never did any with the early Civ's, though I've been an avid player since Civ 1.
Apparently most UI mods require completely overriding existing .lua and .xml files under Base\Assets through <Import>. I'd have thought they'd make a system where you could override specific functions in .lua and tags in .xml, but apparently not.
I've already run into an incompatibility with another mod because we both modified DiplomaticActionView.lua and .xml--even though we modified different parts of both files and our mods would actually complement each other.
The differences are easily automatically resolved with any 3-way merge application, but most users won't even know what a "3-way merge" is much less how to do it. One user has already merged our mods and posted a link to it, but he'll have to update that any time either of us make a change and then if someone else posts a 3rd mod affecting the same files....
So I have a proposal I'd like feedback on.
I've used a an open-source 3-way merge library that handles merges fine as long as neither branch modified the same line. I've tested it on the mod conflict above and it produced a new mod combining both of them that works fine. Of course that won't always be be the case--if both branches modified the same line (by heuristics, not line #), it will fail, as it should, because that represents a true incompatibility. Also, since it doesn't understand the logic of the files it's merging, the merged file might not work--if one person deleted a global the other person refers to, etc. But 95% of the time, unless the mods really do conflict, it will work.
So my proposal is to write a ModManager application (sorry, mac users, in C#, I'm just not familiar enough with Java to do it in Java--Java is one of the few major languages I've never spent significant time with. I could do it in C++, but I'd end up making Windows calls for the UI anyway). It would read through the mods directory and list all mods installed, along with any that conflicted with each other (at least initially just on the basis of overriding the same files in the Import section of the .modinfo file). It could also list additional information such as version--maybe eventually linking to Civfanatics.com to indicate if a new version was available, though that would probably require Civfanatics.com to add a query page--or at least if the .modinfo included a custom <url> tag under Mod\Properties, provide a hot link to that, which could be the Civfanatics page for the mod.
Anyway, the main thing would be from there the user could check conflicting mods and it would attempt to build a new mod that included them all using 3-way merge to resolve differences, with a warning that the result might not work and a failure message if the merge found conflicts. That mod would automatically be added to the mods directory with a description listing all the mods (and their authors) included in it and a custom Mods/Properties value that would allow the ModManager to recognize it as a merged mod and offer to rebuild it if any of the included mods changed.
That's something I could write in 2-3 days--I wrote the base already to test merging my mod with the one it conflicts with. Of course I'd post the source to on GitHub.
Would something like this be useful and a good idea? Would a more limited tool for modders showing differences from the base files and letting them manually resolve any 3 way merge conflicts be better (the for-general-consumption one would just fail if there were any conflicts that couldn't be auto-resolved), though they'd then have to post the resulting combined mod for others to use and redo it when any of the underlying mods changed?
Last edited:
