Draco18s

Yes, I agree. But even so I still see people doing this wrong. Like I said, I've seen people pass their item reference to their block (heck I once saw someone do both: item ref to the block and the block ref to the item!). Literally every time I see a thread with the word "crop" or "seeds" in the title I know what the problem is, and it's this problem. The registry events have (somehow) not made this common issue go away.

This issue is only ever a problem "when someone is creating crops" (90%+). Usually it's someone passing an item to a block constructor, but only about 60-40. I'd write it as... "Do not pass items to block constructors, if passing blocks to items, insure blocks are initialized first. This is a very common issue when making crops and seeds. Use the debugger to verify your references are not null." Or "When passing block and item references to constructors, insure correct order of operations. Use the debugger to verify your references are not null. Blocks should be initialized before items."

@diesieben07 We should have this problem in the common problems list. I vaguely recall trying to ping you about it before.

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.