Draco18s

You need to GET the type FROM the EVENT and COMPARE it to a single type. What you did is ADD a function that you don't need, does nothing, and isn't even called.

The fuck is this shit? This isn't what V0idWa1k3r told you to do at all.

No one thought about CustomMeshDefinitions? Property overrides only work for number values. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L80

My guess is that your metaToState and stateToMeta functions are not correct.

1.7.10 is no longer supported here.

Also: subtracting 1 does not neccessarily return the block the player is standing on (e.g. carpet, pressure plates, half slabs, enter frames, etc). In fact, such an operation is the source of a long-standing vanilla bug.

Multiplying works out the same. Its dividing that causes problems. (You should still bitshift)

Try not registering null items.

Casting.

That's called "support."

https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

1.7.10 is no longer supported here. But the reason this probably doesn't work is because the client needs the recipe too.

The Capabilities systems are supplied by Forge. They're an advancement on IEntityExtendedStorage (among other things)

Capabilities. You create one, apply it to the entity when it is spawned, then in the EntityDeathEvent you check to see if that capability is there, and if so, do something.

That's probably almost exactly why.

Just because it worked for one person does not mean that it's: a) a good idea b) going to work for you (Thinking otherwise is called Survivorship Bias)

I haven't seen one... Also, the 43 states include the corners (so diagonal connections or lack of connection) which may or may not be important for your usage. In any case, what it's going to come down to is that you will need to construct an Actual State (regular state: metadata, actual state: includes other world information, extended state: client only variable data, used for fluids mostly) that includes the connected/not-connected status of each adjacent block. You'll then have to create a blockstate JSON with each possible result and supply a model (or model changes) based on which state(s) it represents. This will be the hard part. It may be easiest to treat each "face" of the block as its own model (so like the fence) and use the different adjacency information to change which model is used for each side.

It's called "connected texture" and yes, its possible. It's just bloody complicated. There are 43 possible variations needed.

I edited my post because I was a little too hasty. The important bit is the bit I was trying to call out:

That's a reference type. Also, you changed the reference inside the method, rather than changing its properties. Try this: class Main { void bar() { float a = 1f; this.baz(a); System.out.println(a); } void baz(float a) { a = } It'll print 1, not 5. Which is why the code I quoted doesn't work. You need to change the event's properties.

No it doesn't, because you never applied the value back to the event. float damage = event.getAmount(); copies the value because float is a primitive type, not a reference type.

Stop using optifine. They do things that are borderline incompatible with forge.

The event's fields would change, duh.

It'll operate on strings, obviously. "Oh no can't find modid:someblock".

You will also need an IIngredient class to define your axe ingredient.