- Conventions and Terminology
- Development Tools
So you have a DataFixer, how do you tell it what to fix, what version the game the data is from and your target version to fix to? This is where Schemas come in.
Each Schema contains a version, the TypeReferences, Entities and BlockEntities that can be fixed. Then Schemas have their own DataFixes to apply. Schemas can also inherit data from parent schemas (of lower versions). Your DataFixer will contain atleast one Schema (to define type references and elements of the first version of the mod).
TypeReferences can be a bit… confusing. Because of the way DFU has been made, Mojang makes it so you fix a type instead of dangerously modifying a CompoundTag and having to read the compound tag to figure out what type you are even fixing, which could contain about anything.
These types are defined within a Schema and represent Objects that are Serialized in the game such as Entities, BlockStates, Items, BlockEntities, Chunks, World Data, Creative Mode Toolbars, etc and refers to a Type to be fixed.
DataFixers start as a DataFixerBuilder, this is where you define your Schema versions to be stored on your DataFixer.
A Schema represents a data version of your mod's data. It contains all types within your mod at the version and defines the fixes that need to be applied in order to make the data compatible with the version.
DataFixerBuilder builder = new DataFixerBuilder(dataVersion);
When you create your DataFixerBuilder, your first parameter will be the current data version of your mod.
First you will define a Schema. This will be your base version schema which all schemas are a child of. Obviously you could register a blank schema or MC's Identifier Schema (Which only contains logic to turn namespaced strings to Identifiers) but an issue will arise, any fixes you register will fail because none type references exist to the schema. So your first Schema must define the TypeReferences you wish to fix.
So your mod's DataFixer will look like this towards the start of it's creation.
DataFixerBuilder builder = new DataFixerBuilder(dataVersion); Schema schemaV0 = builder.addSchema(0, FabricSchemas.FABRIC_SCHEMA); // It is reccomended to make the Fabric Schema version 0.
Once you have the schema created, you can register data fixes onto the Schema. You can register more schema versions easily. For example say you have version
Schema schema102 = builder.addSchema(102, Schema::new);
When you add a schema, it will automatically be registered into the DataFixerBuilder.
For the DataFixerBuilder above would to fix any data you need to build the DataFixer.
To create your DataFixer you need to build it by providing an Executor for the data to be fixed on. Normally the executor Minecraft uses for this would be the Server Worker which is accessible through
The DataFixer has been built, it won't actually fix anything unless you invoke it in the vanilla code to fix your blocks and stuff. But the DataFixer API has handles all the injections for where vanilla fixes it's own data. To utilize these injection points, you have to register your DataFixer through the API.
This is done through the
registerFixer takes three parameters. The first String is the key you will use to get the DataFixer. The same key is also used to write the data version info of your mod to the world. You can cache the DataFixer also since it is Immutable. The
newestDataVersion tells the DataFixerHelper what the newest data version of your mod is, this is used for saving the data version of the world and telling the DataFixer what version it needs to upgrade to.
DataFixerHelper.INSTANCE.registerFixer("modid", newestDataVersion, dataFixer); // This registers your DataFixer so it will fix data after the Vanilla DataFixer finishes.