Mod interoperability

This page is aimed towards modders and lists a couple of mods and conventions which are known in the community.

The main goal is to improve interopability between mods and reduce code duplication. Often it is better to use existing APIs rather than trying to reinvent the wheel to reduce code duplication, redundancy and overall chaos. Of course, deciding to not use existing APIs may still be aviable choice if they do not suit your needs.

This page will be a permanent work of progress since there are many different mods out there.

Mods

One way to ensure interopability is to know what other mods exist out there. This section will show you mods which you can use to achieve a particular task or point you to mods which might need some “special treatment” for maximum interopability.

Basics

This section is about mods and practices which apply to almost every mod.

Internationalization

Minetest itself can be translated (mostly the main menu), but Minetest does not support direct translation for mods. This feature has been requested in issue 2270. In the meanwhile, a few mods have emerged to enable internationalization. Note, however, that mod-based internationalization is rather limited. A major problem with the existing mods is that all clients connected to a server will always see the language used by the server, rather than the language used by the client.

These mods are known to enable internationalizaion (only use one mod at once):

• Internationalization Library [intllib]

TODO: Add more mods, there are more mods for this.

Gameplay

Status effects

If you want to add temporary or permanent status effects for players (such as poisoning), you can use this:

• Player Effects [playereffects]
• Player Monoids [player_monoids]

Mobs

Mobs are non-player creatures to interact with the world, they may be peaceful or attack on sight. Usually they are based on entities. Minetest does not support mods natively, but if you still want to add custom mods, you have various mods to choose from, each of them with somewhat different priorities. Most APIs are not compatible which each other, so in general you should only use the API which suits your needs in the best way. If you want to create a subgame, you have to be very careful with interopability.

Note: Only mods with their own dedicated API are listed. Note: There are multiple mods with the short name “mobs”, you can only have one of these mods installed at once.

• Mobs Redo [mobs]

TODO: Add more API mods here

See also: Mobs page on the Community Wiki

Interface

Showing status information

If you create a new player attribute/stat (like health) and you want to expose it to the interface somehow, you can use:

• HUD Bars [hudbars]: Provides an API to add your own indicators like the “hearts” for health. Displayed in either a “progress bar”-like fashion or the classic statbars like in vanilla Minetest

TODO: Add more mods.

Decorational

Colors

If your mod provides blocks in multiple colors, there are various mods and conventions to consider for ensuring the best interopability.

It is strongly recommended you only use colors which follow an agreed-upon set of predefined colors. A basic set of 15 colors is defined in the “dye” mod in Minetest Game. Read the source code to learn more. Other mods provide an extended set of dyes. The mod Unified Dyes [unifieddyes] extends the set of colors to 90 colors.

Other specific mods for consideration:

• Colorization by crafting: Consider if you want to add crafting recipes by adding a dye and your item (like wool in Minetest Game, read it source code to learn how it works)
• Color Machine [colormachine]: Coloring support will be provided by the mod itself, as long as the authors update the mod. Your task would to to make sure that the names of the textures and nodes follow naming conventions
• Paint Roller [paint_roller]: Use the API of this mod to enable the paint roller to colorize your blocks

Groups

Another way for interopability is by using groups. If used properly, they can greatly increase ease-of-use when other modders want to work with our mod. The rule of thumb here is that you generally use groups which are already widely used if you can. Only if your needed group does not exist, you should define your own group.

On this wiki, the Groups/Custom groups page tries to document the usage of groups and lists some commonly used groups. If your mod defines its own groups and they are *not* just to be used internally, please edit the Groups page to help other modders.