Minecraftforge: [Feature/Discussion] Handling duplicated Ores

Created on 11 Sep 2017  路  20Comments  路  Source: MinecraftForge/MinecraftForge

Hi,

while creating my own modpack I had the problem that multiply mods generate the same ore.
This I came up with some ideas to change this:

  • having a way to override ore generation in Minecraft (as I don't know any way except for ASM).
    This (I refer to it for know as an event) event could be used to override the ore generation of mods (and vanilla ones) in order for one mod to handle all ore generation.

  • I guess another approach for this could also be to let the Ore Dictionary handle
    duplicated ore generation as every mod has a specific balance and when now 10
    mods generate the same ore, the numbers of this one ore would be ~10 times
    greater as the mods are balanced around. (my prefered way from those two ideas)

Note: I created this issue for discussion purpose as I think such a system needs discussion if
Forge should handle such things and how etc.

Stale

Most helpful comment

If no one fires the event that doesn't mean the event is bad, mods just need to be PR'ed/bothered to fire it.

All 20 comments

This could be a very nice, very powerful tool for modpack creation. Tied in with #4139, it would allow for modders to register an ore for generation, but then the actual generation could be handled elsewhere (even in json if that is where people eventually want to go, but let's hold off on that one for now at least).
It would move towards the data-driven API that Mojang are angling for, and reduce duplication in a standard, user-specified way.

This event already exists, most mods just don't fire it.

This event already exists, most mods just don't fire it.

@diesieben07 Meaning it is not a solution to this issue. Thought if there is an event and most mods don't fire it, it makes my first thought about how to solve this unnecessary as it already exists and doesn't work.

@Alpvax If this stuff would be bound to a json system, a system could be implemented to have server side ore generation values differ from client side ore generation and stuff like that. Thought I'm not really a fan of all those jsons. I would rather write 100 lines in Java or C or C++ or C# or whatever than write 1 json file. ^^
But thats just my opinion and as everything goes more to jsons I have to live with it.

If no one fires the event that doesn't mean the event is bad, mods just need to be PR'ed/bothered to fire it.

Thought I'm not really a fan of all those jsons. I would rather write 100 lines in Java or C or C++ or C# or whatever than write 1 json file. ^^

Can we stop this crazyness, please? It's not "hip" to dislike Json or whatever the heck.
Json is a data format, you can't say "I would rather write C than Json", the two do different things, with different purposes. That's like saying "I would rather eat a cake than use a hammer" - yes, sure. But eating a cake does not get the nail into the wall.

If no one fires the event that doesn't mean the event is bad, mods just need to be PR'ed/bothered to fire it.

@williewillus Hm, thought how would one go about having mods to fire it? I also never said or meant to say that the event is bad, just that it is unnecessary if no one uses it.

This event already exists, most mods just don't fire it.

Can we stop this crazyness, please? It's not "hip" to dislike Json or whatever the heck.
Json is a data format, you can't say "I would rather write C than Json", the two do different things, with different purposes.

I know that those two have completly different purposes. This doesn't change that I don't like JSON. Thought I would say back to the topic.
Also I guess having such a feature like the event allows in form of the OreDic could also solve the problem you mentioned that many mods don't fire the event as they then don't have to if they don't want to for whatever reason they may have.

Hm, thought how would one go about having mods to fire it? I also never said or meant to say that the event is bad, just that it is unnecessary if no one uses it.

The mods just need to post the event to the forge event bus when they generate ores, like Forge already does it for vanilla.
Mods will always have to do some action to make their ore-generation available for some kind of API. This event is that API, mods need to integrate with it. If you add yet another API, you now have two APIs that nobody uses.

If you add yet another API, you now have two APIs that nobody uses.

Thought with letting the ore dic solve those problems we wouldn't have another API and the problem would also be solved for mods which don't fire the event as nearly all ores are registered using ore dic to provide some kind of compatibility in crafting recipes etc.

How you want the OreDict to stop ores from generating is beyond me.

Most mod packs get around this by just disabling each mods ore gen and use a third party ore gen system, like CoFHWorld.

I think mezz made a OreRegsitry as an extra mod wich fixes this problem.

There is another way to get what might be the same effect in a more universal way -- you can handle the chunk populate event and after it is generated you can scan the blocks in the chunk and replace them with whatever you prefer. You might even be able to do it somewhat generically by looking at ore dictionary and if there are alternatives you can choose based on modid or some other criteria, or otherwise if there are specific mods you are targeting you can look for their blocks and replace them.

I don't know if this approach is what you're looking for but the nice thing is it uses existing event and I think could give you a lot of control.

@jabelar while this is as it is a good idea, s canning all chunks and changing them will be a huge hit on performance.

I really don't understand why the job of making sure USERS configure the configs of the mods they install falls upon forge. Any sane mod will provide a config for their world generation, simply pick a mod that you want the ores of to exist and don't disable those. There is also the issue of some mods don't necessarily agree on what spawn rates should exist for each type of ore they share in common.

I sort of feel that the generation should be outside of the mods. Something which allows the users to specify a generation type, and a min&max height, plus rarity and possible vein size. Should probably be moved to json, but needs a lot of discussion before implementation.

@jabelar while this is as it is a good idea, s canning all chunks and changing them will be a huge hit on performance.

I don't think it is that bad because it only has to be done one per chunk during generation. Also, if you want to be clever you can distribute the replacement over several ticks since the player is unlikely to quickly get to layers that are at a distance from where they are at.

But performance is all relative and computers are rapidly getting better performing and Minecraft and Forge occasionally make perf improvements. Something that is a noticeable lag two years ago, probably wouldn't be noticed on a newer computer. But not everyone is lucky enough to have good gaming rigs I guess, but I also suggest that people who are into gaming do invest in modern systems otherwise the entire community for the game gets dragged down because developers can't advance the complexity of the code.

Anyway, if the ore conflict is a big concern just saying that there is a simple and universal way using current Forge hooks to accomplish what you want.

This event already exists, most mods just don't fire it.

How would one use that event? Say that I want to spawn copper ore within my mod. Would I then fire the event after I have run my generator?

How would one use that event? Say that I want to spawn copper ore within my mod. Would I then fire the event after I have run my generator?

You first call TerrainGen.generateOre. If it returns false, you don't generate the ore, otherwise you do. Forge does this in the patches to the BiomeDecorator class.

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AlgorithmX2 picture AlgorithmX2  路  20Comments

Boundarybreaker picture Boundarybreaker  路  71Comments

ShieLian picture ShieLian  路  42Comments

fscan picture fscan  路  24Comments

cpw picture cpw  路  97Comments