Fix cascading worldgen caused by Oreberries#275
Open
Charsy89 wants to merge 2 commits into
Open
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
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.
Adds an offset of +8 to the random coordinates for Oreberry generation. Using ArchaicFix to detect cascading worldgen revealed Tinkers' Construct as an issue mod. After applying the offset, there were no reports of CWG from Tinkers' Construct in the log.
It still occurs periodically due to slime islands, but this is inevitable given their size.
I was originally going to do this as a mixin in Hodgepodge, but it ended up being too complex given TC's behavior with regards to generating Oreberry clusters. Specifically, TC determines an appropriate location to spawn the Oreberries after generating random coordinates, meaning I would have had to inject between variable
STOREs orLOADs to add 8 toxPosandzPosso that thefindAdequateLocationmethod's return value would still be proper, which isn't such an elegant solution. Because of this, it is also not possible to apply the offset inside ofOreberryBushGen, because again, the Y level returned byfindAdequateLocationwould become obsolete.After light discussion in GTNH discord, I concluded that patching GTNH Tinkers Construct directly is the best solution.