Data Generation #419
Open
Data Generation #419
Conversation
This file contains 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
- Added datagen for blockstates and block models - Added DataGenDeferredRegister, IEBlockProviders, IEDataGenerators - Most blocks now have data generation expect glowdust layers, torches, lanterns, campfires, fires, foliage and glass - Removed "_anim" and "_animated" suffixes from texture files as they were redundant, they weren't consistent and would've complicated the addition of datagen - For all pillar blocks "_side" was added to the name of the texture files for the side of the block. This is to maintain consistency with vanilla practices (Although even those are a little inconsistent) and to make the addition of datagen easier - Generated data files have been moved to the main resources folder. All blocks with datagen added have been tested and are working as intended
- Added documentation to IEBlockProviders on how the different data providers work
…s, fires and potted plants - Renamed glowlight_glass textures to glow_glass for consistency with item id
… and buried bones - That's all the blockstates and block models done. On to item models
- All items except weapons now have datagen for their item models
- Moved block providers that are only used for a specific block, like luminous fungus, to IEBlockProviders to reduce clutter in IEBlocks
- That's all item models done! Onto tags next?
- Split IETags into IEBlockTags, IEItemTags, IEBiomeTags, IEStructureTags. This was mainly done out of necessity because any reasonable name for the subclasses of IETags would conflict with Blocks, IEBlocks, BlockTags - Added DataProviderCollection to provide a way to have a collection of ProviderConsumers without needing to have a DeferredRegister
- Renamed IETagsProviders to IETagProviders - IETagProviders no longer inherits TagsProvider. The only reason it was inheriting this previously was to open up access to TagsProvider#tag. This is now down with an access transformer
- Shaped crafting, shapeless crafting, smelting, blasting, smoking, campfire cooking and smithing recipes now all have datagen - Moved some of our own tags that were under the minecraft namespace (for some reason?) to our own namespace and added them to IEItemTags - Refactored CompatibilityQuark to QuarkFlagCondition - Moved the registering of the QuarkFlagCondition serializer from InfernalExpansion to registry event in MiscEvents
- Stonecutting recipes now have datagen - Fixed small issues in recipe builders - Added missing entries to IERecipeProvider
- Create crushing and pressing, Farmers Delight cooking and Mining Master forging recipes now have datagen
- Replaced old recipe files with their new data generated equivalents - The recipe advancement and recipe book system should now actually work as intended with IE - Fixed MiningMasterForgingRecipeBuilder. Replaced "level" with "lvl"
- All overridden tags now have data gen ("mineable/pickaxe" was a real pain lol)
- Moved some of our own tags that were from some reason under the "minecraft" namespace to our own namespace
- Added LanguageProvider's for every language we currently support (except lv_lv as every translation was the same as en_us) - Added convert_lang.py which takes a lang JSON file and outputs the required Java code to then in turn generate the lang JSON file. While it's not perfect it significantly cuts down on the amount of time required to create a LanguageProvider from a lang file - Every LanguageProvider has entries for all translations, even ones that are missing from that specific language. IELanguageProvider enforces this by throwing an error if this requirement is not met. This gives us a great view of what languages are missing what translations.
- Data generator will no longer add untranslated entries to the JSON lang files. When MC builds the lang maps it automatically retrieves missing entries from en_us. This reduces the file size of lang JSON files - Data generator still checks to see if a LanguageProvider has add methods for all entries. Again, this is done to keep a comprehensive list of all lang entries in every LanguageProvider
- All blocks now have datagen for their loot tables - Their loot tables are configured in IEBlocks like their blockstates and block models are - Removed DataGenDeferredRegister's dependency on DataProviderCollection. DataProviderCollection will be completely removed once I remove IETagProviders dependency on it
- Replaced all instances of DataProviderCollection with an ArrayList
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
DataGenDeferredRegister,IEBlockProviders,IEDataGeneratorsThe methodology behind this datagen system is to bake it into the deferred registers. This allows us to keep all the code to do with defining blocks, for example, in the same place:
IEBlocks. Instead of having two separate places, one where the blocks are defined and one where the data generation is defined. This is done by creating a wrapper aroundDeferredRegistercalledDataGenDeferredRegister.Block models working with generated data files
I plan to finish adding data providers for all blocks then move onto datagen for items. Recipes and loot tables will come after.