-
Notifications
You must be signed in to change notification settings - Fork 1
API Documentation
From an API standpoint, there's not much that the mod itself provides. However, this document describes what is there.
As a refresher, custom tests are used when a test patch provides the type field, and may be used to evaluate arbitrary tests. For example, a mod could expose its boolean configuration options by registering a test condition, allowing them to be queryable by patches. Alternatively, a mod could take advantage of the fact conditions get the target element (when specified) and provide comparison operators.
Patched provides Patched.registerTestCondition(ResourceLocation, TestCondition) and Patched.registerSimpleTestCondition(ResourceLocation, TestCondition.Simple), which can both be used to register custom test conditions. The former gives you all the context available (minus the type — you don't need that), while the latter only gives you the value argument. The latter is generally what most people will want, but the former still exists should you need it.
Patched provides a handful of custom tests out-of-the-box which can serve as examples for how to write them. See PatchedTestEvaluator.registerDefaults() method for details. (Please note that this class is internal and therefore not considered API.)
For those on older versions of Patched, you register test conditions using the PatchedTestConditions class.
On (Neo)Forge one can alternatively use IMC to register test conditions.
Simply send a message with registerTestCondition as the method and a Pair<ResourceLocation, Predicate<JsonElement>> as the parameter. (That's a commons Pair by the way.)
This refers to data sources of the paste patch type.
This patch type can be used to (among other things) get configuration values into json files.
For example, a mod could use it to make a structure's rarity configurable without needing someone to make a custom data pack to change it (something that, unfortunately, many people struggle with).
However, this is not all that data sources can do — on the extreme side, a mod could create a whole custom patch type using them.
For example, suppose you want to add an arbitrary number to an existing json-defined one.
With a data source, this becomes trivial, since the data source can simply add both numbers together.
This means mods could add arithmetic operators, or a way to add multiple values to an array, or do something else entirely!
To register a data source, use Patched.registerDataSource(ResourceLocation, SingleDataSource).
Like with test conditions, on (Neo)Forge one can also use IMC to register data sources.
To do this, send a message with registerDataSource as the method and a Pair<ResourceLocation, BinaryOperator<JsonElement>> as the parameter. (Again, that's a commons Pair.)
Patched provides a patch DataProvider called PatchProvider which can be used to generate patch files.
To use it, simply override registerPatches() and call patch(ResourceLocation) to begin a patch file definition.
For the ResourceLocation argument, there are two id() helper methods that can make these less tedious to write.
Once you have a patch builder, you can call any of the methods named after an operation to add a patch of that operation. They are structured similar to patch files, so make sure to use compound patches when necessary!
When you've finished adding patches to a compound patch, you can call end() to terminate it. Terminating a "root patch" (the builder returned by patch()) does nothing, so you do not need to terminate those.