Draco18s

Or you can write your own Ingredient or IRecipe class.

You would need to use the oredict wildcard value, but I think it is broken at the moment. Ok, not broken, short of intentional. See this issue: https://github.com/MinecraftForge/MinecraftForge/issues/4516

Container items are not handled by the json recipe files. Its handled by the item class as it always has been.

That would never make sense.

Sounds like you searched for references writing the hierarchy, rather than everywhere.

We used to, but we got new software, so, no, its gone now. We do have a "like this" button.

You can create resource packs via code and apply it as needed.

I'm not sure what your problem is. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OresBase.java#L281

you are correct, I'm on a tablet right now, so things are tricky.

Why are you casting that way? (ModelBase)foo is sufficient.

if(!world.isRemote) { Also, world not World. World is a class name and isRemote is not static.

I am not touching this thread with a ten foot pole.

Good luck with the divining rod. No really. I've gone to a lot of effort to create ore-finder mechanics and I'm only happy with one of them (the other *works* but has display problems) and it is not a divining rod.

Beetroots don't use the same AGE property as other crops: public static final PropertyInteger BEETROOT_AGE = PropertyInteger.create("age", 0, 3);

Probably alterations in the formula. I don't know when things were changed (and I don't go looking into them often myself), but I do know that at one point armor was a flat 4% reduction per point (which lines up with your 1.10 result). It's also possible that Forge mucked with things (I've heard comments about it, but again, never tried to verify them).

JSON recipes are so easy to set up. Pretty much anything you'd want to deserialize out of them as ingredients has already been done in either the vanilla or Forge recipes. The ones I've done have been smashed together from what I can find in existing code. You're welcome.

You're clicking a button on the client, writing the NBT to the item on the client, then picking up the item, the server then overwrites the client's data because it is the authority.

Skip all that nonsense (your class doesn't change, but you register it differently) and make the recipe follow the JSON format. You still need an IRecipe class, but you just add a Factory class to it that can deserialize the json. Which...takes almost nothing at all: public IRecipe parse(JsonContext context, JsonObject json) { return new RecipeGift(); } After that, you just need a file that looks like this in your assets (named _factories.json): https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/hardlib/recipes/_factories.json And this: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/ExpandedIndustryBase.java#L171 And oh yeah, you'll need a single json for the recipe of course.

It's a Java convention thing, that. Static values are in all upper case, class names are UpperCamelCast, variables and function names are lowerCamelCase. The BlockFoo and BlockBar and ItemBaz are an MCP naming convention, but one that I happen to like. After that, making method calls that invoke more method calls is just ridiculous. The only reason to do that is if the method actually adds something from its scope context (that isn't accessible outside it). For example, if I want to have items that define their model via NBT data I still want to register it as normal, but I need additional information from the class / class instance, so I have this method: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L89 Or this method, for custom IStateMapper implementations: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/flowers/block/BlockOreFlower1.java#L160 And when I need those functions I can just cast to the interface. Or use generic covariance magic: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L75 The cast here is actually unnecessary due to said magic (block is of Type T which is defined as block a Block and an IBlockWithMapper): https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L79

This is very confusing: https://github.com/THEJean-Kevin/goblin/blob/master/src/main/java/com/mineaurion/tjk/goblin/block/ModBlock.java#L17 1) Class names should start with an upper case letter 2) You really should use the most general-case Type possible (e.g. Block mine0 = new Mine_Lv_0();) so that people reading your code can understand it better. 3) Then if you need to, you can cast (I don't like seeing createItemBlock() in a base block class that all your blocks extend, but it's not that terrible). 4) Even better, make your class names include the base class, e.g. BlockMine_Lv_0 Oh god this is disgusting: https://github.com/THEJean-Kevin/goblin/blob/master/src/main/java/com/mineaurion/tjk/goblin/block/ModBlock.java#L31 You take a client-side-only event, call a piece of code that is not marked Side Only, then just forward the method call to your Proxy. Just do Main.proxy.registerItemRenderer(Item.getItemFromBlock(mine0), 0, name); https://github.com/THEJean-Kevin/goblin/blob/master/src/main/java/com/mineaurion/tjk/goblin/proxy/clientProxy.java#L23 Use item.getRegistryName() instead of References.modid+":"+name

Don't spawn items on the client. Only spawn them on the server.

Is one of the calls with simulate=true?

I don't understand your problem. What disappears?