Draco18s

You can use getCraftingResult(InventoryCrafting inv) to examine the crafting grid and snag the NBT.

You need to add to, not overwrite, the loot table

Yes, you can still use the JSON system with custom IRecipe implementation. You just need a Factory internal static class that implements IRecipeFactory, a _factories.json pointing to this factory, and you're basically good to go.

My point was that there are already effects in the game. Sure, that one's small, but it still exists, so there's no reason why you couldn't do more.

You've got like a dozen coremods. We can't really support you as a result.

Why not just generate them anyways? It would suck to have built this awesome house underground kill a boss that spawns a structure and then go back to my beautiful house that has just been built over with a dungeon. Cough, the end portal in the end after you kill the dragon?

Don't register your recipes that way. Use the JSON system.

Vanilla furnace doesn't operate this way. You would need to create your own machine to do this. I did this with my Sifter and Pressure Packager. I don't use fuel (e.g. coal), however.

But not Forge, so why are you on the Forge forums? Whatever that is.

True enough. But if someone can't solve the "there is no constructor that takes these parameters" issue, they need to go learn Java first. There's literally only two options to fix it and they can't figure out what to do.

In which case, I would do something like this: public String getActionbar() { try { return (String)overlayMessageField.get(Minecraft.getMinecraft().ingameGUI); } catch (IllegalAccessException e) { e.printStackTrace(); throw new RuntimeException("Get Message Overlay failed!"); } } If it should crash, then let it crash. Don't handle the exception, then return null, allowing other code to null-check and not crash.

You shouldn't be stuffing NBT data into the item. That's why you have a Capability.

As far as I can tell, Minecraft vanilla code is crashing here: double d0 = (double)y - (1.0D - this.blockaccess.getBlockState(blockpos1).getBoundingBox(this.blockaccess, blockpos1).maxY); The only thing that could even be null on this line is the return from getBoundingBox(), but the code you've shown does not override this method.

This is how you post code:

Yes, because that's what Minecraft does when the stack NBT changes: when the server sends the update packet, the client assumes it is a new stack and recreates it.

Oh I agree it should never happen. But if there's one thing I know about programming. "Should never happen" is not as absolute as one would think.

Um...ok? Do you have a question or problem you want help with?

Would I rather check validate that the string returned by this function is null, or display an empty string (or the string "null")? I think I'd rather have a non-null string.

Return an empty string instead of null.

Or you can copy and paste the files on your computer and declare it a new repository.

That's not why you use !worldIn.isRemote. You use !worldIn.isRemote when you want code that runs on both the client and the server to only run on the server.

You might be interested in my sifter, then: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/recipes/OreProcessingRecipes.java (Note: I haven't converted my machines to JSON "recipe" format yet because I'm lazy)

Clone/Fork the repository, (re)name it to your new project, and don't worry about it. (Forking will leave a reference back to the original, if that's important to you--either for wanting the link or being aware and doing it manually because you don't want the link)

Clone the project. If you want your starter mod to be its own project and treat it like a library, then treat it like a library: make your other mods depend on it.

Ew, no. Don't do that. Branches are for things like maintaining the source for the same mod across multiple versions of Minecraft, not for unrelated projects.