V0idWa1k3r

Why are you scheduling this as a task to the client thread? Shader binding must be done on the GL/render thread. Also the player should never be null during RenderGameOverlay event. Additionally rendergameoverlay event fires multiple times per frame per element being rendered. You need to check the one currently rendered.

Block#harvestBlock isn't called if the block isn't actually harvested(broken by the right tool). You need to use a different method.

You are binding your texture during the background pass but rendering it during the foreground pass? This makes no sense. Render the background during the background and after binding the texture.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a Specifically this section:

How and when are you loading the shader? (aka post your code)

This means you are not interpolating your rotation based on partialTick. basically your rotation should be lastTickRotation + (lastTickRotation - currentRotation) * partialTicks

I think he means his model is huge as in scaling, not huge as in file size. Scale the model down in the model editor you are using.

1.7.10 is no longer supported on this forup. Update to a modern version of minecraft to receive support.

You can use capabilities. A capability can be attached to an ItemStack just as it can be attached to entities, TEs and other things.

I think this happens because the event bus doesn't care about threads(and is static), and simply sends the event to all listeners. While you are posting the event on the server thread it goes to the event bus which iterates through all listeners, which the client-sided TEs are and gives the event to them. So in a way you made a jump from a server event to a client listener. I don't know for sure though and can only be guessing from my inspection of the EventBus class.

Well, your TileLamp only registers itself as an event subscriber on the client, so the event handler method only fires on the client, and as such the wisp is only spawned on the client.

Before the registry events fire, so in pre-init.

That is correct, but your event handler methods don't have to be static. Again, read the docs I have linked.

static initializers != static fields. Initializer means you are instantinating something. If you just use a static field to store data between methods then it's not a static initializer. This is also a false statement. Read the docs on events.

Why did you upload your code as files here? Use github. Don't implement ITileEntityProvider, this interface is not needed. Just override Block#hasTileEntity and Block#createTileEntity You don't need the setState method. Just override TileEntity#shouldRefresh. The fact that you are using InventoryHelper.dropInventoryItems makes me suspicious of your TileEntity implementing IInventory. Never implement IInventory, use capabilities instead. @Override public EnumBlockRenderType getRenderType(IBlockState state) { return EnumBlockRenderType.MODEL; } Why? Block#getRenderType already returns MODEL. as for your issue: You have never told the block state container that your block has the BURNING property associated with it in Block#createBlockState. You must put all the properties you wish to use there. Additionally you are not (de)serializing your BURNING property in getStateFromMeta nor getMetaFromState. You must do it in order for the property to persist.

This happens because this returns the player's base inventory. In this case you need a custom capability class and you can't use the default IItemHandler(or rather you can't use the capability instance injected into the field that expects a IItemHalder capability). I think you can just make an extension of ItemStackHandler and register it separately and use it as your capability.

Why? Vanilla code works perfectly fine for vanilla. In this case it should work perfectly for your use-case aswell as long as you implement it correctly. If you have no idea what the code does you can look at vanilla's class and figure it out. Sure it changed but that doesn't stop you from figuring out how it works. You are not looking at magical spaghetti code of 10000+ lines after all. Since you are making a block you need to extend Block. Depends on what you want your block to do. Again, see vanilla for examples. Again, you can see it for yourself in vanilla classes like BlockFurnace, BlockDispenser, BlockPiston, etc. What does this question even mean? Why do you need to be "checking" the player? ...in your block class. I am sorry but if you are asking questons like these you need to learn basic java. You can't make a minecraft mod without understanding the fundamentals of the programming language you are using. Your IDE tells you that. Well, here are your answers - learn java(at least the basics of it) and look at how vanilla does things. Then you can come back with more specific questions we would be able to answer without telling you to look at vanilla's code.

Override GuiScreen#mouseClicked and pass it to your text field.

Before models are loaded, so in pre-initialization for example. Be sure to do this through a proxy though. Use forge's blockstates format to specify the model of the item to point to your obj file.

You haven't provided neither enough of your code nor a better description of your issue. What does "can't use the slot" mean? Is it not physically there? Can you not put anything in it? Is it not saved? We need more details than a simple "doesn't work". As for your capability code it's fine. You don't need a field for the capability though, forge already provides one. Your container slot ID is wrong. Since this is slot 0 in your inventory it's ID should also be 0. IDs are relative to the inventory, not the slot's index. See any vanilla's container for an example.

Don't just blindly copy the code others provide. For that matter never blindly copy other's code. In this case you are trying to use 1.12 code in a 1.13 environment. You can always see how this is done in vanilla, something like BlockDispenser for example should be exactly what you need. I don't really see the point of this assertion. If the placer is null you will crash anyway one line later with a NPE.

Since this is your own crafting table with a custom recipe list you don't "have to" change anything between 1.12 and 1.13 here. It would be nice to utilize the datapack feature for your recipes though to allow modpack and mapmakers to override your recipes and other modders to add new recipes easily without even needing to specify a dependency but that is optional.

Just register a new object with the same registry name as the old one, that will result in an override if the registry supports that. Depends. If they use those fields to reference their blocks for checks here and there then no, they won't be. If they are only using them to instantinate the block and never do anything with the field beyound that then they will be compatible. Besides you always can resort to reflection to change the values of those fields if you need to. Although yes, there wouldn't be a need to do that if those mods used the ObjectHolder annotation.

You could collect all the quads into a single buffer and render it. The most expensive operation in graphics is the draw call. Kinda similar to what a FastTESR does.