Draco18s

Biomes are in the registry the same way blocks are in their registry.

You either: a) need to set a block state (make sure to override shouldRefresh in your TE to return false if the block remains the same). b) need to override getActualState in order to get the state property from TE data.

Imagine four cables placed into a square: # 1 2 3 4 Where the # is some producer. The producer pushes to 1, 1 pushes to 2, 2 pushes to 3, and 3 pushes to 1. Infinite loop (well, not necessarily, unless the power producer is removed and there's less total energy than what 4 cables can "hold"). On the other hand if a pull system is used, each of these cables will check all of their neighbors to see if their neighbors have more power than they do, if that neighbor does, extract it, and fill self. If none do, then the state of the system doesn't change.

Items don't have metadata. As you are on the client you can call getSubItems safely and literate over the returned last of ItemStacks and get their metadata.

In case 2, you should do it as a pull not a push. It is really hard to create infinite loops of "pull from upstream" compared to trying to determine which direction is downstream.

Uh. Your counter exists in two logical sides, too...

Oh look. That thing.

Resources must be all lower case, files and code references.

You mean a compiled jar file? You don't.

Also, 1.7.10 is no longer supported here.

There are three methods in the block class you need to override: Render type, is full cube, and is opaque cube

stack.getItem() == item

This is because player input is handled client side and updates the server with the new position only.

> Its not working > No code > No log / error messages And...you expect us to just read your mind?

Or...just not expose the capability on that side.

You're in the wrong place for 2 reasons: 1) this board is for mod developers, not mod users 2) This forum no longer supports 1.7.10

Those are IInventory methods. You don't need them. The IItemHandler handles that. You return a different handler based on the side accessed in getCapability

You subclass SlotItemHandler. For example, one of these two: https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/hardlib/api/internal/inventory Note that SlotOutput will not allow any item to be inserted what so ever while OutputItemStackHandler is a wrapper around another handler that prevents input through the wrapper.

From the javadoc on the method itself

Null sides are essentially for "internal" use. Such as a block being broken being able to drop all of its contained items

That's funny.

You mean the non-static method just above it that invokes the static one? addCollisionBoxToList?

You can't override static methods.

You can only do that for items that you control.

There are circumstances where casting null is necessary. Such as when two methods have other wise ambiguous signatures, casting the null makes it unique.