Having seen a few threads about people wanting to merge various mods, and having read of jiaco’s and other’s experience with merging various mods together, I thought a thread that discussed this issue would be useful. (If there’s already a thread @ this issue, please point me to it.)
Are there things that a modder can do when creating a mod to make it easier for others to merge it with another mod?
I perused through Elfe’s tutorials, and it seems like naming of things would be the big issue, e.g. *.dbr files.
If that’s the case, some sort of “namespace” per modder/mod would work? For example “jiaco-grimmest-*.dbr”, Though I suspect filenames would get long.
Are there other things, e.g. variable names, etc that would be useful for a modder to know and prep for in order to facilitate the ease of mod merging?
A namespace per mod would be the way to go imo. There are still some adjustments when you merge depending on what you merge, but it would resolve a lot of problems. Use it for both .dbr and source files
Next would be to not change vanilla files when possible or as little as possible and have as many changes as feasible in mod specific files.
This is how I started doing things, so don’t take it as a rule of how to make a mod, I’m sure I’m the only one who actually does it that way:
I always make a new folder for my *.dbr - I don’t use the records folder, even if I’m trying out something new I make a dev folder where it all goes in, the only time where I need to use the records folder is to override vanilla for the reference, you won’t get around that, but updating a comp where the records folder is done with all these dbr references and all you have to copy over is the mod’s folder (can ignore records unless there was a new feature which the creator could mention), should make it easy to keep that mod up to date.
Same with sources, new folder with all the quest, conv, tex, scripts inside the only ones that need to go in their vanilla directory are tags (TEXT_EN) and in case of scripts the include for the main.lua inside the scripts/main.lua. For tags I do modtags_mymod-items.txt.
A side note for quests/conv translations, apparently they only have the file name and no paths to them, so you should give them a unique name (myfunmod-startquest.qst).
You could even copy the .arc into the vanilla resources and it would work for every mod that needs it only really useful when the arc becomes massive and you don’t want it 5 times, because all the compilations are using it.
I believe Ceno started putting his Zenith source into a separate *.arc as well.
as an example:
|-- database
|-- dev (can be ignored if using github or move it out before making the *.rar/*.zip)
|-- mod_myname
|-- records
|-- source
|-- scripts
| |-- main.lua
|-- text_en
| |-- modtags_myname-items.txt
|-- mod_myname
| |-- quests
| |-- conversations
| |-- scripts
| | |-- main.lua
|-- mod_myname_levels
Also has a nice side effect of being more structured and organized, when you start using these mods like stasher/goodlooking in your mod.
The initial setup for a compilation can still be a pain, after that it can become easier to update it (that was my intention at least), but at this point forcing everyone to redo their mod is not something we should do.
There can always be issues merging mods, being in touch with the person who made the mod can help here, too.
I also prefer database files set up per the vanilla tree, yet source files in custom folders (Ex: database/records/skills/playerclassNecrotic/selfies.dbr, source/Necrotic/images/selfies.jpg). Zenith went to this system later and I found it helpful to finding images for quick editing as needed.
The work of Warebare and Okami was easy to manage as well. Do to the unique nature of their mods, their database material were in their own custom database folders. They could pull this off because the they had very little overlap with other dbr files. Again, drag and drop updates for the most part.
There are only a handful of files that overlap between mastery mods. The comp curator will have (should have :p) identified those files and set them aside in his/her custom folder. After all drag and drop updates are done, copy the custom files in overwriting the existing, test, package, deliver. Another drag and drop operation ftw
Try not to use enumerated file or folder names (PlayerClassBadass is better than PlayerClass17). And if doing a mastery mod, try not to include game changes outside of that (camera behavior, mastery points, etc). Lazy modders like me would miss those changes until the player feedback started rolling in.
Never have a record in your mod that is not modded.
Think of your mod as a patch to the main game. Even when you add new records and are not overriding vanilla ones, your mod will become out of date fast. The devs never stop tinkering and even templates can change. You will rapidly become incensed at your inability to tell if a change between a new-vanilla-record and your-mod-record is because you actually modded that value, or if you had the old vanilla value but that value has since been changed by the devs.
Updating something like Grimmest is more and more me following my own guide to remake Grimmest from scratch so that it can always be based on the latest records from Crate. As that has somehow worked out to be easier than trying to read difference logs between text file comparisons.
only really useful when the arc becomes massive and you don’t want it 5 times, because all the compilations are using it.