Having some experience in a semi-unified semi-fragmented worlds that are GNU/Linux and Minecraft Modding , i was wondering what your ideas on such a concept was. GNU/Linux suffers dependency fragmentation, as well as Minecraft modding. Terasology and GNU/Linux falls in the same category of fragmentation since Minecrafts is much worst due to mods breaking every version, and almost everything being closed source. Minecraft Forge mod loader has some unity in the fact it has an ore library. We too have an ore library. So, it remains to be seen, if like linux, we can, and usually do, go off and do our own thing, or, more like Minecraft, which has a semi more tightly knit dependency group. Although, minecraft's current modding dependency state is not something to be desired. Should we have libraries for everything, or should modules provide their own.
Personally i believe modules should have ultimate freedom, but it should be strongly recommended to follow and use certain libraries (like GNU/Linux does). I also believe certain very important bits of code should be added to core. (for example, there are multiple dependencies for various minecraft mods that have to be updated each time minecraft updates, things like FML, bukkit/whatever server software they use now, deps used in mo' creatures, debs used in smart moving, important APIs that should be included in default etc.)
Currently we have a ore library, if a mod adds a normal, not overly specific ore (ie, chessandgoium, or cheese ore) they should just add it to the ore module, so then other mods can use it and have compatibility.
For example, trees (of the same code type) should be put in a library/tree module. Trees typically are very general, and an overland feature that users would encounter quite a lot, something any module could use. Of course the ShipsMadeOfWood module could build a compatibility with SomeOakTrees module, and SomePlantsWithLeaves module, but that is both more work, and the two modules are duplicating effort (as Oak trees happen to be a type of plant with leaves). Since many module authors may want to use, or build compatibility with some trees, it would be much simpler to put all general type trees into one tree module. Thus any modules that use trees are not duplicating effort, and can build compatibility quite easily.
Same should be done with biomes and perhaps soil and earth types. This can be easily seen in Minecraft modding.
Biomes O Plenty (open source mod if you are interested in perhaps lifting some assets, or looking into the terrain generation)
and Biomes XXL are both mods that add around 90+ biomes. These mods are totally separate from each other, and do not use each others biomes. As such, there are many duplicate biomes, and incompatibility. Other then this first level frustration, when adding other mods it gets even worst. Some mods interact with Biomes O Plenty some interact with Biomes XXL, some do neither because they have to code code to a specific API of each mod. Some are incompatible because they use their own biomes. These are biomes, very general things that and mod would like use. But these is a major split between them, and that is only the main two. As a module developer, wouldn't you like to just be able to use fall biomes or oasis biomes?
Imagine for a moment, we just put all general biomes into one module. Anybody can use any biome because they're all together. And if two modules use the same dep (the biomes module) then they are by nature compatibility and can interact between each other.
This is again shown in geology mods in minecraft. Many mods add their own soil, stone, earth, fossils, soil specific machines, etc, and none of them are compatible with each other. I just want to use silt dammit! I shouldn't have 5 mods trying to over write each other and do the same thing. I should be able to use my earth oven with my river clay, but i can't because they're from two different mods.
Personally i believe modules should have ultimate freedom, but it should be strongly recommended to follow and use certain libraries (like GNU/Linux does). I also believe certain very important bits of code should be added to core. (for example, there are multiple dependencies for various minecraft mods that have to be updated each time minecraft updates, things like FML, bukkit/whatever server software they use now, deps used in mo' creatures, debs used in smart moving, important APIs that should be included in default etc.)
Currently we have a ore library, if a mod adds a normal, not overly specific ore (ie, chessandgoium, or cheese ore) they should just add it to the ore module, so then other mods can use it and have compatibility.
For example, trees (of the same code type) should be put in a library/tree module. Trees typically are very general, and an overland feature that users would encounter quite a lot, something any module could use. Of course the ShipsMadeOfWood module could build a compatibility with SomeOakTrees module, and SomePlantsWithLeaves module, but that is both more work, and the two modules are duplicating effort (as Oak trees happen to be a type of plant with leaves). Since many module authors may want to use, or build compatibility with some trees, it would be much simpler to put all general type trees into one tree module. Thus any modules that use trees are not duplicating effort, and can build compatibility quite easily.
Same should be done with biomes and perhaps soil and earth types. This can be easily seen in Minecraft modding.
Biomes O Plenty (open source mod if you are interested in perhaps lifting some assets, or looking into the terrain generation)
and Biomes XXL are both mods that add around 90+ biomes. These mods are totally separate from each other, and do not use each others biomes. As such, there are many duplicate biomes, and incompatibility. Other then this first level frustration, when adding other mods it gets even worst. Some mods interact with Biomes O Plenty some interact with Biomes XXL, some do neither because they have to code code to a specific API of each mod. Some are incompatible because they use their own biomes. These are biomes, very general things that and mod would like use. But these is a major split between them, and that is only the main two. As a module developer, wouldn't you like to just be able to use fall biomes or oasis biomes?
Imagine for a moment, we just put all general biomes into one module. Anybody can use any biome because they're all together. And if two modules use the same dep (the biomes module) then they are by nature compatibility and can interact between each other.
This is again shown in geology mods in minecraft. Many mods add their own soil, stone, earth, fossils, soil specific machines, etc, and none of them are compatible with each other. I just want to use silt dammit! I shouldn't have 5 mods trying to over write each other and do the same thing. I should be able to use my earth oven with my river clay, but i can't because they're from two different mods.
