ELI5: Ore Dictionary expanded or "Why can't forge handle the ore generation?"

[Acediar]

Without any potential baggage or any knowledge about the question I wanted to ask why, even though most mods featured in FTB/FTB affiliated mod packs, require forge and integrate with the Ore Dictionary we still have multiple versions for ores, ingots and nuggets for commonly used metals like tin, copper or bronze.

Most of the time it doesn't really matter since most recipes can use all ore types, but if you store them in a chest or any storage system like AE they end up using different slots or spaces.

So why can't the ore dictonary handle this for us? I have little to no knowledge about java programming and mod development so if there is an obivous reason I am overlooking PLEASE correct me!

As far as I understand during the early phases mods check if other mods are installed, to me it would seem logical at this point for mods to check "Is forge installed? - Yes - I turn off my own versions of the ingots/nuggets/etc and use the forge versions"

There are currently 4 versions of the common (3 copper + 1 tin) bronze ingots

• Bronze Ingot - Tinkers' Construct
• Tinker's Alloy Ingot - Tinker's Construct (shouldn't it be Tinkers' Alloy?)
• Bronze Ingot - IndustrialCraft 2
• Bronze Ingot - Forestry

in the current DW20 modpack which you get depending on mod which added the recipe, which clutters my storage system due to not stacking. Most of the time you can even convert them by reducing them to nuggets or blocks and recrafting ingots.

Wouldn't it be possible to consolidate them into one block which gets used in every recipe and which is the output for every furnace?

 

[HeffronCM]

This would require every Forge mod maker that uses Bronze to come to a consensus on the rarity of copper, rarity of tin, spawn area for each, and their conversation rate to Bronze. Having seen how fiercely individualistic and unwilling to allow anyone else to "compromise their vision" some of the mod makers get, I don't think that is happening any time soon.

Sent from my SM-N900V using Tapatalk

 

[ShneekeyTheLost]

The reason they exist is that every single one of those mods has a use for bronze, and cannot rely on any other mod providing it.

The solution is several-fold:

1) Disable ore generation from all mods but one, so you only have one ore type spawning, thus only one mod's ore exists and only one type of each ore is available for refinement. Most mod packs already do this.

2) Forge Ore Dictionary means it doesn't really matter which mod's material it is, because they are all interchangeable in recipes. Therefore, it is simply a space issue.

3) There are several ways to transform an item from one mod's version to another, the easiest of which are JABBA barrels.

 

[Acediar]

This would require every Forge mod maker that uses Bronze to come to a consensus on the rarity of copper, rarity of tin, spawn area for each, and their conversation rate to Bronze. Having seen how fiercely individualistic and unwilling to allow anyone else to "compromise their vision" some of the mod makers get, I don't think that is happening any time soon.

Sent from my SM-N900V using Tapatalk

This can be handled by config files, as it already is in mod packs (thanks jaded)
Plus you could automatically take an average as default

The reason they exist is that every single one of those mods has a use for bronze, and cannot rely on any other mod providing it.

The solution is several-fold:

1) Disable ore generation from all mods but one, so you only have one ore type spawning, thus only one mod's ore exists and only one type of each ore is available for refinement. Most mod packs already do this.

If would still be splitted depending on the methode of smelting wouldn't it?

2) Forge Ore Dictionary means it doesn't really matter which mod's material it is, because they are all interchangeable in recipes. Therefore, it is simply a space issue.

Correct

3) There are several ways to transform an item from one mod's version to another, the easiest of which are JABBA barrels.

Yeah but why introduce convertion methods into the system if you could handle the problem far earlier in the line?

It is a convenience issue, no argument here, but I think this could be addressed and solved

 

[HeffronCM]

This can be handled by config files, as it already is in mod packs (thanks jaded)
Plus you could automatically take an average as default

Here's a hypothetical situation. Say Forge handles all mod generation. One mod wants veins of copper to contain 8 ore each and generate 10 per chunk. Another mod wants copper to generate in veins of 20 with 2 per chunk. What happens when these two mods are tossed into Forge? Neither mod author is happy with the situation. The world ends up with too much copper per chunk for one mod, and not enough for the other, so the balance point they designed their recipes on is way off. It becomes easy to quickly progress in Mod A and difficult to progress in Mod B. Why would they agree to stop adding their own ore and let Forge handle it if they are not going to get the balance point they want for their mod?

 

[Hoff]

Problem of the premise of the question: Forge doesn't add ingots, ores or anything of the like. It adds a reference all mods can link their ingots, ores, etc to and if the references match for items from two different mods they become interchangeable. Mods are not necessarily designed for modpacks and generally tend to balance against themselves as the only mod generating ores unless they are an addon. Another problem highlighted by Heffron; balance based on generation. This is not something that is meant to be handled by configs when it's the only mod generating ore because it's premised on the idea that it is the only mod generating said ores. Other mods like cofh core offer ways to generate anything you wish at your prescribed rarity so that a balance can be achieved that is good enough for all mods you're using that add like ores. At the same time it offers a way to make everything that will ever generate to be one type. On to your issue of most likely that different machines output different types of ingots based on the mod the machine is from regardless of the mod the oreDict ore came from. This could be addressed but I'm not sure it's not a very hacky way of doing it. The best solution you have is to use the many oreDict unifying blocks like Jabba barrels and the Unifer from MFR.

 

[ShneekeyTheLost]

Not to mention the fact that it would likely corrupt worlds to do this update because you are changing all the ores around.

I think what the OP is asking for is that all ores registered to the ore dictionary are registered, but instead of the mod's x ore, a universal forge x ore is spawned in world.

For example, You have three mods that have Copper and Tin ore. None of them are disabled. Forge Ore Dictionary sees that each one is registered respectfully, then during worldgen, all copper and tin ores spawned in the world are Forge Copper Ore and Forge Tin Ore, and all outputs proceeding from there are likewise Forge Copper or Tin whatever.

Problems are as follows:

1) As Hoff said, Forge is an API and a tool for mods to work together. It doesn't add any Block or Item ID's, and if it did so, this would be a huge problem that everyone would have to work around, due to how items are currently handled on the back-end, because it would be a dynamic rather than static number of ID's due to not knowing precisely how many unique ores are registered to the Forge Ore Dictionary. If you have something like Metallurgy installed... good luck with that.

2) As previously mentioned, there's a problem with balance. The solution I outlined would be spawning all three mod's spawning of ore per chunk combined, making WAAAAY too much ore for any of the mods. So then you disable one or two of the mods until you only have one left and tweak settings. Great, now why do you need Forge to do this when you just did it yourself?

3) The inconvenience for the average user is very trivial, considering the tools put in place, and the work on the back-end for mod packs that works to alleviate this problem (CoFH Core or Metallurgy both do a good job of this).

End result: Net gain is not worth the enormous monumental hassle involved in application. There would be too much qq, not enough pew-pew.

 

[Hoff]

There would be too much qq, not enough pew-pew.

Oh god. I fell on the floor laughing and I can't figure out why.

 

[WTFFFS]

Gregtech used to have unifier code that changed all outputs to one type of ingot, while it worked in most cases some things required their own ore to actually work and unless you were unifying to that type of ore you were outa luck. My current method is to change the ingot types to whatever my current processing method is you tend to have stages so it isn't terribly difficult to use the MFR unifier after you change processing methods to retroactively change any already processed ingots to that type. It can be automated fairly easily as well.

 

[ShneekeyTheLost]

Dartcraft Force Pipes can also have a unifier card placed in to unify anything passing through them

 

[Darkone84]

Here is my 2 cent.

I too think that either forge should handle more or if not forge some sort of Ore Gen Mod should and it should set the standards. Have configs in place so that mod packs can the spawn size ect. I know that CoFH Core or Metallurgy both do a good job of this already.

All the main Ores & Alloys, Bronze, Copper, Tin, Siliver, Lead ect. should be apart of forge. Not keep having every mod keep creating there own versions of the same connonly used ores Copper, Tin, Siliver, Lead ect. I know this when you create you own mod pack it's just pain full to turn off all the unwanted ores I don't want 9 different copper ores/ ingots should only be 1 ore and 1 ingot for that ore.

I can understand the some mods may have an one off ore e.g. Dartcraft "Power Ore" thats fine but all the other common ores and alloys move from the mods and into forge.

I can understand what Gregtech is tring to do but it's just crating other issues with other mods, it's only going to get getting wose until the main problem is fixed.
With Jabba it fixes the storage issue unifieing the ore and ingots into one type by using the Ore Dictionary.

 

[Acediar]

Not to mention the fact that it would likely corrupt worlds to do this update because you are changing all the ores around.

I think what the OP is asking for is that all ores registered to the ore dictionary are registered, but instead of the mod's x ore, a universal forge x ore is spawned in world.

For example, You have three mods that have Copper and Tin ore. None of them are disabled. Forge Ore Dictionary sees that each one is registered respectfully, then during worldgen, all copper and tin ores spawned in the world are Forge Copper Ore and Forge Tin Ore, and all outputs proceeding from there are likewise Forge Copper or Tin whatever.

This! Sorry if I explained it incorrectly but this is basically what I meant

Problems are as follows:

1) As Hoff said, Forge is an API and a tool for mods to work together. It doesn't add any Block or Item ID's, and if it did so, this would be a huge problem that everyone would have to work around, due to how items are currently handled on the back-end, because it would be a dynamic rather than static number of ID's due to not knowing precisely how many unique ores are registered to the Forge Ore Dictionary. If you have something like Metallurgy installed... good luck with that.

It actually wouldn't have to introduce blocks of it's own it could just change them all to... let's say the first mod that registers or a mod specified by the player.
I just think with tin, copper and bronze being that common in mods (which I think all require forge to be installed anyways) it would be logical to move a baseline of blocks to forge on which other mods can build upon

2) As previously mentioned, there's a problem with balance. The solution I outlined would be spawning all three mod's spawning of ore per chunk combined, making WAAAAY too much ore for any of the mods. So then you disable one or two of the mods until you only have one left and tweak settings. Great, now why do you need Forge to do this when you just did it yourself?

By just converting the ore types to one this would be out of the picture, wouldn't it?

3) The inconvenience for the average user is very trivial, considering the tools put in place, and the work on the back-end for mod packs that works to alleviate this problem (CoFH Core or Metallurgy both do a good job of this).

End result: Net gain is not worth the enormous monumental hassle involved in application. There would be too much qq, not enough pew-pew.

Well I could make a bug report out of it: I taught my AE system to produce bronze ingots you need to put 3 copper + 1 tin ingots in a thermal expansion induction smelter and a recipe to use thermal expension bronze ingots - Sadly if you do this you get Tinker's Alloy Ingots and I have to redo the patterns since AE doesn't recognize these two ingots as interchangable

 

[Sphinx2k]

Why Forge? How about a layer deeper directly in Minecraft?
It seems to me this is something that the mod api (when it is ever done) should handle.

 

[Golrith]

I've always felt (since 1.2.5) there should be just "one mod to rules them all" when it comes to ore generation.
While it makes sense for a mod to supply the ores needed, once you get to multiple mods, you've got to deal with different types of the same thing, different spawning, going through configs, etc, etc.

If one mod controlled the ore generation, not only will you not need an ore dictionary, you'll also save a little bit of memory resources by not having duplicated textures for ingots, dusts, ores.

All mods are designed around vanilla iron, gold, redstone, etc, etc. But there's no real agreement in the spawn rates of what are now the more common ores.
An extreme example is Silver. Factorization spawns that in big massive clumps because Factorization eats it like candy, but any other mod that uses silver only uses a small amount. There's no real way to generate a fair supply/demand situation.

Due to human nature, there will never be an agreement to an unified ore generation system.

 

[Yusunoha]

another reply from someone with no coding knowledge at all... would it be possible when you've several mods installed that add an ore type, that forge will register all these mods and create some sort of configuration file after the first launch which reports all the mods that add the same kind of ore. when you open this configuration file you'd then be able to specify which mod you prefer to handle the ore generation of that type, and it'll override the configuration file from the mods themselves...

this would be a way to see which mods add the same type of ores, and you'll be able to configure them all through a single configuration file.
but this is probably quite impossible to do as you'll need to be able to either override each and every configuration file, or make them partially unused, which I also have no idea how you'd be able to do that...

but I do like the idea of forge generating a text file that tells you which mods adds the same kinds of resources and what they are, as slowly mods also start to add their own kinds of stones and such...

 

[WTFFFS]

another reply from someone with no coding knowledge at all... would it be possible when you've several mods installed that add an ore type, that forge will register all these mods and create some sort of configuration file after the first launch which reports all the mods that add the same kind of ore. when you open this configuration file you'd then be able to specify which mod you prefer to handle the ore generation of that type, and it'll override the configuration file from the mods themselves...

this would be a way to see which mods add the same type of ores, and you'll be able to configure them all through a single configuration file.
but this is probably quite impossible to do as you'll need to be able to either override each and every configuration file, or make them partially unused, which I also have no idea how you'd be able to do that...

but I do like the idea of forge generating a text file that tells you which mods adds the same kinds of resources and what they are, as slowly mods also start to add their own kinds of stones and such...

Even if there was just a text file that reported all registered mod added ores it would be incredibly handy when setting up a pack, I might not forget to disable Forestry copper\tin for the hundredth time....

 

[Yusunoha]

Even if there was just a text file that reported all registered mod added ores it would be incredibly handy when setting up a pack, I might not forget to disable Forestry copper\tin for the hundredth time....

true, very true. I hate it to find out while you're playing a world that you forgot to turn a generation off and you either have the choice
1) start over
2) live with the fact your chunks are full of holes
3) tinker your whole world to fix the holes

perhaps this could be done if mods would allow forge to control their generation like that, but that'd really be impossible as it'd require all mods to change their codes for this to happen

 

[Skyqula]

I would be satisfied with the ability to simply disable a mods ores/ingots/nuggets/blocks/dusts/fluids/annything individualy per mod (ala extra utility's, setting it to 0 simply doesnt load it).

I would however love this to be a feature from forge. Where if you enable it, it only uses the first registered version of annything put in the oredictionary and does not load annything else. Ofcourse, the problem here is that all wood is the same not to mention that not everything from each mod acts the same IE: reasonant ender (TE) vs fluid ender (TiC), so there should probably be some whitelist and blacklist funtionality. Wich in turn makes this all very complex, but awesome none the less.

 

[Revemohl]

Dartcraft Force Pipes can also have a unifier card placed in to unify anything passing through them

And Dartcraft chests can use that unifier card as well to convert anything you place inside them. It's as amazing as it sounds.

Anyway, I don't find this to be an issue because pretty much every mod that adds worldgen ores has an option to, at least, choose whether its ores should spawn or not, with the better ones letting you customize vein size and quantity per chunk. Thank you TE. If you're too lazy to look into the configs of everything you've set up in your pack to do that, I don't think you should try making your mod pack by yourself yet.

As for the bronze problem, just choose one way to create it and avoid using the rest. For example, I like the name of TE's version and how it looks, so nowadays I only make my bronze in the induction smelter. Who cares if combining 3 copper and 1 tin by hand is more efficient, that isn't sciencey enough for me.

 

[ZacIsCool]

What about this: forge has a list of two hundred different adjectives, and when two types of ore have the same ore dictionary name it will apply a random adjective to one so that they have different names, and it will check to make sure names aren't already taken. Then they ditch the idea of all ores work for all recipes. That way, it would be like "rough bronze" and "heavy bronze", and so it would make sense that they are different, because some things need rough bronze and others need heavy bronze. Mods could also specify any number of additional adjectives it want's to allow, and specify preferred adjectives. That would also mean all mods would need their own ore so they will all be balanced, because if all ores work for all recipes, even if two mods add the same amount of copper, they would normally both generate their own copper and there would be too much copper and both mods would be unbalanced.