Maintaining Compatibility With Other Mods

Hello, I am Iamgoofball. I noticed that a lot of you are having issues with mod compatibility due to mod authors editing the same files. Here's some tips and tricks for modders to maintain compatibility with other modder's creations so that everything can be run at the same time with minimal issues.

Tips and Tricks on Mod Compatibility:

• Put "[modname]_" at the start of all your files, IDs, and anything related. This ensures you know exactly which files were added by your mod. For example, ChemBound has "chembound_" attached to the front of all the file names and IDs, so "bottle" would become "chembound_bottle". This prevents conflict errors at the same time as allowing you to find your files.
• Don't edit files that come with the base game. This is crucial to maintain compatibility and easy uninstallation. When used in combination with the above tip it makes uninstalling mods manually a breeze. If you think that you must edit a vanilla file, go to ##starbound-modding on irc.freenode.net and ask if there's a way to do it without editing a vanilla file. If anyone has the answer, they should.
• Keep an eye on the modding scene. If someone releases a big new modloader that requires drastic changes in how you distribute your mods, package up your mod for using it. This not only ensures people don't have to jump through hurdles to install your mods, but also ensures you can easily bugtest your mod playing it the same way your consumers, or players, do.

Tutorials on Mod Compatibility
Tutorial 1: Adding recipes to a player's list without editing player.config
For this tutorial, we will be using the Chembound Empty Bottle as an example of how to do the first way.
Keep in mind that Stone Furnace recipes do not need to be put inside player.config to work.
Let's look at the recipe file for the chembound_bottle.

Code:

{
  "input" : [
    { "item" : "glassmaterial", "count" : 3 }
  ],
  "output" : {
    "item" : "chembound_bottle",
    "count" : 1
  },
  "groups" : [ "stonefurnace", "all" ]
}

As you can see, it's a furnace recipe that smelts 3 glass into a bottle.
Let's go look at the item code for the chembound_bottle now.

Code:

{
  "itemName" : "chembound_bottle",
  "rarity" : "Common",
  "inventoryIcon" : "bottleinv.png",
  "description" : "It's an empty bottle.",
  "shortdescription" : "Bottle",
  "learnBlueprintsOnPickup" : [ "chembound_bottle_potassium", "chembound_bottle_water", "chembound_bottle_sugar", "chembound_bottle_phosporous", "chembound_bottle_antitoxin", "chembound_bottle_inaprovaline", "chembound_reaction_explosive", "chembound_reaction_gas", "chembound_reaction_healgas" ]
}

Notice the "learnBlueprintsOnPickup" part. That's what Chembound uses to give you the recipe as an option. It allows me to add recipes to your list of blueprints without modifying any core files.
Say we wanted to add a "chembound_bottle_liquidbananium" recipe, and that we had it coded and ready. Our goal is to make it so that when you pick up a bottle or craft one, it gives you that recipe.
So, we would add "chembound_bottle_liquidbananium" to the array. Provided you have written up the recipe and have it coded and in the right places, all we would have to do is this:

Code:

{
  "itemName" : "chembound_bottle",
  "rarity" : "Common",
  "inventoryIcon" : "bottleinv.png",
  "description" : "It's an empty bottle.",
  "shortdescription" : "Bottle",
  "learnBlueprintsOnPickup" : [ "chembound_bottle_potassium", "chembound_bottle_water", "chembound_bottle_sugar", "chembound_bottle_phosporous", "chembound_bottle_antitoxin", "chembound_bottle_inaprovaline", "chembound_reaction_explosive", "chembound_reaction_gas", "chembound_bottle_liquidbananium", "chembound_reaction_healgas" ]
}

And now, when we pickup or craft the chembound_bottle, along with all the other recipes defined, we will gain the chembound_bottle_liquidbananium recipe and be able to build it. All without touching player.config. This ensures the mod is compatible with any other mods that touch player.config.

If you have any suggestions for additions to these sections, let me know in the posts below. Thanks for reading, and have fun developing Starbound mods!
PS. If I could get this stickied that would be awesome.

 

This is nice, but sadly not all mods will be able to work like this. For example, what if I want to add a crafting table? I would need some way to craft it with either my hand, or through another crafting table. I cant use something like smelting an item to get it. Still... very clever.

 

I should probably explain a bit more.

What you're doing is just making an item that's entire purpose is to unlock blueprints. Not actually creating the object you want. It just makes it so that crafting it is an option.

 

I understand perfectly what you are saying. But if that item that you create for learning the blueprints on pickup is not obtainable via smelting/cooking/printing (EG. Any other way that is not through a crafting bench) then you are still stuck in the "I need to edit the default blueprints" scenario.

 

Ah, alright., that makes more sense.
I'll look around for ways to bypass that too.

 

You could do something like make an item called "[modname] Manual", a book-like object crafted from a few plant fibers, which then "teaches" your player all the blueprints your mod needs.

 

That is exactly what you should NOT do. You still need to modify some loot tables to make it drop, or be spawned, or otherwise obtainable.

 

In the OP goofball said that recipes that are part of an existing crafting table (such as a stone furnace) don't have to modify core files to work; so I assume what Phlosioneer means is that the manual would be available through the crafting bench. I might be missing something, though.

 

Yes. You are. Just because it is in a crafting table already does not mean it will just work from the start. He got around this by using the furnace recipes which does not require blueprints.

 

Don't you need to modify some base files to get the item that unlocks blueprints anyway? there's no way to give the player the item to unlock the blueprints without modifying loot tables or quests.

(Besides furnace recipies ofcourse, which are a little silly for proper progression and integration)

 

It's silly, but it works. Up until people start doing it too often. Then we need a new way when all the mods have smelting dirt or rainbow wood or what have you to get their recipes.

 

Compatibility shouldn't be too much of a problem once someone does finish a dedicated mod manager. It's a matter of writing a program that can look at the base file, the mods that alter that file, and combine them all into one while maintaining the format integrity. It's an easy thing you can do manually with only a minor understanding of software programming. The hard part is getting a program to do it automatically, flawlessly, in a way capable of detecting human errors in the modded files.

 

So basically, the lesson we've learned here is "we can't."

Appending the mod name to the item is a good idea, though. Looking forward to when we can add crafting recipes that don't conflict with all other similar mods.

 

Seriously? Couldn't you just make the blueprint available on pickup of something really common... Like.... Pixels?

People have to get pixels and will always get pixels...

 

But if you were to do that with pixels, wouldn't you have to modify the base pixels item?
I feel like there are two possibilities for a workaround. The first is a mod manager (which could simply add default recipes and items to the player.config programatically). The second is that we demand for a better way to implement defaultItems and defaultRecipes. Perhaps instead of a "player.config" the devs instead change it to "*.playerconfig" so there can be multiple .playerconfig files?

 

I'm all for the mod manager route. Where the mod manager adds recipes that are flagged to player.config with the modname prefix. Then if a user removes a mod, it can pull them back out. Maybe use XML since it's pretty strict and the modmanager could deny adding the mod if the XML syntax is incorrect or if the modname prefix conflicts with an existing mod. That way if a mod author messes up and uploads a mod with a bad config, the mod manager wouldn't screw up the player.config file.

Mod authors could then have manual installation instructions for people that choose not to use the mod manager for whatever reason where part of the process is overwriting the player.config file and it would be up to the end user to resolve conflicts between mods on their own or use the *recommended* method of using the mod manager.

 

It's all well and good that this method let's you not touch the player.config file and therefore avoid that sort of conflict, but there's still a problem- that if you and another mod modify this file there will be conflicts.

So while you've avoided the player.config file, you've not avoided mod clashes. Just because you mod something out of the way, doesn't mean you're not modding something someone else has.

 

If everyone used unique item identifiers, it wouldn't be a problem.

For example, modname_modder.

Like, chickengun_neurisko. The odds of someone using that naming scheme is astronomical.

 

Note: I've not read the entire thread, I'm just throwing in two cents.

When using this hypothetical mod manager or simply modifying player.config in general, you still need to create a new character every time something is changed. Nasty crashes and perfectly generic items are two probable outcomes from not doing this, especially when removing assets. Perhaps when the player (and universe?) files have been deciphered can a mod manager "clean up" properly.

I'm not sure it'd be practical for a mod manager to try and merge changes. In the event multiple mods are trying to modify the same stock files, I would assume that said mod manager would more likely fall back to some sort of configurable load order (like Skyrim, Terran Conflict/Albion Prelude) than try to account for and merge any and all changes, flawlessly. Obviously things are a much simpler if mod authors create all their own assets however, they could be using the bootstrap.config method or simply plonk all their mod files in a custom subdirectory of the assets folder, "Assets/Mods/ModName" for example). I've been using the bootstrap.config method myself. Tasks could be automated using Command Prompt (.cmd or .bat files) to make client's [or your] lives easier.

It probably goes without saying but tweaks are continually being made to stock files too, so if you've used any of these pre-updated files (craftingtable.config for example) as a base and your modified versions still contain some stock code, some comparison software might be handy after an update. Notepad++ has a simple plugin called "Compare" for instance, you can download and install it via the Notepad++ Plugin Manager if you have it installed. Comparing all your modified files though may quickly become tedious as your mod grows.

 

Sure there would still be conflicts if two mods try to overwrite the same game file. From what I've seen the only reason to overwrite core game files would be cosmetic and vanilla stat changes.

It would be up to the mod authors (or another person) to resolve those conflicts so that they play nice together.

Mod authors, with the exception of rebalancing / complete overhaul type mods, should be able to easily avoid modifying core game files.

For example, if I want to make a mod that makes the matter manipulator useful I could just change the vanilla values overwriting the original file. Or, I could make a brand new item, "Matter Manipulator MKII" that has the stats I want and adds in a crafting recipe that takes only the vanilla MM as a component, uses the same sprite as the vanilla item, and when named correctly and injected into player.config by the mod manager wouldn't conflict with anyone elses mod.

That way players could install one balancing type mod that modifies core files, and many mods that just add new content.

As for cosmetic mods, as an end user why would I download conflicting mods? If two mods change the appearance of the racial armor, why would I try to install both of them? And in that type of scenario, wouldn't the last mod to load take precedence?

Lastly; part of the XML spec for the modmanager could require authors to list the core vanilla files that their mod changes (along with any dependencies on other mods), then the mod manager could deny installing conflicting mods or mods that are missing prerequisites.