Translation notice

This page was translated with machine translation and may contain inaccuracies. If you can help improve it, please open an issue or submit a pull request.

How to merge data packs of multiple versions?

Dreamy_Blaze

Strong coupling of data pack

As we all know, Minecraft's data pack (Datapack) and game version are strongly coupled (data pack loaded into a non-specified version of Minecraft will most likely be discarded). Before the official version of 1.20.2 was updated, data pack authors usually implemented version loading in this way:

• If the syntax changes between the two versions are large: copy the data pack multiple times, make modifications according to the version format differences (json or mcfunction), and publish them separately. It is direct and efficient. It is inconvenient to copy and modify multiple files multiple times.
• If the syntax changes between the two versions are minor: both are loaded into the same data pack, based on command syntax differences or [data versionDataVersion](https://zh.minecraft.wiki/w/数据版本"[Chinese wiki] Data version") to load different functions, etc. (data pack syntax check is based on files, and erroneous files will be ignored). The advantage is that there are more compatible versions. However, when /reload is reloaded or restarted in a multi-person server, the server background will report errors one by one for files that are not of that version.

After Minecraft is officially updated to version 1.20.2, data pack authors can now use the officially provided setting of "loading different sub-data packs with different versions". This setting can be implemented by editing the data pack metadata file pack.mcmeta. This simple and effective method is not well known today (the Wiki only talks about the syntax but no examples (especially the folder structure), making it difficult to understand the specific operation of the sub-package function).

Override subpackages based on version

Here is an example format of a data packpack.mcmeta file:

{
    "pack": {
        "pack_format": 61,
        "description": "子包测试"
    },
    "overlays": {
        "entries": [
            {
                "directory": "1_21",
                "formats": 48
            },
            {
                "directory": "1_20",
                "formats": {
                    "min_inclusive": 15,
                    "max_inclusive": 26
                }
            }
        ]
    }
}

explain:

The data pack version is 61, corresponding to 1.21.4. If the data pack is installed in the archive of 1.21-1.21.1 (data pack version 48), the 1_21subpackage will be enabled. If it is installed in the archive of 1.20.2-1.20.4 (data pack version 48), the1_21subpackage will be enabled. In the archive of packversion18-26), the subpackage of1_20will be enabled (the corresponding MCversion of 15 is 1.20, but the subpackageoverlays is supported starting from 1.20.2, so the minimum version must be 1.20.2. If it is lower than 18, it will not cause the data pack to fail to load, and it can only load the main package content like the old version);

pack_format: 61means that the main version is 1.21.4. In addition to thepacktag, define anoverlaystag, which only includes anentrieslist. Each composite tag in the list is a sub-package to be overwritten by the corresponding version on the original data pack. Each composite tag must include the two tagsdirectory(subpackage directory) andformats (the version&version interval to be covered).

Then the file directory structure of data pack should be like this:

In the picture, the datafolder at the same level aspack.mcmetais the content of the main package. There aredatafolders in the1_20and1_21 folders, which are two sub-package parts; If the sub-package has files with the same path as the main package (for example, there are three hello.mcfunctionin the samezbnamespace as shown above), when loading the corresponding version of the sub-package, the file of the main package will be overwritten (that is, only the sub-package function will be executed, and the main package function will be ignored. After all, they are calledoverlays, and the priority must be greater than the main package) Note: Starting from 1.21, most folders in the data pack are named in the original singular form (functions->function);

• In 1.21.4, the hello.mcfunctionandhello2.mcfunction files in the function folder in the main package data/zb will be loaded, and the sub-packages will not be loaded;
• In 1.21, the hello2.mcfunctionof the function folder in the main package data/zb and thehello.mcfunctionand121.mcfunctionfiles in the sub-package1_21/data/zb will be loaded. The hellofunction of the main package is overwritten by thehello in the sub-package;
• In 1.20.2, the qwq.mcfunctionfile in the functions folder in the main package data/zb and thehello.mcfunctionfile in the sub-package1_20/data/zb will be loaded (the folders before 1.21 were all in plural form).

Well, that is to say, if there is a jsonormcfunction file with the same path as the main package in the activated sub-package, it will be overwritten in file units. (Subpackage first)

When creating a 1.20.2+ data pack, it is a good choice to use the method of loading sub-packages with different versions. Of course, in works spanning 1.21, it is quite awkward for the same data pack to maintain function and functions folders at the same time. Sub-packages can also be divided into two packages based on 1.21, for example: 1.20.2-1.20.4 is the version before the item stack component is updated, and 1.20.5-1.20.6 is the version after the item stack component is updated. The same data pack is used between these versions, and different sub-package strategies are loaded according to different versions (the folders are all plural); After 1.21, every official syntax update for Minecraft can be overwritten in a sub-package, so there is no need to copy multiple data pack modifications (the folders are all odd-numbered).