Draco18s

ArrayLists are wonderful things.

...yes, that's the whole point of the @ObjectHolder annotation. Yes you can. You still need to call new somewhere and you can still use local variables.

No. That is not what he said. He said don't assign a value to the field. @ObjectHolder(ExtraCraft.MOD_ID + ":sugar_block") public static final BlockSugar BLOCK_SUGAR;

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)