Ideology: should modules be more unified or fragmented.

chessandgo

Member
Contributor
Hunter
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.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Moved to Dev Portal - is plenty on topic for Terasology development

I'm happy to say we're fairly well on top of this :)

Rather than even need to have all biomes in a single module we encourage using more small modules based off a central content-less framework. See for instance the GrowingFlora module, which is a framework for trees and such, that that PlantPack module then builds on and creates a bunch of trees for. Anybody else can come around and depend on GrowingFlora, add some different trees, and there are no compatibilities issues yet a shared base.

Note that this isn't fully fleshed out yet - a lot of modules are still very random. One big goal is to provide a base set of modules (the Iota distro, as per current plans I've thrown together) that contains everything basic you could wish for, yet can override individual pieces from easily. When full support for that is in we'll go over the existing modules and categorize them better. Then we'll address any holes and extend support for users playing along with the base set and adding new stuff, offering to build and even test their modules whenever anything in the engine or Iota changes.

We might not always be able to suggest outright fixes but at the very least we can get much better visibility in what is likely to break when, and what exact changes caused it :)

More on that later - just keep an eye out!
 

Nym Traveel

Active Member
Contributor
Art
World
"I should be able to use my earth oven with my river clay, but i can't because they're from two different mods."

Concerning ores, Minecrafts Forge has an interesting approach: The ore dictionary.
Basically, when different mods add their own kind of copper, the ore dictionary handles it, so you can use the ores equivalently.

Some system like this would prevent the problem you described to some extend.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Hi @Nym Traveel ! Nice to see you around, how have you been? Check out the fancy new world gen stuff, if you haven't already :D

Yup, would like to do something like a registry like that, probably in a base module provider you can easy consult somehow. Not to mention just providing every mineral/ore we can think of and allowing modders to tweak them from their modules using stuff like delta prefabs or overrides.
 
Top