Draco18s

if (tileEntity instanceof TileEnityCrystallizer) { TileEntityCoalGenerator tileInventoryFurnace = (TileEntityCoalGenerator) tileEntity; if (tileEntity instanceof TileEntity) { TileEnityCrystallizer tileInventoryFurnace = (TileEnityCrystallizer) tileEntity; return new GuiCrystallizer(player.inventory, tileInventoryFurnace); } if (tileEntity instanceof TileEntity) { TileEntityCoalGenerator tileEntityCoalFurnace = (TileEntityCoalGenerator) tileEntity; return new GuiCoalGenerator(player.inventory, tileEntityCoalFurnace); }

One is unaltered, the other is altered? Like, it's not that hard. The Forge project is where Forge makes their changes. The clean one is clean.

Try not returning true on the client. Remove that line entirely.

You mean this?

Annnnd your block code?

private ItemStack ItemStack; The fuck? public ItemStack getItemStackFromSlot(EntityEquipmentSlot slotIn) { return ItemStack; } Double da-fuck? The magic of packets.

Something something look out in front

This will not work on the dedicated server. The server doesn't necessarily know what a "keyboard" is, much less which player is pressing it.

There are two things that much be true for your keybind to do anything. 1) The key needs to be pressed 2) The player needs to be wearing the armor 3) the server needs to know about it You've got #1 at the moment, now do #2 and #3.

Well. For the entity to destroy a block that has the same coordinates as the entity, then the entity must be inside the block. If it is inside the block, then it must have impacted the block. If it has impacted the block, then the entity must be dead.

Your method "disrupt" is private and not called from anywhere, then calls super.onEntityUpdate

That is not the correct hasTileEntity() method. You want hasTileEntity(IBlockState state).

(You should do both, just to be 100% safe)

Eclipse can highlight syntax and semantic errors, but it can't predict very many runtime errors. Code can be faulty simply by trying to use a pointer before it points to something. Eclipse can sometimes warn you where that's likely, but not always (Eclipse can't predict that a method will return null). This kind of error is what the industry calls a runtime exception and is still an error. There are also logic errors where there is nothing wrong syntactically nor does a runtime exception occur, but the function does not performed the assumed duty that it has been given. Eg: Which is why there are things called unit tests. The fact that I, Jeffry, and D7 are all posting the posts we do in response to you says that you're wrong.

If you're using Eclipse, go to the Eclipse market place and install JSON Editor Plugin.

It is surprising how much of this thread is relevant.

I prefer calling it "declaration" as in "I declare that this variable exists" vs. "definition" as in "this is what this variable is." Instantiation need not be part of a variable definition, but often is. (e.g. it can be passed as a method parameter instead, or ignored (cough, dead code, cough)).

https://github.com/MinecraftForge/MinecraftForge/wiki/If-you-want-to-contribute-to-Forge

int counter = 0; for each { if connected { counter++; } }

You were already told. for (EnumFacing face : EnumFacing.values())

Those are indicators of position within the vanilla class file. You shouldn't be needing to worry about those.

Note that this will return the location your own block is. You should call some combination of up(), down(), north(), south(), east(), and west() to get an adjacent block.

This is just wrong: if (ep.isSneaking()&&world.isRemote) { Minecraft.getMinecraft().displayGuiScreen(new magnetGui(ep.inventory)); } You can't reference Minecraft.getMinecraft() in common code, not even if you wrap it in world.isRemote because the dedicated server's ClassLoader does not know that that field will never be true, so it must insure that it can load that class, and will not find it. Also WTH is InventoryEffectRenderer?

You don't need a separate server proxy class. I still don't see why it's crashing though.