Animefan8888

Post the debug.log file.

Where do you call this?

net.minecraft.state.StateContainer.Builder is the correct one. Also side note use your IDE to override methods in a subclass.

Ok what is the problem? Have you ran those? runClient runs the Minecraft Client. runServer runs the Minecraft Dedicated Server, and runData I'm not a hundred percent on but I think it runs the Provider system for generating BlockStates and other json files.

Here is the forge documentation. It's a good place to look for things first, but it is very sparse.

You need a custom packet. Send your packet from the server to the client and when the packet is received call Minecraft.getInstance().gameRenderer.displayItemActivation(...)

The "minecraft: at the beginning IE "minecraft:diamond_pickaxe" is the modid for vanilla stuff.

Have you tried "modid:testitem"?

Metadata is old you are looking at outdated docs. A predicate is just an interface with one function you can use a lambda for it. The predicate is supposed to determine if the ItemStack passed as a parameter matches the item you want to remove.

This doesn't even compile. The goal is only running when there is an OcelotEntity or a CatEntity nearby. You have to use Reflection to get the Goal out of the GoalSelector.

It depends on your situation. Is there a finite number of possible Items? Will there be animation IE moving parts? If there are finite possible items just make a model for each state. If there are moving parts you have to use a TER. If there are no moving parts, but an infinite amount of possible Items then you should have a custom IBakedModel. The first is obvious how to do. The second vanilla has a Model class that it uses, you should probably use that. Take a peek at the Vanilla TileEntityRenderers. For the third option you need your own IBakedModel implementation that combines the Quads of an Item(s) with the Quads of your Block model. Then you must register it using the ModelBakeEvent by just putting it in the registry.

I don't believe this is true anymore. With the new vanilla BlockState system. However do not do this. This is also wrong, I don't know where you heard that. You register a Block to an IBlockColor instance and that instance determines the color for that block, for each BlockState in the World. Use a TIleEntity to store the state of the color. Don't use a TESR for this. A TESR is for something that has moving parts. It seems you have already found LeatherArmor, but you can use ItemColors and IItemColor just like you would for BlockColors and IBlockColor.

Java is just another program on your computer, you uninstall it just like you do everything else. Google it. It's different for each OS.

This error happens when you setup your environment with Java 9+ and then run it with Java 8. If your JAVA_HOME is set to Java 8 now create a new workspace. If that doesn't work uninstall all Java 9+ then setup another workspace.

At the link you can download the fields.csv file and open it like a txt file and look for the field names.

Specifically the and Need to be the obfuscated names. Check out here.

Check out this post.

You never linked it how were we supposed to know or have access to it. You need to specify what you are attaching it to IE AttachCapabilitiesEvent<Entity> then to only attach it to player do if (event.getObject() instanceof PlayerEntity) then add the Capability. Here's your NullPointerException an issue... Did you forget to update your git repo?

Creating a tag for those items. Use IMC events to communicate between the mods.

Does your CompoundArrowRenderer's constructor ever get called?

I said to override the getType method I assume public TileEntityType<?> getType() { return MyTileEntityTypes.MY_SIGN_TYPE; } Would work just fine.

Why would the type be invalid during AttachCapabilitiesEvent? AttachCapabilitiiesEvent<TileEntity> gives you the TileEntity object not the TileEntityType and the event is fired when the TileEntity is constructed aka when the block is placed. By then the Type has been registered and the TileEntity::type field is private and there is a TileEntity::getType so no need to use Reflection to access it. I fail to miss how this breaks certain mods.

This is true. Don't I look like a fool. Instead override TileEntity::getType and return your own type.

Each TileEntityType has a Set<Block> which are the valid Blocks for that TileEntityType. So you will need your own TileEntity. However you can just extend SignTileEntity and override the constructor that takes no Parameters and pass your own TileEntityType into the super constructor.