Skip to content

Latest commit

 

History

History
57 lines (49 loc) · 5.08 KB

README.md

File metadata and controls

57 lines (49 loc) · 5.08 KB

Data Pack Checker Rules

This repository contains the source code and releases of rules made by and/or supported by the creator of Data Pack Checker. There is a recommended configuration that all data pack creators should use here.

View the documentation on how to start using the rules.

Blacklist.dll

Core.Blacklist.Commands
Certain commands are not allowed in certain functions.
Some commands are not allowed in some functions. Each command will be tested with a filter.

A filter consists of multiple lists, one for resource location ([#]{namespace}:[path/]{name}) and one for commands. Each list contains regular expressions and the first match determines the verdict based on a + (allow) or - (disallow) prefix.

If the first match in the 'resources' list (matching any referencing function/tag) is prefixed with - AND the first match in the 'commands' list is prefixed with -, the command is disallowed. Each command will produce an error for each of the filters with a double negative match.
Core.Blacklist.Identifiers
Certain identifiers are not allowed in certain functions.
Some identifiers of in-game resources are not allowed in some functions. Each identifier (e.g. an objective name) will be tested with a filter.

A filter consists of multiple lists, one for resource location ([#]{namespace}:[path/]{name}), one for namespaced identifiers and one for plain identifiers. Each list contains regular expressions and the first match determines the verdict based on a + (allow) or - (disallow) prefix.

If the first match in the 'resources' list (matching any referencing function/tag) is prefixed with - AND the first match in the 'namespace'/'plain' list is prefixed with -, the identifier is disallowed.

Each identifier will produce an error for each of the filters with a double negative match.
Core.Blacklist.ResourceLocation
Certain resource locations are blacklisted.
Some resource locations are blacklisted. Each resource file path (starting with 'data/') is matched against a list of regular expressions until one matches. Based on a +/- prefix, the file will be allowed or disallowed. If none of the expressions match, the location is allowed. Use [^/]+ to allow any path element.

Compatibility.dll

Core.Compatibility.NoTagReplace
Tags must not overwrite entries defined in lower priority data packs.
Setting 'replace' to true in a tag can prevent other data packs from working correctly.
Core.Compatibility.VersionId
The version identifier must be correct.
The version identifier 'pack_format' in pack.mcmeta has to match the number set in the configuration.

Style.dll

Core.Style.AsAtComments
A function must start with comments describing the 'as/at' context.
In each function a certain context is assumed, which includes the meaning of @s, @p and ~ ~ ~. Writing down that context at the top of the function might save some time debugging and help out if the function is revisited in the future. Spacing within the lines is not checked.
Core.Style.UninstallFunction
There must be an uninstall function.
Providing an uninstall function will help remove traces and leave a clean world behind before the data pack is removed. An uninstall function must contain commands that remove all created in-game resources. The function file can be located in any directory.

Uniqueness.dll

Core.Uniqueness.Identifier
All in-game resources must have a prefixed identifier.
In-game resources like scoreboard objectives have to be prefixed to prevent clashes. Only 1 prefix per namespace is allowed and should be separated by any of these characters: . _ -
If a namespace is allowed, all resources must be prefixed by the namespace of the function.

Prefixed:

  • scoreboard objectives
  • tags
  • teams

Namespaced:

  • bossbars
  • data storage

Configuration can be used to extend or overwrite the default rules with a custom set of prefixes and namespaces.

Core.Uniqueness.ResourceLocation
All data pack files must be in a subfolder with the same name.
Assuming the namespace is author specific, putting all resources in subfolders will prevent clashes with other data packs of the same author. By default each namespace can have its own subfolder, which can be extended or overridden by a list of names in the configuration.