V0idWa1k3r

I do not know if this is the correct way to do it(i'm pretty sure it isn't and the correct one is described in the topic you've linked) but you could add your dependencies as external jar libraries in eclipse as a workaround.

If your models are located anywhere within the assets folder then it is a matter of a setCustomModelResourceLocation invocation. If they are not - you need to use a custom ICustomModelLoader. It may be possible to do with a custom IResource/IResourcePack implementation but I have never done anything like that and can't really help you with it.

EntityPlayer::isPlayerSleeping?

You use it in the exact same way you would use RenderPlayerEvent. It also has a cancelable Pre sub-event. I do not currently see any event related to EntityItem rendering, that might be impossible to cancel.

As far as I am aware you do not need packets if you only want to see things changing in the gui. See how it is done in vanilla's classes, for example in ContainerFurnace (the methods that interest you are addListener, detectAndSendChanges and updateProgressBar). Vanilla uses get/setField that you should not have unless you are implementing IInventory which you should not do, but they are only a level of abstration, you can still send/recieve any numeric data you want with IContainerListener::sendProgressBarUpdate and Container::updateProgressBar. The only thing that changes is that you can't use IContainerListener::sendAllWindowProperties... but you can still send everything using sendProgressBarUpdate. Although custom packets will obviously work too, they are just a bit more complicated

The error log is pretty descriptive. Your blockstates file is invalid here, here and here. You are not defining the "texture variable" your texture should be assigned to. For example "textures": { "someusefulthings:blocks/remove_enchantment_off" } could be "textures": { "side" : "someusefulthings:blocks/remove_enchantment_off" }

So, I've investigated the issue. I have managed to achieve something somewhat similar. In fact, I've achieved pretty much the same picture of yours! The issue is very obscure, and it lies within the way the game renders it's sky. Or, rather, within the fact that it only properly colors the top half of the sky only (+ sunrise/sunset gradients ofc) and kinda leaves the rest for the fog. Usually the fog is dense enough and matches the sky color to hide the transition from 'skybox' if you could call it a skybox to a solid color. However if you remove the fog and just set the color... Well you get the background color of the color you've specified, but the sky is a different color! Thus you see this result. The only reason I was not able to replicate your issue is because I've had my own sky renderer enabled that eliminates the issue by rendering a propper-ish skybox... I am not sure if much can be done tbh. Even custom fog rendering with GL would not help here. You can however hide the issue by matching the color of the fog with the color of the sky - it is available at World::getSkyColor. Or do not touch the color event at all. That would work as by default it matches the color of the sky. (pretty similar to what Jay suggested) Or make the fog relatively dense with your color so it hides the sky. Apart from that the sky color is hardcoded and I do not see any hooks to modify that... The biome can return a custom sky color but there are no events in place to affect vanilla biomes. A WorldProvider can return a custom color implementation but yet again - no events... You could implement your own sky renderer but it will break with any mod that does the same(although something like this might be possible in the future, see #3665) I could be missing something though.

Okay, looking further into the slab issue:

Your blocks return the content of drop field when the getItemDropped is called. That field is assigned in a constructor. Your blocks are created in createBlocks method, and items are created in createItems method, respectively. Those methods are called in your... proxy for some reason like this: ModBlocks.createBlocks(); ModItems.createItems(); So every time your block is constructed it gets a reference of item that has not yet been initialized and thereforeafter is null. So your ores always return null when it comes to their drops(apart from that one that drops vanilla clay). Just determine the drop item right in that method, on the fly. Or assign that field later, when the item is not null. Blocks/items should not even be constructed by you like that. They should either be constructed straight in the field initializer or provided by forge's registred-objects-to-fields-injection(if that is available for you).

Well, 0 will pretty much disable the fog - and that is what you are seeing to be fair. I am not sure what causes the sky color issue, it might be something else as I do not experience it with your code.

I do not experience any issues with your implementation. What is ? It is supposed to be a float of [0-1] range (0 - no fog, 1 - pretty much only fog is visible, you can barely see the world)

Post your new code

If it is storing them as int values do not forget to cast them to floats/doubles before you divide by them otherwise java will perform an int/int division that has no decimal part and will get auto-rounded to 0(or 1, if the variable is 255)

cancaled? That would not even compile. You do not need to cancel FogColors event. Only FogDensity. What is Constants.fogColor ? Why are you dividing 255 by it's variables? rgb are float ranges[0-1], and unless Constants.fogColor contains floats/doubles that are greater than 255 it is not going to work and is going to set the color to either white(if they are less than 255) or black(if getRed/green/blue returns not a float/double and is greater than 255)

FogDensity/FogColors events work just fine for me. How exactly have you tried using them?

You DO have an instance of BlockDoor at net.minecraft.init.Blocks, You in fact have 6 of them there. Blocks are singletons. But that will obviously only work with vanilla doors and only if you hard-code them. If you want your method to work with any door that uses an inplementation of ItemDoor to be placed you would need to use reflection to access the block field of ItemDoor

Unfortunately that's the way it is. You can't reliably prohibit your item from going into the offhand slot(apart from ugly sollutions like dropping them if they are in that slot) so you have to handle it somehow. Unless all your items have their item-unique custom transform creating correct transforms for the offhand is just going to be figuring it out for one item and copy-pasting it to others. Even if each item is unique there has to be some kind of pattern for their transformation you can use. In any case you should do this. Imagine a mod adding a mannequin. That mannequin is it's own entity with it's own slots. It indeed can have items in the offhand slot. A user puts your item in there and... yeah. You know what is even worse? The name of that mod is Minecraft and the name of that item is Armor stand.

Item::isValidArmor is only fired for armor, hence the name. I do not see a not-ugly/hacky way to make the item invalid for offhand slot - it is initialized as a regular Slot without additional checks and swap hotkey has no hooks at all. Even if you cancel the keybind and handle the slot click some mods that have that slot in their own container will allow the item to go in regardless as you can't reliably handle that. Why are you trying to prohibit the use of the offhand slot fot your item to begin with? There is nothing special about that slot unless you explicitly handle your item being in that exact slot. Most methods that do something with the item do have an EnumHand parameter that will allow you to check if the item is not in that slot.

Here is a tutorial. It is a bit outdated but should work for the most part. Apart from that forge itself contains an example. Or you can see the example for JEI - mod, factory and gui

You need to register an IItemColor implementation using ItemColors::registerItemColorHandler. You can obtain an instance of ItemColors with Minecraft::getItemColors

I am afraid those are hard-coded at Entity::doWaterSplashEffect thus there is not much that can be done.

Define 'custom dimensions'. If you just want to scale your model use GlStateManager::scale. If you want the rendered block to be 3d - it already is, guis just disable lighting when rendering items so it looks flat. You can render a block/item model using RenderItem::renderItem. Use the overloaded method that suits your needs.

Just render your fluid texture using Tessellator in your event handler, then cancel the event. You can do this the same way vanilla does it in ItemRenderer::renderWaterOverlayTexture, just bind your overlay texture instead of the water one

I think I might have found what you are looking for. RenderBlockOverlayEvent is a cancelable event that renders a texture of a block the player is currently in. It also catches water overlay if the player is in water and fire overlay when player is on fire.

Well, I've tried to replicate your issue but even with something as ridiculous as this I couldn't get my game to crash. Granted, I've used a more recent version of forge for 1.8.9... Anyway, you could try and check if the chunk you are generating in exists, and the chunks that are triggered by your offsets exist before firing any generation. (IChunkProvider::chunkExists). Do not forget that that method takes chunk coordinates as it's arguments, not block coordinates