Draco18s

And you still don't.

Store the world time of the time you want the condition to end. When the entity is struck by lightning, check to see if that time is in the future, or the past.

https://lmgtfy.app/?q=java+%40override+annotation

What. Just register your events in your mod constructor or use the class annotation.

Look at line 20 very carefully. Think about what D7 said in his first reply.

Line 20 is wrong.

You know you could just do the second if statement, right? Think about it. If the second one is true, the first one MUST be true. The vanilla code is then wrapped in an if-else that checks for flint and steel or fire charges, and a final else-return-super. If the catch-fire portion ("from here on its vanilla code") is the code from the TNT block (your super) you could just call super...

What. Gross. First off, you could just loop ax = -1; ax <= 1 (same for y and z) and then use BlockPos.add(ax, ay, az) Or you could use the static method in the BlockPos class to get all blocks in range and iterate over the resulting collection (the MCP name was getAllInBox). Older code, but example of the latter: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/EventHandlers.java#L121

You can't if you're on the client. That's why packets exist and why OpenGui does what it does. You can only interact with the data the client knows about and OpenGui will send the inventory contents to the client (including all of the lore, because how else would you be able to see it?)

No. It can link to any asset. Loot tables, block states, models... In theory yes, in practice no. There are no existing vanilla assets that are of this type, so they aren't supported. In theory you could make them be supported, but it would take a lot of work messing around with the internals.

None of them. Resource paths are interpreted, not hard coded. It's formed via concatenation of $domain + ":" + $block_registry_name and later is it parsed to locate the actual file. ALL assets are referenced this way.

Yes. There are functions for that. Look at the shulker box.

You probably want a TileEntity.

Only ran into it recently, but it was so good. Another classic.

The email that only goes 500 miles.

It's almost like you didn't wait for the packet to go anywhere and get data back before you tried to query it...

Its probably still possible, but animated stuff is not something I've ever messed with. Vanilla chests still work however they work, which might be worth seeing how it is coded. I know the TE Animation Forge thing...exists, but I don't know that it is complete or documented.

One exists from the more recent 1.16 names to 1.17 via the bot on the Forge discord server. But oh boy, you're coming from 1.7 You may as well throw everything you have in the trash and start from scratch as if you never modded before, relearning all the basics.

Specifically which version are you wanting to go back to? And honestly, run the setup for it and see what happens.

Yes. As evidenced by the fact that MISC != MATERIALS

I use different workspaces for each version of Forge. Re-running setup might not be sufficient, as the server resources have moved a couple of times, so the old setup files might not be downloading from the right URL.

Put the correctly named loot table in the correct folder. In this case the reason your attempts didn't work was because you put the loot table in {your_mod_id} directory not the {minecraft} directory. You have to make your chest block return the correct Resource Location. Look at the vanilla chest for examples.

You still need to reference the loot table somewhere in your code. Blocks are automatically linked to a loot table with the correct name, but chest and chest contents are special and need to be explicitly mention where to find their loot table.

ItemFrames aren't blocks, they're entities, so you'll never see it with GetBlockState.

Still don't know why anyone would assume that an Axis Aligned bounding box could be anything other than aligned to axis.