I'm reporting this here first because RFTools is the only mod (That I am aware of) reacting with chisel and bits this way.

The startup logs for minecraft contain ~400 lines similar to this one:
[22:45:59] [Client thread/INFO] [chiselsandbits/]: Unable to determine blocks eligibility for chiseling, mcjty.rftools.blocks.spawner.MatterBeamerBlock attempted to load mcjty/theoneprobe/api/ProbeMode

Blocks mentioned in this manner are: BoosterBlock, ElevatorBlock, GenericBlock, EnderMonitorBlock,
EndergenicBlock, BlockProtectorBlock, MatterBeamerBlock, SpawnerBlock, EnvirenmentalControllerBlock, PowerCellBlock, BuilderBlock, SpaceChamberControllerBlock, SensorBlock, InvCheckerBlock, RedstoneRecieverBlock, RedstoneTransmitterBlock, CounterBlock, SequencerBlock, ScreenBlock, SimpleDialerBlock, MatterTransmitterBlock, MatterRecieverBlock, ModulerStorageBlock, & CoalGeneratorBlock.

I don't know if this is important or not, but I thought I would report this.

Referring to ChiselsAndBits/Chisels-and-Bits#80

C&B is having an issue accessing the Block with reflection because its trying to load a class that doesn't exist, If a method contains a reference to a class which isn't available it should be marked with the appropriate @optional or @clientside.

That said I don't think these should be chiseled because they are TE's and they can probably be ignored earlier in the checking process then they are now, which is causing the logging.

I avoid @optional due to a bug with @optional in combination with generics which are used heavily by my blocks. This was something cpw and I found out. I'm not 100% sure it is fixed right now.

Turns out I can't just ignore those blocks because they have a TileEntity, because I have an API that can ignore them... but I can't confirm that the API isn't used unless I can get the reflected class.

I guess we just ignore the log items then?

You also reported this on the Chisel & Bits tracker?

Not yet, I thought I would report it once and then report it to chisel and bits if you said it was an error on that end.

Hard to say. I have no idea what they are doing with my blocks so I guess it needs feedback on both sides

I'll report it there too then

I asked CPW about the @optional thing, he said it should be fixed, so should be fine to use?

I don't want to fix this really as I prefer to avoid @optional as much as possible. I've had too many issues with it in the past

Any progress on this? We're still seeing the log spam on 1.12.1. Thanks.