Choonster

I've just compiled and uploaded the latest version of the code here.

You can run the dedicated server and a client on the same computer, I did this myself for quite a while when I last played Minecraft.

You could run a dedicated server and use the /setidletimeout command to set the idle timeout to 0. My mod is under the MIT License (see the LICENSE.txt file), which means you can do pretty much whatever you want with it as long as you retain the license/copyright info. To compile my mod, you'll first need to install the JDK and set the JAVA_HOME environment variable to its location. You can then download or clone my mod from GitHub and run gradlew setupDecompWorkspace to set up the workspace (this only needs to be done once) and gradlew build to build it (the compiled mod will be in build/libs). If you want to edit it, you can install Eclipse or IntelliJ IDEA and follow steps 5 and 6 of this tutorial to set up an IDE project for it. I personally use IDEA, but either will work. Like the name suggests, TestMod3 is just a test mod. I make no guarantees that it's stable or balanced (pretty much everything is creative-only), but things should generally work as they're intended to. If you do encounter an issue, please report it on GitHub.

Are you looking at an old version of the README? The latest MDK's README tells you to use setupDecompWorkspace and only suggests using setupDevWorkspace if you don't need the source code. Even Forge's README suggests using setupDecompWorkspace if you want the decompiled classes.

Actually, I just remembered that Forge recently added the TileEntity#onLoad method, which is called when the TileEntity 's block is first placed in the world and when its chunk is loaded from NBT. You should be able to override this to do the coolant calculations instead of using the flag in the update method.

Unless the mod provides some form of retrogen (i.e. applying world gen to existing chunks) itself, it will only generate in new chunks.

I don't think this is possible, since the TileEntity isn't added to the World until after it's been loaded from NBT. Instead, I'd recommend setting a flag in readFromNBT and then checking for this flag in your update method. If it's true , set it to false and then perform the load-time coolant calculations.

You've overridden the deprecated method Block#hasTileEntity() . This method is never called, so your TileEntity is never created. You need to override Block#hasTileEntity(IBlockState) instead. I would recommend creating a Git repository in the mod's root directory (where build.gradle and the src directory are) instead of in the src/main directory. IDE project files (e.g. Eclipse's .project file) don't need to be included in the repository, they can be generated by Gradle. The $ cat .gitignore line of your .gitignore isn't doing anything and shouldn't be in there, it's a command that prints the contents a file (.gitignore in this case). I assume you copied it from this tutorial by Jabelar, it looks like he just screwed up the formatting.

Block#createTileEntity is only called if Block#hasTileEntity returns true . Upload your latest FML log and Block , Container and GuiContainer classes to Gist with syntax highlighting and link them here.

Can you use events or reflection to modify these values?

I don't know. You may be able to subscribe to and cancel RenderPlayerEvent.Pre and handle the player rendering yourself, but that may conflict with other mods that do the same thing. You may also be able to use the Render Player API mod to handle your animations.

The Item argument is the item to render the entity as and the RenderItem argument is Minecraft's RenderItem instance (coolAlias showed how to get this in post #4).

Runtime patching with ASM (what coremods do) is different to (and a lot harder than) compiling your code with MCP and dropping the modified classes into the Minecraft JAR. You'll need to have a solid understand of the Java bytecode format and the ASM library to make a coremod, neither of which you're likely to learn here or in Forge tutorials. You'll need to find your own resources.

coolAlias has a tutorial on a backpack-like item here. If you're using 1.8.9, you may want to check out the capability system and IItemHandler / CapabilityItemHandler . You should be able to use these to store an inventory in an item without having to read from and write to NBT every time you want to access it.

The question doesn't make any sense, you can't cast between unrelated types. An Item is a type of item, an ItemStack is a stack of an item. A TileEntity is linked to a block in the world. A TileEntity can store ItemStack s in it, but these ItemStack s don't know anything about where they're being stored. What is it you're trying to achieve?

The IInventory you passed to the Slot constructor is null . I suspect this is because you haven't overridden Block#hasTileEntity to return true , so your TileEntity isn't being created.

Forge recently added an animation system for models. You can see an example of it here (assets).

setupDecompWorkspace gives you the source, setupDevWorkspace doesn't.

So it's definitely still throwing a NullPointerException on line 654 of NetHandlerPlayServer ? Does this happen directly after resuming from the breakpoint on this line when none of the values are null ?

There are doc comments in the Forge/Minecraft code, but I don't think Forge actually compiles Javadoc pages. If you've set up your workspace properly, you should be able to view this code from your IDE.

I don't understand what you mean, sorry. The only values that could cause this crash are this.playerEntity , this.playerEntity.openContainer , slot and this.playerEntity.inventory . Which of these is null ?

I'm not familiar with Eclipse's debugger. Does it not show the values of all current variables somewhere? Does it tell you the value of a variable if you mouseover it? IntelliJ IDEA's debugger looks like this:

I explained how to do this here.

You installed a client-only mod (Resource Loader) on the server.

World#spawnParticle calls IWorldAccess#spawnParticle for every registered IWorldAccess . RenderGlobal (the client-side IWorldAccess ) spawns a particle in its implementation of this method, WorldManager (the server-side IWorldAccess ) does nothing. WorldServer#func_147487_a(String particleName, double x, double y, double z, int numParticles, double displacementX, double displacementY, double displacementZ, double velocity) sends a packet from the server to the clients of the players within 256 blocks of the specified position telling them to spawn particles there. Look at RenderGlobal#doSpawnParticle to see which particle names you can use. Use your IDE to find usages of these methods to see how they're used.