Industrial Foregoing Version:
TeslaCoreLib Version:
Crashlog (If Any):

I've been thinking about changing up how the laser drill system works and actually want to try implementing the idea myself; I am wondering if this is something I might want to make a pull request for and integrate into the main mod, or if it is better off just being an external add-on:

The ores the drill produces would be defined in an external config file. In addition to name and color, rarities would be listed by biome and a range of depths, e. g.

emerald : lime {
mountains[
(4, 20): 0.2
]
all[
(0, 255): 0.001
]
}

The drill would have a configurable "drill depth" in the GUI, and when extracting ores would check the biome it's in and the depth against the config file in order to determine what ores it should extract and in what ratio. I personally like this option because it gives the player more control over what ores are actually produced in a manner that can be made to closely approximate actually digging at a specific location, but I'll be the first to admit it may be a little bit more heavyweight than most would want.

Im thinking about it, I kinda wanted to do this at some point

From where are you getting it?

Nvm its a fork

What is the problem?

Trying to play around with this myself and having some trouble getting the mod to work in a development environment; should I be using the source or deobfuscated version?

I'm currently trying two approaches- running the mod as a fork, and using the jar from Curse. I'm not sure how to integrate the fork with my Forge development environment as parts of the file structure are duplicated and others are not, so I've been focusing on the jar method. That causes the game to crash on preinit with the following error trace:

java.lang.NoSuchMethodError: com.buuz135.industrial.fluid.IFCustomFluidBlock.setTranslationKey(Ljava/lang/String;)Lnet/minecraft/block/Block;
at com.buuz135.industrial.fluid.IFCustomFluidBlock.(IFCustomFluidBlock.java:46)
at com.buuz135.industrial.proxy.BlockRegistry.(BlockRegistry.java:110)
at com.buuz135.industrial.proxy.CommonProxy.preInit(CommonProxy.java:127)
at com.buuz135.industrial.proxy.client.ClientProxy.preInit(ClientProxy.java:71)
at com.buuz135.industrial.IndustrialForegoing.preInit(IndustrialForegoing.java:85)

are you using the same mappings as me? stable_39

Yeah that was the problem. Got the fork working properly; Eclipse is flagging some errors but the game itself will build and run.

Currently have a system implemented to read JSON configuration files and produce ores based thereupon. There is also a method to add default configuration files stored within a jar which will then be spawned on launch if absent; I think this will be useful for compatibility since different mods can each have their own ore configuration file.

Two things remain to be done. One is to decide what to do with the CraftTweaker methods relating to adding and removing drill entries, since these are now rendered obsolete by the presence of a dedicated config file. The other is to figure out how to handle the JEI recipe integration, since ore frequency is now dependent on depth and biome.

The Craftweaker part it can be removed and I will handle the JEI part, I like doing JEI things.

Just doing some final cleanup with the intent to submit a pull request later today. I've kept the error output minimal since the rest of the mod just uses PrintStackTrace() on exceptions.

Ah, Okay. Ty

Hi,
a quick question:

Can we edit the default_ores.json with our own entries, or we have to create a new .json for the custom ores?

You can do both things