Add support for multiple OreDictionary names#68
Open
JoshieGemFinder wants to merge 1 commit into
Open
Conversation
When creating modpacks, it's very possible that you'll want to mark an item that already has an existing OreDictionary entry as being an ore (or ingot, etc), while also wanting to keep the original OreDictionary values. Since OreDictionary does not support reordering or removing values, this makes it incredibly hard for modpack devs to mark something like this with the tools available (without writing java code, that is, which most modpack devs will want to avoid) to COFH mods, since they only check the first OreDictionary entry, and not ones after it. This tries to fix that by simply checking all of the OreDictionary entries on an item, hopefully making this much easier for modpack devs in future.
Author
|
Something else I mentioned elsewhere: in some (admittedly rare) cases, the names of mod jar files can affect the primary OreDictionary entry associated with an item. Personally I have a strong bias against issues caused by loading order of mods; however, since it's a very rare issue and I know my biases I wasn't certain whether to include it in the main pull request description. |
JoshieGemFinder
added a commit
to JoshieGemFinder/CoFHCore-1.12-Legacy
that referenced
this pull request
Jun 30, 2024
Most of what I said in CoFH#68 still stands, this should hopefully provide an less-obtrusive alternative that won't break anything that already exists. While I was writing my pull request for Thermal Expansion I noticed that it had something extremely similar (just for only food items) and figured I could at least try replicating it for other ore types here.
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.
When creating modpacks, it's very possible that you'll want to mark an item that already has an existing OreDictionary entry as being an ore (or ingot, etc), while also wanting to keep the original OreDictionary values.
Since OreDictionary does not support reordering or removing values, this makes it incredibly hard for modpack devs to mark something like this with the tools available (without writing java code, that is, which most modpack devs will want to avoid) to COFH mods, since they only check the first OreDictionary entry, and not ones after it.
This tries to fix that by simply checking all of the OreDictionary entries on an item, hopefully making this much easier for modpack devs in future.