Draco18s

1.7.10 is no longer supported. The reason for the failed download is because the URLs changed some time ago and the installer you're using doesn't have the new URLs. Update.

NEVER extend BlockContainer. It is only used for vanilla blocks and does so many things modders don't want. SO MANY THINGS. LIKE THIS ISSUE.

Why do you need to run the command? Why not run the code that the command commands directly?

You have to use NBT for numbers that large.

I can tell you that it works in 1.12, as I'm using it.

So. In other words. Recreating metadata. I suppose you could do this by using a custom IStateMapper

Considering that the blockstate file dictates model and/or textures, if you were to use the same blockstate file, then the blocks would have the same texture. You're literally asking to do something that can't be done because you want things to look different, but use the same data that defines their looks.

Those blocks will have the same class, same properties, and different blockstate files, which will reference different textures.

IBlockState is a Block/Metadata combo. So if you have a new block, it will have its own block states. Please clarify.

10 minutes is not 200 ticks, its 12000.

It is, but containers (chests, things that hold an inventory) hold their items on the server, and for the game to synchronize what you're doing in the client-side-gui with the server, the server has to know that you're interacting with that container. So you open the "gui" on the server. What actually happens is that the server goes "cool, got the container, sending a packet to the client to open the actual gui, and maintain synchronization."

Create everything (calling new) in your PreinitializationEvent method.

What if they are wearing only a chestplate? Is the list still 4 items long? Are the items in the right order? if(armor.get(0) == narmor.get(3)) This will never be true. You should be using EntityPlayer#getItemStackFromSlot(EntityEquipmentSlot)

If you have a reference to the player, check their equipment slots. There are four of them.

You need to use their API.

This is over-engineered. The check for the Axis being Y and setting the facing to North isn't really needed. The only way this could ever happen is if you used external tools to force the block metadata to be something other than what the allowable states are. Use EnumFacing.getHorizontal(meta) instead. This is likewise over-engineered copy paste "I don't know what the fuck I'm doing" garbage. You created a local facing variable and then don't even use it. You even cast the property to an EnumFacing (why?) and use getIndex, which is wrong. No wonder you have to fix things with the getAxis == Y.... return state.getValue(BlockHorizontal.FACING).getHorizontalIndex();

Pretty much. You can use blockstates to determine which textures to show, and have some manner by which you detect that the multiblock is complete. Usually a central block that looks at the other positions around itself and if it finds them all, it says "hooray!" and the structure is built. Then when any of the blocks is broken, alert the central one and say "recheck!"

You cannot do this. If it was even allowed, programmatically (it is not), it would play havoc on the AI pathfinding and "can the entity be here" checks.

And you're in the wrong forum, you should be posting in Support & Bug Reports.

They are functionally identical. Pick a place to put your registration handler functions, where ever sounds good to you. And what tutorial was it? I would like to go tell the author they're being dumb.

Do you need help with that error, or not?

How did you compile your mod into a jar file?