Leaderboard

Alright thank you guys for all the help. In order to test that the underlying mechanic is working I added a right click event to my item and used this code to see if it gets the smelt result: String rLoc = new ResourceLocation(nbt.getString("parentBlock")).toString(); String itemResultStr = OreRefinerRecipes.getInstance().getSmeltResult(rLoc).getDisplayName(); player.sendMessage(new TextComponentString("Stored Block Smelt Result: " + itemResultStr)); and it returned the proper ingots So assuming all my code elsewhere is correct then my main mechanic to my mod should work. Haven't been this excited to finish a mod in a while. Thank you all so very much

If you want to use variants for your ore types you need to use a single block (BlockModOres) with a variant property, then distinguish your different ores by variant, including in the blockstate file. Here's the best example I have: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/flowers/block/BlockOreFlower1.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/blockproperties/flowers/EnumOreFlower1.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/oreflowers/blockstates/oreflowers1.json You'll have to pretend that some of the block properties (Props.FLOWER_STALK,Props.HAS_2D_ITEM) don't actually exist, as they're handled magically* elsewhere (and not relevant here). Additionally, the enum field for ore type is just a convenience mapping for my useage. A flat enum like you already have is fine. *I use a custom statemapper.

All of your ore blocks declare a variant which is not present in your blockstate.json

This won't work. ItemStacks do not override Equals (or the == operator). You need to check Item bitem = Item.getFromBlock(block); if(entry.getKey().getIem() == bitem) { }

Yeah, the general idea looks correct. You might need to trace through to make sure there aren't any detailed bugs, but conceptually yes -- you take the smelting list, you grab the block from the block recipe, and iterate through the smelting list to find a match. For storing in NBT, store the registry name (and anything additional you care about like metadata) then read the NBT to restore it from registry (and restore any additional info you care about).

I would probably say "Minecraft is blocky" and leave it with the imperfection. Otherwise if you're willing to work for the smoothness I think you can make a custom baked model, and if that doesn't work then yes a tileentity with special renderer. Others know more about it than me, but I'm certain you can achieve it with some work. The question is whether it is worth it or whether you can live with a Minecraft-typical "imperfection".

I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.