Choonster

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.

Forge's blockstates format may be useful here. You can specify a default model (e.g. builtin/generated ) and transform set (e.g. forge:default-item ) and then specify the textures in each variant. Despite the name, Forge allows it to be used for items as well as blocks. For the ModelResourceLocation passed to ModelLoader.setCustomModelResourceLocation or returned from ItemMeshDefinition#getModelLocation , use the location of the blockstates file as the domain and path (e.g. <modid>:<name> , which maps to assets/<modid>/blockstates/<name>.json) and the variant in the blockstates file as the variant. If you're using an ItemMeshDefinition with ModelLoader.setCustomMeshDefinition , you need to call ModelBakery.registerItemVariants with the same ModelResourceLocation s yourself. If you're using ModelLoader.setCustomModelResourceLocation , ModelBakery.registerItemVariants is called for you.

I use Forge's blockstates format to compose the models for my pipe blocks from two basic JSON models (the centre cube and a side connection). You can see the blockstates file here and the pipe models here here. This is just the basic shape of a pipe, it doesn't have any sort of fancy rendering like Buildcraft pipes do.

I don't know of any tutorials, but I do have working example code. You can see my fluid creation code here, my model registration code here and my blockstates file here. ModFluids.registerFluids is called in preInit from TestMod3 (the class with the @Mod annotation), ModModelManager.registerAllModels is called in preInit from the client proxy (after everything else has been registered).

Have you got a blockstates file that specifies the model for each variant? Forge's blockstates format may be handy here.

I've managed to get this working, you can see my code here. I ended up using the Shadow plugin to package and relocate the dependency and just told ForgeGradle to reobfuscate the resulting JAR.

Have you called CapabilityManager#register for your capability interface?

It looks like you've extracted mod JARs into your mods folder, don't do this. Mod JARs should be placed in the mods folder without being extracted.

I think the documentation on Read the Docs is for ForgeGradle 1.2, there doesn't seem to be any documentation for 2.x. I'm looking through ForgeGradle's code, but I don't fully understand how Gradle works. This PR changed the reobfuscation system, so now you need to specify reobfuscation per JAR task (like this). I'll try this myself and see if it works.