Datapack standards help keep different datapacks from interfering with one another, and also can help improve performance. The Brickmasons team has adopted these standards so that our maps run efficiently, and our datapacks are both efficient and compatible. If you wish to make datapacks compatible with the Brickmason's datapacks, please follow these standards.

Standards

These are the rules that must be followed. Some ideas are imported from The Datapack Center

Namespace Usage

Namespaces are used to help keep functions, tags, and scoreboards from interfering with each other.

Examples include:

Using: /tag @s add bm.<tag> instead of /tag @s add <tag> (bm is the official Brickmasons namespace)

Using: /scoreboard objectives add bm.<scoreboard> dummy instead of /scoreboard objectives add <scoreboard> dummy

Global Tags

Certain tags are used for specific entities/functions that are very important and shouldn't be manipulated.

List:

global.ignore - this entity should not be selected in any way, a good use of this would be /kill @e[tag=!global.ignore] which doesn't kill entities with the global.ignore tag.

global.ignore.pos - this entity should not have it's position changed by teleporting or data modification.

Installed Datapack View

This is a global standard that allows your datapacks to be viewed in the advancement screen. See the link above for more info. This convention usually doesn't apply to maps, but rather it mostly applies to stand-alone datapacks.

All Brickmasons maps are to be released under the author "Brickmasons" with the icon of a brick (item).

Guidelines

These are not rules, but are recommendations to follow so that the datapack will run efficiently and improve performance.

Restrict Selectors

Using as few @e selectors as possible is always a very good idea. Also, when using them, it is a good idea to be as specific as possible in the entity selector. For example @e[type=pig,tag=bm.seat] is more efficient than @e[tag=bm.seat] and is less likely to cause issues with other datapacks.

Only One Ticking Function and Only One Load Function

In the #minecraft:tick json file, it is best to only have 1 function listed, and then have that function run all other necessary functions. The same is true for the load json file. This gives more control over how functions are ticked and how they are loaded, which can help with troubleshooting later. This would be one per datapack of course.

Lowercase Naming

Unless it makes otherwise, name files, tags, and scoreboards all lowercase. Many of the files in a datapack must be lowercase anyways, so to simplify the creation of datapacks, using an all lowercase or snake_case format works well.