V0idWa1k3r

Why would you simply copy-paste my proxy implementation? You don't need any of those methods. I only provided you with an example of how to use an interface for your proxy, I didn't tell "hey, here is my code, copy all of it!" You have never instantinated any of your blocks. Your array that you pass to the register method is an array of nulls. Instantinate your blocks before registering them. It is very obvious. But don't use static initializers. Instantinate them directly in the registry event. Don't use a method that is extremely outdated and deprecated. Use the overload that takes in a ResourceLocation as it's second argument. Your ItemsInit and ArmourInit are still not changed, but for some reason reuploaded. You need to fix those too. @SidedProxy(clientSide = Reference.CLIENTPROXY) public static ClientProxy proxy; This makes no sense. Again, proxies exist for separating sided only code. Please, understand what you are doing and how things work. A ClientProxy is a class that only loads on the physical client. A ServerProxy is a class that only loads on the physical server. A IProxy interface defines methods that these proxies share so you can call them without having to care which side you are on. Why do you have a Constants class and a Reference class if they both serve the same purpose - hosting final fields? Also your reference class still references the common proxy. Your RecipeHandler must not exist. Recipes must be done via json, not code. I mean you could use code for your recipes still since it is 1.12 but this option is out in 1.13 - every recipe must have a json counterpart in 1.13. You might as well start defining your recipes via json now than having to rewrite everything into json once 1.13 hits. Why is RegistryHandler still a thing again?

Sure

Well first of all your repository is setup incorrectly. Your root directory must be your root workspace directory, not the main folder, not even the src folder. Next up - why on earth do you have 2 mods in your repository? Which one am I supposed to be looking at? I'm assuming the AE Addon one, correct? Common proxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes into your main mod class. Hmm, wait a second, didn't I already tell you not to use CommonProxy? Why yes I did. Well I shouldn't be too harsh on you, you did listen when we told you not to use IHasModel after all, so good job on that. Now delete your CommonProxy, replace it with an interface and we shall never speak of this again. I am just going to quote myself from the post I've just linked public static void registerItem(Item item) { ForgeRegistries.ITEMS.register(item); item.setCreativeTab(ModClass.kryptonitetab); ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); } You can't do this. First of all ModelLoader is a client-side only class, you can't invoke it in common code like this, it will crash the server. And even if you could - this is too early to be invoking it. Models must be registered in the ModelRegistryEvent and not somewhere else. public static void Client() { RecipeHandler.registerCrafting(); RecipeHandler.registerSmelting(); } Recipes are a common thing. Both the client and the server need to know about them. It makes no sense to only register them on the client. First of all I am in the middle of my reply here, nice. Secondly this is not a chat room, be patient. And finally you don't even need to "bump" your post, it is in the top 3 posts... Registry names must be entirely lower-case. Same with asset names. No. Don't ever access the registries like that. Use the appropriate RegistryEvent.Register events and access the registry provided to you by the event. public static void registerBlock(Block block) { ForgeRegistries.BLOCKS.register(block); block.setCreativeTab(ModClass.kryptonitetab); ItemBlock item = new ItemBlock(block); item.setRegistryName(block.getRegistryName()); ForgeRegistries.ITEMS.register(item); ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), null)); } You can't do that. Items and blocks have separate registries and thus separate registry events. You can't register them both in the same event, that's not how anything works. Also: I already told you to do this in the appropriate event, but as an addition - variants can't be null. If you don't know which variant to pass to the item pass "inventory". Oh yeah, let me emphasise - you MUST register your stuff in the appropriate registry events. Not in your pre init. Please fix all of that, update your repository and then I will take a look at it again to try and determine what's wrong with your model registration. Right now the fact that the game even starts is a miracle.

Well first and foremost stop using GL11 directly. Use GlStateManager. Why do you need to disable the GUI scaling exactly? You can easily draw anything you want based on width/height and have your fullscreen GUI independent of the scaling factor. You don't actually need to be pushing/popping matrix here at all because if you are doing it in the middle of your operations you are screwing them up and once your drawing is done the game will reset the matrix anyway. The matrix mode is already modelview though. You've just set it to modelview 7 lines above and you haven't changed it. Any reason you are doing this? The game just did that for you like 6 operations or so ago. You are not using a different framebuffer after all and the one currently in use has just been cleared. You don't need to be doing this. The viewport is already set to the game's display width/height. Or to the custom framebuffer's resolution. In fact you could be screwing up someone's framebuffer setup by doing that. Apart from all that looks fine-ish to me. Fix all that and see if you have any more issues.

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file. In fact I am pretty sure that this is the root cause of your problem. You can't do this on a server. Translations are a client-side only thing.

In addition to what everyone else said I've seen people say that people using static initializers is the only thing that prevents registries from being reloadable during runtime.

Yes you do. Registry events are events where you register your things. RegistryEvent.Register<? extends IForgeRegistryEntry>. If you have any items/blocks present in your mod you are using registry events. Yes you do. You are currently instantinating your objects in static initializers. Just do the same in the registry event instead. Well maybe it is time to start. You can't really solve issues without a debugger and you can't write pretty much anything above a hello world application if you can't solve issues. They are a java feature. If you don't know java then you need to learn it before making a mod otherwise you are constructing a rocket without any instructions.

Don't do this, use ItemStack#isEmpty instead. An item stack may be empty but not equal to ItemStack.EMPTY. Don't ever use static initializers. Instantinate your stuff directly in the appropriate registry event. Apart from that use the debugger to see which items are actually selected within the AABB specified and whether ut contains your axe item. You might need to extend it a bit. Also consider using java 8's streams instead of loops in cases like this one.

Unless the OP made a class that is named EventBusSubscriber there is exactly zero difference between using the class prefixed name and the non-prefixed name. More than that you already know that their event handlers are working otherwise they would not have an item at all and wouldn't be able to report a missing model issue, they would be reporting a missing item issue. As the log clearly points out their model file is not in the right location and this is the issue that needs to be fixed for the model to appear in game. This is not how anything works. We are not here to write code/organize your workspace for you. 2 people have already told you what you need to do. Your models are in the blocks and the items folders, but the game looks for the block and item folders. Notice how there is no S at the end. Your folder structure is incorrect and you need to fix this.We told you how to do it, so just do it. There is nothing hard in renaming a folder. Besides this is dropbox. The most I could do with it is download it to my PC which doesn't help your in the slightest.

The game clearly thinks otherwise because it can't find the model file at the specified location. Check the folders carefully. As @luiihns pointed out items != item. What exactly have you tried? You need to move your model json file from the models/items folder into the models/item folder. Can we see your project's folder structure?

This only checks for whether it's raining or not. It doesn't actually check for the snow(which you've wanted to know about) and it doesn't check for cases where it won't rain/snow in a biome like a desert either.

What exactly is difficult to read here? I think I've explained everything pretty clearly - telling you what's wrong, why it's wrong and how to fix it. I don't know how can I be more clear than that.

The weather in the game is globalized, meaning if it's raining - it's raining everywhere in the world at once. And "raining" in this case means that the weather isn't "clear" so to speak. So you can absolutely keep this method: However when it comes to snow it's a bit different. You see, if it's supposed to be snowing in the biome instead of raining then the World#isRainingAt will return false. It will also return false if you go high enough so the rain becomes snow. So you need to account for these too. Basically I would have separate checks to determine the weather at the current spot: public enum EnumWeather { CLEAR, SNOW, RAIN, DRY } public static EnumWeather getWeatherAt(EntityPlayer player) { World world = player.world; BlockPos pos = player.getPosition(); if (!world.isRaining()) { // If it isn't raining at all in the world it means that the weather is clear everywhere in the world. return EnumWeather.CLEAR; } Biome biome = world.getBiome(pos); if (!biome.isSnowyBiome() && !biome.canRain()) { // If the biome can't have rain nor snow then it's a dry biome like a desert where it never rains. return EnumWeather.DRY; } boolean isSnowingAtHeight = world.getBiomeProvider().getTemperatureAtHeight(biome.getTemperature(pos), pos.getY()) < 0.15F; if (isSnowingAtHeight) { // If the adjusted temperature is less than 0.15 then it is snowing here. // And before you tell me about Biome#isSnowyBiome - all the logic is taken from EntityRenderer#renderRainSnow. It doesn't care whether the biome is a "snowy" one to render the snow effects - it only cares about the temperature at a given location. return EnumWeather.SNOW; } // If all other options are out then it must be raining return EnumWeather.RAIN; } Any particular reason you are using a forge version that is soon to be a year old? You should update.

There are 2 things that need to be changed in the code to save with transparent background. Firstly, you need to set the clear color to be transparent: GlStateManager.clearColor(0, 0, 0, 0); The clear color really simply tells GL how to fill all pixels of a texture when the color buffer is cleared. Setting it to having 0 as alpha will make sure the texture is filled with transparent black pixels as it's background. The second and the final thing to change is the format of the BufferedImage created. From BufferedImage bufferedimage = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); Which would save every pixel passed to it as 0xFFRRGGBB to BufferedImage bufferedimage = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB); Which will change the format to 0xAARRGGBB.

Yeah I would assume something is up with the GL matrix at the time of the rendering. Tweak it yourself untill you acheive the desired result.

public static void register() { gui = new KeyBinding("key.gui", Keyboard.KEY_U, "key.categories.mhq"); ClientRegistry.registerKeyBinding(gui); Keybinds.register(); MinecraftForge.EVENT_BUS.register(new KeyInputHandler()); } Are you... calling the register method from inside of the register method? The fact that you do not have a StackOverflow on your hands means that you are not calling register from anywhere in the first place.

Are you calling this from your main mod file? And even if you are - why are you passing the FML event as a parameter? You have exactly zero use for it. Just creating a KeyBinding isn't enough, you also need to register it in order for it to appear in the options menu with ClientRegistry.registerKeyBinding

Update to the modern version of minecraft of course.

Don't ever use static initializers. Instantinate your things in the appropriate registry event. ItemBase is an antipattern, you do not need it. IHasModel is stupid. All items need models, no exceptions and there is nothing about registering an item model that requires access to private/protected stuff. Just register your models directly in the model registry event, not in your item class. CommonProxy makes no sense. Proxies are meant to separate sided-only code. If the code is common it goes into your main class, not in your proxy. (I am assuming you are using this as your server proxy)This makes even less sense. A server proxy either provides noop implementations for client-only methods or contains server-sided only code. A common proxy can't be your server proxy. dum is a terrible modid. You have 64 characters available. public class ClientProxy extends CommonProxy { public void registerItemRenderer(Item item, int meta, String id) { ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(item.getRegistryName(), id)); } } Use the @Override annotation when overriding methods. Don't ever manually override methods, use the generate override feature of your IDE. As for your issue I would need to see the log generated by your game when it starts up. You can find it in %workspace_dir%/run/logs/latest.log(or debug.log) As a sidenote don't use tutorials from youtube. They are made by people who have no clue what they are doing or how to write propper forge mod(or in most cases even how to write okay java code in the first place) who just figured out how to make their code not explode on them and have some effect on the game and are very eager to share the knowledge. The problem is that they have written their code in the worst possible way making every mistake possible dragging along years of cargo-cult programming. This is probably the worst place/way to learn minecraft modding.

It will neither be sent to the server nor appear in the client's local chat. These are different things. When the client hits enter to send a message it first gets added to it's local client's chat - it is not yet visible to any other player on the server but is visible to the client who is sending it. It then gets sent to the server which sends it to every other player for them to see if needed. I don't know whether you want the client who typed the message to see it, which is why I've included an explanation as to how to add it to the local client's chat. Again, you can add anything you want to that chat and only the client that you are doing it with will see those messages, not anyone else.

Did you see what I've quoted? I didn't quote the item registration, I quoted this line This is client side only and must happen in the ModelRegistryEvent. This line has nothing to do with item registration, it registeres a model for the item. Item RED_COAL = new ItemBase("redCoal"); Item ... e.getRegistry().registerAll(ITEMS.toArray(new Item[0])); The issue with this approach is that the registry can't be dynamically reloaded now since you never clear the list. It is not a problem *now* but it is nonetheless an issue. As an example here is me registering items in one of my mods. As you can clearly see I do not use any kind of a list or anything to hold my items in. In fact I don't and just use ObjectHolders to get the reference to my items when I need it.

So do you want to detect when the client player types a message, respond to it and stop it from reaching the server? Forge has an event for that - ClientChatEvent. You can cancel it and then it won't be sent. It however won't add it to the chat either so you would have to do that yourself with GuiNewChat#addToSentMessages. You can get the GuiNewChat instance from GuiIngame#getChatGUI and you can get a GuiIngame instance with Minecraft.ingameGUI.

Start off by making your custom GUI obviously, then make and register a KeyBinding, listen for the KeyInputEvent, check if your keybinding is pressed and display your GUI with Minecraft#displayGuiScreen.

This is client-side only and thus can't be used in common code otherwise you will crash the server. In any case this needs to happen in the ModelRegistryEvent, not anywhere else. You are registering your items twice. As for the error: Whatever you are doing in your PreInit method in your main class crashes the game. I can't tell you what you are doing because you've not provided the code needed. But from the stacktrace it looks like you are calling the Item.registerItems method for god knows what reason.

No, there isn't a single comment suggesting that you could multithread world generation. The top comment suggests multithreading the mask generator, not the world generator. The world generator uses the mask provided by the mask generator to generate stuff. You can't worldgen with multithreading because the game's world accessors aren't thread safe. You will crash with a ConccurrentModificationException sooner or later.