Jay Avery

The string you pass to your @ZenClass annotation doesn't match the class it's referring to. What do you think that string represents?

You're misunderstanding that code. A StringBuilder is a kind of mutable string object. All that line of code does is put together a string from those components - the result is (almost*) equivalent to just using the + operator on string literals directly. (*StringBuilder tutorial) Simple model code is usually controlled entirely in the json model files. If you want more help understanding or adapting the code that you found, we need (lots) more context to understand what it's doing.

You shouldn't use Minecraft.getMinecraft().getRenderManager() - the createRenderFor method has a RenderManager parameter for you to use. (The render factory methods are called in the constructor for Minecraft's RenderManager, so it's null at the time you call it.)

RenderingRegistry.registerEntityRenderingHandler is overloaded with two versions that take different arguments. The version you are using takes a Class and a Render as parameters. This version is deprecated and due to be removed in a later version, and it's not recommended. But if you do use it, it must be in init, not preInit - that's the actual cause of your current issue. The recommended version of that method to use takes a Class and an IRenderFactory as parameters. An IRenderFactory is a functional interface with one method which simply returns a new instance of the entity Render. That version should be called in preInit. Your IDE should show you this information - the methods have doc comments explaining how and when to use them, and the old version is annotated with @Deprecated.

Take a look through the forge docs, which summarise most things well enough to get started. The forge workspace comes with an example mod file which you can look at to see the structure.

You don't have to compute them all when loading the models, just calculate them on the fly (as you currently do) but store the result in a cache (a map from the state to the list of quads). Then at the start of getQuads, add a check for whether your cache already contains the state, and if it does just return that instead of calculating anew.

We can't help with your updated code unless we know what has changed. This would be easiest if you create a github repository so you can push changes as you go along - but if not, then you need to post all of your updated code every time you change it and still need help.

What exactly do you mean by NBT stopped working? What do you find in the debugger? Are the read/write methods being called? Are the values null or incorrect? What was the last thing you changed before the problem started?

There's no isPublic field, so what do you mean by this?

What tells you that the power is reset after one tick? Are the values different on the server and client? Edit: Actually this is probably because TEs are refreshed when the block state changes, which you do in your updateInventory method. To stop this from happening, you can override shouldRefresh in you TE to only return true if the block is different. Also, your getActualState method does nothing, it just sets the powered property to... the current value of the powered property. If you have a TE to store the power information of the block, it's best not to store that information in the block's state as well - that just leaves more likelihood of them becoming mismatched somehow. Instead you can simplify it by only setting the block's powered property in getActualState, by checking the TE's data. Then scrap the metadata methods (because the powered property doesn't need to be stored in the block as it's already stored in the TE), and the setBlockStates in the TE (because it's all calculated in getActualState whenever it's needed). On an unrelated note, your blocks are 'stringly typed'. You should use an enum for this purpose.

You don't need to use an event to control the behaviour of a class which you wrote yourself. You can just do the checking in the onBlockActivated method itself, all in one place.

Post your TileEntity class.

You're defining the type in a static field. This means the value is the same globally, not different for different instances.

If you want to make your properties different based on other properties, the only solution will be to define every combination of variants separately. In the vanilla multipart format, you can define a list of conditions to be true for a certain part (e.g. "when": { "type": "advanced", "north": true }), so you can combine variants in that way.

Do you remember when I said this?

What exact functionality do you want, and what isn't happening?

Read the page I linked you.

You need to override createBlockState in your block class. Read the page I linked you, this is explained in there.

Have you read the forge format documentation? Inside your "variants" tag, you need one tag for each property in your block. By the looks of it, you have two properties, "type" and some unnamed facing property. Inside each property tag, you need one tag for every possible value that property can hold. So "type" needs to contain one "basic" and one "advanced", and the facing tag needs to contain one for each direction. Inside those, you specify the effects this individual property should have on the block - adding a submodel, altering the rotation, etc. When the bock is modelled, the effects of each property are all combined to produce the final result.

This is not a valid blockstates file. It looks like you're trying to nest properties inside one another, but that's not possible with the forge format. You need to list the effects of each property separately (as the forge format specifies), or use fully-defined variants (vanilla style).

Be more specific, no-one here is looking at your workspace or reading your mind.

You can NEVER use instance fields to store information about individual blocks (or items), because they are singletons. There is only one instance of that block in the entire game, so if you change that isOn field, it will effect every block of that type. That's what blockstates are for. If your block is supposed to face a specific direction and behave accordingly (like a comparator, repeater, observer, or etc), then you will also need a facing property in your blockstate.

All asset paths (model names, blockstates, textures) must be entirely lowercase.

Thanks for the tip! I've implemented my own NetworkChecker, and then found that... it still ignores the version compatibility when connecting to vanilla servers. I tracked it down to FMLHandshakeClientState.HELLO, where it shortcuts all the checks and immediately returns DONE if it doesn't get an FML message from the server. So I don't even get a chance to intervene using my own NetworkChecker. So I guess this means that any forge client will always be able to connect to a vanilla server, and I just have to trust users not to be silly enough to do that? It seems like a strange arrangement..

Exactly what do you expect to happen, and exactly what does?