Upcoming Mod Support Changes

[JarrettM]

Hi everyone,

We’ve been thinking about ways to create a smoother update experience for players who use mods. We make an effort to avoid breaking mods if possible, but we also need to be able to improve our code and add new features.

In future updates, we’ll be creating a “previous update” branch that offers a grace period for mod developers to update their mods without disrupting gameplay. 

There are a few caveats—see below. 

For players: “Previous update” branch

Each time we ship a major update, we’ll make the previous update available on a Steam branch. This branch will be available for a limited period of time after the update’s launch and will be removed when a new “previous update” branch is created.

Players can opt in to the “previous update” branch to continue playing while mod developers update their mods, finish the current playthrough, and/or use this extra transition time to prepare their save file for the new gameplay challenges. 

Caveats:

• Opting in to the “previous update” branch means opting out of all new features, fixes and content contained in the update. 
• If a mod developer has updated their mod to match the live branch (aka current update) and has not created an archived_versions folder, the mod will be broken in the “previous update” branch. See below for information about archived_versions.
• This branch is unsupported. Please do not report bugs or issues related to this branch. 
• This branch is temporary. 

Does this affect the Public Testing branch?

No. The Public Testing branch will still be updated with work-in-progress changes prior to an updates release.

When is this happening?

When we ship our Klei Fest update (tentatively scheduled for sometime in May or June), we’ll open a “previous update” branch to temporarily preserve the content from our February update. 

For mod developers: “archived_versions”

We introduced mod support for “archived_versions” a while back. This makes it possible to publish two or more mod versions in the same distribution—the game will dynamically load the correct one. 

Archived_versions are intended to allow mod developers to update their mods on one branch without breaking them on another. When an update goes live for everyone, it seamlessly transitions to using the updated version.

Best practice:
When updating a mod to support the live branch, we recommend that you include an archived version for the “previous update” branch so that anyone playing on that branch can continue using your mod.

More info on the archived_versions folder here.

For mod developers: “Obsolete” attribute and modding API

When we preserve old code to maintain mod support, we’ll mark it using the “Obsolete” attribute. This indicates that this code may be removed in a future update. You should see warnings when compiling your mod. 

It recently came to light that building mods were not using ModUtil.AddBuildingToPlanScreen because it lacked the ability to insert it before or after a specific building. We added that functionality in a recent hotfix. 

While we can’t promise to expand our modding API with every request, we encourage you to let us know in this thread if you feel that something is missing.

Summary

Opting in to the “previous update” branch allows players to continue their games short-term, and our existing archived_versions system allows mod developers to maintain mod compatibility across both the “previous update” and live branches. 

There’s a chance we’ll need to make adjustments to this new strategy as things develop, but we’ll make sure to loop you in on any changes. 

We hope this will help make future updates easier to navigate for everyone! 

[Cairath]

That's great news, thanks a lot!

[Gurgel]

It is a difficult problem. This is probably the best that can be done with the current tools.

[arvenil]

I think the flow should be a bit different. I would say there should be pre-release branch as intendent for release and if possible mod creators notified that there is new version to be released

 

Not sure if feasible but maybe automated way to load all popular mods into the game before pre-release and checking if some failed to load

[Cairath]

There already is a branch that is pre-release - the testing branch. People just cannot expect mods to work there. For us modders it's time for update preparations

[ALCRD]

Wait the currently available "previous version" beta (that is update just before the Big Merge) will be removed/updated?

RIP so my performance will go to nearly unplayable on that version too.

Well was good while it lasted.. :/

Cause in "previous version" i get 60-50 fps on medium bases and 80% of map explored while on any update after the merge including current one: ~20fps in same scenario.

Guess my adventure with ONI is over cause honestly i cannot fix or pin down whats causing such a drastic leap in performance between versions before and after the merge with SO.

I hate Unity engine with passion...

[pether]

11 hours ago, JarrettM said:

While we can’t promise to expand our modding API with every request, we encourage you to let us know in this thread if you feel that something is missing.

That is great news! Thanks a lot for the info.

I believe that adding items to the tech tree and registering strings (mostly for buildings, but also traits, critters, plants, diseases, status items, etc) are two most commonly used pieces of code and having API for them would be great. But I understand such things take your time and aren't high priority for you.

Please let us know if modding community could somehow help you with the API (in other way than the feedback) - all in all we already have this code and the experience with it and by nature we love sharing with community

[DolphinWing]

1 hour ago, ALCRD said:

Wait the currently available "previous version" beta (that is update just before the Big Merge) will be removed/updated?

I think they will keep it since you asked. Of course I may be wrong but Klei will listen our feedback and they will come up a good solution to that. 

 

12 hours ago, JarrettM said:

In future updates, we’ll be creating a “previous update” branch that offers a grace period for mod developers to update their mods without disrupting gameplay. 

Here *creating* in my understanding is a new branch. So I guess they will keep it. But again mods may not be supported I'm afraid.

[SharraShimada]

Is there any chance to get a "As it is version" that people can just install, put the then working mods into the game and leave it that way? No autoupdates, no new problems? Just this one version to play with as long as they see fit?

[sakura_sk]

2 hours ago, SharraShimada said:

No autoupdates, no new problems? Just this one version to play with as long as they see fit?

Let the forever bugs stay forever unfixed? Sure there will be no "new problems", just the old problems.  I'm sure you like dupes getting stuck in oil wells and fish feeder eating the food meant for the fish.

[RomenH]

Quote

While we can’t promise to expand our modding API with every request, we encourage you to let us know in this thread if you feel that something is missing.

I would love to see more methods on ModUtil that are kept in working condition for every update. Methods found here can let modders defer the "best practices" to Klei for some of the most commonly used helper methods that mods need. As pether pointed out, adding buildings to a technology seems to be missing from ModUtil.

 

A second request that I would like to make on behalf of a couple other modders is about providing some method for inter-mod communication.

I believe that adding a Dictionary<string,object> ModData member to UserMod2 will allow mods to exchange data and enable some cross-mod integrations that aren't possible right now. Right now all of the mods that attempt to do any kind of interop need to work around the difficulties of reflection and safely loading shared referenced assemblies. With this dictionary, modders can document the keys and values used by their mods and allow other modders to manipulate them without needing reflection to find the actual dictionary instance. (This is a big challenge right now!)

 

[EricKlei]

I've noted the modding suggestions in this thread and will continue to monitor it for further suggestions.

@RomenH Could you point me to mods which already implement inter-mod communication or would benefit from it?

[SharraShimada]

5 hours ago, sakura_sk said:

Let the forever bugs stay forever unfixed? Sure there will be no "new problems", just the old problems.  I'm sure you like dupes getting stuck in oil wells and fish feeder eating the food meant for the fish.

If there are no bugs that bother a player, why should the game be updated? Most of the bugfixes in the past few patches i did never run into, and if, i never noticed, so the have never bothered me at all.

[RomenH]

@EricKlei

Among my own mods I have LUT Not Included and Festive Decor working together. Festive Decor changes the colour correction for the game to give it a more spooky feeling, and I have separated this colour correction patch into a standalone mod. If multiple mods want to override the colour correction through LUT Not Included then it can decide which one to use by the mod load order while also respecting the extra features LUT Not Included provides.
You can see how I've implemented a shared dictionary for my own purposes on my github. We can't simply reference another mod's DLL to access their public members because this causes all kinds of issues.

I believe some mods by Stephen (aka @Peter Han) on the workshop also use a shared dictionary like that to share data between his own mods.
Their PRegistry class can be seen on github too.

An unreleased mod that you may have heard of is the one that adds Twitch Chat Integration to the game, made by @asquared31415. Part of the modding community is communicating on the unofficial discord about how to make plugins to add more chat commands and integrate our own mods with that Twitch framework.

There are also a few ideas kicking around about mods in that discord that we can't make yet because we all need to agree on an interface to share data between these mods.

[Yobbo]

52 minutes ago, SharraShimada said:

If there are no bugs that bother a player, why should the game be updated? Most of the bugfixes in the past few patches i did never run into, and if, i never noticed, so the have never bothered me at all.

Because more people than just you play this game.

If all the developers cared about was your personal opinion on what was or wasn't important, not those of any other player... honestly i don't think there's any way i can point out everything that's wrong with this while remaining polite.

8 hours ago, SharraShimada said:

Is there any chance to get a "As it is version" that people can just install, put the then working mods into the game and leave it that way? No autoupdates, no new problems? Just this one version to play with as long as they see fit?

There has been a non-updated pre-mergedown version available as a beta on Steam since last June.

[DDElephant]

2 hours ago, Yobbo said:

Because more people than just you play this game.

If all the developers cared about was your personal opinion on what was or wasn't important, not those of any other player... honestly i don't think there's any way i can point out everything that's wrong with this while remaining polite.

There has been a non-updated pre-mergedown version available as a beta on Steam since last June.

I think the request of "as it is version" is reasonable, especially for a completely offline game like ONI and it should be possible in theory (as it is the nature of "unlicensed/pirated distributions"). However, the problem is that Steam don't allow players to stick to a specific versions of games so that develops have to create extra branches for players, which may take unnecessary extra efforts for Klei.  

With that said, I notice that Factorio has all its major versions and recent minor versions listed in its branches. I think it would be grate if we can have something similar for ONI if that won't take too much effort. 

[Aki Art]

3 hours ago, EricKlei said:

I've noted the modding suggestions in this thread and will continue to monitor it for further suggestions.

@RomenH Could you point me to mods which already implement inter-mod communication or would benefit from it?

A small extra example would be my Decor Pack I, it adds tons of tile variants that currently ship with other mod's elements built into it, instead of those other mods being able to register their own variants or create add-ons to expand on it. All tweaks have to be done through me updating this mod. A dictionary like that would simply let the other mods tell me what elements/items they got, and what image file they want for it, and my mod could just handle the data provided very easily.

I have other mods on their way which could benefit from this Dictionary greatly as well, one of them would love to use LUT Not Included and supply it some data, which Romen mentioned.

 

There aren't many examples of interop mods live because right now most often modders just shy away from implementing it.

Also relevant i think that modders have some kind of unwritten rule to not patch/reflect each others mods without permission; which takes extra rounds of effort; while a mod using this dictionary would be an explicit way in for interactions.

[SharraShimada]

@Yobbo i honestly dont know whats your problem with me. I only asked a question to the devs, not to you. And not even for me, because i manage to use the up to date version. But i know for a fact there are people out there, who just want to play for a few hours, with working favorite mods, and dont want to worry about there may be an update that breaks mods again when they come home.

[sakura_sk]

1 hour ago, SharraShimada said:

and dont want to worry about there may be an update that breaks mods again when they come home.

And that's exactly what this topic says will be possible with "previous update branch" so what is the problem?

[Prince Mandor]

1 hour ago, sakura_sk said:

And that's exactly what this topic says will be possible with "previous update branch" so what is the problem?

Problem: this "previous update branch" will update automatically with each update, making mods unplayable again, causing more slowdowns, introducing questionable mechanics and ruining old builds

[SharraShimada]

2 hours ago, Prince Mandor said:

Problem: this "previous update branch" will update automatically with each update, making mods unplayable again, causing more slowdowns, introducing questionable mechanics and ruining old builds

This. 

Its not a "keep this and be happy as long as you want". Its just a "hey heres something until the mods are updated, then its gone".

[RomenH]

Quote

Problem: this "previous update branch" will update automatically with each update, making mods unplayable again
...
Its not a "keep this and be happy as long as you want". Its just a "hey heres something until the mods are updated, then its gone".

You guys seem to not understand the "archived_versions" functionality.
 

As modders, we are supposed to be conscious of this new branch and ensure that the previous versions of our mods are included after updating. We've been through this problem before where mods had to have different builds for Spaced Out and Vanilla before "The Big Merge" happened. Lots of mods were available for both versions of the game for a while, and some even supported the testing branches too. You can count on the most active modders getting this right and supporting "previous update" too.

"archived_versions" being used to its full extent would mean a mod can be loaded by any version of the game ever released. Even if you freeze steam updates to keep an old version it should be possible to support you too.

If the game updates, the version you had the day before is going to be available in the "previous update" branch. So you switch to that branch. Then the unfixed mods will keep working, and fixed mods will be using their previous version from the "archived_versions" folder; So you get to have both fixed and unfixed mods on this branch!
Then when the mods you are using are all fixed, you could switch back to the main branch if you want.
The next time the game updates, you will be forced to "switch back" due to the branch updating, and most of the mods will be fixed by then anyway.
Not much can be done about a modder abandoning their mods in that time frame, but it should be uncommon.

[Prince Mandor]

28 minutes ago, RomenH said:

The next time the game updates, you will be forced to "switch back" due to the branch updating, and most of the mods will be fixed by then anyway.

And we are talking about exactly this. We are not happy about being FORCED to some changes in already released offline game.

For example, nothing wrong in changes of food decay rules in DLC. But changing this in already released vanilla version is wrongness.

We was happy and open to new changes while it was Early Access stage. In online games some fixes is necessity. But not in released offline game

[RomenH]

I don't think this is the appropriate thread to express those concerns. It seems like you want Klei to make another new branch, but this thread is not about asking Klei to make branches. It's about a specific branch they have already made and there are comments from modders here that shouldn't be missed/buried amongst the off-topic discusssion.

[Yobbo]

14 hours ago, SharraShimada said:

@Yobbo i honestly dont know whats your problem with me. I only asked a question to the devs, not to you. And not even for me, because i manage to use the up to date version. But i know for a fact there are people out there, who just want to play for a few hours, with working favorite mods, and dont want to worry about there may be an update that breaks mods again when they come home.

As i said, there has already been such a version for over 8 months.

I don't have a problem with you, i have a problem with what you have said and how you have said it.