Master 1.20.1 #197
Open
Master 1.20.1 #197
Conversation
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
Not much done yet and this is more a rewrite thanks to the amount of change in Forge and Minecraft
1) Removal of the entire plugin/annotation system coming - first start is in the code right now 2) Change to doing a flat resource scan for files in an `orespawn4-data` directory under `assets` 3) Add collection of files on disk into the mix there 4) Mostly stubbed out buidlers for various bits 5) Untested but largely complete loaders for things 6) Cleanups and fixes to issues with the `mods.toml`
1) Implement resource scan to look for files under "/assets/orespawn-data" in all loaded resources 2) Implement scan of "config/mmd-orespawn-4" for all files 3) Load data files from both sources 4) (not yet done) Remove annotation based system remnants
1) Abstract out the "assets/orespawn-data" path-string as a constant 2) Remove the remnants of the old annotation based integration system
…t loaded and what configs proper get loaded
1) Implement use of Blocklist/Blacklist created in previous commit 2) Refactoring to split out shared code and make json config loading more streamlined
Final resolution of spawns - which need occur, necessarily, at the end of the block registry event (the start of the item registry event, at a minimum) is the next step. Will need to create a BlockMatcher setup to take over for the Replacements and a generic utility for turning OS4BlockData into a BlockState.
1) Resolve data for blocks, dimensions and such in FMLServerStartingEvent 2) Prep work for porting all features 3) Start to finalize setup for world-gen bits
1) Fill out a stubbed data structure for representing a somewhat data-resolved spawn (this is likely to go away as things get fixed so they expect a late resolve) 2) Move some helper function to Utils.Helpers instead of having them private to a class 3) Implement a "common" Config - nothing for Server or Client in OreSpawn so...
Updates across the board, implement the config system, start of work on cleaning things up and implementing a proper resource loading and resolving system.
Few small fixes and language cleanups here... How to tell IDEA that an inner class that is used a ***LOT*** can't be "static" ?
TODO, in no particular order: 1) implement new world-gen wrapper setup 2) register a world-gen wrapper per spawn 3) implement features from OS3 4) implement feature that wraps vanilla's generation bit 5) add CrT integration stuff
It appears that Mojang has inextricably tied world generation features to datapacks and the JSON they contain. Current OreSpawn configuration system is going away. OpenLoader will be required for any user configs, otherwise mods will just have to include their own data-packs to cover spawns.
See TODO.txt for a proper run-down of what is coming. Basic overview: Mojang's push towards having as much as possible configurable via datapacks has pushed me to need to change things so that OreSpawns features are exposed in the same manner and configured in a similar manner.
…plified but functional manner. Refactors coming that will restore the buildability.
…just figure out WTF is going on with the `DefaultFeatureConfig`
… takes all `Config` parameters (and a `String`) - it does not take a concrete `DimensionMatcher`...
…still has a lot of code to be added...
… need to add another event to registered configured features ?
Almost entirely just added debugging and a few pokes to see if I could get things working by throwing shit at the wall while dead tired. But I know what I need to do now and it is rather brain-dead simple. I need to add some tracking of configured features so they can actually be registered in the correct registry - or just do it on the fly... Vanilla and all existing mods appear to do the WorldGenRegistry stuff hard-coded for at least one feature... this isn't what I want here, so I'm going to have to do it separately and cross my fingers. Thats for later, though.
…ork last night...
…on processor with FG5
…tuff is broken completely in Forge, at this time... Going to revert back to the `load from custom JSON` setup and have everything done in `FMLCommonSetup` moving forward. It's just easier, overall
…tice - nothing to see here, carry on\!
Lots still to do, but at least we have a proper start now.
Contributor
Author
|
Not sure how to resolve conflicts that exist in files that were deleted |
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.
Port to 1.20.1 and get fully functional.