Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Random idea for mod merging/compatibility  (Read 612 times)

somebears

  • Bay Watcher
    • View Profile
Random idea for mod merging/compatibility
« on: January 02, 2018, 04:23:29 pm »

After thinking about managing/merging mods over the holidays and reading various threads around here (of special note is probably http://www.bay12forums.com/smf/index.php?topic=142295.0 and the ones concerning PyLNP, PyDwarf, BAMM, Rubble and all the ones I have forgotten), I've had a random idea, that I like quite a bit and that could solve some problems that exist. And now I am stuck waiting for my train home, so I decided to create this thread. Whatever comes out of this will probably be some random side-project, but I'd like to avoid to work on something completely pointless.

Please note that (at least for the context of this post) consider the process of simple (just replacing/adding/deleting a line/tag) as solved, although there are still open questions.


My proposition:

Generate a structure that, let's say represents dwarves and how they work in the raws. (if raws were in xml, those structures would be a XML-Schema.)
So basically a file that says what is "allowed" or "compatible" and what's not.

By parsing both the base raws and the raws of the mod file, two structures are created. By comparing those structures I hope to be able to create a strategy for merging those mods or at least detecting their incompatibility.

Such a structure would have to have the following basic properties:
  • If two mods have the same structure, they should be very easy to merge
  • also: mods that can not be trivially merged should not have the same structure (ideally not even similar)
  • If two mods have a similar structure should be reasonably easy to merge
  • there is some way of creating a sort of "translation" to allow mods with different structures to be merged correctly

A more specific example:
Please note that this is just an example to get the general point across, I do not know how the structure will look like or what it will do exactly. Those raws will probably not even work.

Spoiler (click to show/hide)
TLDR of the spoiler; We detected an inconsistency between two mods changing castes and then created a patch to solve the problem

Why do I think this is good?

  • It supports "classic mods" because it does not require mods to have a certain structure/language
  • worst case: the raws are so different/complex that the created structure is not usable. In this case we can just fall back to other merging methods.
  • it can be used to divide mods into smaller parts that can be merged with ease - divide and conquer!
  • the merging system can be optimized for small merges and still work great with big mods
  • many mods should work out of the box
  • a annotation system can ease the creation of compatibility patches, feature just active when a certain mod is present. Also easy graphic packs.
  • facilitates modding standards

If all this does not feel very structured, I apologize. It's little more than a random idea at this stage and I have tried not to make it too technical or concrete.

As a modder I'd probably be culled during wold gen, so before I dive into programming and excessive experimentation I'd like to make sure this is not an obviously bad idea from the start. Also someone might have an infinitely better idea.

To this end I'd like to address my biggest concerns:

In order to require as few compatibility patches as possible, the structures have to be as broad as possible but as narrow as necessary to avoid conflicts. I do not know if such a balance can be found, I could be underestimating the complexity of many mods.


Deciding what structures are compatible might not be reliable enough. This can be avoided by not allowing changed structures without patches, but that kind of defeats half of the purpose of this.

I do not want modders to not implement a feature because it would not be compatible with some arbitrary standard created by some script that I wrote.


What do you think?
Would it even help with anything / make any sense or is this a stupid idea?
Logged

Hugo_The_Dwarf

  • Bay Watcher
  • Modding Mentor
    • View Profile
    • Regeneration: Forced Evolution
Re: Random idea for mod merging/compatibility
« Reply #1 on: January 02, 2018, 06:05:35 pm »

I like your idea, I actually have one very similar, the only challenge is the formatting for complex objects like creatures, and now, entities (with the ANIMAL tags now) and Interactions/materials with syndromes


I was thinking of the program reading vanilla raws, and formatting it in a known manner, then reading raws of "mods" then comparing the formatted versions to find "change of actions" between the two and allow a "pick all from 1, or merge both favor changes from 1 (conflicts overridden)"

this would allow for mod updating/merging however the logging and technical readout would be more for someone with an understanding of Raws to make it "user-friendly" just have to allow for assumptions and configs (mod load order)
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Random idea for mod merging/compatibility
« Reply #2 on: January 03, 2018, 12:27:37 pm »

Parsing the raws is absolutely terrible and I hate it so.

I would personally export any consistent schema by using DFHack to read the already-parsed raws and spit out some properly computer-readable data rather than reading the raws directly. It's not that the raws aren't computer-readable (obviously they are, otherwise they wouldn't work), but something that's actually consistent rather than requiring weird-ass backreading would be great.