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

[GreenZombie]

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

It doesn't really.
All forge needs to do is enforce "strict unification" for ores: It would register only one type of copper: first-come-first-served or via config. At any rate, the first mod to register copper (ore, ingot, dust etc.) (for example) gets it, every subsequent mod that tries to register copper will get back the first mods copper and believe it to be their own.

Forestry, TE, Tic and IC2 can then all implement their own configurable rules for spawning copper - it doesn't really matter as all the copper ore generated would be the same.

 

[gattsuru]

At any rate, the first mod to register copper (ore, ingot, dust etc.) (for example) gets it, every subsequent mod that tries to register copper will get back the first mods copper and believe it to be their own.

There are some reasons that's likely to be complicated, as a subset of the general issues with how Block IDs are handled and some of the parts of worldgen. Each mod handles its own WorldGenerator interface, for example, so Forge generally lets them do their own thing. It's historically been easier to convert items on pickup (see TeamCOFH's Forge Lexicon, or the Gregtech unification concept). It's not an unsolvable problem, but is complex enough and fraught with enough peril that it doesn't seem likely to get the most attention from a development team that's got very limited time and energy. Moreover, it'd /still/ require everyone implement the conventions accurately to avoid issues, in a modding community where there's a lot of controversy over even simpler conventions. There are already tools to make sure, for example, but that doesn't seem to reliably occur.

At a deeper level, I can't quite blame the Forge team. The absolute best-case scenario for a strict ore unification would allow modpack makers to not have to disable certain ores in certain mixed pack configurations. But that won't make the default configs on any large pack terribly good : it's very hard for the ore generation for two different mods to be well-balanced with each other, to the extent that a handful of mods have had shooting wars over this sorta thing. You'd still need to tweak the configs to get ore rates that work. Once that's necessary, disabling superfluous oregens is a fairly minor task

 

[Qazplm601]

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.

yay i figured out how to add pics!