Draco18s

That would be this stuff https://github.com/Cryptic-Mushroom/The-Midnight/blob/4bef239506abd6a401af55a95c6f52bdbfe589c8/src/main/java/com/mushroom/midnight/client/render/block/BlockRenderLayer.java#L11 Client side only which there should be an FML lifecycle event you can call it from (that mod uses FMLCommonSetupEvent).

Render layer is no longer handled by the block class, which is why it was removed and commented.

...yes...the line I directly linked to...

That png is referenced in this model: https://github.com/Cryptic-Mushroom/The-Midnight/search?q=bogweed_glow&unscoped_q=bogweed_glow Which is unused. The glowing parameter refers to whether or not it emits light: https://github.com/Cryptic-Mushroom/The-Midnight/blob/1.15.2/src/main/java/com/mushroom/midnight/common/block/MidnightPlantBlock.java#L39

Related, does documentation for how to use the JS system exist somewhere? I have no plans on using it, but beyond references I've seen to its existence (and one person linking to some code they wrote using it) I know nothing about it. (And its fine if the answer is "no" or "yes" without saying where)

I thought that fullbright or no-shade is possible with block json models, let me see...try this: https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/eb320948208a91fe4d21f364cb6973b335f367df/src/main/resources/assets/testmod3/models/block/fullbright.json#L10 Though that might not actually be sufficient.

This basically can't happen. ModEnergyStorage extends EnergyStorage, so getting a class that is the former and not the latter is impossible. Is this getting called? No? Have you tried figuring out if the parent method is getting called, but skipping over the lambda?

Considering that I don't know what you actually did, I have no idea.

Those are two different things. IEnergyStorage is the interface that defines the storage of the data, CapabilityEnergy.ENERGY is the type of capability. Anyway, the class I was referring to is one that Forge created (EnergyStorage note the lack of an I on the front), I thought they left it for modders to implement, I was wrong. What I'd do, then, is, extract all the energy that the client side capability thinks it has (just dump it on the ground, all we care about is getting the internal value to zero) then inserting the value received from the nbt data.

You implemented the interface somewhere, yes? Use polymorphism to your advantage.

Gosh if there was only some other method that accepted a value instead of returning it.

Yes. You want a model that uses more than one texture, create a model that uses more than one texture. They're not magic, a model that only looks for one texture cannot and will not do anything with a second texture.

I'm sure that when you're READING its a great idea to WRITE. Try READING instead.

Editing* Edition means something else entirely. No I do not think so. At least, not easily. There might be a way if you intercepted the rendering, but having not tried to do this, I am not sure.

This is true for all rendering. That's why translation matrices exist. Check for a method in the player class that does this calculation for you, the last time I did something like this I had a line that called player.getPosition(event.partialTicks); Beyond that I can't see any problems.

handler is your capability instance, you don't need to call getCapability inside here. I don't know why you're doing this. Use ifPresent Yes, that's it, just throw the value into a local variable, I'm sure nothing could go wrong.

Don't do this. Return super if the capability isn't the one you care about, you never know who else might attach a capability to a stack. Scratch that, I was thinking about how things work for TileEntities.

Capabilities aren't sync'd to the client automatically. That is not how you get a capability. Minecraft calls that method automatically when an item stack of your item is created. Do not call it yourself. Call getCapability on the stack instead.

initCapabilities is called once per item stack, you don't need to worry about calling new there. What you do need to worry about is not calling new inside getCapability Hint: inside new ICapabilityProvider() { } is a class.

Ah, I had forgotten.

Well, sort of. should be item.modid:itemid Because resource locations are correctly separated by colons.

Are your folders nested folders (models/item/) or do you have one folder named with a . (models.item/)?

You're also still recreating the LazyOptional every time its gotten. Compare: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/AxelTileEntity.java#L28

...which is why deferred registers exist, because people couldn't be bothered to not statically create everything.