Static Data

# What does it do? Creates a third class of resource, "static data", which lets mods search each other and their environment in an easy, structured way for compatibility and interop information. For instance, a mod might register a slope-shaped block based on a set of vanilla blocks, but also offer to register new slopes based on modded blocks. Tags aren't available early enough for this! Static data is. Responsibility for mod interop data isn't locked into one particular place. Static data relating to mod B, queried by mod A, can be supplied by mod A, mod B, a third mod, or even a static datapack. Data from all these sources can be mixed and used additively. # Why do we need static data? ## Static data is static Datapack and Resource-pack reloads do not affect static data and static datapacks. The same data is available, and its source mod (if any) identifiable, through the entire lifecycle of your mod. You'll never have to call any entrypoints for this data, you don't have to care what loader the mod is from, the data is just already there. You'll never have to worry if connecting to a server has changed the data, static data doesn't change so you can initialize once with confidence. ## Static data is available early As soon as the first entrypoint runs anywhere in the loader - whether that entrypoint is quilt-loader, qsl, qfapi, or a mod integration entrypoint, if your mod has been asked to initialize something, static data is already ready. ## You can use it to trigger registrations Since ordinary datapacks change over time, it's a can of worms to use them to change frozen registries. Since static data does not change, and is available before registries are frozen, you can register blocks and entities using information you get from static data. This is the primary reason for its existence - to allow mods to communicate feature information to each other in a way that vanishes if the other mod is gone, but doesn't rely on the mods having the same modloader. # How can I provide staticdata? ## Mods provde staticdata like other kinds of data Static data is placed in a `staticdata` directory alongside the `assets` and `data` directories, and items are namespaced within the staticdata folder. So if the mod "architecture_extensions" is looking for files in the "blockgroups" path, and you provide an integration called "obsidian.json", the full path of this file would be ``` src/main/resources/staticdata/architecture_extensions/blockgroups/obsidian.json ``` Note that you do not use your own namespace at all - your modId is already provided by placing the data inside your mod. ## Players and Pack-Makers can provide static datapacks A zip file whose root folder is named "staticdata" is a valid static datapack. This works exactly like a resource pack except for static data. To provde the same file as the previous section, the file's path inside the zip would look like: ``` /staticdata/architecture_extensions/blockgroups/obsidian.json ``` Having a pack.mcmeta and pack.png inside the root directory is optional, and these files are currently ignored. Static datapack zips can be loaded from two places: - from within mods, in the root `src/main/resources/staticdata/` folder - from the root `.minecraft/staticdata/` folder, which will be created if not present when any mod requests static data Static datapacks placed within subdirectories will not be accessible. ## Raw files can be placed in the staticdata folder These files still need to be namespaced, but again using the above example: ``` .minecraft/staticdata/architecture_extensions/blockgroups/obsidian.json ``` As long as the files are placed in the correct namespaced folder, they will contribute to data searches. # How can I use static data in my mod? First, depend on staticdata. This requires a gradle `modImplementation` entry and a quilt.mod.json `depends` entry. See the source repository for current version and maven/gradle details. Second, it is recommended to add an `include` to your gradle so that the library ships inside your jar. For some reason this doesn't seem to imply `modImplementation` so you'll probably need both lines. Third, during your modInitializer, you can do something like ```java // You could use quilt-json5 or jankson here instead Gson gson = new GsonBuilder().create(); // Get all the static data in this folder and subfolders List<StaticDataItem> dataItems = StaticData.getDataInDirectory( new Identifier(MODID, "bees"), //Search for mymod:bees true // Yes, do a recursive search through subfolders ); for(StaticDataItem dataItem : dataItems) { // MyDataObject here is the class that represents the data you want MyDataObject dataObject = gson.fromJson(item.getAsString(), MyDataObject.class); // This is just a suggestion - staticData is most useful if you // load the data conditionally! String requiredMod = dataObject.only_if_present; if (requiredMod != null && !requiredMod.isBlank()) { // Should