Attempt #6 at a Fabric Data Fixer API #3649
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.
| value = "INVOKE", | ||
| target = "Ljava/util/List;forEach(Ljava/util/function/Consumer;)V", | ||
| ordinal = 1, | ||
| shift = At.Shift.BEFORE |
| ordinal = 1, | ||
| shift = At.Shift.BEFORE | ||
| ), | ||
| locals = LocalCapture.CAPTURE_FAILHARD |
There was a problem hiding this comment.
Never use LocalCapture, at all. MixinExtras' @Local is preferable but this should be a @ModifyReceiver anyway and it does not need locals.
apple502j
added
the
priority:low
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: