V0idWa1k3r

Blocks do not have any NBT data associated with them. Do you mean ItemBlocks or TileEntities? ItemBlocks are not different from regular items in this regard. You can use Block::getActualState to return an IBlockState that relies on something like a TileEntity to define values for some of it's properties. See BlockFlowerPot for more details and an example.

That is not how you use events. This is how you use events. The :: thing is just a way to write method references I use(and I use it because that is the 'official' way to write method references in java). When I say use ModelLoader::setCustomModelResourceLocation I do not mean that you should literally copy the line into your code. I mean to use the setCustomModelResourceLocation method from the ModelLoader class. And get rid of the Minecraft.getMinecraft().getRenderItem() entirely - you do not need it.

Well show your code and that error then. You... pass a new instance to the registerAll method. Like event.getRegistry().registerAll(new Obsidian_ingot()); That is essentially what you are doing already, you are just creating an unnecessary local to immidiately discard it. To set a registry name call Item::setRegistryName(%yourname%) somewhere, in your item constructor or chain it after instantinating your item.

Just use the ModelRegistryEvent as you would use any other event, like the registry events you are currently using. You use ModelLoader by calling ModelLoader::setCustomModelResourceLocation in the same way you are calling ItemModelMesher::register. The arguments are the same. I'm sorry, I haven't quite understood your question here. Could you explain it a bit better?

Do not use ItemModelMesher, it is buggy and outdated. Use ModelLoader and do it in the ModelRegistryEvent. Why do you create a local to immediately discard it? Just pass a new instance of your item to the registerAll method, you do not need a local. Also make sure that you have set the registry name of the item you are registering. That is not how things are registered. Create a public static final Item %NAME% = null field and annotate it with ObjectHolder with the registry name of the item. You can either include your modid in that registry name or annotate the class with that field with ObjectHolder and give it your modid.

You are using the wrong coordinate getter. You need WorldServer::getSpawnCoordinate, not World::getSpawnPoint

All redering must be done on the rendering thread. You need to use render-related events. You can still access capabilities and such from the render thread just fine. If the data you need is only present on a server then yes, you need a custom packet to sync the data to the client.

Entity::getCapability allows you to get a specified capability data. As EntityPlayer(and EntityPlayerSP) are child classes of Entity you can use this method just fine. Minecraft.player was never EntityPlayerMP as EntityPlayerMP is a multiplayer player entity. NBT has nothing to do with getting the data of a capability. Capabilities are common and are present on both client and server. What exactly have you tried? You can simply check that the active itemstack contains the desired item(if the item has a use duration) or if the currently selected itemstack contains the desired item and the right mouse button is pressed down.

You can simply use your IDE to navigate to any vanilla class (IDEA: Navigate -> Class, Eclipse: Navigate -> Open Type) and type in the name of the class you wish to go to. You can drop your own property and the enum and simply let BlockRotatedPillar do everything for you then.

Because BlockRotatedPillar specifies it. When you are setting a property in your blockstate the BlockStateContainer associated with that block must have that property in it's list of valid properties. You are setting a value of your property but the BlockStateContainer does not have it registered in it's list. Why are you extending BlockRotatedPillar that already has the rotation axis coded in and reinventing the wheel introducing your own axis property? Either do not extend BlockRotatedPillar or drop your property and enum completely.

Everything in the net.minecraft.server.dedicated package is server-side only, so if you want to access something from there you would need a server proxy.

No, he isn't. The constructor for PotionEffect takes in a Potion, duration and then amplifier so OP is passing 500 as the duration. Getting potions by ID though... Should not be used. I personaly have no idea what is potion with an ID of 9. And what if it changes later? Potions should be referenced from the MobEffects class instead of their IDs. Unlocalized names have nothing to do with registry names. This signature doesn't look right to me. I think that the method params have a different order. Add an Override annotation to the method. If eclipse reports an error then I am correct. You should not manually write overrides, let your IDE do that for you.

Assuming that your TE's code had not changed I think you are missing a super call here. You at the very least need to know the position of TE from the NBT so it can be loaded into the world properly.

There is nothing stopping you from separating that ItemStack/whatever requirement from a constructor argument into a setter method and invoking it some time later in your code at init for example.

No you didn't. Not in the class file you've posted. Honestly it looks like you are in a middle of rewriting some code in the class(for example you've added the Block::onBlockPlacedBy but it is empty). You should do it first and post the final code here if you have any issues left. As I've said blocks are singletons. Changing their properties like this changes them for all blocks of that type in the world.

Yes and there is no need to use custom data for that. It is your own tile entity. TileEntity::getTileData is for tile entities that you do not own but want to store some data in. If it is your own tile entity you can and should just declare some fields in that tileentity and set/get them when needed. The placement of the block already happens on the server. The server is already aware of the placer as you set it right there. You are literally setting your data on the server and then sending a server -> server packet. That is not a good idea. The client may be the one you need to notify, not the server.

Why are you using custom tile data on your own TileEntity? Blocks are singletons. When this piece of code is executed all your chests will become unbreakable. Even those which are not placed yet. Block::getPlayerRelativeBlockHardness allows you to handle block hardness in cases like this. This condition is redundant as it is always true due to this line above Why are you sending anything to the server at this stage? Both Block::onBlockAdded and the suggested Block::onBlockPlacedBy are common code. You do not need to send anything to the server - the server should already have all the data it needs.

You could use this if you need an instance of ItemBlock, sure. Or you could completely dismiss this line and just use Item::getItemFromBlock whenever you need an instance of ItemBlock. This should be in a client-only side class. In your client proxy or some place else. Yes, it will. First the registry event is fired for blocks, then all ObjectHolders for blocks get populated, then the registry event is fired for Items, then all ObjectHolders for items get populated, then all other registry events get fired in alphabetical order and all other ObjectHolders are populated last. Apart from all that - yes, looks like you are using the new registry system correctly.

If you are using an .obj model you must specify the file extension too.

You still need to subscribe an instance of a class that contains methods annotated with SubscribeEvent ot forge's event bus. Here is the tutorial from the official docs. Registry names should be entirely lower-case. You will have lang conflicts if another mod adds an item named modItem. It is a good practive to use your registry name as your unlocalized name to avoid such conflicts. Yes there is. It is called C Languages(C, C++, C#, Java, ObjectC)

I do not know how items work with this, I assume they are fine since all my ItemBlocks are displayed correctly but I am able to specify the texture for the material through the blockstates json file with it working just fine in the game.

The recipeList for the villager is indeed null on the client even if you intercept the interact event for the villager - the client simply recieves no data of the recipe list untill it's needed. When you open the Container of a villager MC sends a custom payload packet to the client. That packet contains the recipes for the villager. By the time the gui is opened on the client the packet is not yet recieved it seems. Waiting a bit does the trick. There is a big issue with using vanilla's packet though - it will only get processed if the GUI is an instance of GuiMerchant and the container IDs match. While there may be a dirty workaround for that(use a custom GUI that extends GuiMerchant and use the container of that GUI as your container...) I think that a cleaner solution is using custom packets. You do not need to create a "bunch" of them though - one should be enough. It would send the client the recipe list and be an indication for the client to open your GUI(the packet would then also need to carry some way of getting the villager on the client if you actually need that). Another somewhat helpful thing you have is that MerchantRecipeList already has the code in place for network writing/reading. It wants a PacketBuffer and not a ByteBuf though. You could find a workaround for that(like construct a PacketBuffer, pass it and reflectively get it's unerlying ByteBuf/get it via a method if possible). Or just use that/similar code adapted for ByteBuf, there is nothing special about that code that would be unique to PacketBuffer, it would be possible to replicate the functionality.

That is what you use language files for. The item.%unlocalizedName%.name is your key and whatever you want to see is your value. See how vanilla structures it's language files for more info

That should not be the case if by 'item's name' you mean "unlocalized name I see in the game". How do you know that the game uses the registry name as the unlocalied name? That should not be possible. In the game you should see item.wooden ring.name as the name of your item. If it would be using your registry name you would see item.simplerings:wooden_ring.name in the game when mousing over the item.

setUnlocalizedName requires a string as a parameter. That string will be the unlocalized name of the item. If you mean the registry name then it is Item::setRegistryName for that, but that is something you set once and never change. That is not a name, that is a ModelResourceLocation. Please clarify what you mean by "the name persists"