V0idWa1k3r

Do you use 32bit java? What's the output of java -version if you type it into cmd?

You only need 3 gigs for decompilation though so technically you do have enough memory.

Why? You should have the decompiled source code. It is pretty much necessary for learning modding. How did you setup your workspace?

You do not need this iterative mess. You already have both inputs in a triple, that's why I recommended a triple in the first place. This just makes your iterations take O2 instead of O time to complete. Just do for (Triple<ItemStack, ItemStack, ItemStack> triple : smeltingList) { if (this.compareItemStacks(input1, triple.getLeft()) && this.compareItemStacks(input2, triple.getMiddle())) { return triple.getRight(); } } Or even better return smeltingList.stream().filter(t -> this.compareItemStacks(input1, t.getLeft()) && this.compareItemStacks(input2, t.getMiddle())).map(Triple::getRight).findFirst().orElseGet(ItemStack.EMPTY)

You need to provide both the MCP(for dev) and the SRG(for non-dev) names. Use ReflectionHelper.findField. It even sets the field as accessible for you when it finds one.

See EntityZombie#onKillEntity

I can't really type it out for you since that won't help you. I can guide you through the steps needed at most: Replace your Table<ItemStack, ItemStack, ItemStack> field with a List<Triple<ItemStack, ItemStack, ItemStack>> field When adding new things to the list do List#add(Triple.of(input1, input2, output)) When iterating through the list do the enhanced for loop (for (Triple<ItemStack, ItemStack, ItemStack> triple : list)) When comparing ItemStacks use triple#getLeft and triple#getMiddle. When getting the result use triple#getRight. Or however you choose to represent your items in said triple. Or better yet instead of manually iterating the list you can use java8's Streams - list.stream().filter(...).map(Triple::getRight).findFirst()(pseudo-code) That gets you an Optional<ItemStack>. If that optional has an element then the recipe was found. Otherwise there is no matching recipe. Make sure you cache your recipe that you've found in your TileEntity because streams are relatively expensive(although there is a point to be made that after a certain amount of iteration the JVM will optimize the stream(see this) but caching is still much better) While this is valid java code it changes nothing compared to your previous implementation. You've just initialized a new local List<Triple<ItemStack, ItemStack, ItemStack>> that by default is null and did nothing with that local.

What exactly did you not understand? Use X instead of Y means "replace all X with Y", so using a List instead of a table would mean to replace the Table field with a List field and adjust your logic accordingly to the change(iterate the list instead of a table, etc.).

This is not even valid java code. Do you know java? If you don't then learn the language first before making a mod.

You can find the .csv files that contain a mapping of SRG-MCP names in %username%/gradle/caches/minecraft/de/oceanlabs/mcp/mcp_snapshot/[date]. Or at least that's where I look them up, this changed a lot between versions so I might be incorrect. Please correct me if I am. Or you can use MCPBot. Although I've never used it it should be as simple as joining the channel and typing a command.

You need to fix all the issues regardless. Now you have this problem and later you will have an issue of EnderIO pipes not working with your machines and you will come here again asking for help and I will have to tell you for the fourth time to stop using IInventory. I am not telling you to fix those issues just as a friendly advice. Those are issues that need to be fixed or they will create more problems in the long run. It is easier to fix them right now while your codebase is small rather than only fix one specific issue to later find out that you need to rewrite everything to fix some other issue. As I've said I suspect either the broken logic in the condition I've linked 2 times now or in your Table iteration. So the solution to this particular problem would be to fix the logic and switch from a Table to a List<Triple>.

I am also pretty sure this will not work. You need an existing instance of BiomeProvider, not the one randomly created out of nowhere. And this needs an SRG name too or it won't work outside of dev environment. And it needs to be static and final. Field lookups are expensive.

Well stop using IInventory and use capabilities instead(IItemHandler/ItemStackHandler). Do not use CommonProxy but use a shared interface(IProxy, for example). Do not use IHasModel and register your models directly in the ModelRegistryEvent. Make the logic correct on this one, it doesn't seem right to me. And as I've said switch from using a table to using a list of Triples.

I already told you to never use IInventory in your other thread. Fix this. Please at the very least fix this. Same with this. And this. These are issues that need to be fixed. While they are not the cause of your main issue they still need to be fixed. How do you want your furnace to work? From what I can decode you want a furnace with 2 inputs and 1 output. Is that correct? In that case consider rewriting this mess Instead of using a Table(and having this iterative mess as a result) consider using a List<Triple<ItemStack, ItemStack, ItemStack>>(left: input1, middle:input2, right: output) that is easier to iterate than a table. Or at least iterate your table by Table#cellSet. Tables are used for column - row => value data storage. This is not the use case for a table(in my opinion). I think that your error lies either here... Why do you need this if you continue using this.isBurning everywhere else in your code? What's the point in this boolean declaration if you don't use it? So, continue the burning checks if the furnace is burning or if the coal slot isn't empty and (stack in slot 0 isn't empty or stack in slot 1 is empty)? This doesn't seem right to me. Check your logic. ...or here Aren't you forgetting something? Your recipe class checks for something else in addition to just item comparason. Why doesn't your tile do the same? And the contents of this method. Please do not blindly copy vanilla classes. This method is public and static in TileEntityFurnace and you have changed nothing in it. Why copy it at all? Just use the one TileEntityFurnace provides. Otherwise you are a)doing unnecessary work b)making it harder for you to upgrade later c)breaking compatibility if some modder uses asm to modify the method in TileEntityFurnace(although they really shouldn't) Also your code is impossible to read on the dark theme.

Pre-init.

IHasModel is redundant, don't use it. All items need models and nothing about registering a model requires access to something private/protected. Code-style isue #1. Never use IInventory. Use capabilities and IItemHandler. Where is this called from? I do not see you calling it anywhere. Also wrong subforum.

Short answer - you can't. Everything OpenGL related must be done on the render thread. When a texture is created it needs to upload the pixels - that is a GL operation. Most you can do is load your buffered images async on another thread and when they are ready signal the render thread to upload them.

new ResourceLocation(yourString). That method does the same thing @Animefan8888 suggested but if it can't fing the block converts the string to a number and tries to get the block using that number as an ID. Do not use it, use IForgeRegistry#getValue.

The server has no concept of translation(or language at all for that matter). What OP did is the correct way. It send the lang key to the client and the client then translates it with the language the client has selected.

See how the slimes are done, they also have both a transparent and an opaque part. If I recall correctly it uses a separate layer to render the transparent part. I would suggest creating 2 separate models, render the opaque one in the main renderer and render the transcluent one in a separate layer. As for the particles - you will have to go through a lot of trial and error positioning your particles correctly. You can use a client proxy to get the model, then get it's parts and get their offsets and position however due to the way models and their rendering work you can't get any dynamic properties of the model(such as rotation for example) since MC will use 1 model instance for every entity and as such you will only have the rotations of the last entity rendered. An alternative hacky solution would be to spawn the particles directly in the renderer but make sure that you are not spawning the particle each frame but instead each tick. That way you can also get the current rotation of your part. Then you can construct a matrix, translate it by offset, rotate it by rotation, translate it by position and multiply your particle origin vector by that matrix to get the position. That is theoretical though, I've never tried anything like that.

Well, first of all Don't use GL directly. Whatever you are doing can be achieved by different means. In this case a BufferBuilder will do the trick just fine. In other cases use GlStateManager. Secondly, MC expects vertices to be specified CCW, but glRect specifies them CW. You can most likely disable culling(or change the cull method) and see everything working just fine regardless of the order. Also 1.10.x is outdated and you should update to the latest version(1.12.2).

All I can recommend is stop using the BlockEntityTag hack. Do the following: Make your ItemBlock have the capability that stores your values(check) When the block is broken/harvested create the item and then copy the capability data from the TE to your item's cap. When the item is right-clicked open your container-gui pair with the data pulled from the item's capability(check) When the ItemBlock places your block access it's TE and copy the capability data from the item to the block's TE. Currently you are storing the TE's data using BlockEntityTag which is completely detached from your capability.

If the method is static you don't need an instance to invoke it. This is basic java. As long as RegistryHandler is subscribed to the event bus this will work, yes.

A handler can be declared anywhere you want as long as it is registered. Here are the docs on the events and handlers.

As the error message tells you you need a RegistryEvent.Register<EntityEntry> as an argument to your event handler(you currently have no arguments at all). When you declare an event handler you specify the event you listen to by having that event as the argument to the listener method.