Draco18s

Oh I agree. Just that some new folks don't know that and seem to think that because the code is in the same file it's fair game to dip things that won't work. Like making the message and message handler the same class...

Eg https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java That class is set up to only allow extraction, not insertion, but the methodology is the same. I recommend this because it us a wrapper around another handler that CAN have things inserted into it (eg by the machine's own logic) but which isn't exposed directly.

While true, I recommend against it due to the potential to confuse the scope ("my packet handler runs, but it doesn't recieve the data, but I know I'm sending it!") as the modder tried to reference the packet data not from the object passed, but through container scope, even through the objects were different instances. Keeping them in separate files helps the fledgling modder. I use nested classes for things like data wrappers, where I need to bundle two items together for a sorting function, or similar, but that that wrapper is never used outside that scope.

What're you, 12?

No, that would also be wrong. ITileEntityProvider is also out of date (look, it even still uses metadata) Override the createTileEntity() and hasTileEntity() from the Block class

You still shouldn't use BlockContainer. It's old and out of date and does a bunch of garbage (like overriding the render type) that you don't want.

oh no. ten dollars. whatever shall you do. Seriously. https://www.amazon.com/UGREEN-Ethernet-Adapter-Nintendo-Chromebook/dp/B00MYT481C/ref=sr_1_4 also, start using MB notation rather than GB in your decompile command. 1G will be too little and 2G your computer can't supply. You need to drop down and get finer grained. I did it once, you can too.

It's called exactly once. Once for each hand

1) you implement those methods 2) you call these when the data changes

Multiple instances or multiple types? Am interface is just an object which says "this method exists" and then every class that inherits that interface MUST provide an implementation.

EntityJoinedWorldEvent probably

Block#getDrops() getItemDropped() specifically returns only an item which would have to be combined with getDamageDropped() or whatever it's been renamed to.

Same way you register any other item model.

Likely whatever feature your about to ask for is already possible. You can combine ItemHandlers already, so you'd just spilt them up and combine them as needed. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L143

Also your code is a mess. There's a half dozen or more variable with names like xxx1, xxx2, xx3, etc. Not to mention constructing facing enums from their index, which is SUPER meaningless.

world.getTileEntity(pos)?

You can't do server things from the client.

If you're transferring power then yes, you'd need a TE to store the power in.

https://github.com/Jigokusaru/MegaMoney/blob/master/main/java/com/jigokusaru/jmmm/JMMM.java#L35-L36 You initialize your items before your blocks, so ModBlocks.vendingmachine is null.

BlockPos.getAllInBox(from, to)

I don't see anything wrong, so you're probably going to have to debug this yourself.

So what's the problem?

1) Do not use ITileEntityProvider, override the methods found in the Block class. ITileEntityProvider is old and is based on metadata, not IBlockstate 2) You need to mark dirty in the case if (FUEL_AMOUNT <= 0) { } as well.