It's the most annoying thing in the latest modpacks, isn't it? you go to the cave for some ores and in one second your whole inventory is full of stuff.
why? because you have 4 types of copper and 3 types of tin, bronze, lead and many more.
Plus, in your chests, it's all full so many of the same materials from different mods. so hard to organize everything.
How fun was it in classic modpacks, as Tekkit, when there was only one type of each material?
So yeah. I think that someone has to build a mod that will combine all the different mods maretials to one type each. it's just has to be done. for the future modpacks, and for everyone else.
This can be done in the configs for most mods that add ore gen. Simply pick the mod that generates the ore you like the best, and turn the rest off. No reason to code things that you don't have to.
It's the most annoying thing in the latest modpacks, isn't it? you go to the cave for some ores and in one second your whole inventory is full of stuff.
why? because you have 4 types of copper and 3 types of tin, bronze, lead and many more.
Plus, in your chests, it's all full so many of the same materials from different mods. so hard to organize everything.
How fun was it in classic modpacks, as Tekkit, when there was only one type of each material?
So yeah. I think that someone has to build a mod that will combine all the different mods maretials to one type each. it's just has to be done. for the future modpacks, and for everyone else.
What do you think?
This has been tossed around, especially at the one point all mods share (Forge), and has been denied, for a few reasons.
Firstly, a mod solely uses it's own ore for all it's recipes (if you're wanting to know how most recipes can support ore types of all variants, I'll explain in a bit), so for this to be feasible, every mod would need to rely on this one mod, which is impractical. If this was added to Forge, this wouldn't be an issue, however, as I said, it's been denied by LexManos and the rest of the dev team for various reasons (basically, Lex and the team feel that Forge simply gives mods the ability to add stuff into the game, and the mods' have the responsibility of managing what's in the game and what isn't in the game, so they refuse to make Forge add in it's own ores purely because some users don't like multiple variants of ores in their world, that's up to the modders to decide, in their opinons).
Next, having every single mod rely on one variant of ore would be boring and may potentially limit mods in what they can do. Think about it, sure, having multiple types of ores is annoying and fills up your chests, but later on in the game you'll have a system which automatically takes and processes ores, funneling them to be only purely one type, so this issue is "filtered out" later on. Also, every single mod would rely on the same ore with the same texture, which doesn't add the spice and uniqueness to the mods', this is a minor issue, I know, but still an issue nonetheless, the next one is a bit bigger though. What if one mod adds say copper ore, with a twist, in that it has unique drops? Say that mod's copper ore can occasionally drop gold or whatever. If you make every mod rely on one form of common ore type, that removes this potential.
Now, LexManos and the Forge team did see the issue here, and they did give modders something which could help out, which is a function of Forge called the Ore Dictionary. Essentially, the ore dictionary (ore dict for short) is a very powerful list of common items which mods can add onto. Mods can then use the ore dict to build dynamic recipes for their mods, so that the recipe supports all ore dict entries for a specific item. This is what allows say IC2 copper to be used with Thermal Expansion recipes, or the reverse. Or what allows IC2 ores to be processed in UE machines, or the reverse. That's because these machines have been hardcoded with dynamic ore dict capabilities, instead of coding the machine so it can only support IC2's copper, the machine is coded so that it supports any copper entry within the ore dict.
So, what does the ore dict do for managing what type of ores or items you have? Like if you have 3 types of copper, 5 types of tin, etc. Some mods utilise the ore dict to allow you to convert between item types. So you can put IC2 tin in, convert it to Thermal Expansion tin, and voila, you now have Thermal Expansion tin instead. But, as I said, specifically for ores, one of the goals of modded Minecraft is to automate trivial tasks such as refining ore, and as such, if you choose to use Thermal Expansion machines for your autoprocessing system, you will thus get Thermal Expansion items out, and the same for IC2 and other such mods.
I do agree with you in that the current system is messy, and at the start you do end up with like 5 different types of the same ore, but face it, unless vanilla Minecraft changes to include these ores, or the dynamics of the modding community change as such that either Forge includes these ores itself or all mods rely on one core mod to achieve this, this isn't going to happen. The key here, though, is not to mope about it, but use the utilities you have in front of you. As llcj20 mentioned, mod authors nowadays see that there can be potentially many different types of the same ore, so generally, they include an option to control their mods' ore gen. You can disable say all ore gen but IC2's, to get IC2 ores, or Thermal Expansion, or UE, or any other mod. I tend to leave these alone though, because, if you think about it, the more ore gen is enabled, the more abundant a specific type of ore is, so the more ore I get! Plus, as I said, late game you do manage to set up an autoprocessing system, so eventually down the line, you will be only storing one type of ore.
This can be done in the configs for most mods that add ore gen. Simply pick the mod that generates the ore you like the best, and turn the rest off. No reason to code things that you don't have to.
This is true, however, not all mods have ore gen settings in the config.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I read what you said. you right. there are alternative solutions.
but it's still too bad that it's like it. I get it that it'll be just more then a little mod, but if someone will take this project to his own hands, we'll all have a better modded time. I can just hope.
Firstly, a mod solely uses it's own ore for all it's recipes (if you're wanting to know how most recipes can support ore types of all variants, I'll explain in a bit), so for this to be feasible, every mod would need to rely on this one mod, which is impractical.
Well, it's possible to make one mod that adds all sorts of different ores, and then the modders just have to choose which ore to activate. It'd get rid of the problem and make the modding process a hell of a lot easier
Firstly, a mod solely uses it's own ore for all it's recipes (if you're wanting to know how most recipes can support ore types of all variants, I'll explain in a bit), so for this to be feasible, every mod would need to rely on this one mod, which is impractical.
Well, it's possible to make one mod that adds all sorts of different ores, and then the modders just have to choose which ore to activate. It'd get rid of the problem and make the modding process a hell of a lot easier
EDIT: fricking hell, why are quotes messed up?
That's one solution I talked about, unfortunately that just adds a dependency to the list of dependencies and makes things a bit trickier for both developers and end users. What if the ore-adding mod updates but each mod using it has updated at different rates (so Some Generic Industrial Mod uses version 1.3.IDon'tReallyCareAbouTheVersionButWhatever of the ore-adding mod, however 3 other mods use 1.2 as 1.3 literally just came out)? All of a sudden the end user can't use Some Generic Industrial Mod because 3 other mods use a different version of the ore-adding mod. Or what if two mods add say Feraldum ore (made up name, heh), should the ore-adding mod add that?
Adding a third-party dependency isn't the best solution in this case, especially with a problem as broad as multiple types of items. This problem isn't only evident with ores either, different types of gears, different instances of the same type of block, etc are all the same problem in different contexts, sorting this all out with a single mod playing a dependency for every other mod isn't a good solution.
And I don't know why, but I had to reread your comment three times to work out what you were saying.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Set what should be the "primary" item so the item that should replace the other ones, this would either be done through a config file or by just using the first one.
This is the reason why forge doesn't automatically do it. How does it decide which ores/ingots etc. to use? What if one player likes one texture, and another prefers a different texture.
why? because you have 4 types of copper and 3 types of tin, bronze, lead and many more.
Plus, in your chests, it's all full so many of the same materials from different mods. so hard to organize everything.
How fun was it in classic modpacks, as Tekkit, when there was only one type of each material?
So yeah. I think that someone has to build a mod that will combine all the different mods maretials to one type each. it's just has to be done. for the future modpacks, and for everyone else.
What do you think?
This has been tossed around, especially at the one point all mods share (Forge), and has been denied, for a few reasons.
Firstly, a mod solely uses it's own ore for all it's recipes (if you're wanting to know how most recipes can support ore types of all variants, I'll explain in a bit), so for this to be feasible, every mod would need to rely on this one mod, which is impractical. If this was added to Forge, this wouldn't be an issue, however, as I said, it's been denied by LexManos and the rest of the dev team for various reasons (basically, Lex and the team feel that Forge simply gives mods the ability to add stuff into the game, and the mods' have the responsibility of managing what's in the game and what isn't in the game, so they refuse to make Forge add in it's own ores purely because some users don't like multiple variants of ores in their world, that's up to the modders to decide, in their opinons).
Next, having every single mod rely on one variant of ore would be boring and may potentially limit mods in what they can do. Think about it, sure, having multiple types of ores is annoying and fills up your chests, but later on in the game you'll have a system which automatically takes and processes ores, funneling them to be only purely one type, so this issue is "filtered out" later on. Also, every single mod would rely on the same ore with the same texture, which doesn't add the spice and uniqueness to the mods', this is a minor issue, I know, but still an issue nonetheless, the next one is a bit bigger though. What if one mod adds say copper ore, with a twist, in that it has unique drops? Say that mod's copper ore can occasionally drop gold or whatever. If you make every mod rely on one form of common ore type, that removes this potential.
Now, LexManos and the Forge team did see the issue here, and they did give modders something which could help out, which is a function of Forge called the Ore Dictionary. Essentially, the ore dictionary (ore dict for short) is a very powerful list of common items which mods can add onto. Mods can then use the ore dict to build dynamic recipes for their mods, so that the recipe supports all ore dict entries for a specific item. This is what allows say IC2 copper to be used with Thermal Expansion recipes, or the reverse. Or what allows IC2 ores to be processed in UE machines, or the reverse. That's because these machines have been hardcoded with dynamic ore dict capabilities, instead of coding the machine so it can only support IC2's copper, the machine is coded so that it supports any copper entry within the ore dict.
So, what does the ore dict do for managing what type of ores or items you have? Like if you have 3 types of copper, 5 types of tin, etc. Some mods utilise the ore dict to allow you to convert between item types. So you can put IC2 tin in, convert it to Thermal Expansion tin, and voila, you now have Thermal Expansion tin instead. But, as I said, specifically for ores, one of the goals of modded Minecraft is to automate trivial tasks such as refining ore, and as such, if you choose to use Thermal Expansion machines for your autoprocessing system, you will thus get Thermal Expansion items out, and the same for IC2 and other such mods.
I do agree with you in that the current system is messy, and at the start you do end up with like 5 different types of the same ore, but face it, unless vanilla Minecraft changes to include these ores, or the dynamics of the modding community change as such that either Forge includes these ores itself or all mods rely on one core mod to achieve this, this isn't going to happen. The key here, though, is not to mope about it, but use the utilities you have in front of you. As llcj20 mentioned, mod authors nowadays see that there can be potentially many different types of the same ore, so generally, they include an option to control their mods' ore gen. You can disable say all ore gen but IC2's, to get IC2 ores, or Thermal Expansion, or UE, or any other mod. I tend to leave these alone though, because, if you think about it, the more ore gen is enabled, the more abundant a specific type of ore is, so the more ore I get! Plus, as I said, late game you do manage to set up an autoprocessing system, so eventually down the line, you will be only storing one type of ore.
This is true, however, not all mods have ore gen settings in the config.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
but it's still too bad that it's like it. I get it that it'll be just more then a little mod, but if someone will take this project to his own hands, we'll all have a better modded time. I can just hope.
Firstly, a mod solely uses it's own ore for all it's recipes (if you're wanting to know how most recipes can support ore types of all variants, I'll explain in a bit), so for this to be feasible, every mod would need to rely on this one mod, which is impractical.
Well, it's possible to make one mod that adds all sorts of different ores, and then the modders just have to choose which ore to activate. It'd get rid of the problem and make the modding process a hell of a lot easier
EDIT: fricking hell, why are quotes messed up?
That's one solution I talked about, unfortunately that just adds a dependency to the list of dependencies and makes things a bit trickier for both developers and end users. What if the ore-adding mod updates but each mod using it has updated at different rates (so Some Generic Industrial Mod uses version 1.3.IDon'tReallyCareAbouTheVersionButWhatever of the ore-adding mod, however 3 other mods use 1.2 as 1.3 literally just came out)? All of a sudden the end user can't use Some Generic Industrial Mod because 3 other mods use a different version of the ore-adding mod. Or what if two mods add say Feraldum ore (made up name, heh), should the ore-adding mod add that?
Adding a third-party dependency isn't the best solution in this case, especially with a problem as broad as multiple types of items. This problem isn't only evident with ores either, different types of gears, different instances of the same type of block, etc are all the same problem in different contexts, sorting this all out with a single mod playing a dependency for every other mod isn't a good solution.
And I don't know why, but I had to reread your comment three times to work out what you were saying.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I haven't actually tested it yet, but it at least runs with my game. There is in fact a mod that claims to solve this sort of thing:
My Mods:
Fool's gold & other dumb things
Placebo Effect
Two others that I am pretending don't exist.
Also, Modding Theory.
This is the reason why forge doesn't automatically do it. How does it decide which ores/ingots etc. to use? What if one player likes one texture, and another prefers a different texture.
If I helped you, please click the green up arrow.