V0idWa1k3r

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.

This will never be true because ticks is a local variable assigned to 0: World#getEntitiesWithinAABB is the perfect way to get all entities of a given type in a box around some point. The only thing I could advice is to use EntityCreature as the base class instead of EntityLiving since you are already checking if the entity is an EntityCreature, put the other conditions into the predicate of World#getEntitiesWithinAABB and invoke the method when this condition is satisfied: Otherwise you are just doing extra work that is not necessary.

Where on earth did you get that idea from? Did you read the thread that I linked? Absolutely nowhere does it say anything about threads, much less multithreading. And even if you attempted to you would just crash horribly because the game isn't thread safe at all. And even if it was it wouldn't eliminate the issue at all since it comes from your worldgen loading chunks that were not generated yet and thus causing them to generate. A direct quote from the thread: This is all you need to do. Unless your worldgen is bigger than a single chunk. In that case you would need to split it into pieces and generate those pieces separately.

This is not an argument. 1.8.9 is 4 years old and is no longer supported on this forum. We simply can't offer you help with this version because there were too many changes and nobody wants to remember how to work with the outdated methods anymore.

A concept of a common proxy makes no sense. Proxies exist to separate sided only code. If your code is "common" then it goes into your mod class, not into your proxy. serverSide = Reference.COMMON_PROXY_CLASS This makes even less sense. Server proxy either hosts noop methods that are only applicable for the client or server-side only methods. Your common proxy can't be your server proxy. ItemBase is an antipattern. You do not need it. public static final Item RUBY = new ItemBase("ruby", CreativeTabs.MATERIALS); Don't ever use static initializers. Instantinate your stuff in the appropriate registry event. IHasModel is stupid. All items need models, no exception and there is nothing about an item model that requires access to private/protected things. Register your models directly in the ModelRegistryEvent, not in your item classes. What is up with your ruby.json model? Why are there so many transforms specified? Why is it's parent a item/handheld? Main.proxy.registerItemRenderer(this, 0, "invetory"); invetory != inventory. Actually also related and the cause of your issue: public class CommonProxy{ public void registerItemRenderer(Item item, int meta, String id) {} } public class ClientProxy extends CommonProxy{ public void regsterItemRenderer(Item item, int meta, String id) { ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(item.getRegistryName(), id)); } } regsterItemRenderer != registerItemRenderer. This is why you a) Never use a CommonProxy but instead an interface. b) Never manually override methods and use the override feature of your IDE c) Always annotate methods that are intended to be overridden with @Override As an unrelated sidenote: Any particular reason you've hosted your code on mediafire of all places? You can just create a free github repository, you know?

Ugh, another crappy youtube tutorial. I've watched a total of 10 seconds of it and I immediately saw the CommonProxy, IHasModel, static initializers and ItemBase. No, thanks. In general youtube tutorials are pretty bad, don't rely on them. I have yet to see at least an okay modding tutorial on youtube. They teach you all the things not to do so I am not surprized you are encountering issues. As for your issue - I see no errors in the log which likely means that you've not registered a model for your items in the first place but I can't tell for sure since you've shown zero code. So could you please provide some of your code so we can inspect it for issues?

Is this your mod? If it isn't complain to the author. If it is you need to read this:

Uh, the naming of the last parameter is wrong. It's partialTicks, not ticks. There is a huge difference. if(timer >= 0) { timer--; if (this.fade < 1.0F) { this.fade += 0.03F; } } else { this.mc.displayGuiScreen(new ArsenalMainMenu()); } You can't do this in the drawScreen method because it happens each frame, not each tick. If you want your animation to stay consistent with the framerate you need to use GuiScreen#updateScreen to update your counters, that happens each tick, not each frame. Why are you passing y as partialTicks? All resources must be lower-case(as far as I am aware anyway, feel free to correct me). Same with the line directly after. And what does this method do? Or rather what is the code of this method? There is no need to push/pop matrix here as you are not changing the matrix at all. Do you have any idea what this does? What does 3042 magic number mean? Please don't just blindly copy deobfuscated code and call it good, actually understand what's going on. Also don't use GL11, use GlStateManager. And if you are enabling blend you need to specify the blend function too since you don't know what it was specified to beforehand(3042 is GL_BLEND in case you were wondering) You just enabled it. 3 lines above in fact. Oh and while I am at it if you are changing the GL state take care to restore it after you are done your drawing. Don't just leak GL state. Apart from all these glaring issues I immediately see - yeah, what @diesieben07 said. You need to clarify your issue a bit more and show a bit more code.

My bad, I misread this As "this breaks textures". Now when I've looked at your blockstates I see that you are good on variants. I am actually unable to reproduce the issue described in my local copy of your repository. After adding this @Override public IBlockState getActualState(IBlockState state, IBlockAccess worldIn, BlockPos pos) { return super.getActualState(state, worldIn, pos).withProperty(BLOCK_STATE, ((LogicTileEntity)worldIn.getTileEntity(pos)).getClickCount()); } To the LogicBlock class I am able to both click the block and see the texture changes as well as relog into the world and see the correct textures(and by proxy the correct state)

Popular != good. A lot of popular mods are actually quite badly written with a lot of bad practices in place and a ton of cargo-cult programming in place. I can recommend some trustworthy repositories for learning:

First of all your actual issue - you've never actually registered your gui handler. You have the method that registered it correctly... in an another method that is never called from anywhere. BlockBase/ItemBase is an antipattern. Composition over inheritance. IHasModel is stupid. All items need models, no exceptions. And nothing about item model registration requires access to private/protected stuff. Register your models in the ModelRegistryEvent directly. @SubscribeEvent public static void registerBlock(RegistryEvent.Register<Block> event) { event.getRegistry().registerAll(ModBlocks.BLOCKS.toArray(new Block[0])); TileEntityHandler.registerTileEntities(); ClientRegistry.bindTileEntitySpecialRenderer(TileEntityCopperChest.class, new RenderCopperChest()); } You can't do this. Registering a renderer for a TE is a client-side only operation, while RegistryEvents are common code. This will crash the server. public static final Block COPPER_BLOCK = new BlockBase("copper_block", Material.IRON); public static final Block COPPER_CHEST = new BlockCopperChest("copper_chest"); public static final Block LOG_STRIPPER = new BlockLogStripper("log_stripper"); Never ever use static initializers. Instantinate your stuff in the registry event directly, not in static final fields. compound.setInteger("BurnTime", (short)this.burnTime); compound.setInteger("CookTime", (short)this.cookTime); compound.setInteger("CookTimeTotal", (short)this.totalCookTime); Any particular reason you are replicating a vanilla bug of casting things to a short but saving them as ints? public static int getItemBurnTime(ItemStack fuel) *Sigh*. This is like the tenth time I see this method in custom TEs that have a fuel unedited and blindly copied from TileEntityFurnace. You are not changing the implementation of this method. It is static. And public. Just invoke it from TileEntityFurnace, there is absolutely zero need to mindlessly copy-paste it from TileEntityFurnace, this is not how programming works. You are not using IInventory, why are you copying this abomination of a method from it? Just reference your fields directly, you do not need this. @Override public void tick() public void update() So, you've blindly copied TileEntityFurnace and yet it never occured to you that it is a little bit strange that the TileEntityFurnace has no tick method at all yet you are for some reason required to override it, and when you put @Override over the update method you get an error? No, no concern at all? Again - you need to understand what is actually going on, not blindly copy classes and then hope everything works out. If you ever want to learn you need to start understanding. Also, auto-fix in eclipe isn't a magical "fix all my issues" button. Instead of using it here you need to try and understand why do you need to implement tick here. I am kinda going on a tangent here, and I am sorry if I sound rude or something, but I am trying to help you. The issue in this case is simple - you've implemented the wrong ITickable but if you actually stopped and thought about the issue for a minute instead of blindly applying auto-fix of eclipse then you woundn't have this issue in the first place. This applies to your other TileEntity too, the copper chest one. public Table<ItemStack, ItemStack, ItemStack> getDualSmeltingList() Again, this is not the first time I am seeing this. Why are you using a Table exactly? There is no reason to use Table here, this is not it's use case. Use a Triple<ItemStack, ItemStack, ItemStack> instead. Why do you have 2 of the same class LogStripperRecipes in 2 different packages? They are identical after all. Your TileEntityCopperChest implements IInventory. Not directly, through inheritance but still. Never do that. IInventory is a horrible artifact of the past and nobody should be ever using it. Use capabilities instead, like you are doing in your furnace TE. CommonProxy makes no sense. Proxies are to separate sided only code. If the code is common it goes into your main class. Do not use a CommonProxy, use an interface instead. Your NBTHandler methods are kinda broken. First of all when saving an ItemStack you also need to save it's NBT and capability data, not just it's registry name and count. And second of all ItemStack already implements the methods for (de)serializing it into NBT, there is no need for duplicate functionality. public interface IStructure { public static final WorldServer worldServer = FMLCommonHandler.instance().getMinecraftServerInstance().getWorld(0); public static final PlacementSettings settings = (new PlacementSettings()).setChunk(null).setIgnoreEntities(false).setIgnoreStructureBlock(false).setMirror(Mirror.NONE).setRotation(Rotation.NONE); } You really can't do this. This is not how anything works at all. These are static final fields meaning they get instantinated when the class is loaded. A lot of the things you are referencing here will be null by then. This makes even less sense than a CommonProxy. A server proxy is NOT your CommonProxy, it's a collection of methods that either provide a noop implementation for client-only stuff or reference server-only things. A server proxy can't and musn't be a CommonProxy. This is not how proxies work and they are not meant to be used like this.

Could you please setup your repository on github so I can debug it locally?

You still haven't answered most of my questions. It is not supposed to. Place a breakpoint in your IGuiHandler implementation when returning the GUI or the Container object to see if it is getting called. Place a breakpoint in your GUI/Container constructor to see if they are getting invoked.