Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Solutions for mod merging  (Read 1068 times)

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Solutions for mod merging
« on: March 04, 2019, 07:31:05 pm »

The raw files are difficult to work with in code, and the game does not support merging of two mods which change the same object (necessary for any mod that adds reactions to dwarves). PyLNP attempts this with standard 3-way merges of text files, but it fails way too often to be useful. There are a few solutions I've thought up for this, ordered mostly by how suggestiony it is for DF itself:

1. Write an entire raw parser in Python, manually implementing each individual token, then having a standardized exporter of its internal format. You have to manually write down every token, then put them together in a way analogous to how DF itself parses the raws. DFHack already has DF's memory mapped out for loaded raws, so that's not much of a problem, but manually putting down every token and how they relate to the individual parts is super annoying. However, this can already be done by someone willing to take the dive into tedium. I keep thinking I might be that person, but I'm not.

2. Just open up the raw parser for perusal and copying. Obviously I can't know how viable this is.

3. As 1., but have Dwarf Fortress include exporting to some standard format each individual object type and token; someone'd still have to write the separate parser, but not having to manually implement each token would be of great help.

4. Rather than raw duplication spitting out an error and causing weird off-by-one indexing errors, have raws in later files override raws in earlier files as if it were part of the same object. This is actually pretty weird in concept, since there'd e.g. be no way to remove a token from an existing file, such as if one wants dwarves not to have strange moods.

EDIT: 4.5. Have a more proper raw patching system to allow for addition and removal of tokens in existing objects without having to destructively overwrite the files that contain them. This is probably the way to go, considering steam workshop.

5. Spirits of programmers long passed crying for a proper scripting language etc. etc., would be a total overhaul in how everything works and break all existing mods.
« Last Edit: March 15, 2019, 07:37:32 am by Putnam »
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Solutions for mod merging
« Reply #1 on: March 15, 2019, 07:37:43 am »

Added a 4.5 considering the prospect of steam workshop.

FantasticDorf

  • Bay Watcher
    • View Profile
Re: Solutions for mod merging
« Reply #2 on: March 16, 2019, 05:01:51 am »

I almost spat my morning cup of tea out thinking about this and the concept of Toady writing a compiler to check submissions into the raws and help smooth over additional community made patches and modded content & utilities.

Actually just adding compiler support would probably make the game less dense and it easier to run a large amount of RAW'S and files at once similar to the HUGE winrar dump that is masterwork given that other indie games like SS13 (space station thirteen) also use compilers to properly update their content on servers via github and updating and handle more abstract game files.

Quote
Imagine a Pseudo reality where DF makes the jump to using a launcher with internet connection *and the game being connected* that auto-updates the game from github so you never have to download the (latest) version from the bay 12 page again and always keep up with the latest ones, or watching Toady submit PR's to dedicated DF github.

Look at DUNG for instance, which is utilised for MUD's via web connectivity for multiplayer text based games, adventurer mode with all local chat put into a talkbar and multiple players interacting with the world  on screen and far away.
Logged