So I opened this thread so that anyone who is clever can look and see (and hopefully add to) A list of things that will break cross compatibility for mods that would be a part of the UMS (Universal Mod Solution) Project. These are projects that share a common .dll code base. Here are some previous comments that inspired me to make a thread on this: Lib: Spoiler : So I guess in this goal oriented conversation we need to understand what modifications will/will not or may/may not break the core .dll. For the purposes of this conversation in my mind I am making two definitions. Core Dll and Xml Dll. Now I know they are one and the same but for this conversation they need a simple differentiation for 'Breakable Code base' and 'non-breakable code base'. Core Dll: Is the stuff like you just mentioned(See Nights post below). Stuff that will break 'cross mod compatibility'. Xml Dll: Stuff that will automatically read a default (probably 'off' in most cases) for every mod, unless it has the appropriate xml entry to make it do something, and so will not affect cross compatibility, but will automatically allow any mod to use the new xml effects if it so chooses when it updates it's .dll. Nighttinggale: Spoiler : What I want to do before next release is to make a "final" version of XML and savegame setups. 1. CivEffects 2. No arrays in savegames. Replace all with JIT arrays as this will make savegames less likely to break 3. Make JIT arrays save even less data (I have a nice idea on how to reduce savegame file size) That's it. Those changes could cause issues for other mods if added later, which is why I want it now. Everything else that I want to add can be added to multiple mods with few or no issues. "So the final question, what other modifications/concepts would/might be Core Dll, not Xml Dll?" Good question. Hopefully nothing after the next release. I made that list because I can't think of anything else offhand, which I would like to add and would break stuff. There are a number of core features (like AI), which can be improved without breaking anything. If we need a new setting, which has to be set, one solution could be to assert on the default setting. That way we will know which setting to adjust to fix the problem, which is more or less the same as not breaking the game. Now that I think about it, I wrote about route movement cost. It is currently set to how many 1/60 of movement points it cost. I want to change it into how many plots one movement point can travel as this is a whole lot more friendly towards CivEffect, which can then give +1. In fact it can make a road, which cost 1 movement point and then have two CivEffects giving +1 and they stack as intended, something which isn't possible right now. I have come to the conclusion that we can split development into a few steps: 1. CivEffects is finished. XML modding can begin and graphics can be added. 2. More CivEffects (like traits) are added to XML and can be changed by a mod. 3. DLL gets a savegame upgrade, which breaks old savegames. 4. M:C is tested, bugfixed and released. Originally I planned for other mods to start at step 4. However strictly speaking mod development could start when 1 is done, which is why I will aim at 1 right now.