Draco18s

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.

[me=Draco18s]looks at your Git repo[/me] private static void registerRender(Block block, int meta, String file) { Minecraft.getMinecraft().getRenderItem().getItemModelMesher() .register(Item.getItemFromBlock(block), meta, new ModelResourceLocation(Reference.MODID + ":" + file, "inventory")); } Why are you still using the ModelMesher? You should be using ModelLoader.setCustomModelResourceLocation(...)

UpdateTag is more of a "first spawn" thing. Also, if you only call super, there's no reason to override. You actually need: @Override @Nullable public SPacketUpdateTileEntity getUpdatePacket() { return new SPacketUpdateTileEntity(this.pos, 3, this.getUpdateTag()); } @Override public void onDataPacket(NetworkManager net, SPacketUpdateTileEntity pkt) { super.onDataPacket(net, pkt); handleUpdateTag(pkt.getNbtCompound()); } These are the methods called to synchronize TEs. See also: http://www.minecraftforge.net/forum/index.php?topic=43417.msg231329#msg231329

While that's what it's for I'm not sure it's actually used the way you think it is. I know that for entities like cows, the weight is irrelevant because there's only one entry in the pool. Let me look at fish for a minute. Ah, ok. So my LootUtils class is not constructed to properly handle adding items to the fishing tables because: I have them added as new pools and vanilla is going to ignore it. Along with a few loot functions that aren't needed (unclear if having a stack other than size 1 is relevant, applicable, or allowed for fishing). You'll want to get a reference to the LootPool named "main" (there's a table#getPool(name) method) and you'll want to insert a new LootEntry to it.

You need to supply an item model.

You have the Windows default "hide known file extensions" option enabled. Its fucking stupid, and this is why.

The fact that it's ternary doesn't matter. 0 * (rand.nextInt(2) == 0 ? 1 : -1) is still 0.

You can call a method in your proxy class, yes. But it must be done through MainMod.proxy.whatever() not ClientProxy.whatever().

Why not server side?

Having had to fight with COG to get the server running in Dev, I was wrong. Yes, the server needs to know about the packet handler, because you need to register the networking stuff on both sides. Which means... You guessed it... The packet handler cannot contain client-side-only code. I just had to move a bunch of stuff to my client proxy.

Register your network handler in your client proxy.

I've had similar problems. I do this, and it works most of the time: worldObj.markBlockRangeForRenderUpdate(pos, pos); worldObj.notifyBlockUpdate(pos, getState(), getState(), 3); worldObj.scheduleBlockUpdate(pos,this.getBlockType(),0,0); markDirty();

You need a 0-argument constructor for SaveScanMessage.

TL;DR don't do that. Use separate classes. Your packet handler code is trying to load client-side-only objects and because it's the same class on the server, the server tries to load those objects in order to instantiate your packet. Ergo, it crashes.

rand(9) - 4, then. Seriously, it's not that hard to make a linear distribution across any range.

Also, just as a heads-up to the OP: Checking the stored item stack's Item isn't sufficient. Blue, red, white, etc. wool will all be detected as "same" and get inserted.

You mean ItemStack#writeToNBT(...) ? Gosh, so hard.

Prepare for a tedious journey of writing and rewriting. A few tips for when you're editing vanilla code: Don't touch the vanilla lines at all if you can avoid it. That includes blank lines. Don't turn a blank line into anything, just insert stuff above/below it. Always make your call a call to ForgeHooks, "its shorter." Always use fully qualified names (no imports).

It's one of those things I bumped into without realizing it and had to do some refactoring.

Ok? What's your question/problem?

The only reason I don't like the preInit methods getting passed off to the proxy is that often times they're passed on (again!) to another class and when something goes wrong, it's a huge pain for us here to help debug because we have to ask "for your main class" only to then ask for the "proxy classes" and again for the "ModBlocks" and/or "ModItems" class. I grumble about the ModBlocks class (such an awful name for it*) but it's not wholly bad. What's bad is when people just pipe the FML events all over the place making it difficult to track the execution of potentially faulty code. If I wanted to track the execution of faulty code and find the error and have it be intentionally difficult, I'd go here. *I literally cringed when I saw one noob comment to another, "Hey we use the same class name!" No shit, you both watched the same tutorial. Get over yourselves. At least replace "mod" with the name of your mod, "ArtifactsBlocks" "HungerOverhaulBlocks" "SuperChestsBlocks." Why? In case anyone ever plans to integrate with your mod and wants to reference your class without needing a fully qualified name because there's now TWO ModBlocks classes.