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. [h3]For players: “Previous update” branch[/h3] 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. [list] [*] 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. [/list] [h3]Does this affect the Public Testing branch?[/h3] No. The Public Testing branch will still be updated with work-in-progress changes prior to an updates release. [h3]When is this happening?[/h3] 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. [h3]For mod developers: “archived_versions”[/h3] 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 [url=https://forums.kleientertainment.com/forums/topic/126022-setting-up-mod_infoyaml-and-archived_versions/]folder here[/url]. [h3]For mod developers: “Obsolete” attribute and modding API[/h3] 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 [url=https://forums.kleientertainment.com/forums/topic/137919-game-update-497575/]recent hotfix[/url]. 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. [h3]Summary[/h3] 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!