Animefan8888

No because you are constructing an object every frame in that case. While a ResourceLocation isn't all that taxing in terms of creation it is a bad practice and shouldn't be done. I would create a static array of ResourceLocation and index the value I want to use when I want to use it. Yeah even with the most up to date mcp snapshot they don't have proper parameter names. But if you take a look at the execution order. It all leads into innerBlit which deals with Tessellator and BufferBuilder. From there you can figure out what each parameter is: protected static void innerBlit(int p_innerBlit_0_, int p_innerBlit_1_, int p_innerBlit_2_, int p_innerBlit_3_, int p_innerBlit_4_, float p_innerBlit_5_, float p_innerBlit_6_, float p_innerBlit_7_, float p_innerBlit_8_) { p_innerBlit_0_ is the x position on the screen. p_innerBlit_1_ is the x position on the screen with the width added. p_innerBlit_2_ is the y position on the screen. p_innerBlit_3_ is the y position on the screen with the height added. p_innerBlit_4_ is the z position on the screen(use this.blitOffset). p_innerBlit_5_ is the textures x position in a 0-1.0 scale. p_innerBlit_6_ is the textures x position with the width added in a 0-1.0 scale. p_innerBlit_7_ is the textures z position in a 0-1.0 scale. p_innerBlit_8_ is the textures y position with the height added in a 0-1.0 scale.

First I hope you're not doing new ResourceLocation in your actual code because you should just create it once in a static field. If I'm not mistaken there are other versions of blit that take more parameters and let you change more things. If that isn't true or satisfactory you could always use GLStateManager.scale

Post your code.

Are you in a dev environment or a real launcher environment?

This is the correct way to do this. You tell the server hey open this gui from this mod. The server says ok it creates the server side Container and then sends a packet to the Player(client) and then the client opens the gui and container on that side. My bad, but you've solved this by getting rid of the AttachCapabilityEvent right? Nice It might not have been also I failed to notice this on my first glance through your code, but... The string in the Instance annotation needs to be your modid.

AxisAlignedBB is a bounding box right now you are asking for a bounding box that goes from x to x, from y to y+3, and from z to z. Which is not a box it is a line. Thus on your second x and z you need to add 1.

Why? Something is null on line 30.

Post your code. I mainly need the block class and subclasses if they are important(IE change behavior). If there are multiple a git repo would work great.

Use this one. The predicate is for determining special data about the entity for your case along as you pass AbstractVillagerEntity(or whatever the class name is) you can just simply return true.

What version of forge are you using try using the most up to date version.

They are slightly different. There is no IConditionFactory as a matter of fact no need for one. You create an IRecipeSerializer(This is an IForgeRegistry thing) and return whatever IRecipe implementation you want there based on whatever you want in the JSON recipe.

You dont need to use this when it's your TileEntity. Also you wouldn't use new TileEntityAltar here there is a field in the event parameter. You dont ever have to do this unless you are adding a new object type that has Capabilities. Get rid of IItemHandler here you only need the field in your class.

Look at any of the vanilla classes that extend Screen. Preferably something similar to what you want to do if it exists.

Of course there is. Normally it shouldn't be done, but since this also refers to other mods I'll say it here(not sure if overriding another mods recipe is viable with the data system). Basically you'll likely need reflection and the RecipeManager is stored server side inside the World class. If it isn't immutable just replace the IRecipe instance with a dummy instance that returns ItemStack.EMPTY when it is matched. However when replacing them maybe check the output first to see if it is planks. If it is Immutable replace the whole fields value.

Dont use this. BlockBase serves no purpose. You probably have something like "registerModels" in here. You could easily switch this to Block and be capable of extending any Block class. You're using the wrong create method. Use the one with an IBlockState parameter. Remove this method it is useless. Do not implement IInventory. Instead use the IItemHandler Capability. It's way easier to use and is the compatible option to use with other mods. No mods expect your TE to use IInventory anymore and stuff like pipes/machines/etc. Do not support it. This is literally the same as this.world = this.world; It serves no purpose. The load method is called after the TileEntity has been added to the world and has had its world field initialized. You dont need this function unless you have important stuff to do when the TileEntity is first created and placed or when the chunk gets loaded. There is no point to this if you dont use it anywhere. Fix all this and your code will be better and easier to understand. Your error should also go away.

Basically when you are doing fancy render stuff like this you need to ask yourself a few basic questions. Are there going to be a large amount of these blocks in one area? If yes it is likely better to use the model system. Is your block animated? If yes then you will need to use a TESR preferably a FastTESR. Is your block is gonna update at a ridiculous rate IE every tick? Then you should probably not use the model system unless the update has a switch. If it has a switch you should use both model and TESR. Model for non updating mode and TESR for updating mode and basically all data for the update should be in the TE for the block. And the switch should be stored in the blockstate so it is capable of switching between not having a TE and having a TE. Basically weigh these questions against your Block then make a judgement call. If it turns out to be terrible try another implementation. I recommend using the switch method of things.

This is just you. You never actually modify the vanilla recipes or BOPs recipes out of the game. Therefore they are still registered and you are hoping your recipe will be found in the registry first. You cannot do this. It doesnt work in all cases.

As Draco said you need to enable alpha via the GLStateManager in your code then disable it after your code runs.

Just sounds like it'll eat up a lot more ram and have a little longer startup time. Though I dont know exactly you'll have to test it and find out. If you mean in terms of fps as long as ram is sufficient the user shouldn't experience any drops in fps from the way the textures work however they may experience a drop in fps if the blockstate changes really fast. Each time it happens the whole chunk mesh has to be regenerated.

First off where did 2^6 come from? From what I can see here is you need to use the TextureStitchEvent(Not sure if it should be pre or post).Then you'll need to either load(if in the pre event) or get from the AtlasTexture(post event). Then you'll need to use reflection to access the NativeImage array stored in the TextureAtlasSprite via reflection and call setPixelRGBA for your pixels. Then you'll need to add this texture to the AtlasTexture(which is why I'm not sure which event you need I am leaning towards Pre).

You write an IRecipeSerializer you can base it off of vanilla's crafting one(s). Then you also need a IRecipe implementation that actually checks the config data for your mod when determining the result. So the IRecipeSerializer will do everything exactly the same as the vanilla one except it will load an extra piece from the json telling you which config data you need to access(your choice on how to implement that) and it needs to return a instance of your IRecipe implementation.

Have you stepped through the code with the debugger?

Find where the hitbox is stored in the entity class. I cant don it right now dont have an environment set up. You might need to use reflection to edit it.

You should post your new updated code.

The bolded part. It is misspelled. It should be handheld. You also can't have In your json files. That's not how comments work in Json files. Not even sure if there are comments in Json files.