Choonster

I didn't know it recorded any logs. I don't see any anywhere. Gradle outputs to stdout (the console you're running the command in) and saves the most recent output to .gradle/gradle.log in your ForgeGradle workspace directory (i.e. where build.gradle is).

You didn't post logs, though.

You need to understand Java and OO programming in general before you can make a mod. There won't be a tutorial for everything, so you need to know how to read existing code and use it. The registry already has the methods you need, you just need to call one of them with the appropriate arguments. Create an ItemStack each for your input, ingredient and output items and call BrewingRecipeRegisty.addRecipe with these three ItemStack arguments. That's all you need to do.

Do you actually understand Java? You don't need to create a new method, just call one of the existing ones. The methods expect ItemStack or String (ore dictionary name) ingredients and outputs, not Item s.

Change the minecraft.version property in your build.gradle to the new version, run setupDecompWorkspace and refresh your IDE project. If you're updating to 1.8.9, you'll need to update to ForgeGradle 2.1 from 2.0 by changing the version in the buildscript.dependencies section of your build.gradle and update your MCP mappings by changing the minecraft.mappings property. Look at the build.gradle of the latest 1.8.9 MDK download to see what you need.

Make sure you're using the latest version, preferably for 1.8.9. Brewing recipes were introduced in 1.8-11.14.2.1440.

If you're using 1.8+, Forge provides the BrewingRecipeRegistry class that allows you to add brewing recipes. If you're not, update. Simply call one of the BrewingRecipeRegistry.addRecipe overloads to add a recipe, they all have doc comments explaining their inputs.

If you look for usages of the Blocks.bedrock field, you'll see that it's used in BiomeGenBase#generateBiomeTerrain . This is called from BiomeGenBase#genTerrainBlocks , which is called from ChunkProviderGenerate#replaceBlocksForBiome . Each biome generates its own terrain (including bedrock) from this method.

Subscribe to and cancel LivingExperienceDropEvent to prevent XP from dropping when an entity (including a player) dies.

When you use reflection for vanilla fields/methods, you need to need to check both the SRG ( field_77882_bY ) and MCP ( maxDamageArray ) names to support the release (obfuscated) and development (deobfuscated) environments. ReflectionHelper supports this by allowing you to supply multiple names for a field/method. You can find the SRG name of a field/method from the MCP mapping CSVs. If you've set up a ForgeGradle workspace, you can find the mappings used by it in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_channel>/<mappings_version> (replace ~ with %USERPROFILE on Windows). You can also download mappings from the MCPBot website or ask MCPBot for individual names on IRC (more details on the website).

The source download was renamed to MDK (Mod Development Kit) because it hasn't actually included any Forge or Minecraft source code since the switch to ForgeGradle from MCP. This tutorial explains how to set up modern versions of Forge.

What you want is the container item system. For simple items that don't use metadata/NBT, call Item#setContainerItem to set the Item that will replace the item when it's consumed in a crafting recipe. For more complex items or custom logic, override Item#hasContainerItem(ItemStack) to return true when the item has a container item and Item#getContainerItem(ItemStack) to return the ItemStack that will replace the item when it's consumed in a crafting recipe.

There shouldn't be.

In 1.8.9 FML can deobfuscate mods at runtime, so there's no need for deobfuscated builds any more. Anything in the libs directory at the same level as the build.gradle file will automatically be added as a dependency by Gradle. You can also manually add dependencies; using the deobfCompile / deobfProvided configurations will tell ForgeGradle to deobfuscate the dependency on disk. As for your actual issue, it looks like the JAR may be corrupt. Can you open it in an archive viewer like 7-Zip? Can you load it as a mod in the non-development client?

Ok so if I follow your way of coding in order, in my case it would be : Client right clicks on entity --> sends a packet that will be handle to the server --> server decides whether or not to let the client open the gui --> (admitting yes) call openGui method In there, the packet will just be useful to do some "tests" or requirements before deciding to open the gui or not ? When the player right clicks on an entity, the client sends a packet to the server and then calls the entity's interaction method (this actually happens up to twice, once for Entity#interactAt and once for Entity#interactFirst ; the second packet and call only happen if the first returned false ). This happens in Minecraft#rightClickMouse When the server receives these packets, it first checks that the entity exists and the player is close enough to interact with it. If these conditions are met, it calls the interaction method that the packet was sent for. This happens in NetHandlerPlayServer#processUseEntity . You should open your GUI from the server-side call of EntityLiving#interact (called from Entity#interactFirst ), i.e. when world.isRemote is false .

The "fluid" value in the variants of your blockstates file is the name of the Fluid to render (the first argument of the Fluid constructor). I don't think it's possible have a blockstates file that works for any arbitrary fluid unless you create a custom model loader; you need to have one variant per fluid. You can see my fluid registration code here, my model registration code here and my blockstates file here.

My code works, so I'm not sure what you've done wrong. Upload your fluid-related code on Gist/Pastebin (with syntax highlighting) or your whole mod on GitHub/BitBucket and link it here. ModFluids is only for the initialisation and registration of fluids. Any in-world behaviour of the fluid needs to be handled by the fluid's IFluidBlock class. BlockLiquid is only for vanilla liquids. Mod fluids need to use Forge's fluid classes. Create a class that extends an existing implementation of IFluidBlock (e.g. BlockFluidClassic , BlockFluidFinite ) and override Block#onNeighborBlockChange to check for mixing. Create an instance of this class instead of an existing one when registering your fluid.

You haven't defined a variant for each value of the facing property. The normal variant is only used if your block doesn't have any properties. I don't know of any tutorials, only Forge's debug code.

I've tried to test this here and it works in the deobfuscated client, but SLF4J refuses to load in the obfuscated client. I suspect it's something to do with the ClassLoader s used by Minecraft/Forge, but I don't have any idea how to fix it.

If the method doesn't exist, update Forge. If adding fluids using Forge's API conflicts with a mod, that mod is probably doing some weird stuff to the Minecraft code that's breaking Forge. I can't really provide support for closed-source JAR mods/coremods like OptiFine or this Xray mod. I haven't tried to add mixing effects with Water/Lava, but you can probably do it in a similar fashion to BlockLiquid#checkForMixing (called from Block#onNeighborBlockChange ).

Looking at the code, the maximum number of particles in 1.8.9 is always 4000 per combination of particle layer (0-3) and alpha (opaque or transparent). This is determined in EffectRenderer#addEffect . Changing it would require ASM and may or may not break things. The particles setting is only used by RenderGlobal#spawnEntityFX , but some particles are spawned using EffectRenderer#addEffect directly and won't be affected by the setting. The setting doesn't affect the particle limit, it just reduces the chance for particles to spawn (Decreased) or completely stops particles from spawning (Minimal).

I learned Java at university, so I don't really know of any good tutorials for it from personal experience. You could try or Vswe's Summer Courses (covers Java and Forge).

Put breakpoints in ModDrops#onDrop and CommonProxy#postInit and run Minecraft in debug mode. Are the breakpoints ever hit?

Item#setUnlocalizedName takes a String argument, but you're trying to pass it the value of the pocket_watch field (an Item ). String literals are delimited by double quotes ( " ). This is an extremely basic concept of Java. You can't write a mod until you understand Java properly.

Blockstates files work with any format of baked model. Just specify the .obj or .b3d extension in your model paths to use an OBJ or B3D model. If you want to use OBJ models, you need to tell the loader to look in your domain like you did for the B3D loader.