Mod standardization: basic items and blocks

[DcNdrew]

In Minecraft there are lots of mods (and in Minetest is going to have). Everyone has its own ores, ingots, so many pipes, wires and so.
Minetest should avoid it. I know, everybody wants to have their own ways and so. But there should be some mods what contain basic stuff, and their crafting recipes can be disabled.

Here is an example: resistor, capacitor, PCB etc. Many mods can add them, and they won't be compatible.
There should be a mod what contains electronic parts like those, and you can use them. They are just crafting items, but can have other datas on them, like "program name" on PCB-s.

Same with ores. There should be "realistic", "magic", "basic" ores etc.

For modders there should be a nice document about these items.

[cx384]

This is a nice idea but I think in some situations it is better when everyone adds his own stuff because the same crafting recipes can get boring over the time. Moreover ores can generate in different ways in different mods. Nevertheless it is good when mods woke together. Or maybe crate alias

[SegFault22]

It is never good when several mods have their own type of copper and tin, among other things (unless you just like being able to get huge amounts of the same material because the ore definitions add up, and the forge ore dictionary allows you to use one mod's ingots as those of another). A simple mod adding basic resources should be depended on by all mods using such resources, so that different mods which need copper don't have to add their own copper ore.

You could say that mods needing copper and tin should just depend on Moreores - however, Moreores cannot do this best, because its material definitions are static - you have to change lots of stuff to add more items, nodes and tools made of some other metal; so if a mod depends on Moreores, and it needs a different metal such as lead or manganese, it still has to register all of the "stuff" for that material.

I am working on a certain special mod, which makes it very easy to add new items, nodes and tools based on some material, and it seamlessly keeps track of materials' properties such as groups and strength/density, so if you want to change an entire set of tools of the same material and make them last longer or shorter, you only have to change the strength property of the material definition which they reference (this is similar to the concept of "parametric modeling" from CAD programs - where you can change the size of a feature, and all features based on that feature change to reflect the new size of the feature they are based on).

Other mods can use functions from that mod to register stuff easily, but there are a few minor problems.
First, if a mod creates the same material, like "copper" for example, as is also created by some other mod, we have to skip all attempts from the second mod to create the definition and items/nodes/tools/recipes, because the they are all registered when the function is called to create them - allowing the second mod to create another copper ingot, for example, would override the properties of copper and register a new item, which is what we want to avoid. We could raise an issue over at Github to get the devs to create a mod loading "stages" system, so that my mod and ones like it would be able to postpone registering anything until all other mods have finished defining materials and associated items/nodes/tools/recipes (register the actual objects in a "post-init" stage, and require all dependent mods to do their work defining materials and objects beforehand, in the "init" stage). Sure, we could just move the registering code to the end of my mod, where it would only called once everything has been defined in the data tables - but then other mods would not be able to register items using my functions, yet their definitions would still be added to the data tables, which would be horrible.
Second, I am not sure if when another mod registers items/nodes/tools using the functions from my mod, the engine will be "smart" and find the properly-named textures in the other mod's textures folder - all items/nodes/tools are registered in the name of my mod, but it isn't clear which textures folder will be used, since the other mod would be in its loading phase (engine is working in its folder) and my mod would be finished loading, yet the registry call(s) are done from my mod's "side".

If it is not possible to get the other mod to use textures from its folder when registering items via my mod, there are two options - all textures have to go in my mod's folder (not really a fix, problem is still there you're just working around it), or I will have to raise an issue over at Github and persuade the core devs to make the texture loading respect which mod is currently being loaded. This may already be the case, and if so, then there wouldn't be a problem with textures, but I doubt this is what happens, even though I have not tested it.

I am currently re-writing the mod, and it is nearly finished, so I will release it onto the forums soon. Even though it is technically not yet released, so someone could go "steal" the mod-id and maybe some features before I have the chance to post it (just to be a nuissance, of course), I have created a Github repository for the mod (over here), so it technically already exists or was released in some form. However, it has not been updated in a long time, so the upcoming release will not look anything like the version that is there, so please don't use it for anything. The newer version will be much better in just about every aspect, because almost everything has changed except for trivial stuff like using dofile() to load different parts of the mod.

I hope that this is what you are looking for; and when it is released, I hope that other modders can use it to keep up with all of their materials, and avoid creating the problem where there are duplicate sets of items/nodes/tools which has the same material name but different properties (and as such, would not be interchangeable). I will make sure to include an api.txt defining all of the functions and their purpose, so that anyone can get to using it quickly and without problems.

[Wuzzy]

This is actually a double-edged sword:
One the one hand, the idea good because it reduces redundancy. Adding (essentially) the same material over and over again in different mods is not good. We don't need 10 “flesh” items.

I know of one mod which follows the idea of your thread: SAFR's Simple Machines
viewtopic.php?t=9464

I wonder if anyone has used this mod so far. I strongly encourage anyone who finds a mod which is intended to be “generic” like SAFR's Simple Machine to add the mod to this page: http://dev.minetest.net/Mod_interoperability
Because mods like this can be useful to improve mod interopability.

On the other hand, mod standardization might lead to the same old story throughout several subgames. Mod standardization is not always a desirable goal. If someone wants to create an innovative subgame, it is often better to break with existing “standards”.
Also, sometimes mods don't add exactly the same thing, but slightly different. Or in a different gameplay context with different rules. For example, we have different mods which add currencies. However, I don't see this as redundant as many mods use different gameplay rules. So their co-existance is justified. You just probably don't want to have them enabled all at once.
We have to accept that there will always be mods which will always be compatible no matter what. Aiming for total compability is not going to work, already because of conceptual reasons. If two gameplay concepts don't act well together, then no hacking or standardization will help.

There is a conflict between More Blocks and xdecor. Many nodes in xdecor are basically just direct adaptions from More Blocks. But xdecor is explicitly stated to be an alternative to More Blocks, it is not suggested that you should use both mods together. This is also a valid approach, I think. But in this case, the intent must be stated clearly. I think this also applies to forks in general.

If you create a subgame, things become easy again: First, you just put the mods together which you want to be in the subgame. Now if there is any duplicates, modify the mods for your own subgame's sake and remove the duplicates and adjust the crafting recipes. So that in the end, you have a clean playable subgame.

While I think that mod authors should be careful in not re-inventing the wheel over and over again, we should also not be overly too strict about it.

[SegFault22]

Mods can still create different uses for materials and associated mechanisms, without having to register the same material as is in some other mod. If we go ahead and create a system that takes care of keeping track of materials, we won't end up in the situation where several Minecraft mods are, each creating their own variety of copper, tin, lead, silver, and so on, while using those duplicate materials for different purposes than the uses present in other mods.

The goal is to prevent "our mods" (minetest mods) from suffering that way, by only creating the items for a material if they haven't already been created before. For example, one mod might add copper (don't kid yourself, copper in minetest_game was always a joke-level feature because they didn't want to add tin, yet the copper has as many uses as the tin would) and use it for wires to conduct electricity, whereas another mod might add the same ore, lump, block and ingot, yet also add copper tools (they wouldn't last long at all, because copper is weak, even in its work-hardened form) - if the mods followed some special standard, they would be able to omit loading duplicate ores, lumps, blocks and ingots. It wouldn't take long to realize that a lot of the same or similar code would have to be included in all mods adding materials that may be added by other mods, just to check whether items exist before registering them.

That is why I am creating the mod I mentioned before - it takes care of the problem, by checking whether (properly registered) items/nodes/tools/recipes have already been created for a material, so that the mods using the system can use the standard without having to do "all of that".

Materials are a universal concept, because many mods will use several of them, and there isn't really any alternative to using materials, outside of making a totally different mod, such as a mod for farming crops or mobs, which wouldn't use materials for anything "in the first place". If a mod is going to be adding any of the standard items (lump, ingot, nugget), standard nodes (ore, block), and standard tools (pickaxe, axe, shovel, sword, hoe), it would benefit from using a standard that prevents the same items being added by more than one mod. This makes it easier to build a modpack or subgame, because you don't have to remove all of the unwanted registry calls manually.

Even though my mod would be good for this, there are some uses it does not cover - such as doors, fences, storage (chests), fluids, and anything else you can think of that isn't just a simple item or node or tool. I can add functionality for these, so that we can also prevent mods from adding duplicate doors, fences, chests, fluids and so on - but each one is considerably more complex than simpler items, nodes and tools. I would rather finish the mod with most of the widely-used features, then add "other stuff" later, if I see that enough people want to use the mod due to its features. Once I have released it, I won't change the API in ways that will break older versions, unless the internal workings of the game "engine" itself are changed so extremely that most mods won't work at all without being fixed to work with the new system (changing it then would likely not be avoidable, but since it wraps stuff like registering items/nodes/tools/recipes, a lot of the API would look the same or be just like it was before - just the internals would be different in most cases).

Once I have released my mod, I will start working on an "alternative" power system mod - not designed to replace Technic, but it will have some machines that do similar functions, amongst lots of stuff Technic doesn't have, and a radically different power transfer mechanism (IndustrialCraft vs Thermal Expansion, for example) while using some of the same materials. If Technic isn't updated to take advantage of my other mod's features, it would not be too difficult for a modpack/subgame creator to do that, because all that has to be done is replace all the minetest.register_*() calls with a much shorter and neater function call (plus a few more, to add stuff like "material" definitions, "item types", "material types" and such, but it would still end up being much smaller than all of the stuff in those minetest.register_*() function calls)

Because it can help to "see" this by looking at an analogy with CAD "part modeling" programs, this is what a standard for materials would look like:

Basically, it's the Minetest analogue of the "Union/Join" function - instead of having two parts with some volume, each occupying a part of the volume of the other while still being two different parts in that "common volume", we now have a single part joined by the "common volume" - they become one. Minecraft never had anything like this, and probably never will - the Forge people created the "ore dictionary" system after the problem got too big, but it is just a "bandaid fix" which allows you to use the materials from one mod with another that calls it the same thing while using it for other stuff, but doesn't fix the problem that resulted in the duplicate objects "in the first place".

More than one mod trying to add the same materials, should not prevent said mods from creating uses that are substantially different from the uses created by the other mods which add those same materials. We can make a standardized system, and allow mods to create lots of their own unique features that fill different niches, without having to compromise either. It is okay for two different mods, both adding machines but using a different power system, to create their own variations of the "machine block" and components that fill them, because it is likely that the recipes and appearance will be different just as the uses would.