Two

I don't like the Gradle 'update' and imo it is a major mistake. [*]Gradle adds nothing that Maven + Ant couldn't have done as well. [*]Gradle is not supported by the most common IDEs and force the developer to use unsupported/buggy plugins. [*]With no build-in support, changing settings/properties becomes a lot more difficult. @LexManos: I don't really get the supporting arguments. - Cleaner code/workspace What does this have to do with the build system? A tidy environment is a question of project setup. - Separation of mod code I had this since the beginning of Forge: just add a second source directory and you are done. - Dependendy management Can be done with Maven and various other supported features of most IDEs - Automated deployment Whats the big difference between "ant dist" and "gradle dist" ? - OS Independence Which part of Java/Ant was OS dependent before?

The following list has been build on try & error experience and might not be correct or perfect. If you feel that this can be improved, please feel free to comment and add your suggestions. 1. Install the NetBeans Gradle plugin Tools -> Plugins -> Available Plugins -> search for "Gradle" -> install 2. Install the latest Gradle As Forge ships with an outdated Gradle version that causes issues during debugging, you need to dowload the latest binaries from the official source Forge Gradle has been updated, no need for manual install anymore, but guide kept for reference. Extract the Zip into any directory (no installation necessary), then point Netbeans to this directory under Tools -> Options -> Miscellaneous -> Gradle -> Gradle Installation Directory 3. Download the latest/recommended Forge SRC zip Extract it to a new directory, which will then be your project directory. 4. Setup Forge Open a command line and go to that new directory to setup the decompile workspace: gradlew setupDecompWorkspace If you have issues and think you messed up the setup, run: gradlew cleancache --refresh-dependencies If that one fails: go to your \User\Home directory and delete the .gradle directory, then try again. 5. Open the project File -> Open Project -> navigate to the dir where you extracted the files. If you have not installed the latest Gradle, you will receive an error message about that at this point. 6. Run the client To run the client you need to execute the 'runClient' task. If you want to tie that to the run button (F6) you need to first edit the built-in task as follows: [*]Go to project properties -> Gradle project -> Manage Built-In Tasks [*]Select the task 'Run' from the list [*]Deselect 'Inherit' to enable edit, then under 'Tasks' replace "run" with "runClient" 6. Run the server As in 6. just that you need to execute the task 'runServer' instead of 'runClient'. You can change the built-in run task accordingly as described above. If you often switch between server and client compilation, you can add profiles to the project properties like 'Client' and 'Server' which have individual configurations of the 'Run' task. This makes switching a lot easier. Hint: you can debug by using the debugClient and debugServer tasks as above. 7. Build the mod jar To build a distributable mod jar, use the build button (F11). The result file will be placed in "build\libs". 8. Customize your mod Beside adding code you can customize your mod by editing the build.gradle file (Build Scripts -> double-click build.gradle). Here you can edit "version", "group" and "archivesBaseName" to your likings.

Hi, I am currently creating a block that is supposed to drain from neighbor fluid handlers. While it works fine I noticed that it cannot access BuildCraft tanks, because the BC tank is implemented to always return false for IFluidHandler.canDrain. As far as I understand the doc for this function, it should return true if the tank can probably be drained from the given direction, so the BC tank says that it can never be drained. But yet the BC pipes obviously can do that. So my question is: am I understanding this function wrong, so should I ignore the canDrain? Or is BC doing this wrong and should return true?

Awww... crap! Thanks!

Just before I start some probably unnecessary work: If I understand you correctly, I need to implement my own renderer to get a block to render like a block, and there is no way I can use the already existing rendering code for blocks from Minecraft (except for copy&paste), just because I must use my own item so the block retains the meta value if dropped, correct?

I am not sure how this is supposed to help me. The Redstone ore/wire renders as an item in the inventory and not as a block. This is what I already got with my 2nd attempt, but I do want the icon in the inventory to render as the 3D-block.

Hi everyone, I am currently trying to add a new block - a lava tank - that keeps the fuel amount when picked up. So far I have been successful with almost everything, except for properly creating an item that tracks the fuel limit but is rendered as the block at the same time. I can obviously write my own renderer, but why do that if one already exists and is much more upward-compatible? What I have tried so far: My first attempt was to use the ItemBlockWithMetadata item, which works except for the inaccurate storage, but Forge complains that this anonymous item class will not survive a 1.7 update. I tried to create my own ItemBlock sub-class, which works fine, except that the item is now rendered flat instead of the 3d block look. I tried to use ItemBlockWithMetadata and register it with the block, but now Forge obviously complains that I am overwriting an existing block. Could someone please give me a hint how I can do this properly, or if possible a short tutorial (for experienced programmers)? Thanks in advance! Edit: Thanks to Draco18s this was solved in the following way: [*]Created a sub-class of ItemBlockWithMetadata that forwards getIcon(side, metadata) to the same block function [*]Added a new renderer. (Basically a copy of this tutorial) [*]Registered item with renderer in ProxyClient: itemRendererBlock3d = new ItemRendererBlock3d(); MinecraftForgeClient.registerItemRenderer(itemLavaTank.itemID, itemRendererBlock3d);

Max build-height of the world is currently 256, but you can only generate the world with a max height of 128.

Where and how? Have just been starting to work with Forge.

To allow mods to log information properly and in an easy way, please add the following to FMLLog.java: public static Logger getModLogger(final String name) { final Logger result = Logger.getLogger(name); result.setParent(coreLog); result.setUseParentHandlers(true); return result; } In addition please use the standard Java logging message formatter so the standard logging tools can be used properly (as supported by many IDEs): FMLLogFormatter.java:62 - msg.append(record.getMessage()); + msg.append(MessageFormat.format(record.getMessage(), record.getParameters())); This should be 100% compatible to the current logging.

As the title says: I'd love to be able to allow custom world types to be able to generate worlds with a height of 256. The changes necessary are actually very simple and I tried them already by modifying vanilla code. The following (hand written) patch would modify the code so that both vanilla generation and 256 generation would be possible. Chunk.java:131 - int var9 = par2ArrayOfByte[var6 << 11 | var7 << 7 | var8] & 0xFF; + int var9 = var5 == 256? par2ArrayOfByte[var6 << 12 | var7 << 8 | var8] & 0xFF : par2ArrayOfByte[var6 << 11 | var7 << 7 | var8] & 0xFF; MapGenCaves.java:20 + final int chunkDataHeight = par5ArrayOfByte.length / 256; :137 - var45 = (var42 * 16 + var43) * 128 + var44; + var45 = (var42 * 16 + var43) * chunkDataHeight + var44; :139 - if (var44 >= 0 && var44 < 128) + if (var44 >= 0 && var44 < chunkDataHeight) :165 - int var48 = (var42 * 16 + var45) * 128 + var38; + int var48 = (var42 * 16 + var45) * chunkDataHeight + var38; MapGenRavine.java:11 + final int chunkDataHeight = par5ArrayOfByte.length / 256; :124 - var44 = (var41 * 16 + var42) * 128 + var43; + var44 = (var41 * 16 + var42) * chunkDataHeight + var43; :126 - if (var43 >= 0 && var43 < 128) + if (var43 >= 0 && var43 < chunkDataHeight) :152 - int var47 = (var41 * 16 + var44) * 128 + var37; + int var47 = (var41 * 16 + var44) * chunkDataHeight + var37;