Change gas world generation to use ore dictionary "stone"

[Kittychanley]

Would it be possible to change the hardcoded references to Block.stone to instead work with any blocks using the "stone" ore dictionary entry? Because it's a hardcoded reference to the vanilla block, the gases won't generate in worlds where vanilla stone is sparse, or missing entirely like in TerraFirmaCraft.

[Trent VanSlyke]

It should be. I'm looking into it now, should be a simple fix.

[Erlend Åmdal]

With the way the the melting stone currently works, the graphics are a transition from vanilla stone to lava. The system would have to be changed to some kind of wrapper block that can do the transition as a tile entity.

[Kittychanley]

I'm just asking about compatibility for world gen. I'd be ok if the other functionality like melting is still hardcoded to vanilla stone.

[Erlend Åmdal]

Of course. We can't promise any quick fixes regarding this due to more important matters in the backlog regarding the Gases Framework.

[Erlend Åmdal]

At the same time, with additional stone types added in vanilla, this issue is relevant without mod compatibility in mind. I will change the title accordingly. I suppose some other blocks should have reactions to the implied extreme temperatures caused by Iocalfaeus Gas.

[Erlend Åmdal]

I just realised I screwed that up, didn't read it properly. World generation. Oops. I'll make a separate issue for that.

[Erlend Åmdal]

I've had a look at this, but it seems there is no problem on our end for world generation with the way it is intended to work. isReplaceableOreGen must return true for stone-like blocks. If I recall correctly, this is also how vanilla ore gen determines its placement.

[Kittychanley]

No it doesn't. isReplaceableOreGen just does return this == target; It's not doing any sort of ore dictionary checking.

The line:

if(world.getBlock(x, y, z).isReplaceableOreGen(world, x, y, z, replacedBlock))

is literally the exact same thing as doing

if (world.getBlock(x,y,z) == replacedBlock)

And you have replacedBlock hardcoded as Blocks.stone

[Trent VanSlyke]

I addressed a similar issue in commit 4db2b88. I'll take a look shortly.

[Erlend Åmdal]

After taking a second look, I can see it's difficult to trust isReplaceableOreGen. It seems many mods are relying on it by using WorldGenMinable, even Tinkers' Construct. Thermal Expansion/Foundation also use the isReplaceableOreGen method through CoFHLib.

While we can and will add support for ore dictionary stone, I suggest that you override the isReplaceableOreGen method in your stone block class(es) and let it be truthy when the world generator feature is looking for vanilla stone.

[Kittychanley]

We actually can't do that as we have our own generator for ore veins, and don't want vanilla ore blocks generating in the world, which is exactly what would happen if we overrode the method in our stone block class. We already have alternative support in which the player can use our config files to get ore blocks from other mods generating in our worlds, and in the same style as our massive ore veins. I just brought the issue up specifically for this mod because while players could use the config to get the gas blocks generating, it wouldn't really be balanced to have a gas pocket that's spanning multiple chunks and has hundreds of blocks in it.

[Erlend Åmdal]

3fd3028