-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fabric Data Fixer API (v1) #3649
base: 1.21
Are you sure you want to change the base?
Conversation
This allows mods to register more than one datafixer by specifying a key Ex: When mod "fabric-api" registers a data fixer with key "yes", it saves the data version as "fabric-api_yes" This commit also uses a universal method to fix tags, so nothing is left out. However, passing through `WORLD_GEN_SETTINGS` does cause some issues with some mods in very specific cases.
Provides events to register block entities and entities
Also update the lookup testmod to register the inspectable pig entity type to the schema
The events never have a reasonable time to register to, so entrypoints are probably the better option. The entrypoint is now called in `FabricDataFixesInternalsImpl` only. They do not register in the no-op internals.
Registration now uses `Identifier`s instead of strings. Will be used to add choices to the vanilla datafixer.
# Conflicts: # gradle.properties
Also remove schema registration from other testmods
This is not currently tested and may be reverted
# Conflicts: # gradle.properties
The only major concern I have left is that since the schemas are in a single parent line, any mod could cancel the registration of block entities and entities within the schemas by not calling |
Also, I’m wondering what the best way to get modders to register their block entities and entities to the schema would be. Perhaps an integration into the Fabric docs website wherever it talks about block entities and entities and an announcement somewhere. |
Question. This is already included in this PR (though likely controversial since it logs an error), but I’m wondering what any of your thoughts are on this. |
# Conflicts: # gradle.properties
This will hopefully reduce concerns about requiring modders to use the Data Fixer API. If a modder does not want to see warnings in the log, they can simply remove the given identifier.
This reverts commit a8f9f5a.
...api-v1/src/testmod/java/net/fabricmc/fabric/test/datafixer/v1/mixin/RegistryLoaderMixin.java
Outdated
Show resolved
Hide resolved
...api-v1/src/testmod/java/net/fabricmc/fabric/test/datafixer/v1/mixin/RegistryLoaderMixin.java
Outdated
Show resolved
Hide resolved
# Conflicts: # fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/block/entity/FabricBlockEntityTypeBuilder.java # fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/entity/FabricEntityTypeBuilder.java # gradle.properties
# Conflicts: # gradle.properties
I believe this still has the exact same schema/fixer ordering transitiveness issues it did way back last time I took a poke at it on discord? (Namely, issues with mutual transitiveness between different mods as fixers to fix transitive entries are only applied the one time) At any rate, no changes have been made that would resolve those issues. |
To elaborate: mod A and B add an item and a BE each, which they want to fix. Mod A adds both to a schema and adds a fixer for each afterwards. Mod B does the same. DFU only runs fixers during the specific update step when that fixer exists -- so if mod A's stuff is before mod B's schemas are registered, then a mod A item in a mod B BE will not be properly fixed. A slew of similar cases pop up when you consider that "transitive" fixing is accomplished through the AddChoiceType stuff and can in fact be removed if that format no longer exists -- so transitivity in the same mod, with some other mod in the middle, can also cause issues. |
This is a copy of #3644 with changes to use a single schema tree across mods to remove isolation issues across datafixers.
After testing, I believe this is the key to the schema registration isolation issue because the base schema is now the last schema of the last registered data fixer, except for the first registration of course because the parent will just be the vanilla data fixer.
Possible concerns:
Todo: