Draco18s

The Side parameter is which side is the receiver.

PlayerAPI is a mod, it is not in forge. You need PlayerAPI.

Use submodels. That's what you're trying to do.

RegisterShitHereAndStopBreakingStuffEvent would have worked just fine.

Usually button images are contained within the same 256x256 graphic as the rest of the UI (see: the beacon gui image file).

You can edit your post. And if you edit the original post, you can edit the title too. Your problem is likely that the classes and drawing methods you use are intended for textures of exactly 256x256 and you have supplied a 20x20 pixel texture.

You have a typo.

No. And if anyone can point me at a tutorial that is saying to do this, link it, so I can go punch that person in the face for being an idiot. Problematic Code Issue #1

You have copied code from someone else. Your CommonProxy class does not contain a preInit(FMLPreInitalizationEvent event) function, yet you are trying to call it. Of course there is no error in the CommonProxy class, this function doesn't exist and there's no reason that your CommonProxy thinks it should. This is the same reasing calling Math.CalculatePie() throws an error. There is also no reason this method should exist either: anything you might do in your common proxy you can do in your main mod class. See Code Style Problem #2. item.getRegistryName(), you somehow inserted a comma instead of a period, because that function takes 2 parameters. Additionally, you should only be calling this code during the ModelRegistrationEvent.

You didn't need to post 90% of that log. The error itself was probably sufficient. BTW, you have a missing model: Caused by: java.io.FileNotFoundException: zeldadungeons:models/item/health_shard.json

Forge blockstate format.

https://github.com/NicosaurusRex99/farts/blob/1.12.2/src/main/java/naturix/farts/network/PacketSendKey.java#L38-L47 Did you miss the warning?

YOU DON'T HAVE TO. NO ONE SAID YOU DID. YOUR the one who started asking about Forge blockstates. And this isn't even your thread! The whole reason the Forge format exists is to simplify complex state mappings (two or more different values) as Forge will do the cartesian grid for you (so you a) don't have to type out 366 lines of JSON and b) don't have to sort them alphabetically and get it wrong by fucking up and adding a space where one shouldn't be).

You know how much of what you posted was Forge format specific? None of it.

Which one of those two samples that I posted was more complicated?

...

Partial Ticks is what fraction of a game-tick the current render frame is on (if the game runs at 20 ticks a second and the application is rendering at 60 frames a second, then each frame is 0.3333 of a tick). Partial ticks only make sense client side, so please double check that that rayTrace method is not marked @SideOnly(Side.CLIENT)

You need to create a new lightning entity and spawn it in the world at the desired postiion. You can get that by doing a ray trace from the player's eye position and look vector and getting the point that that ray collides with something. There's a raytrace method in the World class that will work (look for a method that returns MovingObjectPosition)

I'm not sure I can in any way explain how this works, but I know it does: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/client/ProspectorParticle.java I only render the particles on one client (not all clients) and I use packets to tell the affected client it needs to render the particle and then handle the message via my client proxy.

The standard for containers is to divide the current used capacity by the total capacity and floor to an integer.

Because the vanilla blockstate format looks like this: "stateA=1,stateB=1,stateC=1,stateD=1" : { ... } "stateA=1,stateB=1,stateC=1,stateD=2" : { ... } "stateA=1,stateB=1,stateC=2,stateD=1" : { ... } "stateA=1,stateB=1,stateC=2,stateD=2" : { ... } ... //11 nearly identical lines skipped "stateA=2,stateB=2,stateC=2,stateC=2" : { ... } And the forge blockstate format looks like this: "stateA" : { "1" : { ... }, "2" : { ... } } "stateB" : { "1" : { ... }, "2" : { ... } } "stateC" : { "1" : { ... }, "2" : { ... } } "stateD" : { "1" : { ... }, "2" : { ... } } Which would you rather write?

This has been asked for many times. It will never be done because it would be out of date for someone instantly, as many people work on different versions of Forge.

I also have an easy way of handling block and item registration. I do endeavor you (the original poster) to write your own code to register blocks and items first (do it once) so that you understand how its achieved. But I wrote a couple of classes that clean up my main mod class significantly while also being highly flexible and capable of registering blocks and items with any possible deviation (that I know of). I've also got some other hooks that are incomplete (does not yet handle everything, just everything I've needed) such as enchantments and advancement triggers (currently requires reflection). https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java These two classes act as CommonProxy and ClientProxy in a library mod (yes, yes, code style #1) hence lines 55-81 in the first class, which redirects static method calls through the HardLib proxy. Example usage: millstone = new BlockMillstone(); EasyRegistry.registerBlockWithItem(millstone, "millstone");

Post the log. There will always be an error in the log about failed models/textures/blockstates. In addition, I notice that your blockstate has 48 possible states, of which only 16 can be encoded in metadata (i.e. without using a TileEntity). The rest need to be encoded in either world information ("there is a solid block under me") or in a TileEntity.