Draco18s

#1 your formatting in a couple of places is awful. #2 you do not need a getter method for your static property #3 why are you using an integer to represent direction? Why not use BlockDirectional.FACING? #4 why are you setting the block twice? world.setBlockState(posNumber, ModBlocks.orangegoo.getDefaultState()); world.setBlockState(posNumber, state.withProperty(SDIR, direction), 6); You should only need the second line, but why are you using flags 2,4 and not 1,2? #5 your updateTick method is garbage. EnumFacing.values and pos.offset(facing) exist, not to mention EnumFacing#getOpposite().

You don't need to override the setDefaultState method, you just need to invoke it (which you're already doing).

Put a breakpoint on the canSmeltOn method, and step through line by line to figure out why it's not getting a result.

Hmm. You might have to step through in the debugger.

Use IItemHandler fields and getCapabilities

Oh, by the way. Be aware of the BlockEvent.CropGrowEvent and its two sub events. You should fire these at the appropriate times if you are not using subclassing a class that does, or not calling super.updateTick(). Look at BlockCrops, Reeds, Cactus, Netherwart, CocoPods, and a couple others for examples of useage.

Hmm, thought one of your other threads was....never mind

Your structure is 3 blocks by 3 blocks, there's no....room to shift things about.

You realize that all bounding boxes in Minecraft are cuboid, right?

Do you mean models > block? Depends on which tiddly wink you actually want. He said "texture" in the thread title, I pointed towards the texture folder.

Post your ItemUtil.areItemsEqual method.

Referenced Libraries > forge[...].jar > assets > minecraft > textures > blocks

Use multiple blocks

One of his other threads is about is.

You never register your mob on the server. Also, do not use registerGlobalEntityID, you do not need it. There's a reason registerModEntity exists.

BlockCrops and BlockReeds both use integers. By the way, be aware of the BlockEvent.CropGrowEvent and its two sub events. You should fire these at the appropriate times if you are not using subclassing a class that does, or not calling super.updateTick(). Look at BlockCrops, Reeds, Cactus, Netherwart, CocoPods, and a couple others for examples of useage.

Yes

My guess is: public boolean isUseableByPlayer(EntityPlayer player) { return false; } Try returning true.

Show your InventoryResult class.

[me=Draco18s]starts writing the packet info to handle the data transmission only...[/me] Aw fuck. The filter rules can change while the inventory is open (that is how one alters them). Which means that what items are valid for the standard inventory slots also changes. There's no easy way to find all possible rule TileEntities and check every item against all of those TEs for insertion from every side. Complexity comes out to... something in the neighborhood of O(kn2) where k is 3 times a subset of n (does that make it O(n2logn) ?). Heck the packet itself could contain upwards of 5kb(?) worth of data too. Each item would need to be paired with a minimum of 3 bits of information per TileEntity found within that list of 36 items, plus 1 bit for being allowed into the rules slots. So 1 bit per item + 3 bits per item per item. And each itemblock that has a TE could potentially need to check 16 possible states to insure validity, meaning as many as 576 setblock operations (average is probably closer to 18). There's got to be an easier way.

If the container is already detecting any changes to slots and sending those changes to any client, why do my slots not update until I close and reopen the inventory?

1 word: Pathfinding. Vanilla barely supports blocks that have collision greater than 1 block tall (animals would routinely attempt to jump over fences back when they were introduced) as several subsystems all assumed that a block was either passable or not, so when fences were added, there were several problems to overcome. This is why a bounding box cannot exceed 1x1.5x1, anything you're doing that makes it appear larger is only working for a subset of all those systems. If you're making a "custom air block that registers as a full block so nothing can be placed there" then I have this to say: Because that's what you just described.

The code is executed on both sides. On the client side it's used to keep the GUI display accurate. Go ahead and try it, make a basic container, then in the "can be inserted" logic of the slot, pass the info off to the TE, then have the TE discriminate based on worldObj.isRemote. You'll see what I mean. When? Edit: Also, there's the issue of the player picking up an item that was not previously in their inventory after the gui was opened (any item stack dropped by another player or a dispenser/dropper/other item transport).

I'm doing crazy shit with a container, due to this crazy shit, I can only determine whether or not an item can be inserted into any given slot on the server. I cannot in any way perform this calculation on the client without doing massive, massive hacks to the way the client handles worlds or completely subverting the suggested solution to the earlier problem (TEs with null worlds). See this post for previous info. How the hell do I handle this?

Except that no, after mining a block you tell your code to reset: hasBrokenBlock = true; break start; //go back to the beginning and run all the loops again