V0idWa1k3r

Client thread isn't nececcairly the same as the render thread, and all rendering-related stuff must be done on the rendering thread unless you are using vulkan. What they need to do is enqueue the action on the client, aka have a static field changed to true on the onItemRightClick method, then in any kind of render event(RenderTickEvent, RenderWorldLastEvent, etc) check for that field being true and if it is do the gl related things and create an image there. Then yeah, a packet to send it to the server is needed, I *think* that if the packet is too big it will be split into multiple smaller packets, but I am not sure, you might just crash right away because of the packet size limit, in that case you would need to compress the image before sending it. And unfortunately clients will be able to abuse this packet and send extremely long byte arrays to the server regardless, and I don't think much can be done about it. You don't need this assertion. This is not the usecase for the statement. I am not sure what do you mean here?

You don't need to send those to the server, it makes no sense. You need to send just enough information so the server can validate it, find the player, find the itemstack in their inventory and do whatever it is supposed to.

This code isn't doing what you want it to do and is horribly inefficient. First of all Chunkevent.Load fires every time the chunk is loaded, not just the first time it generates which will run this snippet of pretty expensive code every time ANY chunk is loaded. Not to say it will also replace the coal ore(in this case) regardless of how it ended up in the chunk - whether it was generated or placed by the player your code cares not. Look at how vanilla's features now work, I believe the generators are registered per biome to a list and you should be able to just search that list on startup and remove the generators you don't want present.

In java everything that is an instance of Object is a reference-type. So, for example if you have this code class Foo { public int i = 0; } class Main { static void main(string[] args) { Foo foo = new Foo(); foo.i = 1; doStuff(foo); System.out.println(foo.i); } static void doStuff(Foo foo) { ++foo.i; } } then the statement being printed into console will be 2. This is basic java. So you have a Map<String, ItemStack[]>(your map is slightly different but effectively it's the same). Then in your drop class you get an ItemStack from said map and drop it to the player. Now the player has that ItemStack, but it is also still in your map. Thus every modification the player's inventory now does to that ItemStack is also applied to the one inside the map(because they are the same object). So if the player increases the stacksize of your itemstack by 1(say by picking it up) your map now contains the itemstack with the size of 2 and when it is dropped it will have a quantity of 2. Which when the player picks it up will become 4 and so on. Basically use ItemStack#copy(or it may be called clone, don't remember and can't look it up rn) to create a copy of the itemstack in your map. Unrelated issues: Don't construct a new Random instance every time, there is no reason to do that.

Since you don't have a pack.mcmeta file in your assets/modid directory the game assumes that your assets use a V2 format. Language files in V2 were defined as xx_XX.lang. The lowercase definition(xx_xx) came with V3.

You can't do any of this. All entities must be spawned on a server, not the client, and inventory manipulations must also be done on the server, not the client. You need to send a packet to the server and do all this on the server.

Why is your json file name not entirely lower-case and doesn't correspond to your block's registry name? Registry names must be entirely lower-cased and so should be your blockstates file and your model file. You are also not specifying the modid that provides the textures/models in your blockstates and model files. You are also using static initializers. Don't ever use static intializers for forge registry entries. Instantinate your stuff in the appropriate registry event.

Since you have not specified a modid for the recipe type the crafting manager tries to find a recipe type of modid:crafting_shaped which fails. Specify your recipe type with a modid prefix according to the mod that provides the recipe, in your case it would be minecraft:crafting_shaped

Wrong subforum. This statement is incorrect, the json you've provided doesn't have a correct syntax. You have extra commas in your ingredient definitions. You might have used a bad json validator, use something like jsonlint

By making a custom class that extends GuiScreen or something and rendering the things as you want here. To see how to render things there you can look at vanilla's classes for examples.

You can still reference it from the Keyboard class instead of using a magical number.

Oh, right, my bad, I am just too used to using the forge-provided constructor and not the default one, you are right. Don't use a magical number for the key-code, reference them from the Keyboard class. You would also need to store the KeyBinding object in a field to actually check whether it is pressed or not. You can instantinate it whereever you like as long as it is not a common class(aka it needs to only be loaded on the client like your client proxy for example).

...You are creating a new KeyBinding object, or in other words another instance of a KeyBinding class here. new Object != new Class. What version of the game are you modding for? This isn't a 1.12.2 KeyBinding constructor.

The key bindings don't have a registry associated with them, just create a new KeyBinding object and register it using ClientRegistry.registerKeyBinding during pre-init. That's all you have to do. To then check whether the key is pressed use KeyBinding#isKeyDown (in a tick event to check if it's hold down) or KeyBinding#isPressed in a KeyEvent to check whether the key being pressed is yours.

Gui#drawTexturedModalRect has parameters which are renderStartX, renderStaryY, textureStartX, textureStartY, width, height. To offset the texture change the parameters to your needs.

Use the KeyBindings for your key registration/detection and register them using ClientRegistry.registerKeyBinding

TileEntity#onChunkUnload

You can either have a block with a TE that takes on the model of the "enchanted" block or have a chunk capability that holds the additional data in a <BlockPos, YourData> map.

You are writing in the read function and reading in the write function.

Use a custom implementation of IItemHandler#insertItem and IItemHandler#extractItem. Both methods give you a slot as a parameter. If you want extraction/insertion to be based on the side you can return a wrapper around your IItemHandler based on the side that only exposes the slots you want to expose for necessarry operation in getCapability. Note that you would still need to use a custom implementation of IItemHandler#insertItem and IItemHandler#extractItem.

use Entity#sendMessage. If you are on the client it will just add the message to the player's chat, otherwise it will just send a packet with the message to that player.

You would have to render the model manually. You can either have a dummy item have that model and render said item in your rendering method or simply parse and render the model yourself.

Bind it before rendering the model

You are already on a render thread in this event.