DoubleNegation

That's an interesting point about keeping the config simple. I see how that could be better in many cases. However with supporting so many ores, the config file will naturally be long if I want every ore to be configurable separately. It kind of seems like a good idea to expose a CraftTweaker API or something similar for defining further custom ores. I'm split on this, however, since ore definitions would then be split into two different places, and I'm not sure I like that. I'm thinking that I'll probably end up using a custom config system, since that seems like it's the cleanest solution. It will allow all of the ores, predefined by me or added by the user, to be in the same place, while not messing with stuff too much. I will also think about breaking the config up into a definition file and a customization file, simply to allow a user to have a simple way of customizing how much a specific ore drops while not having to go through the technical details of how the ores are defined. Anyway, thanks a lot for your input, it was very helpful! I know that's intentional, that's why I was looking for a way to register block variants (BlockStates) based on the config. That, however, also seems impossible if you don't know how many there are going to be.

Thanks for the input, but the problem is not generating the blocks once I know which ores I have to generate them for. This "density" concept is a nice idea, but not what I had planned for the mod. I had only imagined one "dense" variant, not multiple levels. The problem here is the "For each ore" part - because I don't know what ores there are (until the config is loaded). I can't just hardcode all the possible blocks so they're always there because I want the user (or a modpack maker) to be able to add their own ores to the config file. This means that I do not know how many blocks I'll have to register before the configs are loaded - the user could have specified 300 new ore blocks in the config file that I would have to deal with. Another solution could be to register a stupid amount of ore blocks, like 2000 or so, in the hopes that that's always going to be enough, and then only use as many as needed. However, that solution, in my opinion, would be even worse than the two I suggested earlier.

Thanks for the reply! The mod is supposed to add special versions of ores that drop more resources. So you could have a "Compact Coal Ore" or a "Compact Iron Ore". I have made and released a 1.14 version of the mod here if you're curious. It used the first workaround with loading the configs manually and earlier. I'm just trying to find out if there's a better way to do it. In the config file, there would be a list of ore definitions. These specify the base ore block as well as some additional properties. By properties I mean net.minecraft.state.Property, the thing that you attach to the block in fillStateContainer. That you manipulate with the debug stick. The mod is intended directly for users (I want to have a default config that supports popular other mods) I already attempted various methods of implementation for 1.15 a few months ago, you can find them in this branch.

I am creating a mod that adds a generic block type. Each of the instances of that block type is supposed to be able to inherit properties from any other block in the game. These other blocks that my blocks inherit from are defined in the configuration file of the mod. I did some research on how to do this and have already asked a similar question here before. Back then I was told that I should do it a specific way, but after some research I concluded that that's not really possible (at least if you want to do it properly). The gist of the problem is: I need a way to define the variants of a block after configs are loaded. I do not know which or even how many variants are going to exist before config loading. This is what I know this far: I can not register separate blocks for each variant because the registry events happen before the config is loaded. I could use a tile entity though. However, only very few of the methods in Block have a World and a BlockPos in their parameters, which means I can't access the tile entity from those methods (but I would have to). I could use block properties (blockstates) to map the block to the tile entity. However, the block property must be defined by the time the block is initialized, which is during the registry event, so I have the same problem as with the separate blocks again. I have found two (bad) workarounds: Don't use Forge's config system to load the configs, load it manually at an earlier stage instead. This would allow me to use either of the two methods above. Using the second method, initialize the block with "fake" blockstates and then entirely replace its StateContainer when the configs are loaded. Because the StateContainer is a final field, I would also have to re-implement all methods that access it. This could lead to various problems in the future, but I could use Forge's config system. None of these workarounds are pretty solutions. If there is a way to properly implement this, I would really appreciate finding out how. Otherwise, I would probably use the first workaround since it seems like the cleaner solution. Thanks for reading this wall of text and for suggesting your ideas DoubleNegation

I'm sorry, I will I just wanted the first release of my mod to be as simple as possible, so I don't abandon it half-way through like everything else I make.... I promise I will do stuff properly now. Now that the mod publicly exists, there's a reason for me to not just stop developing it, so I can afford to follow the rules now. I know that that's not a good strategy to go through life by, but I've had way too many abandoned projects over the years and I wanted to have at least something for once. Please excuse my improper behavior.

I used nightconfig directly to read the config, because it didn't seem to me as if the forge config api let me structure the file as I wanted to, and I didn't bother looking to closely for that exact reason you mentioned. I'm going to have a lot of restructuring to do...

Well, I know I can, because I already did it, but if I'm not supposed to, that's fine as well, I'll go with the TileEntity then. Thank you!

I'm currently looking into updating my mod from 1.14 to 1.15. When I created it for 1.14 I just wanted the mod to be as simple as possible to get it to work at all. Now that I'm updating to 1.15 I'm reconsidering some of the decisions I made in the 1.14 version. I'm mainly very unsure about the proper way to implement the blocks which can be defined by the user in a configuration file. This ability to define new blocks via configuration is essential to the concept of the mod and can not be avoided. There is no good way for me to register all possible blocks because a new block can be defined for every other block that exists, which means that this would double the size of the block registry for only a handful of new blocks. (Also I'd need to know which blocks are going to be registered before the registry event is fired) As far as I can tell, there are two different approaches on how this could be done: Approach 1: Register each block that is defined in the configuration as its own block. This is what I did in the 1.14 version, and it works just fine. However, I have read that registering things based on a configuration file is not recommended and that all things should be registered, and then disabled based on the configuration file (which isn't possible in my case). Approach 2: Register a single TileEntity that stores information about which block it's supposed to be in its NBT data. I haven't tried to implement this option yet, but it seems like it would be possible. However, I'm worried that this method would not only make the mod more complex and incompatible with other mods than it needs to be, but I also don't know whether there would be a negative performance impact from having these TileEntities generated all around the world (possibly dozens per chunk). Which of these approaches should I use? Or is there an entirely different way to do this? Btw the mod is https://www.curseforge.com/minecraft/mc-mods/compact-ores