Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple OreDictionary names #68

Open
wants to merge 1 commit into
base: 1.12
Choose a base branch
from

Conversation

JoshieGemFinder
Copy link

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.

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.
@JoshieGemFinder
Copy link
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant