Draco18s

For what it's worth, I'd store the facing in the block metadata and store "the other data" in the TE. In either case, you're going to want to handle figuring out how setBlockState(state.withProperty(FACING, val)) is going to work. Some mods add a wrench (or other tool) that rotates blocks with the FACING property and you will mostly likely want to support that.

Correct

Packets.

The "data" parameter refers to metadata. This is so that a hammer of any damage amount can be used. If you want multiple hammers, then you need to register them all with the Ore Dictionary.

Please use the code tag:

I must have been thinking of something else.

No. That's not a thing. You need to sync your configs.

iT makeS youR postS neaR impossiblE tO reaD. herE, i'lL dO thE lasT letteR. iT iS noT betteR, it'S wronG anD noT propeR englisH.

Code and spoiler tags. Use them.

Create your own enum.

You either need a custom state mapper to ignore the property or you need to include all of the level variants in your blockstate file. Just because the value "is always 0" as far as your code is concerned, doesn't mean that the model bakery knows this. It was given a "level" property with 16 values, but you didn't tell the bakery (via a statemapper or blockstate file) what to do with those 16 values.

Done. If you still have a problem, what is the problem?

I can wait.

I don't know, you haven't told me what the problem is.

I said "this line of code is identical" not "this will fix your problem." That said, if you get a field not found exception, you have the wrong field name. Are you sure that that is the only entry for "biomeName"?

But you got the UUID from a player object, and then did nothing with the UUID what so ever.

ReflectionHelper.findField(Biome.class, "biomeName", "field_185412_a" ); is sufficient

And then you do nothing with this. What was the point?

It is used for weighed loot probabilities. e.g. fishing, dungeon chests, etc.

1.12 already does this. /gamerule doLimitedCrafting

All this does it prevent you from assigning a value to it (which, if we're being honest, is something you shouldn't be doing anyway). You can still modify the event's properties through the setter methods, which is an ability you want to have. As far as I'm concerned this suggestion is just adding a sticky note to the breaker box that says "do not repair." No one was going to be repairing it anyway, but we're absolutely going to go in and fiddle with the switches.

Define "doesn't work"

"Translate" is one word, the L does not need to be camel-cased.