[1.15.2] Config-defined block variants

[DoubleNegation]

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

[Cyborgmas]

Could you explain a bit more what you mean by properties? Like the actually code defined Block#Properties? Also, if any of those blocks are tile entities your block will as well need to be a tile entity (pretty sure).

 

How would your config system define the blocks ? Are you trying to make it so that anyone could mix together any number of blocks any number of times? (Have 1 wood-brick block and at the same time a gold-wool block?

 

Also what purpose will your mod serve? Is it for modpack creators or for direct users?

[DoubleNegation]

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.

[Cyborgmas]

Okay so thought your block was much more generic, I think there's a way to make it work then.

Only certain blocks can be modified: ores.

For each ore you generate different textures (haven't looked at how you do it specifically) but those textures are in a fix amount right? If you were to have 5 compacting levels per ore, you could pre generate each of the 5 blocks per ore.

 

Those blocks would have an identical loot table with which you could add a function like density. The value for density would be taken from the config file (mimic a fortune modifier maybe?). 

 

That way all blocks are already generated before config kicks in. Not sure if this is what you want, as they wouldn't be blockstates. You would also need to check if another mod is loaded before generating your own ores that depend on other mods. 

If you want even more config possibilities you could have 10 compact blocks per ore and have some not be included in ore gen depending on configs.

If you think that creating all those blocks would be a waste/not the best way, think about chisel that creates about 10 blocks per block and you only do that on ores, so won't be that much.

[DoubleNegation]

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.

[Cyborgmas]

Yeah so my idea does include to limit the possible configs. Since you can't register blocks from a config file, you have to register a specific amount. This also means you must have an addon per mod that add ores. 

 

It will indeed limit a lot the possible configs for a direct user. However, you could try and integrate an api for modpack creators that could then more precisely define and configure the details of your ores. 

 

I have been managing a mod with a lot of config options for the last 2 & 1/2 months and I feel that having easy configs is much better than having tons of config for direct users. In that mindset, limiting the possibilities of your config could improve user experience: having a config that is just changing 5 numbers and boom gold is super dense, coal less, iron and diamond medium and then they can play.

 

(Reread what you said and not sure I understand what you mean by the density variant isn't the only thing you wanted? Also for the density levels, my bad thought that you were drawing multiple blocks per ore blocks...)

 

Of course this is your mod not mine so if you really want mass configurability it doesn't seem to be possible purely using forge's config system. They also will not add any support for something like this since the "policy" is to always register everything, meaning it shouldn't depend on configs.

 

 

[Draco18s]

FYI, blocks and items are registered before configuration events are fired. This is intentional.

Edited March 16, 2020 by Draco18s

[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!

 

12 minutes ago, Draco18s said:

FYI, blocks and items are be registered before configuration events are fired. This is intentional.

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.