Draco18s

That doesn't even make sense. There are exactly 2 types of JSON file: - Model - Blockstate Every block that has more than one state uses both. All other blocks don't need the blockstate file.

1) [19:56:14] [Client thread/WARN] [FML]: * The object Block{cmo:blocklithium_block} has been registered twice for the same name cmo:blocklithium_block. You have a block being registered under the same name as another block 2) Caused by: java.io.FileNotFoundException: cmo:models/item/blockjohnny_tnt.jso Caused by: java.io.FileNotFoundException: cmo:blockstates/blockjohnny_tnt.json You have missing JSON files. Or they're in a different place than they should be.

Not as bad as you're thinking. You need thousands of them. All being rendered at the same time. If the TE itself isn't ticking, it doesn't apply any impact. You're not overriding a vanilla block, you're extending it. Hahaha no. While you could certainly tell Forge, "the client doesn't need my mod" and the client will connect, they're not going to see all the special blocks and items you've added. This custom barrier block thing-a-jig you're making? That requires the code to exist on the client for it to work.

Would be better if you created a git repo and hosted it on GitHub Basically, you need to fiddle with the display tag of your item model.

For example I have this IStateMapper: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/states/StateMapperFlowers.java#L23 Which handles the "upper/lower" halves of my two-tall flower block (not all variants have a valid tall state). I register it through my EasyRegistry class (which is the proxy/client proxy of a library mod) https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/OreFlowersBase.java#L93 https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L57 Note that IStateMapper is client side only so I had to finagle things to work properly. I am not sure how I would do this using the Registry events.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/block/BlockTanner.java#L90-L104

Caused by: com.google.gson.JsonParseException: Expected between 1 and 6 unique faces, got 0

Question, those folders, are they named "assets.trim" or are they actually two canonical folders and your IDE is just displaying it that way? That is, what does Windows see?

GuiIvVillagerInfo does not interact with the UUID. There is a distinct lack of the string "UUID" in that file.

This is a horrible idea. Bad modder, no cookie. Core mods are not allowed here. I suspect the easiest way to do what you want to do will be to use a TESR, although I don't know if it would be possible using a FastTESR, but if so, that would be better.

I suggest making the block not-falling and working out what the position it is that it finds and figuring out how to offset it from there to where you actually want it.

I don't think he's programming a mod, I think he's trying to run one. Which means he needs to be over in Support and Bug Reports.

Can See Sky is probably a bad choice. You will probably want to look for skyLight > n, where n is some value > 0 and <= 15. Right now I think you're code will end up looking for water in the tree tops.

You should try asking them.

Ew. What will you do when you want to use the same class for more than one block?

What happens if you put an @Override annotation on it?

Yes there is. Try again.

This makes sense...in vanilla. If you're making a mod and want to expose your block properties, then the enum should be exposed (but not necessarily the block) in an API.

Oh I agree. Just that some new folks don't know that and seem to think that because the code is in the same file it's fair game to dip things that won't work. Like making the message and message handler the same class...

Eg https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java That class is set up to only allow extraction, not insertion, but the methodology is the same. I recommend this because it us a wrapper around another handler that CAN have things inserted into it (eg by the machine's own logic) but which isn't exposed directly.

While true, I recommend against it due to the potential to confuse the scope ("my packet handler runs, but it doesn't recieve the data, but I know I'm sending it!") as the modder tried to reference the packet data not from the object passed, but through container scope, even through the objects were different instances. Keeping them in separate files helps the fledgling modder. I use nested classes for things like data wrappers, where I need to bundle two items together for a sorting function, or similar, but that that wrapper is never used outside that scope.

What're you, 12?

No, that would also be wrong. ITileEntityProvider is also out of date (look, it even still uses metadata) Override the createTileEntity() and hasTileEntity() from the Block class