Implement legacy data fixing via DataFixerUpper#4875
Open
screret wants to merge 23 commits into
Open
Conversation
…ons` to `addGTDataVersion`
…20.b** and certainly no longer required by anything
# Conflicts: # src/main/java/com/gregtechceu/gtceu/common/CommonEventListener.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Add DFU-based data fixers as a replacement to manual legacy data conversion
Implementation Details
The implementation primarily lives in
GTDataFixersand thegtceu.common.datafixerpackage, though some utilities are also ingtceu.api.datafixer.CommonEventListener.remapIdswas removed in favor of handling the same logic with data fixers, as wasTagCompatibilityFixer.fixMachineAutoOutputTag.AI Usage
Outcome
Though initial setup may be more annoying, this PR provides considerably more stable legacy data conversion for the future.
How Was This Tested
loaded a bunch of year+ old worlds and checked the logs if any missing IDs were reported. none were (except the ones I expected to appear).
Additional Information
The GT data version field should be bumped with EVERY save data change, no matter how minor. Same goes for adding fixers. All machines should be registered into new schemas. Do NOT put all of them into
V0.Register new datafixers in
GTDataFixers#addFixers. Remember to bumpGTCEu.GT_DATA_VERSIONin every PR that changes existing save data and add a schema & fixer for it here.For changes that do not change named types or add new (block) entities, use
SAME_NAMESPACEDfor the schema. Register machines (and other block entities) in a schema overridingSchema#registerBlockEntities.Reference vanilla schemas for more information on that, examples named below. Also check how they're used in vanilla's
DataFixersclass.net.minecraft.util.datafix.schemas.V1460,net.minecraft.util.datafix.schemas.V1906Note how only fields that use other registered types (such as item/fluid stacks) are defined. The same should be done for all types.
Potential Compatibility Issues
The auto output trait fix might? be wrong, not sure. I couldn't really test it because I managed to corrupt my freshest testing world before I figured out how to fix the forge registry ID map.