• MC Version: 1.11.2
• C&B Version: 13.0.78
• Do You have Optifine: No

Blocks that override getBlockHardness do not have the proper hardness when chiselled since BlockBitInfo uses the value of blk.blockHardness inside createFromState instead of the state-sensitive getBlockHardness.
The same applies for blk.blockResistance and getExplosionResistance.

In addition, the else block inside createFromState, instead of setting the hardness to that of the final Block stone, accidentally uses blk.blockHardness and blk.blockResistance instead of stone.blockHardness and stone.blockResistance or the state-sensitive methods.

Perhaps to reduce instability you could use the world sensitive version only if blk.hasTileEntity(state) is false? Maybe with a config option for those who are certain that enough blocks in their modpack don't have those issues or have checks to handle it.

I don't really know to what extent changes to these classes would affect stability and performance though as I have not looked into much else in this mod code-wise. If the instability is related to the Tile Entity not being the one that was expected to be at the position I would like to think that mods' blocks that do refer to Tile Entities in those methods would have some sort of checks in their implementation to make sure the Tile Entity at the position is actually of the type that they expected and have some default value in the case that it isn't.

If that's not what you mean by instability, I apologize. Please elaborate your meaning if you can.

I intentionally avoided using the world sensitive version of getBlockHardness because many blocks that use it refer to tile entities.

This could potentially cause instability, so I opted to simply "cheat" and fall back on a default.

You are correct however that I goofed the fallback, it should be using the stone values instead, that could potentially cause some bad results with certain blocks that have strange values.

That would help, but there are still potential other cases.. The idea is to simply reduce the chances of issues caused by other mod code.

I might be over thinking it, but hardness tends to be a non-issue in most re-guards. If something acts like stone, most people won't really mind, or worry about it.

There's a number of cases where blocks might act usually, based on other things, blocks that check for other blocks around them, blocks that try to find electrical systems.

All sorts of things.

But the main reason to not use the world sensitive version. Is that it requires "world wrapping" ( Note that the method takes "World" and not "IBlockAccess" this is very important, since World is one of the most complicated classes in the entire game. And one that I whole hardheartedly would rather not touch.