Draco18s

You have to wait for ticks. Doing it inside the function (as a loop or individual actions) makes it happen instantaneously. Because that's how code works.

Update.

Its not. Its because metadata was limited to 16 values (4 bits) and relied on Magic Numbers. Blockstates are contextual. But blocks, in order to handle their functionality, need to know what their own state is. So the state needs to be passed in (just like how metadata was passed in). The "problem" is that one shouldn't be interacting with the block directly when querying the state of the world, as then you lose that contextual information. You don't want to know what the voxel shape of a block is, you want to know what the voxel shape of a blockstate is.

And a docs page (currently up for PR) https://github.com/Draco18s/Documentation/blob/1.15.x/docs/items/globallootmodifiers.md

Its because calling the deprecated version looks like this: world.getBlockState(pos).getBlock().getShape(world.getBlockState(pos),pos) Notice how getBlockState is called twice? Now, this is how you call the BlockState version: world.getBlockState(pos).getShape(pos)

What version of Minecraft?

Mojang marked them as deprecated. Deprecated means "do not call this function." They aren't deprecated in the BlockState class because you're supposed to call the methods in the blockstate class. I'm sure if you searched the forums you'd find a dozen threads about this. Its been like this since IBlockState was introduced (1.10ish) No. I'm not sure what you're trying to do, but no. That would be Wrong.

1.8 hasn't been supported for over 2 years. Update if you want support.

Listen for the BlockBreak event. Cancel it. event.setCanceled(true)

Events don't break blocks. The BlockBreakEvent is simply a notification that the block has been broken. You have to remove/break the adjacent blocks yourself (fire the event for each one, if it was cancelled, don't actually remove the block, be sure to avoid recursion!)

Figure out what the other mod does. Minecraft does not have a global concept of "gravity." Instead each entity type handles its own gravity (and rendering!) separately.

Line 111 is: return ForgeRegistries.LOOT_MODIFIER_SERIALIZERS.getValue(location).read(location, object, ailootcondition); So it looks like your serializer isn't getting registered correctly. I can't tell why.

1.7.10 hasn't been supported here for 2 years. Update.

You may have to tag the stacks with a global loot modifier in some manner.

The event has an entity, you already know how to check if it is an ItemEntity ItemEntity#getItem()

Check the itemstack in the entity's item.

In order to do that you need to wait at a minimum until the item entity exists and has joined the world. The earliest point you can be sure that that has happened is EntityJoinWorldEvent. Just check that the entity is an ItemEntity.

EntityJoinWorldEvent

Well. Yes. Because that's what that event is for. You use either a deferred register or the appropriate event. Also: // SET THE BLOCKS IN THE TNT PROPERTIES ...do that when you construct the block...seriously. You have a perfectly good place to do this already: https://github.com/alessio1309/GhostsExplosives/blob/cd50068d6c3d5a213df7e7c8791b2b3d69470ffc/scr/main/java/mod/ghostgaming/ghostsexplosives2/init/ModBlocks.java#L73

This may be under the issue of "recipes replaced by Forge always win." https://github.com/MinecraftForge/MinecraftForge/issues/6287

Update.

Might help if you actually USED your block class.

Note, if you use that json file, explosions may not treat your block correctly.

Yes you do, because items don't know what their block is by registry name, but by being passed the instance in their constructor.

You need an item form of your block. Blocks only exist in the world.