RANKSHANK

I wouldn't say never. The issue here is it's a massive newbie trap and always has been. Side.Client and Side.server are misnomers: Side.Client is inclusive of the integrated server, and thus does not prevent double calls between the integrated server thread and the client thread. Which is our pitfall here. Side.Server does not include the integrated server, it's solely for the dedicated server. Think of it more as Side.Client&Integrated and Side.Dedicated_Server_Only The reason these exist is that they're a flag for the Classloader. If the given side is not equivalent, the Classloader ignores that method/class/field and it will be missing from the runtime environment. So when you used SideOnly(Side.Client), the dedicated server will be missing that method, defaulting to whichever class in it's heiarchy overwrote it last (unless it's THE override for an abstract type in a non abstract class which will cause {Type}NotFound exceptions up the wazoo when the class is loaded). However the integrated server thread and client thread both have access to that method since they share a Classloader. TLDR: Use ONLY when you know you need the given Type to be missing from a particular runtime(Minecraft client or Dedicated server) As for the cooldown, your best bet is sending a packet if you plan to have this network ready, otherwise you'll hit snags when multiple players try interacting with it

FMLCommonHandler.instance().findContainerFor(Object).getVersion() Put the modid string in for the object and you'll get the version string

Perhaps instead make a custom 'lockable slot' overriding the method: public boolean canTakeStack(EntityPlayer player){} And possibly "graying out" the slot, so they can see

public static byte textureNumber; public static byte rotation; You're using statics for values that you want to have as a per object basis

Just a guess here: Try using getActualState(IBlockState, IBlockAccess, BlockPos){} And then using a value in the tile entity to cycle.

Well arrays start at the 'key' value of zero. so you have an array[x, y] which is accessed by either array[0] for x or array[1] for y... So your index is out of bounds since calling for the array[2] is looking for the third value in a two value array Look here in your code: public ItemStack getStackInSlot(int i) { if(i < 3) { return this.slots[2]; } return this.slots; } slots[2] is actually the third value in a two value array, hence the index error

try worldIn.getBlockState(pos).getBlock() == Blocks.farmland And yes farmland has states for the moist. Comparing just the states is a bad idea in this case

I'm pretty sure that's the scoreboard

Why bother moving the position at all when you counteract the movement? BlockPos is literally a class that wraps the XYZ coords. Calling pos.up() etc provides a new instance and doesn't modify the original position. So you've created a shifted copy of a shifted copy of a shifted copy.... Etc that ends up as an exact copy of the coords you had initially. BlockState != Block BlockState.getBlock() like @ovikk said. So that initial if() is always false, so you haven't hit the other issues yet. world.setBlockState(BlockPos, BlockState, int flag) That's what you're looking for as well. Pos holds all location data, state holds all block info In all honesty you need to sit down and scratch your head for a while at the vanilla classes that deal with this stuff. You'll have a lot less issues if you actually know what's going on. It sucks but it can't be avoided

Have you printed out the list of tags that's handed to you by the load function? May be some abnormalities there

http://stackoverflow.com/questions/27755029/how-to-convert-from-a-string-to-an-nbtcompoundtag Apparently there's a JSONToNBT class... Not 100% sure since this is from January and I'm nowhere near my workspace Aside from there I've seen nothing aside from raw byte handling of NBT.

Definitely a case of Murphy's law By the sounds of it you'll want to start fresh to avoid any issues. 1)Download a fresh MDK and extract 2)run gradlew cleancache 3)run gradlew setupdecompworkspace 4)run gradlew eclipse 5) mount eclipse to the eclipse folder and you should see the project folder labeled MDK Hopefully that helps

Are you running a clean up before re-running all the install tasks?

I'd reccomend trying a custom view point like the one found here, http://www.minecraftforge.net/forum/index.php/topic,35168.0.html and instead force it's location and angles via packets and a client side handler

what does your build.gradle look like?

Well you can either replace the farmland block with your own instance that doesn't need water with a substitution alias, or you can do the same with a substitution alias for the hoe so that it places a new instance of the farmland block

You're not calling the super() for read/writeToNBT

Without the MCP mappings and such from that point in time available you won't be able to deobfuscate, period. If you really want the model files you're going to have to manually translate it by doing a side by side (this obfuscated method looks like this vanilla one) and transfer over the specific values such as box sizes and rotation offsets

I think it's gradlew cleancache but that's just glancing at the task list

As in use the IExtendedProperties and events to manipulate the properties? What do you mean by only modifying one skill?

Off to update my environment then, thanks for the fix Lex! Thanks Diesi! Looks like I've got some reading to do

@Override public void preInit(FMLPreInitializationEvent e) { BlockRenderRegister.registerBlockRenderer(); super.preInit(e); } You're registering your block renderer before initializing your blocks.

. Well my crashes happen on the WorldServer#tick() with none of my blocks being broken (I leave the game running to go grab a beer and will return to a crash log). So the block at the given location is persistent. Mine seems to have to do with the Chunk#extendedblockstorage being null during the light table update... which I'd wager has something to do with chunkloading / chunksaving setting the block storage as temporarily unavailable... but I wonder if there are any ramifications for a block being incorrectly considered as air (lighting glitches being a major possibility).

Definitely a +1 from me. Your tut easily got me up to snuff on SourceTree within a few minutes. Lovely little ui once you grapple with it

Without any in built else statements there it's... a bit more than painful running a breakpoint (actually managed to crash because it's called so many times a tick and takes a few minutes for a failure to occur). The work around is pretty simple and not heavy enough to call to warrant using ASM to add an else{ just to add a breakpoint... I'll just toss it out as one of the many 'unique' characteristics in the lighting engine