Choonster

Thanks for the advice, jabelar. I decided to add a custom Edible Sugar item and replace all recipes involving Sugar with recipes that output Edible Sugar and/or take either kind of Sugar as input. I also added recipes to convert between regular and Edible Sugar. You can see my implementation of this here. This is the class I used to replace the recipes.

You'd want the sickness to be a Potion . When the player uses the Ibuprofen, check if they have the Potion active: if they do, damage or kill them; else heal them and apply the Potion .

Someone posted here asking for help making Sugar edible, so I thought I'd try to help them; but unfortunately it looks like vanilla breaks things by replacing the player's held item with a copy, which stops the item from being used (you can see a full explanation of the effect here). My code is here. Is there any way around this without resorting to ASM or intercepting packets?

Has anyone managed to get Scala and Java 8 working in the same project? I've got a test mod here that's configured to compile both Scala and Java through the Scala plugin, but the compiler fails when it encounters Java 8 features like static methods in interfaces. This is what gradlew --stacktrace build outputs: Attempting to run the client in IDEA outputs the following errors: I'd like to get this working in mixed compilation mode (the default) so Java and Scala code can reference each other in either direction.

You can call vararg methods in Scala just like you would in Java, see this example.

I replied to the OP's post on minecraftforum.net:

One of the mods you installed was made for Minecraft 1.8, but you're running 1.7.10. Mods only work on specific versions of Minecraft, you need to install ones made for the version you're running. Most mods will have the Minecraft version they're made for in the JAR's file name. The crash happened early in the loading process, so it doesn't say which mod caused it.

FMLNetworkEvent.ClientConnectedToServerEvent is fired on the FML bus ( FMLCommonHandler.instance().bus() ) client-side when the client connects to a server (integrated or dedicated). In 1.8 this event is fired on a Netty thread rather than the main client thread, so you can't directly interact with normal Minecraft classes. Read the Warning for Minecraft 1.8 section of diesieben07's SimpleNetworkWrapper tutorial to see how to schedule a task on the main client or server thread; this will allow you to safely interact with Minecraft classes. When the client is connected to a dedicated server or LAN game (only as a guest), Minecraft#getCurrentServerData will return a ServerData object describing the current server and FMLNetworkEvent.ClientConnectedToServerEvent#isLocal will be false . The ServerData#serverIP field contains the IP of the server. In a single-player game or as the host of a LAN game, Minecraft#getCurrentServerData will return null and FMLNetworkEvent.ClientConnectedToServerEvent#isLocal will be true . You can see an example of how to handle the event here.

No, the cache only stores artifacts of Gradle tasks; it doesn't involve your source code.

Did it recompile Minecraft + Forge or just skip it? If it was skipped, you should force it to be recompiled by updating to a newer Forge version, deleting the JARs for the current version in the Gradle cache or running the cleanCache task to completely wipe the cache.

Use EntityPlayer#getGameProfile to get a player's GameProfile . The boolean is whether the downloaded texture names need to be securely signed. AbstractClientPlayer passes true , you probably should too.

There's not much point to that. The problem is with ForgeGradle rather than Forge itself and the latest Forge version still defaults to ForgeGradle 2.0.1 stable rather than the snapshot, so you'd still have to make the same edits in build.gradle.

The NullPointerException in CrashReportCategory#firstTwoElementsOfStackTraceMatch is caused by ForgeGradle not building Minecraft with debug information, this has been fixed in the latest snapshot version. In your build.gradle, uncomment the "bleeding edge" code at the top ( buildscript block and apply plugin ), comment out the "stable" plugins block, re-run setupDecompWorkspace and re-generate your IDE project. Once you've done this, the actual exception should be visible.

Post the actual exception and stacktrace.

The exception was thrown on line 35 of ItemMaskLoup , but line 35 of the code you posted couldn't have thrown that exception. Can you upload the latest version of your code and the crash report to Gist and link them here?

Upload fml-server-latest.log to Gist and link it here.

You installed a 1.8 mod on 1.7.10.

The exception on line 82 of ShapedOreRecipe is thrown when the length of the full shape string isn't equal to the width (the length of the last individual shape string) times the height (the number of individual shape strings). All shape strings must be the same length. Shape strings are whitespace-sensitive, so "I" isn't the same as " I " .

Vanilla has no concept of gases, so most gaseous fluids (at least the ones from Thermal Foundation, IC2 and Railcraft) just use MaterialLiquid (which returns true from Material#isLiquid ).

Most mod fluid blocks will extend from BlockFluidBase (which you probably meant), but it's entirely possible that they'll implement IFluidBlock themselves and not use the reference implementation.

I meant pass the player's held ItemStack to getHarvestLevel instead of creating a new one with metadata 0 and no NBT. What you've done looks correct.

Don't check if the item extends ItemSpade , that's not a reliable indicator that the tool functions as a shovel (Tinkers' Construct tools extend ItemTool directly, bypassing ItemSpade and the other subclasses); some tools may not even extend ItemTool . Just use the harvest level check, any tool that can't act as a shovel will simply return -1 from Item#getHarvestLevel . Don't create a new ItemStack to pass to Item#getHarvestLevel , use the player's held ItemStack . Creating a new ItemStack will break any tool that uses metadata or NBT to determine the harvest level (e.g. Tinkers' Construct).

Use Entity#getPosition to get the player's current position, World#getBiomeGenForCoords to get the BiomeGenBase at that position and BiomeGenBase#biomeName to get the biome's name.

Override isValidPipe / isValidConnection to check if the neighbouring block is an instance of a specific pipe class instead of just BlockPipeBase .

The new fluid models were added in Forge 1.8-11.14.3.1464, so make sure you're using that version or a newer one.