DavidM

Get the instance of Minecraft.getInstance().getItemRenderer(); inside IRenderFactory#createRenderFor, and use the returned item renderer in new RenderSprite<EntityProactiv> as the item renderer parameter.

In that case you'll have to open the chest first. I might have misunderstood your problem. I thought you meant to grab all items out of nearby inventories in a 11x11 area without opening them. Yes, this is possible (although I am not sure whether this is encouraged). If the intention of your mod is to cheat on servers (like auto grab stuff out of chest in hunger games), then I'm afraid you shouldn't be doing it.

AFAIK you can't transfer items from one inventory to another without the player opening the chest in a client only mod.

1. How is the "middle of the area" defined? 2. Get the tile entity of the chest and get the item handler capability from it. 3. World#getEntitiesWithinAABBExcludingEntity (pass the player in the parameter to exclude it)

Can you elaborate? Where exactly are you trying to get the item? In json: just enter the registry name, like "minecraft:stone". In code (to get the item from registry name) : Item.REGISTRY.getObject If you are trying to get vanilla contents, consider using the values from the Blocks and Items class.

private final Table<ItemStack, ItemStack, ItemStack> smeltingList = HashBasedTable.<ItemStack, ItemStack, ItemStack>create(); private final Map<ItemStack, Float> experienceList = Maps.<ItemStack, Float>newHashMap(); @Blue_Atlas At this point I would just recommend making another entry class instead of trying to do everything with Map, then store recipes in a list of entries for the following reason: 1. Your recipe gives experience, and using a separate map for experience is messy. 2. In your current code, you are iterating through the map to find the appropriate entry. 3. Custom entries are more flexible so that you can include more information.

Also, clean up your code, as a clearer logic will fix most of the problems you've stated. Besides logical errors, also optimize your code. For example: public float getNonEnergyForgeExperience(ItemStack stack) { for (Entry<ItemStack, Float> entry : this.experienceList.entrySet()) { if(this.compareItemStacks(stack, (ItemStack)entry.getKey())) { return ((Float)entry.getValue()).floatValue(); } } return 0.0F; } The point of having a Map is so that you don't have to do this.

I did my best trying to understand what you’ve stated here, and assume that you are keeping the fuel code so that you might revert to using fuels if the block formation idea does not work out. What I’m trying to tell you is to delete all your fuel related code and try accomplish the block formation idea first; if that does not work out, then revert to the commit of your fuel related code. So yeah, delete your fuel related code, as there is no reason to keep them at this point.

1. Deleting part of a feature can and will cause unwanted behaviors. You can always revert back to your previous commit in case something went wrong, so you might as well delete your fuel related code. 2. Right, and the progress bar of your furnace will never move because the TE thinks the furnace is not working. No, that is not the desired behavior. According to your code's logic, the isWorking method should determine whether the conditions are met for the furnace to work; the burnTime is completely irrelevant to this. 3. Clean up the logic in your code. I assume that you copied the code from some (poor) tutorial without knowing how it actually works, resulting in most of your code being messy and redundant. Always make sure you understand the code line-by-line before using it.

How are you downloading it and why are you downloading it? Forge already contains MCP mappings.

1. The IHasModel interface can actually be harmful in that it confuses beginners how the model registry actually works. Examples of which being: http://www.minecraftforge.net/forum/topic/69344-solved-1122-block-item-texture-missing/ http://www.minecraftforge.net/forum/topic/69142-texture-not-showing/ Both Modder are confused on how the model registry works, and led to double registering/didn't register some model due to the inconsistence usage of IHasModel. 2. Again, the point of OOP is not "make my code look nice". 3. Never judge a code in the sense "it works so it is fine". Optimizations, readability and conventions matters.

1. As for good tutorials, TGG made a text-based one (personally, I would say this is one of the best tutorials out there as it explains every single concept in great detail (apart from the usage of the common proxy)) : https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample 2. Forge has an event handling system which makes processes like registering items and blocks easier. Always instantiate and register blocks/items in the corresponding event.

1. A registry name is like the unique identifier for a block/item. 2. Push your repo. I cannot find your code for your block in all 4 branches.

Copy and paste the content. Use the spoiler to post long stuff.

Either 1) Read the EAQ. or 2) Google "minecraft log location".

1. Remember to set the block's registry name with Block#setRegistryName. 2. If you want to have an item representation of your block, you also need to register an ItemBlock of it (in RegistryEvent.Register<Item>): itemRegistry.register(new ItemBlock(myBlock)); .

Post your log.

Remove the Obsidian Animator mod.

The Obsidian Animator mod is broken (as far as the log indicates). Remove it and report to its author.

Coding style, 1 and 3.

I suppose you meant TileEntitySpecialRenderer. How is that related to IHasModel? Do not abuse inheritance to "just keep my code cleaner". Composition over inheritance.

https://gist.github.com/Cadiboo/fbea89dc95ebbdc58d118f5350b7ba93 Short version: "Every item/block has a model, therefore every single item/block should implements IHasModel". Well, in that case, since every item/block has a model, then why bother to create another interface for it? Why not just register every item/block's model? Theoretically, IHasModel would not break anything. However, the concept itself is totally pointless, and causes people to write extra useless code. The point of IHasModel is to distinguish those with a model from those without a model; however, everything has a mode. The whole point of having proxies is that they run code based on the sides, which is the exact opposite of what a CommonProxy does. Proxies should not have common code. All common code goes in the main mod file.

Depends. Starting with bad practices might cause people going back and rewriting everything (which normally isn't the desired case). I personally had the painful experience of going "wtf why" as videos promote (terrible) practices like CommonProxy and IHasModel when I first learned to make mods. AFAIK it is the other way around. McJty's tutorials are indeed good, but the rest of the tutorials on youtube only covers the basics, as well as suggesting "just copy the code and paste them in your code because it worked for me" (i.e. loremaster and harrytalks). Text-based tutorials often go in more depth about concepts like packets, complex item/block behaviors, rendering, and networking. To sum it up, I would recommend to start with video tutorials like McJty's, and move on to text-based ones. It is easy to get lost if you start with text-based ones at first, so you might want to get the feel of modding by watching videos first. It's up to you, really.

1. Do not watch tutorials on youtube, as most of them do have bad practices. Most good tutorials are text-based, here is one for example: https://github.com/TheGreyGhost/MinecraftByExample/ 2. Be prepared to make mistakes and get criticized. The best part (and perhaps the worst part) of the Forge Forum is that people are blunt in pointing out all the mistakes in your code. This is a great way to learn coding practices, as well as how to use the Forge API properly. 3. 1.13.2 is indeed quite new, and there are not enough tutorials out there. I would suggest you to search up 1.13.2 mods on GitHub and learn from their source code.

Because: 1. Terrible tutorials (Like loremaster). 2. Some people want to make Minecraft mods but don't want to take the time and learn programming tend to "I don't care how it works. Just gimme the code for it".