V0idWa1k3r

Never register your things into the registries whenever like that. Register your biome in a RegistryEvent.Register<Biome> to the registry passed to you in that event.

FastTESR is for rendering tile entities in batch. That happens by initalizing the drawing buffer once, then the mods can upload vertices to the buffer passed and after everything is done there is a final draw call. That is way more performant than a regualr TESR since a regular TESR can use anywhere from 1 to infinity draw calls per render invocation where as FastTESR uses 1 draw call per however many TileEntities there are and draw calls are expensive. That however comes at a cost of a fixes BufferBuilder format and a fixed GL state. So yes, you can't use GlStateManager in a FastTESR since it screws with the GL state. In general you should use a FastTESR for a model that you can draw with the BufferBuilder that may or may not be animated. I have some utility methods to use with a FastTESR(like rendering an obj model or a cuboid) here if you want an example of what the FastTESR can be used for. However a FastTESR can't be used for some things. Pretty much anything that requires GL state changing or draw calls is incompatible with a FastTESR, and item rendering requires both. Hope this explanation makes it clearer for you as to when to use a FastTESR and when to use a regular TESR.

When you instantinate the multipart you specify the width and the height of it. Those are the dimensions of your bounding box. Then somewhere(presumably in your entity's update method) you update the positions of your multiparts using Entity#setLocationAndAngles. That also updates the position of the bounding box of that entity. See how EntityDragon handles the multipart positions in it's onLivingUpdate method.

What do you mean? As far as I know multiparts don't have a model. In case of the dragon it's only the main entity which has the model. Multiparts are purely for collision/damage detection.

Problematic code issue #14. Override Item#addInformation in your item class and add whatever strings you want to the tooltip list provided to you as one of the arguments.

Don't make your proxies extend your mod class, that makes no sense. Make an interface for them(IProxy for example) where you would define the methods your proxies should provide like I do here. There is no harm in the way it is. It is my personal opinion that having a method the only function of which is to call another static method is redundant and adds unnecessary code. If you are registering your blocks in method X make that method the event handler - there is no need to have a separate method that only calls this one and does nothing else.

Your json now contains syntax errors. It's missing a comma just before the result property.

By changing the structure of your json. Currently your result property is one of the properties specified in the key object. It however must be on the same level as the type property(have no parent). Pull it up one level. See this page on the minecraft wiki for the json structure.

Caused by: java.lang.RuntimeException: OBJLoader.Parser: Exception parsing line #70: `vt -1.42413e-16 0.845956` You still have uv coordinates issues. The uvs must be in range [0-1]. -1.42413e-16 isn't.

Your result object is specified as one of the keys. It needs to be it's own object with no parent.

Models are stored in the block and item folders respectively. There is no blocks folder.

Your recipe json has syntax errors. Specifically these lines: As an advice - install any kind of json syntax plugin in your IDE. It will then tell you if your json has syntax errors. Alternatively you can check your json files through a json validator like jsonlint.

As far as I know minecraft only supports one hitbox per entity and there is no way to lift this limitation. If you want multiple hitboxes you need to use multiple entities(some kind of a "parent" entity that handles all the logic and "child" entities that handle the damage). I believe vanilla already does something similar with the enderdragon so that might be a good place to start.

Well here is the answer. You were already registering your blocks somewhere else and thus putting the subscribeevent caused the blocks to be registered twice. You should just have the ModBlocks be a registration handler, not pass the event from somewhere else to ModBlocks. Think about it - your ModBlocks.registerBlocks already registeres blocks and takes the event as the argument. It doesn't do anything else so why not have it as the handler? Why handle the event somewhere else just to call 1 method? Also Code-style issue #1. Did you mean forge_marker? Currently because of this typo the blockstates is loaded as a vanilla blockstates file and that one expects the model property to be passed in the variant.

Are you registering your blocks in some other method then? You are not annotating the method meaning that the event doesn't fire but the blocks are still being registered meaning that you are registering them somewhere else and you haven't shown that. That would also be the reason for the error that gets thrown when you do annotate the method. You however haven't shown any code that registers the blocks somewhere else. As for the model loading errors: Caused by: java.lang.RuntimeException: Encountered an exception when loading model definition of 'extracraft:gunpowder_block' from: 'extracraft:blockstates/gunpowder_block.json' in resourcepack: 'FMLFileResourcePack:ExtraCraft Mod' Caused by: com.google.gson.JsonSyntaxException: Missing model, expected to find a string You need to post your blockstates file for the gunpowder_block. Looks like it's missing a model pointer.

You obviously need to add SubscribeEvent otherwise you will never get your blocks and items working since they will never get registered. Post your crash report.

Now you are registering different instances of the same block thereby ending with multiple entries with the same registry names. ItemBlocks must be constructed from the same block instance you are registering. The items you are registering for your model registry events must be the same instances of ItemBlock you are registering. Edit: Just to clarify - while it is perfectly fine to register different instances of the same block class as long as the registry names are different you are treating different instances as if they were the same object(which they are not) and you must use the same object to register it and obtain the ItemBlock instance(same with the model registration - you must use the registered itemblock objects to register the models with)

Your registry event handler methods aren't annotated with SubscribeEvent so your blocks and items should not even be registered. Do not use static initializers. Just initialize your blocks in the registry event.

No. Read the docs on the object holders. The field must be final. Don't touch it. Just declare it as null and never put anything into it manually. Forge will do everything for you. Just register new instances of your blocks/items in the registry event like I do here.

Just don't use it. This is for initial sync when the window is opened but you will sync all your data on the first tick anyway. Just get and set your variables directly. get/setField are wrappers for variable access anyway. For example instead of getField(0) you would use tile.progress and instead of setField(0, value) you would use tile.progress = value. I have an example in one of my projects here.

Check one, then check the other. player.getHeldItemMainhand().getItem() == Items.itemA && player.getHeldItemOffhand().getItem() == Items.itemB

EntityPlayer#getItemStackFromSlot. Or EntityPlayer#getHeldItem(EnumHand). Or alternatively EntityPlayer#getHeldItemMainhand and EntityPlayer#getHeldItemOffhand. Any of these will do the trick. Edit: Problematic code issue #12.

Caused by: java.io.FileNotFoundException: lanterns:blockstates/orz1_off.json Is your blockstates file named orz1_off.json? Make sure it is lowercase - all asset names must be entirely lowercase(I see that your blockstates file references the model with upper-case letters in it's name - that won't work)

Do you know java? Your IDE clearly tells you that this methods requires an EntityEquipmentSlot as a parameter, not an integer.

InventoryPlayer#armorItemInSlot is client-side only. Use EntityPlayer#getItemStackFromSlot