Immersiveengineering: [Enhancement] [Suggestion] Simple terrain unification

[alpharou]

In an attempt of creating a modpack (which is private for now) I found out that (surprise surprise) modded ore generation is still un-matured and sparse. Many mods add their distinctive ore, and there's nothing wrong with that. The problem comes when they try to add copper, or aluminium, or any of these common modded ores, and you end up with two or three types of the exact but not stackable nor interchangeable in-game resources. Now, I understand the utterly difficult task of taking into account other mods' blocks, APIs, libraries, etc; so, I think that a possible workaround to all that impractical and nonsensical "unification" is that each mod that generated terrain had a "default ore ID" for each ore that could be generated, which may be left blank by default, or set to another mod's ID to override the ore generated. This way each modpack could be tweaked without entirely overhauling mods like CoFH Core so that there's only one blockID per modded resources in-game.

Just suggesting helpful behind-the-scenes additions to mods in general (in this case IE):

1- Add this modular approach to every type of block generated. (This way, anyone could concoct awesome lightweight modpacks like the one I'm making without needing to go all out and use these mentioned overhauling techniques.)

2 - Also, even go deeper and skip said replaced blockIDs' declaration to prevent them from existing (remember, this is taking into consideration that the config was set correctly and the alternative blockID actually exists). This would prevent other mods from actually taking these blockIDs into account (for example JEI's recipe management or BedRock Ores adaptive custom generation).

What do you think? Is this practical? What drawbacks are there to consider? Or is there another simpler or more elegant way of archiving terrain unification?

PS: I'm only asking for actual terrain generation tweaks to avoid inventory or themed duplicates. Item correlation is already pretty well handled with forge's ore dictionary and there's no need for trying to improve it.

[Alaberti]

Wouldn't it be more practical to edit configs until you have what you need?

[alpharou]

Actually, it's exactly what I am asking for: A config parameter that says for example CopperOreID: "[The ID you want to use]". I don't know if any mod has this feature already, but I didn't find it. The closest editable config I got was the CoFH Core World generation JSON files.

[KnightMiner]

But then assuming each mod had this config, you have the same ore generating multiple times, so twice or 3times as much. Just disable the oregen for duplicate ores entirely.

[alpharou]

The ore is already being generated multiple times by each mod, just different types of the same oreDictionary "copper" for example. Also, if you want to use a mod like Embers which has a copper generation coupled with its high copper demands, if you disable it because "it's a duplicate" you may be running out of copper entirely. Now, if you do it the other way around and disable ore generation to all the other mods that duplicate copper ore (which I don't know how you would do it) you may not generate for example sulfur from Thermal Expansion anymore.

I suggested this feature:

Example IEWorldGen.conf :
enableWorldGen: true/false
generateCopper: true/false
copperblockID: (leave blank for default = immersiveengineering:ore blockstate 0)
generateSilver: true/false
silverBlockID: [...]

This way, if you don't mind different types of copper just by dropping the .jar and hitting play you are set. If as @KnightMiner said you just want a quick fix, search a bit for a mod's config file or dedicated modWorldGen config and tweak literally 1 value and you're also set. You could also make Immersive Engineering generate copper as it would usually do, same shape and Y levels and all of that, just using another's mod copperOreID.

[KnightMiner]

You missed my point. Most mods currently have a config on a per ore nasic, so if you want Embers copper distribution, you keep embers copper disabled and disable just copper from thermal foundation. No need to over complicate this, just pick the ore with the generation you like on a per ore basis.

[alpharou]

Ok, found it: immersiveengineering.cfg line 350. You can actually set individually the oreGen.

But actually, I won't close this issue, I want to know if this blockID override leads somewhere. Now, do you think it's realizable @KnightMiner ? What could be the challenges involved?

[BluSunrize]

The main challenge is that overriding other mod's blocks is a thing you don't do
You don't mess with other mods' internals, because that makes you Greg. And you never go full Greg.

[alpharou]

Oh sorry, I meant to say exactly the opposite. Override (my) mod's blockIDs with (others) mod's blockID via a config parameter at the time of generating that block in the world.

[calloatti]

Just use https://minecraft.curseforge.com/projects/instantunify It solves your problem.

[alpharou]

I am. I wouldn't, it's just another 3rd party that could get dropped in development along the way. It's not sane to rely that heavily on any tool. If this mechanic gets implemented anywhere in the future it would make other generalizing efforts hopefully obsolete. I don't know if this is hard, or even impossible to implement. To replace certain blocks the mod uses with external ones. Not overriding other mod's blocks, but using other's instead of yours.

Just to be clear, I didn't post this issue searching for solutions, but to explain this idea I had.

[bookerthegeek]

@alpharou basically what you are asking for is https://github.com/MinecraftForge/MinecraftForge/pull/4457

One can hope if it gets integrated into forge that it will do what you are wanting.

[alpharou]

@bookerthegeek Yep, it's pretty much the same thing, but 100 times better, thanks for the info! I'll close this thread (issue) since it seems to me that it won't lead anywhere.