In thinking about this, it seems to me that I-Novae Studios would be wise to organize their modding environment into distinct areas that are clearly delimited with software interfaces. The goal is to encourage modders to build their mods right on the Infinity:Battlescape software, instead of building mods on top of mods. The more of the latter that comes into being, the more likely it is that somebody is going to change something that breaks somebody else’s mod. That seems to be the great challenge with a modding environment; Mod A is incompatible with Mod B. If INS takes the bull by the horns and identifies each type of construct that can be created, and defines how they interact - and does it right - then mods will happily coexist with other mods. The only time folks would get messed up would be when INS changes their modding interface.
The most obvious example is a ship. The is a mod. A distinct area. A self-contained component. It requires all the stuff that we came to expect from building ships under the constributions system. Geometry, animations for hangars and gear, UV maps, various textures, hardpoint locations, etc. If you want to add a ship, you create a package that contains all of that information, and the rest of the game software interacts with it via defined ways.
So there may be another mod that adds a missile. That missile can hit any ship, be launched from any ship, detect any ship, etc, regardless of who created the missile and who create the ship. That’s because the missile must use standard sensors, which have a standard interface to users of the sensors. The sensors have a standard interface to the game world that allows them to detect stuff. The ships are part of the stuff in the game world and must adhere to sensor signature interfaces as well.
Note that if each of the ship’s internal components is defined as a mod with a clearly-defined interface, then somebody can come in and change the gear on the ship. Or the location of a hardpoint. Or the definition of the internal structure of the ship, whatever that means. Instead of a ship being a mod, it is a piece of a ship that is a mod. So if you want to alter the sensor signature on a standard INS ship, you would be able to do that.
The alternative is to just create some game software with data and logic, throw in a scripting interface and let the modders have at it. They’ll gradually create their own ecosystem of components, and the result will have the same traits as any other mod environment - lots of incompatibilities and the inevitable scramble to create and install updates.
If the modding environment is well-defined, then a charge-per-mod system becomes much more viable. The mod ecosystem is well-defined and players will have a sense of stability. So long as INS doesn’t make incompatible changes to the foundation mod structure, of course. For example, if a sensor band is added, that’s not a big deal. Lots of ships and sensors won’t operate on that band, but that’s acceptable. If a sensor band is removed, that’s going to break things.