Draco18s

Ok, solar panel. Look to see what RF solar panels generate. There's your equivalence.

I suspect the problem is that the color is coming from NBT and he's using the onCrafted to apply the NBT, rather than in the recipe output declaration. Or something similar.

You'll have to look for some sort of equivalence. I.e. both mods convert charcoal to power via a generator, then the output values of those two generators are "roughly equal." And that's your conversion ratio.

Alternatively if his mod is open source, you can write the block into his mod as a pull request.

Step 0: Know Java Step 1: Know how to mod Step 2: Get the RF and AVP apis Step 3: Convert!

You will probably need a custom IRecipe implementation.

container items. you need to override hasContainerItem and getContainerItem to return the damaged item.

That is most definitely not what that means.

Sooo...question. Why are you using Item.getItemFromBlock when you're the one who had to create the item in the first place?

what's likely wrong is that ModIdSFHCORE contains only the mod ID, whereas the dependecy string wants to look like this: "require-after:modID[v1,v2]"

Then your registration is fubar.

Your problem is here: version=Constants.NTMVersion, dependencies=Constants.ModIdSFHCORE And that class file is not in your repo, so I can't examine it more closely.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/models/item/diamondstud_pickaxe.json

Are you a modder or a player? If you are a modder, post crash log and code. If you are a player, what mods are you using? Contact those mod's authors.

Gosh, if only those pages had an example on them. Something somthing player.getServerForPlayer something something.

Yes

Technically with code you can enchant a stack of items. Just that if they're tools and take damage, ALL of them will until split. They can't be recombined, but if created that way, they are still stacked.

Well...do you ever call setUnlocalizedName on the block?

1) You didn't post the crash, but.... 2) Do not put the IMessageHandler in the same class as the IMessage. You'll only make it harder to separate out which bit belongs to which class.

That's because you never set it: if(block instanceof MarbleSlab) { ItemSlab itemSlab = new ItemSlab(marble_slab, marble_slab, marble_double_slab); itemSlab.setRegistryName(Reference.MOD_ID + ":" + "marble_slab"); return register(block, itemSlab); } You never call itemSlab.setUnlocalizedName(...)

Caused by: java.lang.RuntimeException: Encountered an exception when loading model definition of model betterments:blockstates/marble_single_slab.json You don't have a json file named "marble_single_slab"

You don't ship APIs with your mod. You should not be altering any code inside the Mekanism packages.

If you can get their source code, yes, that would fix it. As your mod has a hard dependency on Mekanism it won't matter to the end user. Mekanism should still fix their shit though. Seems to me that MekanismRenderer.FluidType should be in the API package.

In your item class's constructor? Like....where else would it even make sense. You could also look for existing usages for examples. new Item().setRegistryName("blah").setWhatever(...).setSomethingElse(...) is effectively the same as inside the constructor, as those methods return this so they can be chained and used without needing a unique class. I personally don't like doing it that way when I have a unique class, but that's up to you.