V0idWa1k3r

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"

The way it is defined in your model file right now it would actually be src/main/resources/assets/simplerings/textures/textures/wooden_ring.json. You probably want to change the way you define your texture in your model file. Basically the path will be src/main/resources/assets/%modid%/textures/%path%.png. So a path like "simplerings:items/wooden_ring" will lead to a location of src/main/resources/assets/simplerings/textures/items/wooden_ring.png

Well the log says: Is there an actual file at that location(src/main/resources/assets/simplerings/models/item/wooden_ring.json) or a blockstates file at src/main/resources/assets/simplerings/blockstates/wooden_ring.json with an inventory variant defined? You'll need either of the two. Edit: yeah, your item model file must be located at src/main/resources/assets/simplerings/models/item/

That is an issue we'll need a log for

Yeah, that will work too. I still think that modders should use registry events even if they are not required to as that will make it easier to update later.

clinit is a way to say "class init", when all static things are set and the static block is fired alltogether. Practicaly what I'm saying is "define your item as public static final Item item = new WoodenRing(yourparams) and when your class is constructed the item will be initialized aswell". The docs are being worked on right now, I think. Apart from that they are open-sourced and if you do not like the spelling you are free to change it and submit a PR. Or an issue. Considering that the docs were written for modders in the first place... Anyway the registry system is pretty simple, actually. I'll link you an example in a minute and I'll edit this post when I'll do. EDIT: here(and fields) is an example. This is actually somewhat not the way you are supposed to do it now, but I am not sure if the way to do it now will work in whatever version you are developing for. You should still keep the 'latest' way to do it in mind though.

Booted an older project, checked the thing. Apparently in older versions ModelRegistryEvent is fired before pre-init so you can't have your items being created in pre-init. You need to use forge's registry system. Creating your item instances at clinit(public static final Item name = ...) 'should' work but is not advised. Haven't tested that.

You have only changed the method name. That does nothing, your method can be called whatever you'd like it to be. To change the lifecycle event(aka loading stage) change the parameter. There is FMLPreInitializationEvent for pre-init, FMLInitializationEvent for init, FMLPostInitializationEvent for post-init and a bunch of others.