Draco18s

mc.isGamePaused() public Minecraft mc; #NeverAssigned

Step 1: Loop through all crucibles in range, build a HashMap of the total amounts of every SoulType available in range. Step 2: Check the recipe against this hashmap. If enough, recipe allowed, otherwise it isn't. Step 3: Create a hashmap for the SoulTypes being consumed by the recipe and loop through each crucible in range and deduct as many Soul amounts as possible (keeping track in this hashmap copy) until all souls consumed have been deducted from somewhere.

You need to do this in the Entity, not the Model.

I'm pretty sure the farmland-block needs to cooperate as well. Which the diamond block doesn't know anything about crops, so the calls made to allow planting fail.

setAccessible()

Show ModItems.registerItems();

Not to mention smelting!

What I meant was that you said that "A -> B" means that B relies on A (that is, A is the parent mod) and then went on to say that "generic|machinery -> generic." i.e. you incorrectly stated that generic|machinery and generic|world were the parent mod.

I typed that and had the sneaking suspicion that I may have added too many zeros. The last time I futzed around with it (needing a full-cube block that was collidable from all sides) was in 1.6.4

0.125 is a fairly substantial amount: 2 pixels! If you want something that looks like a full block you can have an offset amount of 0.0001 which IIRC is sufficient for collisions, but small enough that after being rendered you can't tell.

Oh god, ew. This isn't that hard to math. (x + y * 9) * 4 + n where n is 0,1,2,3 depending on which of those four slots. Also. All of those slots are added to the same XY coordinates so they'd stack on top of each other and only the top 4 will be usable. It also appears that your TE only has 45 slots and you're creating 84 slots.

Note that the block boundary must be smaller than 1x1x1 in the direction you wish for collisions to occur in.

One of these three things is incorrect.

Unless you have a reason not to make them match, you should refactor to make them match, it simplifies a lot. And even if you don't there's still no reason to make a request to the TE: you can do your entire current check inside the block and only the block.

Question: Why does your canConnectRedstone method ask your TileEntity if it can, when all the TE does is ask for block metadata? Why not just check the block metadata? return side == metadata

Some bit in or about there, yes.

That's because handleMouseInput shouldn't be drawing anything. You need to get the mouse's coordinates in drawScreen and if those coordinates are correct, draw the tooltip.

Jesus mother fucking Christ in a hand basket to Hell this is a complicated network system. And on top of that, a complicated GUI setup. AFAICT your problem lies here somewhere: https://github.com/p455w0rd/WirelessCraftingTerminal/blob/master/src/java/net/p455w0rd/wirelesscraftingterminal/common/container/ContainerWirelessCraftingTerminal.java#L216-L230 But I can't tell because of the giant interconnected web of dependencies.

entityLocal.getEntityData(); is functionally identical to entityLocal.writeToNBT(tag); for this, but definitely cleaner. I forget that getEntityData() exists.

Because places like Curse can't read your @Mod annotation, but they CAN read your mcmod.info file.

Just fyi, that's not a recipe, that's a structure. Recipes use itemstacks. I don't know about structures.

Define "access." If you want to look at it, like Lex said, then open up the Forge-src jar in the project hierarchy and browse down to net -> minecraft -> blocks -> BlockSoulSand.java

Inside the gradle file. Just pick a spot that isn't inside some other block. Done. How do I know? Because one of those lines says "task" and there's already at least one "task" block in the gradle file already.

I can't find where you actually handle the packet. You send the PacketOpenWirelessTerm to the server and it gets picked up...where?