Leaderboard

Oh wait. You have to call setRequiresTool or func_235861_h_ in your block properties depending on your mapping version.

No. The only way to write an abstraction layer that would be able to determine which method to call (eg. if its signature changed in any way) without crashing would be reflection. And using reflection on every point your code touches Forge or Vanilla would bog the JVM down to uselessness. That's why major versions exist.

Hahahaha no. The underlying code that your mod operates on has changed.

world.isRemote can't help with that. Specifically.

Just a heads up, it probably took so long because you included some folders that were not necessary for a buildable repo. You do not need: .gradle folder .idea folder build folder

Do you know what time it is? IT'S CORE MODDING TIME! *screeches hysterically* </hysteria> (I spend like 14 hours on this what am I doing with my life) So yeah, that's what you have to do to detect block changes client-side. I won't go into details since the devs appear to be somewhat hostile towards anything to do with coremods, short of outright banning them. In my case, I hooked my own custom event into the network manager and checked for SChangeBlockPacket s and SMultiBlockChangePacket s. But yeah, as far as vanilla Forge goes, this is impossible. Note that there *are* events for when the player breaks/places blocks though, so if that's all you need then you can use those. It's just if you need to know when other things move blocks (pistons, falling blocks, etc.) that you need to break into the core. OR, you could bite the bullet and send your own packets from the server. That would probably have been much much easier. And more efficient. But. I like this.

Try add your mod id to the name, something like MODID + ":blue_stone"